Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Nolan

Pages: 1 2 3 4 [5] 6 7 8 9 10
61
z/OS Server / Re: CMoD Administration Roles
« on: January 19, 2018, 10:06:13 AM »
Welcome to CMOD!

Here are a few more items,
1. TSO/ISPF maybe implied with COBOL but strong TSO/ISPF skills are good.
2. JCL/PROC coding.  Lots of batch on Z/OS
3. We use lots of REXX scripts to automate processes, very helpful.
4. Exits are more than just COBOL, we have Assembler and C exits. 
5. AFP knowledge is good.  Not in-depth but we get lots of issues to troubleshoot around AFP.
6. PDF documents are also fun!  PDF indexing needs to run on a distributed platform now so Windows/Linux server skills also come in handy.  (We have a C exit on the Windows server for PDF loads)


Cheers

62
z/OS Server / Re: Contents of data in the CMOD.MIGR.BANNER.INPUT file
« on: January 12, 2018, 12:50:26 PM »
Here is a link to the manual to give you the details.

https://www.ibm.com/support/knowledgecenter/SSQHWE_9.5.0/com.ibm.ondemand.odf.doc/doddf400.htm
 
The samples in SARSINST are not to hard to read and modify.   The problem I had was trying to connect to DB/2 given the exit is now on the OMVS filesystem and not the loadlib.  If you figure that out, please share :)

63
z/OS Server / Re: Folder hit limit in case of multiple AG
« on: January 11, 2018, 07:39:54 AM »
Is this not just having the user adjust the date value to the current date?  When you say only Old Documents are visible that implies the date range can be adjusted.
You could adjust the default date range to only current day if you don't want the users to get older documents unless requested.


64
MP Server / Re: Alternative delete methods
« on: January 08, 2018, 10:12:37 AM »
Lars, perhaps you need to adjust your settings for it to unload jack :)

From the document shared by Ed/Justin.

To help you control how often Content Manager OnDemand reloads a load, include the -D flag when you run the arsmaint
and arsadmin unload commands as part of your expiration process. The -D flag indicates that Content Manager OnDemand should reload a load when
the number of documents with a hold in an application group changes by a specified percentage from the previous time the application group was
loaded.
When Content Manager OnDemand needs to reload an application group, it does the following tasks:

a. Extracts all the documents that have holds applied and their related index data.
b. Loads all the held documents and their related index data into a new load.
c. Deletes the original load (all files from cache and the index data from the OnDemand databases).

65
MP Server / Re: Alternative delete methods
« on: January 03, 2018, 09:51:25 AM »
That is along the lines of what I was thinking.  Now to get IBM to build it  :D


66
MP Server / Re: Alternative delete methods
« on: January 03, 2018, 08:22:34 AM »
Agreed, the compression and bundling does create a serious challenge to this problem/solution.  I think a hybrid solution which "might" appease the auditors would be to make it impossible to recreate a deleted record in the table after the lazy delete has been issued.  Using a key GUID to validate all the indexed rows, then when a "lazy" delete is done rebuild all the remaining keys so going back is impossible. 




68
MP Server / Re: Alternative delete methods
« on: January 02, 2018, 04:39:11 PM »
I don't believe - Enhanced Retention Management is a solution to the real world problem.  Enhanced Retention Management, is good for situations where you need a legal hold on a few documents where 90% or more of the documents in the load will follow the regular delete cycle.   I think IBM needs to try again and create a supported solution to delete a document out of the repository without unloading/reloading and tie into a Records Management system.

Note that  Enhanced Retention Management is only the OnDemand side, you still need to write/build/customize integration to manage the hold on the documents or worse, leave it up to the users!


69
Report Indexing / Re: Exit not found
« on: January 02, 2018, 04:21:25 PM »
I am not sure but things to check.

1. You cycled CMOD server
2. Permissions on /exits folder and on indexexnf
3. Are you loading via command line or a daemon?  Cycle the daemon as well
4. You are running the arsload on the same server?




70
Report Indexing / Re: Exit not found
« on: December 30, 2017, 03:52:03 PM »
It can’t be the the same as the IBM exits folder.  That was a hidden gem not mentioned by IBM!!!

71
Report Indexing / Re: Exit not found
« on: December 29, 2017, 08:54:36 AM »
I have to ask.   Did you cycle CMOD after updating the cfg file. 
😀

I would also try a path other than tmp.   I used.  ../v9.5/bin/userexits/

72
Report Indexing / Re: Exit not found
« on: December 29, 2017, 07:31:57 AM »
Do you have the same path in your ars.cfg file with the user exit setting.
All user exits need to be the path specified in the user path.  It can not be the default path.  Found that out the hard way 😩


73
z/OS Server / Re: Unable to index JES2 Spool files using ARSYSPIN
« on: December 21, 2017, 08:53:29 AM »
On the Load Information tab you need to have PAGE_NUMBER in both of the Load Id Names for index3 and index4 for it to work...don't leave it blank or you will continue to get the missing index error message.

We have
INDEX3='PAGE_NO',FIELD1,(TYPE=GROUPRANGE)

AG Name              Load ID Name
PAGE_NO             PAGE_NO
PAGE_NO_END    PAGE_NO

Try that and let us know

74
z/OS Server / Re: Unable to index JES2 Spool files using ARSYSPIN
« on: December 19, 2017, 06:10:36 AM »
This looks like your first problem.

ARS1130E 22 fields submitted by the indexer, 23 expected                       

You need to give a default value if have 23 items in the AG.  Put a blank or 0 depending on the field type.

75
Interesting, one of our servers also was caught using an old outdated ODLineDataViewer2 servlet.   We were running V8.5.0.9 on the web server we still can not figure out how it broke on Oct 31st for most of our users.  We can only guess that the JAVA cache was cycled or emptied and caused the applet to be pulled from the server again...but it is only a theory.

We have since patched up to V9.5.0.10 and all is well.


 

Pages: 1 2 3 4 [5] 6 7 8 9 10