z/OS - Group home

Being Aware of Changes in z/OS V2R3 Sooner Rather than Later - From Professor Kimura

By Anthony Giorgio posted Thu April 02, 2020 03:47 PM

  

Author:  @Shigeki_Kimura

Recommendation:  When you migrate to z/OS V2R2, you might also want to read the following blog.
Sharing some changes in z/OS V2R2 before you find it - From Professor Kimura

+++  From my session in "SHARE in Sacramento, Winter 2018"  +++

When migrating to z/OS V2R3 from V2R1, it's necessary to understand all of the changes in functional behavior which were introduced in z/OS V2R2, V2R3, or any service stream (APAR/PTF). This presentation will focus on the findings from the viewpoint of an ESP user as well as changes uncovered during regression testing. Expect to have insightful "lessons learned" as well as "hints and tips" when migrating to V2R3. After this session, the changes in z/OS V2R3 will no longer be a mystery and your deployment of z/OS V2R3 should be much smoother.

22600:  Being Aware of Changes in z/OS V2R3 Sooner Rather than Later
< AGENDA >
New information displayed in LOG:

(V2R3) BCP    New IEFA111I message (in both JES2 and JES3)
(V2R3) BCP    New DISPLAY ALLOC,O command
(V2R3) JES2    New $HASP4403 message
(V2R2) JES2    Changed $HASP395 message
(V2R2) BCP    New IOS128I message
(V2R2) BCP    New IEFA110I message

Changes observed in z/OS V2R3:

BCP    SMF recording by Generic Tracker
BCP    Command response from DISPLAY U
BCP    Command response from DISPLAY A/TS/J
HLASM    ALIAS IEV90 for module ASMA90
JES2    Aging calculation for executing jobs
DFSMS    VSAM DBA for CICS LSRPOOLs
DFSMS    Length of VSB control block in ESQA
DFSMS    Length of D type record by IDCAMS DCOLLECT
DFSMS    Command response from DEVSERV PATHS/SMS
DFSMSdss    PPT NOPASS attribute for ADRDSSU program
ISPF    PDSE Alias count in ISPF "Number of members"
ISPF    OPT3.2 and OPT3.4 New Allocation
SDSF    Warning message ISF045W on ULOG panel
SDSF    Suppress starting SDSFAUX address space
SDSF    SISFLOAD requirement for SDSF address space
SDSF    Destination of message HSF0035W & HSF0037W
SDSF    Point-and-Shoot support for Fixed Field on panel
SDSF    Behavior of displaying the SDSF MENU panel

Additional information:
(Related to) DFSMS    VSAM DBA for CICS LSRPOOLs
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).

Additional information:
JES2 DOC APAR OA54439:
Beginning in z/OS V2R3 JES2, specifying an apostrophe (') as either a master character or a nonmaster character for the CHARS= parameter of the COMPACT (Compaction Table Definition) initialization statement will cause message
$HASP003 RC=(01),COMPACT CHARS (CHARS dd)  - INVALID SYNTAX
$HASP469 REPLY PARAMETER STATEMENT, CANCEL, OR END
to be issued.  ("CHARS dd" in the message identifies the location of the apostrophe in the specified CHARS= parameter list.)

Solution: As with the five CHARS= parameter special characters currently identified (i.e., right parenthesis, left parenthesis, blank, comma, and hyphen), for which the equivalent hexadecimal value must be coded for the CHARS= parameter, the hexadecimal form of an apostrophe, 7D, must be coded to specify an apostrophe as a master or as a nonmaster value for the CHARS= parameter.
 

+++  Additional information posted on June 19, 2019 by Shigeki Kimura  +++

SDSF message ISF121I under ISPF

Message ISF121I is issued when displaying the tablar panel, such as DA, if MEMLIMIT=0M is in effect for the TSO/ISPF user session.

ISF121I Module ISFSM64 was unable to obtain 00000000_0000D7D8 bytes storage  (1 segments).  Check MEMLIMIT value.

Explanation for ISF121I message:
SDSF attempted to obtain storage that is above the bar (above the 2-gigabyte line) but the amount of storage was not available. The value for MEMLIMIT for the user ID may be too low. This message is issued only once per session.
System action: SDSF attempts to obtain storage below the bar.

After migrating to z/OS V2R3 SDSF, and under ISPF/SDSF environment, ISF121I message is no longer issued while it is still issued when running SDSF under TSO/E native. The reason for this behavior, which should be expected, depends on the change of timing for request to obtain storage.

Default sysout class "A" for SDSF HSFLOG and HSFTRACE data set

The procedure for SDSF server shipped in the ISF.SISFJCL(SDSF) member does not contain the HSFLOG and HSFTRACE DD statement, which enables the dynamic allocation for these data sets.

The dynamic allocation for both log and trace sysout data sets will be with SDSF address space in z/OS V2R3 while it has been with SDSFAUX in prior releases. If you are migrating to z/OS V2R3 from prior releases where the SDSFAUX address space was not running, both HSFLOG and HSFTRACE should be new for you.

Regarding the dynamic allocation of sysout data set for SDSF log (HSFLOG) and trace (HSFTRACE), you can specify the following options in the SDSF server JCL or the server START command to control the sysout class.

- LOGCLASS or LC (sysout-class) specifies the default SYSOUT class for the server log. If not specified, SDSF uses class A by default.
- TRCLASS or TC (sysout-class) specifies the default SYSOUT class for the trace file. The default for TRCLASS/TC can be specified via OPTIONS TRCLASS(class) in ISFPRMxx parmlib meber or ISFMAC TRCLASS=class in ISFPARMS. If not specified, SDSF uses class A by default.

You need to specify the sysout class explicitly, if required, to override the default class "A" from an operational point of view.

JES2 elapsed time job monitor feature for TIME>1439

JES2PARM ESTIME statement specifies the default elapsed wall clock time for a job, the interval at which the $HASP308 message is written to the operator, and whether the JES2 elapsed time job monitor feature is supported.
Default: NUM=2,INT=1,OPT=NO

If OPT=YES parameter is explicitly specified, $HASP308 message can be issued when job has exceeded its estimated elapsed (wall clock) time in the JES2 execution phase by nnn minutes.

14:37:11.53 JOB06537 $HASP308 BEANSZZ  ESTIMATED TIME EXCEEDED
14:38:11.52 JOB06537 $HASP308 BEANSZZ  ESTIMATED TIME EXCEEDED BY 1 MINUTE
14:39:11.53 JOB06537 $HASP308 BEANSZZ  ESTIMATED TIME EXCEEDED BY 2 MINUTES

However, prior to JES2 APAR OA54766 (for z/OS V2R1, V2R2 and V2R3), the TIME value specified on a JOBPARM statement which was greater than 1439 minutes was ignored, while the documented range was 0-9999 minutes, and no $HASP308 messages were issued.
JES2 APAR OA54766 updated to issue $HASP308 message when TIME specifies the 1440 or greater minutes. It means that you might suddenly receive $HASP308 message after migrating to z/OS V2R3 even without no JCL changes.

TSOENV variable name with ISPF VPUT and VGET statement

Both ISPF APAR OA47890 (for z/OS V1R13 and V2R1) and ISPF APAR OA48325 (for z/OS V2R2) introduced a new TSOENV keyword to the panel statements, such as *REXX, )REXX, and PANEXIT.

