z/OS 2.2 Upgrade Notes

[Ed_Arnold]

My support group upgraded my CMOD test system from z/OS 2.1 -> z/OS 2.2.

Some items:

1. See the z/OS V2.2 Migration pub for what has to happen with OAM:

http://www-03.ibm.com/systems/z/os/zos/installation/

Bottom line is that you have to run the OAM bind jobs.

2. When the system was first turned over to me I couldn't telnet into OMVS.

Here's the response from support:

In z/OS 2.2, a new key file needs to be generated and placed in the /etc/ssh directory. OMVS command added to the Supporting Details for reference. I manually started SSHD and can now SSH via Putty.

OMVS command to generate new key file for z/OS 2.2 SSH:

ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key -N ""

I'll post more if I encounter anything else.

Ed

[Ed_Arnold]

 $DACTIVATE                                                     
 $HASP895 $DACTIVATE 412                                       
 $HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z11                 
 $HASP895 THE CURRENT CHECKPOINT:                               
 $HASP895  -- CONTAINS 11100 BERTS AND BERT UTILIZATION IS 1   
 $HASP895     PERCENT.                                         
 $HASP895  -- CONTAINS 915 4K RECORDS.                         
 $HASP895 z22 CHECKPOINT MODE ACTIVATION WILL:                 
 $HASP895  -- EXPAND CHECKPOINT SIZE TO 985 4K RECORDS.         
 $HASP895 z22 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER. 
 $HASP895     THE FOLLOWING ISSUES PREVENT ACTIVATION:         
 $HASP895  -- CYL_MANAGED SUPPORT MUST BE ACTIVATED.   

$T SPOOLDEF,CYL_MANAGED=ALLOWED                                 
$HASP844 SPOOLDEF 414                                           
$HASP844 SPOOLDEF  BUFSIZE=3992,DSNAME=SYS1.HASPACE,DSNMASK=,   
$HASP844           FENCE=(ACTIVE=NO,VOLUMES=1),GCRATE=NORMAL,   
$HASP844           LASTSVAL=(2014.017,22:10:42),LARGEDS=ALLOWED,
$HASP844           SPOOLNUM=32,CYL_MANAGED=ALLOWED,TGSIZE=30,   
$HASP844           TGSPACE=(MAX=260608,DEFINED=200000,         
$HASP844           ACTIVE=200000,PERCENT=10.4175,FREE=179165,   
$HASP844           WARN=80),TRKCELL=3,VOLUME=SPOOL

$DACTIVATE
$HASP895 $DACTIVATE 416                                         
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z11                   
$HASP895 THE CURRENT CHECKPOINT:                                 
$HASP895  -- CONTAINS 11100 BERTS AND BERT UTILIZATION IS 1     
$HASP895     PERCENT.                                           
$HASP895  -- CONTAINS 915 4K RECORDS.                           
$HASP895 z22 CHECKPOINT MODE ACTIVATION WILL:                   
$HASP895  -- EXPAND CHECKPOINT SIZE TO 985 4K RECORDS.           
$HASP895 z22 ACTIVATION WILL SUCCEED IF ISSUED FROM THIS MEMBER.

$ACTIVATE,LEVEL=Z22                                          
$HASP895 z22 CHECKPOINT MODE IS NOW ACTIVE                   
$HASP895 $ACTIVATE,LEVEL=Z22 426                             
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z22               
$HASP895 THE CURRENT CHECKPOINT:                             
$HASP895  -- CONTAINS 11100 BERTS AND BERT UTILIZATION IS 1   
$HASP895     PERCENT.                                         
$HASP895  -- CONTAINS 986 4K RECORDS.                         
$HASP260 MEMBER E222 IS NOW IN z22 CHECKPOINT MODE   

$DACTIVATE                                                  
$HASP895 $DACTIVATE 429                                     
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z22               
$HASP895 THE CURRENT CHECKPOINT:                             
$HASP895  -- CONTAINS 11100 BERTS AND BERT UTILIZATION IS 1 
$HASP895     PERCENT.                                       
$HASP895  -- CONTAINS 986 4K RECORDS.

Ed

[Ed_Arnold]

Tuning the JES2 Checkpoint is always a concern.

Starting in z/OS V2.2 you can have JES2 automatically choose optimal values.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.hasa300/has2v5_automatic_approach.htm

Ed

[Ed_Arnold]

OA55725

ERROR DESCRIPTION:                                           
zLib deflate() call returns Z_STREAM_ERROR (RC=-2) with a     
z_stream *msg = System Error 003. This is a translated message
that is generated from a RC = x'C' RSN = x'XXXX0206' from     
FPZ4ABC, compression driver. This return code / reason code   
combination indicates that the generated compression output is
larger than the internal zEDC buffer.                         

[Ed_Arnold]

LE APAR PI93384

PROBLEM SUMMARY:                                                   
****************************************************************   
* USERS AFFECTED:                                              *   
* Users of POSIX(ON) Language Environment                      *   
* applications which expect to roll back the                   *   
* in-progress update to the recoverable                        *   
* resources when SIGXCPU is received and                       *   
* there are no signal handlers registered for                  *   
* SIGXCPU by the applications.                                 *   
****************************************************************   
* PROBLEM DESCRIPTION:                                         *   
* When Language Environment applications                       *   
* are terminated with return code 3000                         *   
* due to unhandled SIGXCPU under                               *   
* POSIX(ON), the in-progress updates to                        *   
* recoverable resources would be                               *   
* committed instead of being rolled back.                      *   
****************************************************************   
* RECOMMENDATION:                                              *   
****************************************************************   
See the problem description.                                       
                                                                   
