OnDemand User Group
Support Forums => z/OS Server => Topic started by: Ed_Arnold on August 20, 2016, 01:16:26 PM
-
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/ (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
-
$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
-
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 (https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.hasa300/has2v5_automatic_approach.htm)
Ed
-
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.
-
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
-
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
-
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
-
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