Author Topic: Recent migration from CMOD 2.1 ?  (Read 7272 times)

LWagner

  • Guest
Recent migration from CMOD 2.1 ?
« on: May 28, 2008, 10:10:34 AM »
We still need to migrate from CMOD 2.1 on Z/OS.  We are getting prepped to do this, which inclues freeing DASD, and purchasing additional DASD, though not a whole lot.

Can anyone who has done a migration provide me an estimate of DASD growth/usage in the course of a migration from CMOD 2.1 to CMOD 8.3 ? We intend to migrate only indices, and have new data in the CMOD 8.3 storage sets

Our DASD retention periods vary from 1 day to 24 months.  Online DASD of data and indices move slightly between 180-195 2.95 GB volumes, for both the OAM data and the CMOD 2.1 tables.  About 45 volumes for the OnDemand tables and indices, 140-150 volumes for the non-expired online data. 

Larry Wagner
City of Los Angeles
Dept of Water & Power

geoffwilde

  • Administrator
  • Sr. Member
  • *****
  • Posts: 253
  • z/os erm icn
    • View Profile
Re: Recent migration from CMOD 2.1 ?
« Reply #1 on: May 28, 2008, 01:41:18 PM »
Compression will vary on type of data; either line, AFP, or PDF. Can you shed more light on the data type?
President, OnDemand Users Group
Lead Technician for Content Manager OnDemand @
US Bank
#zSeries

LWagner

  • Guest
Re: Recent migration from CMOD 2.1 ?
« Reply #2 on: June 18, 2008, 01:32:24 PM »
Our customer Bills are in AFP, plus a few other paged reports. Everything else is line data. 

Moving from CMOD 2.1 to 8.1, the question is really regarding a reduction in index space.  We're not moving data, only indices, definitions, and the CMOD metadata.

flemingr

  • Guest
Re: Recent migration from CMOD 2.1 ?
« Reply #3 on: June 20, 2008, 11:12:09 AM »
Hi, we're also starting our migration from CMOD v2.1 to CMOD v8.4. We will migrating the metatdata and the indexes but not the actual report data (we will not be running compatibility mode).
We run ODF but ODF v7.1 had many problems that prevented us from continuing with v7.1. So we hope ODF v8.4 is better (we use lots of Xerox reports with DJDE info).
We hope to capture reports in both v2.1 and v8.4 until users accept their v8.4 reports.
Any insights would be helpful.
-- Roger Fleming, Boeing, Seattle

leodejong

  • Jr. Member
  • **
  • Posts: 24
    • View Profile
Re: Recent migration from CMOD 2.1 ?
« Reply #4 on: July 11, 2008, 03:02:30 AM »
Hi, we have just finished the migration of the indexes in combination with double archiving just like you are planning but we don't use ODF.
A few tips
- Take a good look at the migration job. Use the option MIGR-BY=RUNDATE. Because using the other option will inhibit dual archiving.
- Change the FTP step to a TSO OCOPY command. No hassle with passwords.
- Realise that you might have to run different ARSLOAD jobs for every version of the V2 ACT and specify the corresponding AG on the job. That is not very clear from the Mig guide.
- ARSLOAD as used with loading the migrated index entries can only handle USS file smaller then 2Gb. That is a PITA because 1) the message  is not very clear (file not found) 2) you have to rerun ARSZIMIG with a smaller date range (see next point) and it can be a trial and error exercise to get it right. Later i wrote a program which splits the OS dataset in 2Gb parts at the right record.
- Program ARSZIMIG inserts rows in the ARSOD table, thats why it is so slow. That can be a problem If you ever have to rerun ARZIMIG.
- Be very careful with updating or adding V2 report definitions during the migration period. Keep the definitions in sync. Note there is a ARSMDT table which maps V2 definitions to V7 definitions. It is not documented where this table is used, but i kept in sync with the actual definitions.
- Make some queries to count the number index entries in V2 and V7 to check the progress en result of the migration process.
- We have about 1400 report definition. So i made a set of tools with rexx and ISPF to automate the migration process  and check the progress. If you do have such numbers invest in such tooling.
Hope this help a bit.
leo de Jong, rabobank, netherlands
Leo de Jong, Rabobank,The Netherlands

LWagner

  • Guest
Re: Recent migration from CMOD 2.1 ?
« Reply #5 on: November 04, 2008, 10:48:45 AM »
I just completed one of my REXX tools to autogen my ARSLOAD test jobs.  We have too much variety in our headers and date usage, which the migration tools do not handle correctly, so they are trying to update it for us.  So I get to re-run load jobs with changing application group names. One or more times a week.