PROBLEM CONCLUSION:                                               
The code has been changed to ensure that, when a Language         
Environment application is terminated with return code 3000 due   
to unhandled SIGXCPU under POSIX(ON), the ThliAbnormalTerm flag   
for all the threads in the process which receives SIGXCPU are     
set to ON to notify Unix System Service to propagate the flag     
to TCB_PTHREADTERMABNORMAL. The TCB_PTHREADTERMABNORMAL flags     
are set to ON to indicate that the TCBs are terminated             
abnormally. Then DB2 or other resource managers can check the     
TCB_PTHREADTERMABNORMAL flags to determine commit or roll back     
the in-progress transactions.                                     
                                                                   
TEMPORARY FIX:                                                     
*********                                                         
* HIPER *                                                         
*********                                                         

In other words

OLD BEHAVIOR - the in-progress updates to recoverable resources would be committed instead of being rolled back.

NEW BEHAVIOR - DB2 or other resource managers can check the TCB_PTHREADTERMABNORMAL flags to determine commit or roll back the in-progress transactions.    Which in the case of CMOD because there are no signal handlers registered for SIGXCPU by the applications means that things uncommitted get rolled back.

Ed

[Ed_Arnold]

This is a z/OS 2.2 issue only.  Does not affect either 2.1 or 2.3.

CMOD exposes the following:

IF PE PTF UA96465 is installed and fixing HIPER APAR OA54570 PTF UA97572 is not

THEN page datasets can be filled and not freed even after the started task is ended.

This is more likely to occur with ODF but can also affect ARSSOCKD.

From OA54570:

ERROR DESCRIPTION:                                                 
Freemain processing does not indicate that we should free the     
auxiliary storage of any related in-flight IO, so when IO         
completes we do not release the backing frame and                 
instead lose the blockid. Later, SCM evacuation discovers         
the bad blockid and issues an ABENDC0D.                           
                                                                   
Additional problem can also occur, when an application uses       
IARVSERV TARGET_VIEW=HIDDEN, this results in storage being paged   
to auxiliary slots or SCM block.   Should this storage be         
freemained while having a status of hidden the aux slot/scm       
block can be orphaned.  This was introduced by changes made in     
APAR OA54820.  LE Stack management behaves in this manner.         
XPLINK applications that quickly create and destroy pthreads       
can observe aux slots orphaned at a high rate.                     

Ed

[Ed_Arnold]

Do you have OAM toleration APAR OA51129 already installed on your z/OS V2.1 or V2.2 system? 

If so, then you're all set and the rest of this doesn't apply to you.

If, however, you're upgrading to V2.2 or adding toleration maintenance then:

1) APAR OA51129 has the following warning message:                         
                                                                           
   "**Warning** Information APAR II14842 should be reviewed before         
   applying OA51129. If II14842 precautions are not observed then         
   there may be a potential loss of object addressability."               
   http://www-01.ibm.com/support/docview.wss?uid=isg1OA51129               
                                                                           
2) Technote to alert customers about the possible effects:                 
                                                                           
   OAM Object Required Considerations prior to installing OA51129 or       
   upgrading to z/OS 2.3                                                   
   https://www-01.ibm.com/support/docview.wss?uid=ibm10728703             
                                                                           
3) AI that was included in PTF UA91367                                     
                                                                           
   "Prior to coexistence APAR OA51129, OAM s object support would         
   maintain collection information in two places; in DB2 (in the           
   OAM collection table) and also in the catalog. With new function       
   introduced in z/OS V2R3 (support for multiple OAM instances to         
   exist on the same LPAR) and requirements around that support,           
   OAM is now only going to maintain this collection information in       
   DB2 (regardless of whether the new support is being used). For         
   most customers, the information that was in the catalog and in         
   DB2 should be in synch; however, there is no absolute guarantee         
   that this is the case. As we have discovered, the most likely           
   cause for an out-of-synch condition is the customer themselves         
   needing to clean-up and/or rebuild their collection environment.       
   To be as proactive as possible information APAR II14842 was             
   created along with a REXX comparison tool for customers to run.         
   This tool compares the OAM collection information in the catalog       
   and in DB2 and surfaces any inconsistencies that it detects. If         
   the tool is not run, this out-of-synch condition could exist for       
   years, until the customer goes and retrieves an object from that       
   particular collection."                                                 
                                                                           
4) Informational APAR II14842 with the CATDB2CP tool                       
                                                                           
   http://www-01.ibm.com/support/docview.wss?uid=isg1II14842              

[Ed_Arnold]

CMOD exposes the following z/OS issue:

Symptom:  long running ARSYSPIN task hangs.

Cause:  Virtual storage shortage

Fix:  OA58421: PRLRMAIN & DAGSH WORK AREA NOT BEING FREED AFTER ABEND IN DADSM PARTIAL RELEASE

Ed