z/OS - Group home

Author:  @Shigeki_Kimura270002UD7W​

As the first release of z/OS V2, z/OS V2R1 was generally available in September 2013. In 2014, many customers have successfully completed the migration to z/OS V2R1.  I would like to share with you the “Lessons Learned” and “Hints and Tips” from the experience of migration projects to help prepare your migration to z/OS V2R1 from V1R12 and V1R13.  Of course, it's also applicable to the migration path from V1R13 to V2R2.

Part 1

Here are handouts from my sessions in "SHARE in Pittsburgh, Summer 2014".  It contains the changes of behavior introduced in z/OS V1R13 and incorporated into z/OS V2R1, and also the changes introduced by services (PTFs and SPEs) in z/OS V2R1, especially in the area of BCP, JES2, DFSMS, SDSF, ISPF, TCP/IP, and HLASM.

16186:  z/OS 2.1 from 1.12 Migration Part 1 of 2
16187:  z/OS 2.1 from 1.12 Migration Part 2 of 2

Part 2

Additional items to consider to migrate to z/OS V2R1 and V2R2.  They are related to BCP, JES2 and other components.

1. Blocksize of SYSPRINT data set generated by AMBLIST
Before the APAR OA46441 for z/OS V2R1 and V1R13, AMBLIST utility program by default uses a blocksize equal to the record length, when producing a new SYSPRINT output to a sequential dasd data set, and either a block size is not specified or a blocksize of 0 (zero) is specified.  After the APAR OA46441, AMBLIST now respects the use of SDB (Syetem Determined Blocksize) for a new SYSPRINT dasd data set.

So, please do not rely on current behavior expecting the new SYSPRINT dasd data set to have blocksize 121.  If BLKSIZE=121 is to be assigned to the data set, you need to specify it explicitly in the SYSPRINT DD statement.  Also, when your program later opens the SYSPRINT data set generated by SDB for any purpose with DCB RECFM=FA or RECFM=FA,LRECL=121 parameters, it will be abended with message IEC141I 013-60.  The solution in this case, for example, is to remove the RECFM/LRECL parameter from the DCB macro or update the RECFM to FBA.

2. HASP110 JCL ERROR by invalid NOTIFY= parameter
If the default options in JES2PARM, DESTDEF UDEST=SPLOCAL and LOCALNUM=32767, are both in effect, then values from U1 to U32767 are special to JES2 while anything above U32767 will be treated as TSO/E userid.  Please note that the leading zeros are removed.  For example, U030000 is treated as U30000 which is special to JES2 by default.

When migrating to z/OS V2R1, you need to ensure that the TSO/E userid is not considered as JES2 special and reserved destination.  Because of a release update in z/OS V2R1 and also by JES2 APAR OA46199, JCL ERROR might be resulted with an invalid NOTIFY parameter on JCL JOB statement when the TSO/E userid is special to JES2.

(Examples)   Note: JES2PARM JOBDEF JCLERR=YES|NO option was removed in z/OS V2R1

Behavior when you specify NOTIFY=U0011:

Behavior when you (TSO/E user U0011) specify NOTIFY=&SYSUID:

In the above scenario, if you need to use the U0011 as TSO/E userid and also avoid JCL ERROR, you can change the JES2PARM DESTDEF statement to specify the UDEST=USER parameter.  Please note that this change requires an all member warmstart.  This setting will ensure that destination of U0011 is not reserved to JES2 and will be treated as a valid TSO/E userid.  Another option to avoid the JCL ERROR in z/OS V2R1 is to remove the NOTIFY parameter.  Even before z/OS V2R1, the notify message $HASP165 was not actually issued in above scenarios.

Note:
UDEST=USER causes all the Unnnn destinations to be treated as TSO/E userids.  If there is no reference to Unnnn as a special routing code in your JES2PARM (specifically as ROUTECDE= on a PRTnnn or as part of a DEST= on a DESTID statement that points to the local node), then changing UDEST to USER from SPLOCAL (default value) should be safe.  Otherwise, you have to find the highest Unnnn being used.  For example, if your highest Unnnn routing code is 2000, then set LOCALNUM=2000 and UDEST=SPLOCAL in JES2PARM DESTDEF statement.  It causes anything higher than U2000 be TSO/E userids, while the destination from U1 to U2000 be reserved to JES2.

