OnDemand User Group
Support Forums => z/OS Server => Topic started by: Ed_Arnold on December 09, 2019, 11:53:30 AM
-
If you're migrating from z/OS V2.2 or below, make sure you use the current CBRIBIND member from SYS1.SAMPLIB:
...
//* $P2=OAMR23M R23 161013 TUCAED: Missing prolog multi reference
//* $P3=138323 R23 161101 TUCAED: Added CBRIDBSV package and
//* updated prolog
...
Ed
-
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
-
You can display reason code information for the OAM and OSREQ macros directly from a console or a TSO session, as of APAR OA58344 for V2R3 or later. These commands can also be invoked via JCL to aid in automation of error information capturing in real time.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idao200/displayoaddr.htm (https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idao200/displayoaddr.htm)
-
There was a problem with mixed case passphrases during MFA Web authentication where MFA incorrectly folded a passphrase to uppercase, and is fixed in MFA 2.0 and MFA 1.3 with PTF UI66464.
-
Before upgrading to z/OS 2.4 run the OAM IVP.
It's very easy to set up, doesn't require much time at all.
http://www.odusergroup.org/forums/index.php?topic=887 (http://www.odusergroup.org/forums/index.php?topic=887)
This way you can determine early after the IPL of 2.4 whether OAM is correctly set up. Also, it will assist in determining whether an issue is a CMOD problem or an OAM problem, hastening resolution of any issues.
Ed
-
ARSYSPIN extremely slow to load jobs into OnDemand after upgrade to Db2 V12.
https://www.ibm.com/support/pages/apar/PH34239
-
Symptoms:
JES2 MAS.
Other members of the plex are already at 2.4.
Last member, which also happens to run CMOD, upgraded.
ARSYSPIN very slow ingesting from SPOOL. (Could also affect ARSLOAD as a started task reading from SPOOL)
Cause: JES2 error
https://www.ibm.com/support/pages/apar/OA59967?mhsrc=ibmsearch_a&mhq=OA59967
A workaround is available that can be dynamically implemented, see the APAR description.
Ed
-
CMOD exposes the following error:
https://www.ibm.com/support/pages/apar/OA59954 (https://www.ibm.com/support/pages/apar/OA59954)
OA59954: AFTER OA58718, ABEND0C4 IN HASCPHAM+29B0 READING A SPANNED SPOOLRECORD
ARSLOAD running as a started task reading from spool, S0C4.
Ed
-
OA62618: CBR9912I RSN9013 DURING OSMC OR OSREQ RETRIEVE REASON CODE X'80030200'
Error description
• The issue may be surfaced in either of the following ways: 1)
• During OSMC processing: CBR9912I groupxx CBRHRDAS A request to
• read Object from collection collection-name,object object-name
• in groupxx failed. The return code is 16, and the reason code
• is 9013. 2) Failure from an application to OSREQ RETRIEVE an
• affected object. The OSREQ REASON CODE returned to the
• application is x'80030200'. This issue occurs for a subset of
• object sizes if BUFFER64 was used on the OSREQ STORE that stored
• the object and the object was stored to the LOB table.
•
• IDENTIFICATION:
• The following SPUFI may be run against each Object Storage Group
• that utilizes LOB tables to identify objects affected by this
• issue:
•
• SELECT 'GROUPxx', ODNAME, ODCLID, ODLOBFL, ODSIZE, LENGTH(OTOBJ)
• AS LENGTH
• FROM hlq.OSM_OBJ_DIR
• LEFT JOIN hlq.OSM_LOB_BASE_TBL
• ON OTNAME = ODNAME
• WHERE LENGTH(OTOBJ) <> ODSIZE;
•
• *where hlq is the DB2 qualifier of the Object Storage Group
• table being investigated
•
• If the ODSIZE is 1 byte greater than the length of OTOBJ and is
• a multiple of (1048568 x n) +1, then the object is affected by
• this issue.
•
• ADDITIONAL SYMPTOMS:
• CBR9912I OSREQ ODSIZE
Contact OAM support for details and fix.
-
LE for COBOL issue.
Symptom is arsload started task can't be brought down with a normal STOP, has to be cancelled to terminate.
PH43756: Loop during thread termination starting with IGZETHT and involving repeated invocation of IGZXWAIT
During COBOL runtime thread termination in a multithreaded environment, IGZXWAIT is repeatedly driven waiting on a state that never arrives.