Messages

61

z/OS Server / Re: 'export' of all data from one OD-instance to another

« on: November 02, 2017, 10:30:02 AM »

With ARSADMIN RETRIEVE you will get the object from OAM as a file.
For example you've loaded a document with load-id of 1122-93-0-8FAA-20171102113800-20171102113800-5571
If you issue ARSADMIN Retrieve -g apgroup -h instance -m 2 -n 93-0 8FAAA 8FAA1 -d /u/temp   (not the exact syntax)
You will get two files in /u/temp named 8FAAA and 8FAA1
Now if you issue:
ARSADMIN store -g newapgroup -h newinstance -m 2 -n<new primary - secondary storage> 8FAAA 8FAA1
  (Run this command from /u/temp or direct the input using -d )
This will store the document in OAM for the new OD instance in the primary storage set for that application group.
You then need to move the index data from the old instance to the new.  We used a form of DB2 unload -> DB2 load with modifications.
A few things to note for this method.  You should be extremely comfortable working with DB2 as it requires a fair amount of manipulation of tables and values.  You should also need to be comfortable with the inner workings of CMOD, how various tables, objects, settings.... are referenced/used and you have to account for resources if you are using them.
The Pro's we found using this method is it's quick, Most the of work can be scripted, Requires little or no actual down time, avoids the complications of moving AFP docs, and when done correctly preserves original expiration dates.
Con:   Can be complicated and requires good advance planning, potential for really messing things up, and requires thorough verification
 If you aren't pressed for time and expiration doesn't matter I'm sure an XML import/export to mirror the AGs and APs then some sort of straight up Doc get and Reload would be the easiest.

62

z/OS Server / Re: 'export' of all data from one OD-instance to another

« on: October 31, 2017, 08:09:31 AM »

We've completed 3 migrations from one OD instance to another.  Two were from Windows to z/OS and one was from AIX to z/OS, the most recent about 2 years ago going from an 8.4 Windows to an 9.5 z/OS server. 1,400 AGs and 1TB+ of data Going from CMOD to CMOD was much nicer than our other migrations from other products.  We did not use IBM services for this last migration.
XML export and XML import to move AGs , Apps, users etc... generally worked well though we ran into some issues with XML export from the 8.4 server.
We planned on using ARSADMIN retrieve and ARSADMIN store to move the data however we were able to copy the 1TB of data in the source OD (stored in cache) to a temp location and just ran ARSADMIN stores against those copies.  Total time to move the data was approximately 2 weeks with most of the migrations run during business hours.  The whole project took about 2 months planning and another 1 month to move production.
I would think going from OAM to OAM could make things quicker.

We haven't had the chance to try two OAMs yet.

63

MP Server / Re: ARSDOC UPDATE

« on: October 31, 2017, 05:59:53 AM »

Just to note.  Anytime I've ever received the message "Information has been modified on the server. Please logoff, logon, and retry the operation."   The issue has been traced to a DB error.  Either someone changed something manually or some system table data got corrupted.

64

z/OS Server / Re: ARSLOAD Problem with Documents greater than 100 MB

« on: October 27, 2017, 06:08:40 AM »

They definately seems low.   Ours is currently:
core file         8192b
cpu time          unlimited
data size         unlimited
file size         unlimited
stack size        unlimited
file descriptors  64000
address space     1011240k
memory above bar  2048m

65

z/OS Server / Re: ARSLOAD Problem with Documents greater than 100 MB

« on: October 26, 2017, 07:31:21 AM »

Get your limits from OMVS.  Run the command ulimit -a from the command line or from batch and show us the output

66

z/OS Server / Re: ARSLOAD Problem with Documents greater than 100 MB

« on: October 25, 2017, 07:03:32 AM »

Are you using OAM for your storage manager?  You may be hitting the 50MB limit for OAM if you haven't increased the ability to load larger files through IEFSSNxx

67

Report Indexing / Re: ACIF Indexer and Posting Date

« on: October 24, 2017, 11:34:18 AM »

Glad you got it working.   Sorry I couldn't have been more help.

68

Report Indexing / Re: ACIF Indexer and Posting Date

« on: October 23, 2017, 05:30:55 AM »

Odd.  If it was an issue with the triggers you would be getting an error message, in fact it appears you are successfully indexing the report:
arsload: 10/23/17 07:44:15 Indexing completed

Something is happening during the load.  It clearly identifies the input file, starts the load, then fails to complete.  Look for error messages elsewhere.  If you're on z/OS look in the SDSF log for SMS, OAM, DB2, or security error messages at the same time of the attempted load.

69

Report Indexing / Re: ACIF Indexer and Posting Date

« on: October 17, 2017, 12:24:12 PM »

Yes, it's tough without meaningful 88 error messages.  Usually I can find an error somewhere when using ACIF either in the log or sometimes intermixed with the indexing echoing.  I can say for sure that you can pull the date from one page, we do it often here.

70

Report Indexing / Re: ACIF Indexer and Posting Date

« on: October 17, 2017, 08:30:26 AM »

Based on the sample you listed before try this for the trigger:
TRIGGER3=1,19,X'C481A3857A',(TYPE=GROUP)                         /* Date:          */

I think your issue might be you had * for record but type group instead of float.

71

General / Re: How to Daemon from deleting pdf

« on: October 17, 2017, 07:18:13 AM »

Doing what you are attempting would have unfortunate consequences.  Your loader would load the PDFs over and over with no end until you killed the daemon.  Makes sense it wouldn't allow the -n parameter in a daemon.

72

Report Indexing / Re: ACIF Indexer and Posting Date

« on: October 17, 2017, 07:14:29 AM »

Yes, Something like that.  It doesn't have to be the '/' though that should work as long as there is no / in that same column on later pages.  You could be more specific and use 'Date:'   Either way it should do what you're asking.

73

Report Indexing / Re: ACIF Indexer and Posting Date

« on: October 17, 2017, 06:01:07 AM »

There shouldn't be a problem using ACIF on data that doesn't have a date on every page you just have to get a little more creative in your indexing.  At the most basic you can put another trigger (or mask) in that lets the indexer know if there is a date there or not, for example trigger on '/' in mm/dd/yyyy.  Index the date off that trigger.  If no date exists ACIF won't complain.

74

MP Server / Re: Folder view what specific key or index value, but it displays the whole report

« on: August 17, 2017, 06:33:20 AM »

If the number of records in each page is identical you could use the LINECNT parm to force a page break. Other than that we've used an input exit to insert page breaks as needed.

75

z/OS Server / Re: z/OS 2.3 - OAM Line Item of Interest for CMOD

« on: July 20, 2017, 08:04:37 AM »

Well this one makes me happy.   Good news.