3. PSF and CBLOC VIRTUAL31(IHAASVT) in DIAGxx parmlib member
Beginning in z/OS V2R1, you can specify a DIAGxx parmlib member that contains a CBLOC statement that allows the IHAASVT control block to be located in 31 bit storage by CBLOC VIRTUAL31(IHAASVT).  However, PSF requires the IHAASVT control block to be below the line.  When it was moved above the line, an ABEND0C4 may occur when starting a channel attached printer.  PSF APAR OA45775 for V4R4 and V4R5 documented the restriction that IHAASVT control block must be located below the line, so you must not use the CBLOC VIRTUAL31 statement in the DIAGxx parmlib member to move IHAASVT above the line.

Part 3

Additional items to consider to migrate to z/OS V2R1 and V2R2.  They are related to DFSMSdfp and DFSMSdss.

1. LBI (Large Block Interface) support with IDCAMS REPRO command
Beginning in z/OS V2R1, IDCAMS REPRO command was enhanced to support LBI to perform on data sets with a blocksize larger than 32K.  This change makes the system sensitive to incorrect DCB parameters coded in the JCL.  For a 3390 device, there is a limit below 32K for a blocksize.

In prior to z/OS V2R1, IDCAMS program could not pass a large blocksize, which is over 32K, to OPEN via the DCB so it was ignored and OPEN processing was forced to obtain the blocksize from the data set's VTOC entry.  Beginning in z/OS V2R1, a DCBE is used so larger blocksize, which is over 32K, can be passed to OPEN processing.  It is then verified by OPEN and the REPRO processing is terminated by CC12 with IEC141I 013-68 error message.  The DCB blocksize value specified in the IDCAMS REPRO JCL should be reviewed to ensure it is valid for DASD devices or set to zero.

2. Syntax of DATASET keyword in IDCAMS ALLOCATE command
Beginning in APAR OA42679 (PTF is applicable to z/OS V2R1, V1R13, and V1R12), IDCAMS changed the way it invoked TSO/E to issue an IDCAMS ALLOCATE command.  IDCAMS now uses the TSO/E Service Facility (TSF) to invoke ALLOCATE, rather than running ALLOCATE under the TSO/E TMP (Terminal Monitor Program) IKJEFT01.

In this new environment, the default prefix used is the userid.  So now, with IDCAMS APAR OA42679 applied, you must specify the data set name explicitly with quotes in ALLOCATE command so that the default prefix is not appended to the data set name as a high level qualifier.
If you have a RACF TSO segment, there is no change in behavior.  So, the key difference is that running an IDCAMS ALLOCATE the old way with a RACF defined user with no TSO segment would have resulted in a null prefix, whereas the new way defaults to the prefix equal to the userid.  DOC APAR OA47508 is being written for this change.

Note:
When the quotations are not specified within the DATASET parameter in IDCAMS ALLOCATE command, and if you do not have a RACF TSO segment, the following message is missing after APAR OA42679 and an userid as a prefix is added.
IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED

3. Replacing the existing catalog by DFSMSdss logical RESTORE command
In releases prior to z/OS V2R1, catalog recovery jobs should be modified to include the IDCAMS ALTER LOCK command to lock the existing catalog before the DFSMSdss restore operation.  After the recovery is complete, you need to unlock the catalog using IDCAMS ALTER UNLOCK command.
If you never implemented this recommendation, replacing the existing catalog will fail with error message ADR439E once migrating to releases z/OS V2R1 and later.
ADR439E (001)-TDVSM(04), A PREALLOCATED DATA SET WAS FOUND FOR DATA SET UCAT.XXXX BUT WAS UNUSABLE, 144

Beginning in z/OS V2R1, existing catalog must be locked or suspended prior to invoking DFSMSdss logical RESTORE operation.  For this purpose, you can specify the BCSRECOVER(LOCK|SUSPEND) new keyword in the RESTORE command, for example.  As part of BCSRECOVER processing, DFSMSdss automatically unlocks and resumes the catalog to reestablish normal ICF catalog access.  The BCSRECOVER parameter applies to both RLS and non-RLS catalogs.

- BCSRECOVER(LOCK) will invoke a sysplex wide close of the catalog and lock the catalog (failing new unaurthorized requests), if the catalog is not already locked or suspended
- BCSRECOVER(SUSPEND) will invoke a sysplex wide close of the catalog and suspend new unauthorized requests in the client space, if the catalog is not already locked or suspended

Note:
When BCSRECOVER parameter is to be specified, you require READ access to the RACF FACILTY CLASS profile IGG.CATLOCK.  If no FACILITY class profile IGG.CATLOCK is defined, or you have no READ authority to that profile, the RESTORE operation is failed with error message ADR497E.
ADR497E (001)-CATLG(05), A CATALOG ERROR OCCURRED WHILE ALTERING ACCESS TO USER CATALOG UCAT.XXXX. RETURN CODE IS 186, REASON CODE IS FT-002