This will now be easy.  We had way too many errors in folders and indexing, and dates it could not convert to an index, causing ARSLOAD to be unable to load the report.

LWagner

  • Guest
Re: Recent migration from CMOD 2.1 ?
« Reply #6 on: July 01, 2009, 07:51:25 AM »
I tried some estimates from large report indexes.  Index Migration space requirements for CMOD 7.1/8.4 look to be approximately double that of CMOD 2.1.  It turned out we did not have the DASD to make a copy, and migrate as well.  And with our CPU, my migration will take about 5 months.

Another issue we had is that IBM's configuration guide did not provide adequate guidance to bypass TCP/IP usage in the S4 load step.  It turned out to not be possible with their ARSLOADZ proc.  I did finally get ARSLOAD working so it bypassed TCP/IP buffering back to ARSSOCKD, so the CPU cycles used drop by a factor of 200 !

Also to run in "super migration mode", you must add the Z/OS owning userid to the CMOD database user table, with the password matching the id.

And be sure you discover the PROC ARSZOSHL, and use that when you want to run a long UNIX statement in JCL batch. You can provide it environment variables which fill out to up to 256 characters total. Far more than the 80 or 100 byte limit as a PARM.

I re-gened my migration extract jobs so that the ARSLOAD jobs had the better code below. I also added this comment section, since each load job neede columns 73-80 blasnked out:

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* REMOVE NUMBERS IN COLS 73-80 FOR INSTREAM DATA, ELSE RC=1, S4 FAILS
//*     -  OPEN IN EDIT MODE, USE UNNUM COMMAND  (un-number)           
//*     -  be sure ownership access settings on /ars/cache1 are 777     
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Section S4:
-----------
//* S4 will fail if numbering present in cols 73-80 of IKJEFT01 input   
//*                                                                     
//S4       EXEC PGM=IKJEFT01,REGION=0M,COND=(0,NE)                     
//STEPLIB  DD DISP=SHR,DSN=SYS2.OD710.USERLOAD                         
//         DD DISP=SHR,DSN=SYS2.OD710.SARSLOAD                         
//         DD DISP=SHR,DSN=$DB1.DSNEXIT                                 
//         DD DISP=SHR,DSN=$DB1.DSNLOAD                                 
//SYSEXEC  DD DISP=SHR,DSN=SMPE.OD710.USERPROC                         
//SYSTSPRT DD SYSOUT=*,RECFM=FA,LRECL=133                               
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* REMOVE NUMBERS IN COLS 73-80 FOR INSTREAM DATA, ELSE RC=1, S4 FAILS
//*        OPEN IN EDIT MODE, USE UNNUM COMMAND                         
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//SYSTSIN  DD *                                                         
ARSZOSHL /usr/lpp/ars/bin/arsload $LS -a $APP -g $AG -c /ars1 $HFSF     
//STDENV   DD *                                                         
_BPX_SHAREAS=YES
_BPX_BATCH_SPAWN=YES                                                 
LS=-X G -f -h ARSDBASE -u ARSSERVR -p ARSSERVR -Y                   
AG=ag_name                                                           
APP=app_name                                                         
HFSF=hfs_ix_file_no_type                                             
/*                                                                   
//OSHOUT1      DD   DSN=&&ARSLOAD,DISP=(,PASS),                     
//             UNIT=SYSDA,SPACE=(TRK,(5,5),RLSE),                   
//             RECFM=FA,LRECL=133,BLKSIZE=0                         
//DSNAOINI     DD   PATH='/usr/lpp/ars/config/cli.ini'               
//SYSOUT       DD   SYSOUT=*,RECFM=FA,LRECL=133,BLKSIZE=0           
//*SYSPRINT    DD   DSN=&&ARSLOAD,DISP=(,PASS),                     
//*            UNIT=SYSDA,SPACE=(TRK,(5,5),RLSE)                     
//CEEDUMP      DD   SYSOUT=Z                                         
//*                                                                 
//* If S4 fails, check for numbering in 73-80 in IKJEFT01 input above
//*                                           
--------
and the step immediately following:
//ARSLOAD  EXEC PGM=IEBGENER,COND=(0,NE)   
//SYSPRINT DD DUMMY                       
//SYSUT1   DD DSN=&&ARSLOAD,DISP=(OLD,PASS)
//SYSUT2   DD SYSOUT=*,LRECL=133,RECFM=FA 
//SYSIN    DD DUMMY                       
//*                                           
---------
and I changed all SYSOUT or SYSTSPRT DD statements to   =*,LRECL=133,RECFM=FA