OnDemand User Group
Support Forums => z/OS Server => Topic started by: Ed_Arnold on August 10, 2020, 11:51:57 AM
-
This is an oldie that tripped up an install.
z/OS V2.3 is a pre-req, but also this very old LE APAR / PTF from 2017:
https://www.ibm.com/support/pages/apar/PI80298 (https://www.ibm.com/support/pages/apar/PI80298)
CEE3559S External variable _StdStringExponentialAllocation...not found in DLL C128
Ed
-
When I tried to install 10.5 in a zone that had a previous CMOD release I could never get it to work.
It never cleaned up properly the old release.
So I installed 10.5 in a fresh SMP/E.
Ed
-
When I tried to install 10.5 in a zone that had a previous CMOD release I could never get it to work.
It never cleaned up properly the old release.
So I installed 10.5 in a fresh SMP/E.
Ed
I always install into a new zone in order to preserve and maintain multiple releases.
-
Hi Ed. What is the part number for cmod and odf 10.5 for z/OS? My passport advantage only seems to show System I
-
FYI, I think you need to use ShopZ to order
-
FYI, I think you need to use ShopZ to order
Correct!
And what you want to order are the FMIDs for CMOD and ODF, H272A50 and J272A52.
Ed
-
Is there a link to 10.5 installation for z/OS? I recall 10.1 having jobs to run that setup the SMPE zones and DDDEF. When doing shopz and trying to run the job it is failing on GIM54501S ** ALLOCATION FAILED FOR SMPLOG BECAUSE THERE IS NO DD STATEMENT IN THE JCL AND NO DDDEF ENTRY IN THE GLOBAL
ZONE.
-
Is there a link to 10.5 installation for z/OS? I recall 10.1 having jobs to run that setup the SMPE zones and DDDEF. When doing shopz and trying to run the job it is failing on GIM54501S ** ALLOCATION FAILED FOR SMPLOG BECAUSE THERE IS NO DD STATEMENT IN THE JCL AND NO DDDEF ENTRY IN THE GLOBAL
ZONE.
I think what you're looking for is the Program Directory of the base FMID for CMOD 10.5:
https://www.ibm.com/support/pages/node/608849 (https://www.ibm.com/support/pages/node/608849)
Ed
-
PH31060 -
ARSUUPDT FIELD ARSCSXITUPDTEXIT-FILENAME VALUE CHANGED IN VERSION 10.1
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: All Content Manager OnDemand for z/OS 10.1 *
* and above using arsload -E and loading files *
* from the JES spool. *
****************************************************************
* PROBLEM DESCRIPTION: When loading files from the JES spool *
* and specifying the -E option to *
* arsload, the arsuupdt exit *
* ArsCSXitUpdtExit->pFileName parameter *
* receives a pointer to a string that *
* starts with 'DD:'. Previously it *
* pointed to a string containing a *
* psudo-filename like *
* /arsa/tmp/MVS042.BPXAS.ADFOUT.STD.20110 *
* 5.1804170016779814.ARD. *
****************************************************************
ARGLOAD was inadvertently changed to pass the DD name as the
pFileName parameter when processing a spool files.
PROBLEM CONCLUSION:
ARGLOAD is changed to pass the psudo-filename as the pFileName
parameter when processing a spool file.
Had a report of loads failing.
(a) be sure to test the exit after applying this maintenance
(b) Level 2 might have a workaround
Ed
-
Using 31-bit COBOL exits?
New DD def per the ++ACTION HOLD
++HOLD(UI74252) SYSTEM FMID(H272A50) REASON(ACTION) DATE(21062)
COMMENT(
New DD definition to be added: ARSSYSOU.
Changed DD definition: SYSOUT as used by the CMOD.
This fix changes the LE runtime options for 31-bit exits.
Previously, any 31-bit exit COBOL DISPLAYs appeared in SYSOUT.
With this change 31-bit exit COBOL displays will now appear in
the ARSSYSOU DD definition.
This change fixes a problem with a 64-bit LE enclave interfering
with 31-bit LE enclave usage.
It does this by separating 31-bit enclave usage of the MSGFILE
with the default of SYSOUT from the 64-bit LE enclave usage of
the MSGFILE with the default of SYSOUT.
This change will cause any 31-bit exit COBOL DISPLAYs to now
appear on a DD of ARSSYSOU instead of a DD of SYSOUT.
If customers are relying on the output from the exits appearing
on the SYSOUT DD, the ARSSYSOU DD needs to be used instead.).
-
Red Alert
PTF service orders from 4 December 2020 to 10 December 2020 need to be reviewed.
CMOD PTFs are on the list.
https://www.ibm.com/support/pages/node/6441973 (https://www.ibm.com/support/pages/node/6441973)
Ed
-
Customers installing the PTF for PH31060 should also install PH36829 at the same time.
This affects customers at both the 10.1 and the 10.5 level.
Ref (a): https://www.ibm.com/support/pages/apar/PH31060
Ref (b): https://www.ibm.com/support/pages/apar/PH36829
PH31060 fixed an incompatibility issue with the ARSUUPDT exit.
Unfortunately, at the same time it exposed an issue in some exits which was then resolved by PH36829.
Note the following in the HOLD ACTION for PH36829:
This sysmod updates INSTALLDIR/bin/exits/arsusec, arsuupdt, and
arsuupdt. If the installation has copied those to another
location, they will need to get copied again.
This sysmod updates SARSINST(ARSUSEC, ARSUPERM, and ARSUUPDT) to
allow them to call a COBOL program.
If you have been compiling
SARSINST(ARSUSECC or ARSUPERC) solely in order to call a COBOL
program named ARSUSECX, the supplied bin/exits/arsusec and
arsuperm will now do that without needing to compile ARSUSECC or
ARSUPERC.
If you have been compiling SARSINST(ARSUUPDC) only in
order to call a COBOL program named ARSUUPDX, the supplied
bin/exits/arsuupdt will now do that without needing to compile
ARSUUPDC.
If you are compiling SARSINST(ARSUSECC, ARSUPERC,
and/or ARSUUPDC) for other changes, the changes will need to get
reworked in the updated SARSINST(ARSUSECC, ARSUPERC, and/or
ARSUUPDC).
In short, the PTFs for these two APARs should be installed together.
Of course, ensure any exits are tested before upgrading to production.
-
The doc
Further guidance for Content Manager OnDemand exits beyond what's in the V10 readmes
has had some minor updates:
https://www.ibm.com/support/pages/node/1165276 (https://www.ibm.com/support/pages/node/1165276)
Ed
-
The end all and be all for 10.5 and log4j remediation is this doc:
https://www.ibm.com/support/pages/node/6525888
Highly recommended is the 10.5.0.4 fixpack as it removes vulnerable releases of log4j from the installation directories.
https://www.ibm.com/support/pages/how-do-ptf-numbers-relate-content-manager-ondemand-product-version-numbers-and-maintenance-fix-packs
Ed
-
10.5.0.4 did not pick up PH37343/UI76042:
S0C4 IN ARSRPRNB
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: All ODF 10.1 and above users using *
* submitted job processing. *
****************************************************************
* PROBLEM DESCRIPTION: ODF is encountering an ABEND0C4 in *
* ARSRPRNB+01D8 when ARSRPSUB starts up. *
****************************************************************
ODF is using the wrong length to clear memory.
PROBLEM CONCLUSION:
ODF is modified to use the correct length
Ed
-
For everyone upgrading to 10.5 on z/OS - make sure you're referring to the z/OS 10.5 Upgrade Readme file located here:
https://www.ibm.com/support/pages/ibm-content-manager-ondemand-zos-v105-readme
This is separate from the multiplat server and client readmes which are published one-for-every-fixpack available here:
https://www.ibm.com/support/pages/ibm-content-manager-ondemand-multiplatforms-version-105-readme-files
Ed
-
The arsmaint program has always been designed to be initiated on the server.
Prior to fixpack 10.5.0.6 this restriction was not enforced.
Starting with 10.5.0.6 this restriction is being enforced.
This can result in arsmaint failing in two different cases.
1.) If arsmaint is not being initiated on the server, the solution is to run arsmaint on the server,
2.) If arsmaint is being initiated on the server, the server may not be resolving localhost correctly. Check to ensure the domain name localhost is resolved correctly.
Ref: https://www.ibm.com/support/pages/node/7027952
-
Had a couple reports of the 10.5.0.7 PTF not APPLYing.
Solution is to APPLY everything up to and including 10.5.0.6 first.
In other words, 10.5.0.6 is the keyhole that service application has to pass through before APPLYing 10.5.0.7.
Ed
-
IF you're configuring ICN for Single Sign-On on z/OS
THEN you need to be at 10.5.0.6.
HOWEVER - I am told that if you're not running arsusec as shipped, right out of the can, then there are no guarantees as to whether SSO will work.
Ed
-
Specifying an index parameter two different ways is unsupported.
Specifically, in this instance, the problem was specifying job_name index created from two different sources: (INDEX1= and -b/-B).
After upgrading from 10.1 to 10.5 the symptom was reports that failed to load, despite having loaded successfully at 10.1.
In these cases, the 88-type record simply indicates an error of RC = 6.
The desire was for -b/-B to win, overriding what ACIF (or any of the indexers) might have found in the report.
However, that is not supported.
Remove one of the specifications.
-
At 10.5.0.7 the default TLS (SSL) level for both clients and the server flips from TLS V1.2 to TLS V1.3.
If implementing TLS for the first time, things might be easier if all of CMOD, clients and servers, are at 10.5.0.7 first.
-
10.5.0.7 - the default IMDS switches from V1 to V2
The Instance Metadata Service Version 2 (IMDSv2) adds protections; specifically, IMDSv2 uses session-oriented authentication with the following enhancements: IMDSv2 requires the creation of a secret token in a simple HTTP PUT request to start the session, which must be used to retrieve information in IMDSv2 calls
-
At 10.5.0.7 the default TLS (SSL) level for both clients and the server flips from TLS V1.2 to TLS V1.3.
If implementing TLS for the first time, things might be easier if all of CMOD, clients and servers, are at 10.5.0.7 first.
10.5.0.8 Release Note --- recommended for TLS V1.3
Changed in 10.5.0.8 is that if GSK_V3_CIPHER_SPECS_EXPANDED is not specified and you want TLS 1.3, development has added TLS 1.3 ciphers to the default ciphers.
If prior to 10.5.0.8, specify GSK_V3_CIPHER_SPECS_EXPANDED=130313011302C02CC02BC030C02FC024C023 to ensure the TLS 1.3 cipher pairs (1301, 1302, 1303) are available.
Ed