For example, the TSOENV keyword in the *REXX statement indicates that you want ISPF to use the current TSO environment. If your dialog does an IRXINIT to create its own REXX environment, but this keyword is not specified, that environment is not used to process the REXX code. The REXX code is instead invoked in ISPFs REXX environment.

After migrating to z/OS V2R3 from z/OS level without APAR OA47890/OA48325 applied, and if you attempted to display a panel that did a VPUT or a VGET for a variable named TSOENV, the panel incorrectly failed to display with error message ISPP245.
The solution for this problem is ISPF APAR OA56912 for z/OS V2R3.

ABEND dump suppression with IEA848I for started task job

After ABDUMP APAR OA49595 (for z/OS V1R13, V2R1 and V2R2), if the JSCBPASS bit is setting in the BATCH job step, ABEND dump is no longer generated with message IEA848I even if SYSABEND, SYSMDUMP or SYSUDUMP DD is allocated. SLIP trap may need to be requested to generate an SVC dump when the problem scenario is recreated.

IEA848I DUMP SUPPRESSED - ABDUMP MAY NOT DUMP STORAGE FOR JSCBPASS JOB jobname
(Routing Code: 11, Descriptor Code: 4)

However, depending on the key value which it is running in, some started task jobs are receiving message IEA848I when an ABDUMP was requested following an abend.
Typical example: IEA848I DUMP SUPPRESSED - ABDUMP MAY NOT DUMP STORAGE FOR JSCBPASS JOB DFHSM

ABDUMP APAR OA56310 (for z/OS V2R2 and V2R3) changed to allow all started task jobs to receive dumps which enable a level of serviceability regardless of which key they are running in.

Size and location for VSB control blocks (VSCR for ESQA storage)

VSB (Volume Statistics Block) control blocks are built in ESQA storage to represent volume statistics which are used to capture SMF type 42 subtype 5 and 6 records, regardless of recording these SMF type/subtype. It is allocated for each online volume that is used, regardless of SMS-managed or not, and it is true even when SMS null configuration is activated.

In z/OS V2R2 and APAR OA44322 with z/OS V2R1, the length of VSB has been increased to 616 bytes (x'268') from 216 bytes (x'D8') to support new DFSMS statistics information. For example, additional 4MB ESQA storage is needed to support 10,000 online and used volumes. Message IRA103I can be issued after this change, which suggests that you might evaluate the system requirement for SQA/ESQA storage.
IRA103I SQA/ESQA HAS EXPANDED INTO CSA/ECSA BY    nn PAGES

After that, DFSMS APAR OA55711 (for z/OS V2R2 and V2R3) provided new I/O statistics for system I/O and Data transfers between DASD and cloud. Prior to DFSMS APAR OA55711, each online DASD device allocates 616 bytes for VSB in 31 bit common storage (ESQA) for VTOC and VVDS I/O statistics. After DFSMS APAR OA55711, each online DASD device allocates 48 bytes in 31 bit common storage (ESQA) and 896 bytes above the 2G bar (HVCOMMON) for VSB. It means a Virtual Storage Constraint Relief (VSCR) for ESQA by reducing the allocated VSB size.

DFSMShsm HLIST command behavior when LIST function is held

HBACKDS, HMIGRATE, HRECALL and HRECOVER commands are held when either HOLD ALL is issued or if the HOLD command is issued for BACKUP, MIGRATION, RECALL or RECOVER command respectively.

However, when a HOLD command is issued with the ALL or LIST keywords, the LIST function will be prevented from executing by message ARC0814I with RC=002 but a TSO/E user may still sucessfully issue an HLIST command.

This exceptional behavior has been addressed by DFSMShsm APAR OA56926 (for z/OS V2R2 and V2R3), where DFSMShsm modified to also hold the HLIST user command when the LIST function is held via HOLD ALL or LIST command. The change is applicable to any of optional parameters (TERMINAL/OUTDATASET/SYSOUT) specified with HLIST command.