Author: @Shigeki_Kimura270002UD7W
Recommendation: When you migrate to z/OS V2R2 from V1R13, you might also want to read the following blog.
Some useful advice on z/OS V2R1 migration - From Professor Kimura
https://www.ibm.com/developerworks/community/blogs/e0c474f8-3aad-4f01-8bca-f2c12b576ac9/entry/Some_useful_advice_on_z_OS_V2R1_migration_From_Professor_Kimura?lang=en
New message during NIP for IPL device information
After NIP initialization, when commands are available (see message IEE389I MVS COMMAND PROCESSING AVAILABLE), you can issue the D U,IPLVOL command and D IPLINFO command to identify the IPL device information via message IEE457I and IEE254I.
Beginning in z/OS V2R2, a new message IOS128I showing the IPL device information is issued early in NIP.
IOS128I IPL DEVICE: sdddd VOLUME: vvvvvv
The message displays the IPL device early in the IPL, thus allowing for earlier problem detection if the IPL device was incorrect.
Note: The console display of message IOS128I (like message IEA091I) is controlled by the IMSI character specified in the 7th position of LOADPARM. The message is suppressed with a "blank" while displayed with an "A" and "M".
Enhancement for DISPLAY UNIT command
By APAR OA34502 with z/OS V1R13, V2R1, and V2R2, some variations of the DISPLAY U (D U) command output now generate display message IEE457I with new column SS that will identify the associated device's Subchannel Set ID. Variations in output message formatting when using the OFFLINE or ALLOC device state options prevent their output from showing a Subchannel Set ID.
Also, the D U command now accepts 5-digit device numbers except for use with the ALLOC parameter. D U,,ALLOC,nnnnn command is not supported and will fail with IEE453I UNIT STATUS INVALID OPERAND RE-ENTER.
Base output (i.e not requesting a 5-digit display) simply has the additional SS column on the right side of the message IEE457I output. So long as you request a 4-digit display, the UNIT column in the response message IEE457I continues to show a 4-digit device number. Since it does not change the base layout of the message data, it should not affect those automating on this message data. However, you might be advised to check the message automation scenario before applying this APAR/PTF to ensure that no updates are required.
Note: Message IEE457I displays null values in SS column for both D U,IPLVOL and D U VOL= command as is described in the FIN APAR OA49562.
Exploitation of new IEAVTABX_EXIT by Fault Analyzer
Prior to z/OS V2R2, Fault Analyzer (FA) required a dump capture exit, IDIXDCAP, to be installed in the IEAVTABX installation exit list. This exit is installed by the IDITABX USERMOD. Normally, the IEAVTABX exit process is only called by MVS if the job step has allocated a SYSMDUMP, SYSUDUMP, or SYSABEND DDname. However, the FA IDITABD USERMOD permits the IEAVTABX-defined exits, including IDIXDCAP, to be invoked regardless of any JCL dump DD statement specification.
For z/OS V2R2, with the support incorporated via OA48457, a new dynamic EXIT called IEAVTABX_EXIT receives control for all ABDUMP dump requests. Its interface is exactly like the existing IEAVTABX interface, but the difference is that the dynamic exits will always be called whether an ABDUMP will be taken or not, and whether or not an ABDUMP DD statement was specified in the job's JCL steps.
This new functionality was exploited by FA.
For z/OS V2R2, the Fault Analyzer dump capture exit, named IDIXDCAP, is installed as a IEAVTABX_EXIT dynamic exit routine by including the following statement in a PROGxx parmlib member (which can be automatically selected at IPL time):
EXIT ADD EXITNAME(IEAVTABX_EXIT) MODNAME(IDIXDCAP)
To activate the IDIXDCAP exit prior to the next IPL, issue the operator command: SET PROG=xx (xx matches the suffix used for the PROGxx parmlib member)
IDIXDCAP will therefore be invoked for all abends where RTM will drive ABDUMP processing, regardless of whether the job step has allocated a SYSMDUMP, SYSUDUMP, or SYSABEND DDname.
Note: Fault Analyzer USERMODs IDITABX and IDITABD are not applicable to z/OS V2R2 or later.
The following FA PTF should be installed to prevent an inappropriate IDI0095W message from being issued whenever IDIXDCAP is invoked via the dynamic exit interface: V13 APAR PI46839 (PTF UI31227), V12 APAR PI46838 (PTF UI31231), V11 APAR PI46837 (PTF UI31220)
Please see Chapter 16 "Customize Fault Analyzer by using USERMODs" of the latest FA V13 User's Guide & Reference (SC19-4116-10, December 2015) for information on these changes.
http://publibfp.dhe.ibm.com/epubs/pdf/idiugm10.pdf
Additional information with message $HASP395
Beginning in z/OS V2R2 JES2, "Job completion code" was added to the message "$HASP395 jobname ENDED" for the JOB, TSU, and STC. The additional information is RC=nnnn, ABEND=Sxxx, ABEND=Udddd. The information displayed in the HASP395 message is the return code as defined by the JOBRC keyword on the JOB statement and it's applicable even if the JOBRC=MAXRC (default) is in effect.
Examples from syslog in z/OS V2R2:
(JOB) $HASP395 BEANSZZ ENDED - RC=0000
(TSU) $HASP395 IBMUSER ENDED - ABEND=S522
(STC) $HASP395 IZUSVR1 ENDED - RC=2048
Increase of JES2 virtual storage allocation
The new functionality in z/OS V2R2 JES2 such as Job Execution Control (JEC), Checkpoint Extend and Alter processing, and Larger limits (JQEs, JOEs, BERTs) requires z22 checkpoint mode which is new in z/OS V2R2. To support new functionality, virtual storage requirement was increased in z/OS V2R2 JES2 regardless of z11 or z22 checkpoint mode.
Note: The default mode on JES2 cold start is controlled by the COLD_START_MODE on JES2PARM OPTSDEF statement which is z22 by default. The COLD_START_MODE value should be set to the checkpoint mode JES2 is expected to be running in so that an unplanned cold start does not result an unplanned activation. When you issue $ACTIVATE command to change the checkpoint mode, the message $HASP260 will include this recommendation if it finds the inconsistency.
JES2 31-bit virtual storage allocation was increased by about 200MB and the largest increase was observed in SP132 Key1 (CTENT: Checkpoint Table Entry) to support the increased limits for JQEs, JOEs, and BERTs. The virtual storage size will not change with z11 vs z22 mode. As for the JES2 64-bit virtual storage allocation, checkpoint I/O area (about 800MB) was moved in z/OS V2R2 to 64-bit storage location from 31-bit storage.
Tip: $JDDETAILS(STORAGE) command reports the JES2 31-bit virtual storage allocation size in your configuration. Also, beginning in z/OS V2R2, SDSF (DA, I, INIT, NS, ST) provides a new JM (Job Memory) panel which enables you to get the memory map for a specific address space, including the 64-bit virtual storage.
Additional information: Regarding the JM panel, the address spaces started by SUB=MSTR are not supported in z/OS V2R2 while supported in z/OS V2R3.
You need to check the REGION size of JES2 procedure to prevent an ABEND878 situation during JES2 initialization. Also, you need to check the maximum possible size of extended private storage in your system because the large ECSA allocation, for example, might not tolerate the increase of JES2 EPVT allocation in z/OS V2R2.
DDNAME information by LISTDS STATUS command
When you specify the STATUS option in TSO LISTDS command operation, the DDNAME information is displayed. In prior to z/OS V2R2, the DDNAME information was blank when a data set was the second or subsequent data set in a concatenation.
After DFSMS APAR OA47704 with z/OS V2R2, DDNAME information was changed to display for all the data sets in concatenation regardless of the position.
Before z/OS V2R2, you can tell that the data set is within the concatenation if the DDNAME information is blank. However, beginning in z/OS V2R2, this assumption does not work because the DDNAME information is always displayed in the concatenation.
New message for SMS resource name IGDCDSXS
SMS issues a RESERVE with the resource name, IGDCDSXS, to serialize the access to SMS control data sets, ACDS , COMMDS and SCDS, across multiple systems. To minimize delays due to contention for resources and prevent potential deadlocks, SMS resource name IGDCDSXS should be placed in the GRS RESERVE conversion RNL as a generic entry so that it can be converted to the global ENQ.
PARMLIB(GRSRNLxx): RNLDEF RNL(CON) TYPE(GENERIC) QNAME(IGDCDSXS)
Beginning in z/OS V2R2, SMS will issue a new informational message if IGDCDSXS is not specified in the GRS RESERVE conversion RNL for the system that is to participate in a global resource serialization complex.
IGD06041I SMS RESOURCE NAME IGDCDSXS IS NOT FOUND IN GRS RESERVE CONVERSION RNL. RETURN CODE retcode REASON CODE rsncode
Routing code: (2,10) & Descriptor code: (4,2)
This message is issued during IPL and the activation of a new SMS configuration, and the system continues processing.
If you receive this message after migrating to z/OS V2R2, you are recommended to define IGDCDSXS in the GRS RESERVE conversion RNL in GRSRNLxx parmlib member.
Note: If GRS=NONE (by base code) or GRSRNL=EXCLUDE (fixed by APAR OA48758) is specified, the message IGD06041I will not be issued.
Additional information: After z/OS V2R2 DFSMS APAR OA50221 and in z/OS V2R3, the IGD06041I message was enhanced to include the data set name for COMMDS, ACDS and SCDS.
Non-SMS managed PDS and PDSE multi-volume data set
PDS and PDSE data sets (i.e. DSORG=PO) are limited to one volume by definition regardless of JCL and Dynamic allocation. In case with SMS managed PDS and PDSE data set with multivolume definition (DC Volume Count > 1), the new allocation is not allowed by the following message.
IGD17293I DATA SET dsname HAS PARTITIONED ORGANIZATION AND IS NOT ELIGIBLE TO BE A MULTI-VOLUME DATA SET, ALLOCATION FAILED
However, in case with non-SMS managed PDS and PDSE data set, the new allocation with multi-volume definition is possible without error message. Of course, switching to a new volume is not possible (ABENDE37-04) and only a single-volume data set is allowed.
Beginning in z/OS V2R2, the new allocation of non-SMS managed PDS and PDSE multi-volume data set is not allowed by error message IGD17293I regardless of JCL and Dynamic allocation. FIN APAR OA45917 has been fixed in z/OS V2R2.
If you depend on a new JCL or Dynamic allocation of non-SMS managed PDS and PDSE multi-volume data set, you need to update the procedure to avoid such operation. In prior to z/OS V2R2, such data set could be created and usable so long as residing on only one volume.
Note: With ISPF OPT3.2 new allocation, even in prior to z/OS V2R2, you cannot allocate a new multi-volume PDS and PDSE data set with error message "Invalid combination" regardless of SMS-managed or non-SMS managed.
VSAM DBA (Dynamic Buffer Addition) for LSR pool
In z/OS V2R2, LSR buffering was enhanced with a function called VSAM Dynamic Buffer Addition (DBA). If the specified number of buffers is inadequate to process a request and DBA is allowed, VSAM will attempt to add additional data and index buffers dynamically to the resource pool to avoid the 'out of buffers' logical error (8), reason code 152 (X'98'). DBA is allowed for LSR only, for task mode requests and if DBA=NO was not specified on the BLDVRP macro.
Note: You need z/OS V2R2 DFSMS APAR OA48387 to specify DBA=NO on your BLDVRP macros to prevent VSAM from dynamically adding buffers to the LSR pool. DFSMS APAR OA48387 with z/OS V1R13 and V2R1 releases will allow the DBA parameter to be specified for BLDVRP's with TYPE=LSR without generating an error, but also without enabling any new functionality.
When dynamic buffer addition occurs, VSAM issues a new informational message IDA9990I (Routing code 11 & Descriptor code 6) indicating the number and size of buffers and the shared pool to which they were added, and the processing continues. Regular buffers are added by DBA, but Hiperspace buffers are not added.
IDA9990I VSAM DBA ADDED xxxx DATA | INDEX BUFFERS OF yyyyy BYTES EACH TO SHRPOOL zzz BECAUSE THERE WERE INSUFFICIENT BUFFERS TO PROCESS THE REQUEST. RECOMMENDATION: FOR BETTER PERFORMANCE, REBUILD THE SHARED POOL WITH AN INCREASE IN SIZE.
No action is required in response to the message IDA9990I, but for performance reasons you are encouraged to rebuild the shared pool with BLDVRP, specifying an increase in pool size. The searches in the LSR resource pool will not be as efficient after buffers are added by DBA, and performance may be degraded.
Note: FIELDS=BUFNOL operand in SHOWCB macro was introduced in z/OS V2R1 and it will return the current number of LSR buffers. It does not matter how or when the buffers were built, and it will return the current number in the pool.
If you run IMS V14 with z/OS V2R2, both DFSMS APAR OA48387 and IMS APAR PI45378 are required. OA48387 added a new optional parameter to the BLDVRP macro that disables DBA. IMS APAR PI45378 added code to invoke BLDVRP with the new parameter DBA=NO, when LSR pools are acquired, to ensure the buffers stay contiguous. If you run IMS V14 with APAR PI45378 at z/OS V2R1 with DFSMS APAR OA48387 applied, DBA=NO parameter will be ignored since the Dynamic Buffer Addition function is introduced in z/OS V2R2 and not available in z/OS V2R1.
Similarly, if you run IMS V13 with z/OS V2R2, both DFSMS APAR OA48387 and IMS APAR PI45377 are required.
Note: DFSMS service needs go on at the same time or before the IMS service, and the IMS service cannot go on without the DFSMS service.
Additional information: For CICS TS V5R1, V5R2, V5R3, and V5R4, APAR PI92486 has been taken to disable the VSAM Dynamic Buffer Addition for CICS LSRPOOLs. CICS File Control has been changed to specify DBA=NO on the BLDVRP macros issued to build LSRPOOLs to disable Dynamic Buffer Addition.
Additional information: After DFSMS APAR OA54666 for both z/OS V2R2 and V2R3, the calculations for the amount of buffers to be dynamically added has been changed to be no smaller than four and no larger than fifteen. Note: This will not affect users (like IMS) that specify at the time they build the LSR pool that they do not want to allow Dynamic Buffer Addition (DBA).
RACF RCVTVRMN field in RCVT control block
Historically, the field RCVTVRMN in RCVT (RACF Communication Vector Table) control block contains the last 4 characters of the RACF FMID. For example, it was "7790" in z/OS V2R1.
The FMID of RACF (Security Server) has been updated to HRF77A0 in z/OS V2R2, but starting in z/OS V2R2, "77A0" is not used in the RCVTVRMN field. Instead of "77A0", RACF will store "7791" in RCVTVRMN during initialization so that release comparisons will continue to work. Also, the ICHPRCVT mapping macro is updated with comments stating that the value of RCVTVRMN is frozen at "7791" starting with z/OS V2R2, and that MVS control blocks should be used to determine release level. These changes were incorporated into z/OS V2R2 via SAF APAR OA47957 and RACF APAR OA47956.
Note: RACF will continue to display the expected "HRF77A0" value in all messages and reports.
Inspect your application code to find references to RCVTVRMN and determine if a change is required, because RCVTVRMN no longer contains the last 4 characters of the RACF FMID.
Also, check the usage of SYSVAR('SYSLRACF') function in TSO/E REXX and &SYSLRACF variable in TSO/E CLIST. The value of both SYSLRACF and &SYSLRACF is equal to the value in RCVTVRMN and it no longer contains the last 4 characters of the RACF FMID.
Note: The changes were meant to preserve behavior of applications that were using RCVTVRMN inappropriately as a means to compare release levels, but any new such comparisons added to an application will not work anymore with RCVTVRMN, and should be using MVS control blocks instead.
Removal of redundant TSO commands from ISPTCM
ISPTCM describes the TSO commands that are invoked under ISPF. When a TSO command is issued, ISPF searches ISPTCM. If the command is found, it uses the information in the table to process the command. If the command is not in ISPTCM, ISPF uses default values, which are in the table. To change the list of TSO commands, their characteristics, or both, customize ISPTCM in SISPLPA using the ISPMTCM macro in SISPSAMP.
The very old stand alone program product TSO Data Utilities (5734-UT1) provided COPY, FORMAT, LIST, and MERGE commands. It was withdrawn from marketing in February 1997 and is no longer supported, but these commands are still defined in the shipped ISPTCM as command processor with FLAG=02.
Beginning in z/OS V2R2, the following redundant TSO commands have been removed from the ISPTCM table module and source.
COPY, FORMAT, LIST, MERGE, FORM, PASCALVS
If you used to modify the ISPTCM table to remove these commands' definitions, it is no longer needed because of the ISPF product change. However, if you still need these entries as command processors, you need to modify the ISPTCM table to restore them. Without this action, message IKJ56500I COMMAND command_name NOT FOUND might be issued.
Note: In z/OS V2R2, even when you enter the TSO COPY command by mistake without TSO Data Utilities (5734-UT1) installed, you no longer get an ABEND806-04 (Load module not found) situation by default. But, the old REXX EXEC named COPY, if it exists, will have a chance to execute unexpectedly.