Messages

91

MP Server / 10.5.0.4 ifix is only for the FTS server

« on: February 07, 2022, 11:32:00 AM »

The interim fix for the FTS server is now out (10.5.0.4.001) on fix central. 

It looks like it's an OD server fix but once you dig deep enough you will see it is only for the FTS server.

You can search using the normal parameters on fix central (product, installed version, platform).

For instance, if you search on “Content Manager OnDemand for Multiplatforms”, “10.5.0.4”, and “AIX 64-bit, pSeries” and then select “Browse for fixes” you will see what looks to be an interim fix for the OD server product because the Abstract states “This I-fix contains the SERVER files and readme.”

But, if you select this interim fix and continue you will then see the list of files:
 
odftsaix.bin
readfts.txt

It's only a fix for the FTS server.

Note that the FTS server only runs on AIX, Linux, Windows and zLinux

92

OD/WEK & JAVA API / There is no 10.5.0.4 Windows Client Update But There Is a 10.5.0.4 ODWEK Client

« on: February 07, 2022, 11:25:49 AM »

10.5.0.4 is primarily a server-only release, mostly to incorporate log4j remediation.

There is no 10.5.0.4 Windows client release.

As of this writing, there are no plans to come out with a 10.5.0.4 Windows client.

Probably what will happen is that level will just be skipped - next Windows client will be 10.5.0.5.

However, there is a 10.5.0.4 ODWEK client that picks up some minor fixes.

Ed

93

MP Server / Reminder - CMOD V10.1 End of Service 30 April 2022

« on: January 31, 2022, 02:09:59 PM »

90 days out.

Ed

94

z/OS Server / Re: CMOD 10.5 Release Notes

« on: January 26, 2022, 12:05:35 PM »

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

95

z/OS Server / Re: 10.1 Release Notes

« on: January 26, 2022, 12:03:18 PM »

The end all and be all doc for 10.1 log4j remediation is this techdoc:

https://www.ibm.com/support/pages/node/6525892

Highly recommend the 10.1.0.10 fixpack no matter whether you're directly affected or not as it completely shuts down questions about log4j and CMOD.

https://www.ibm.com/support/pages/how-do-ptf-numbers-relate-content-manager-ondemand-product-version-numbers-and-maintenance-fix-packs

Reminder - V10.1 goes EoS all platforms April 30th, 2022.

Ed

96

MP Server / Re: Upgrade CMOD 8.5 to 10.5

« on: January 21, 2022, 12:28:34 PM »

Andre - sadly I don't have the requirements for those levels anymore.

But usually the CMOD pre-req doc always says "such and such a level or later."

So you might want to try upgrading everything non-CMOD first and save it for last.

Ed

97

z/OS Server / Re: Content Manager OnDemand for All Platforms EoS 04-30-2022

« on: January 12, 2022, 06:27:43 AM »

A little late to the party but want to make sure everyone knows CMOD V10.1 EoS all platforms is 4/30/22.

Ed

98

z/OS Server / Re: ARSSOCKD and TLS v1.2 - proof of concept

« on: January 06, 2022, 07:33:41 PM »

I was informed today that TLS V1.2 is the default starting at CMOD V10.1.

Ed

99

z/OS Server / z/OS V2.5 Release Notes

« on: December 20, 2021, 08:52:21 AM »

OAM issue surfaced by CMOD:

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.

100

z/OS Server / OAM Problem Surfaced by CMOD

« on: December 20, 2021, 08:51:25 AM »

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.

101

z/OS Server / OAM Problem Surfaced by CMOD

« on: December 20, 2021, 08:51:00 AM »

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.

102

Tips and Tricks / Re: Checklist for New CMOD on z Installations

« on: December 10, 2021, 07:45:37 AM »

Running two instances of CMOD, say test and production, pointing to the same OAM back end is okay.

Just don't try to share the STOGROUPs. 

They can step on each other.

Ed

103

Tips and Tricks / Checklist for New CMOD on z Installations

« on: November 30, 2021, 11:43:52 AM »

Just some things I came up with that too frequently get overlooked by new CMOD customers on z:


On the EXEC PGM=ARSSOCKD, the “/” in the parm= line is required to ensure that LE doesn’t try to read CMOD parms and vice versa

XXONMVS222 EXEC PGM=ARSSOCKD,REGION=0M,TIME=NOLIMIT,MEMLIMIT=NOLIMIT,
XX* PARM='TRACE(ON,15M,,LE=8)/-S -I ARCH1010 -v'                     
XX* PARM='/-S -I ARCH1010 -v'                                         
XX* PARM=('ENVAR(_CEE_HEAP_MANAGER=CELQMCHK)/-S -I ARCH1010 -v')     
XX* PARM='/-S -I ARCH1010 -v -1 /tmp/ela.trc -2 ALL=15'               
XX*PARM='/-S -I ARCH1010 -v -d "keystore_location=CKDS,keystore_mkl=*"
XX  PARM=('ENVAR(LDAP_DEBUG=2147483647)/-S -I ARCH1010 -v ')         
XX* PARM='RPTOPTS(ON)/-S -I ARCH1010 -v'                             
XX* PARM='DYNDUMP(IBM),RPTOPTS(ON)/-S -I ARCH1010 -v'                 
XX* PARM='RPTOPTS(ON),RPTSTG(ON)/-S -I ARCH1010 -v'                   
XX* PARM=('ENVAR(_EDC_DLL_DIAG=TRACE)/-S -I ARCH1010 -v')             


On z, if your back end is OAM, it’s so fast you don’t probably don't need cache except for handling the system log (contact L2 if want you an explanation).


You probably don't want to load exclusively to virtual tape.  It isn’t fast enough to handle a heavy load of ‘hot’ data.


When defining a test application group, the default number of rows for a table is probably way too large.  From the first screen in defining a new app group, select Advanced.  On the next screen is the default, 10,000,000 rows, which is probably way too big and a waste of space.


Don’t ever change the permissions on the cache filesystem.


Example of config link to ars.ini file --- need that symlink:

   Type  Perm  Changed-PST8PDT   ------Size  Filename
 _ Dir    755  2021-09-16 09:54        8192  bin     
 _ Dir    755  2021-04-16 11:27        8192  www     
 _ Dir    755  2021-04-16 11:23        8192  midserver
 _ Dir    755  2021-04-16 11:22        8192  jars     
 _ Dir    755  2021-04-16 11:22        8192  samples 
 _ Dir    755  2020-11-25 08:17        8192  locale   
 _ Dir    755  2020-03-31 11:58        8192  ..       
 _ Syml   777  2020-02-26 07:49           8  config    <------
 _ Dir    755  2020-02-26 05:28        8192  .       


Ars.ini file has to have a very first line with x’AD’ and x’BD’:

***********************
έ@SRV@_ARCH850¨       
HOST=mvsxxx           
PROTOCOL=2             

with hex on

έ@SRV@_ARCH850¨ 
A7EDE76CDCCFFFB 
DC295CD1938850D 


That first line is the CMOD instance name, used with arsload.  Which is different from the “SERVER_INSTANCE” which refers to the database name

έ@SRV@_ARCH850¨                         
HOST=mvs222                             
PROTOCOL=2                             
PORT=1447                               
SRVR_INSTANCE=ARS850DB                 
SRVR_INSTANCE_OWNER=ARSSERV2           
SRVR_OD_CFG=/etc/ars/V850/ars850.cfg   
SRVR_SM_CFG=/etc/ars/V850/ars850.cache 
SRVR_FLAGS_SECURITY_EXIT=1             

Note that in both the admin and user clients, in the lower right corner is the level of the CMOD SERVER.  To get the level of the CMOD CLIENT go to Help -> About OnDemand

Feel free to add any items.

Ed

104

z/OS Server / Re: z/OS V2.4 Release Notes

« on: November 19, 2021, 08:03:15 AM »

CMOD exposes the following error:

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

105

MP Server / Re: How to remove vulnerable ciphers

« on: November 15, 2021, 01:34:53 PM »

Sue - are you on z?

This is how we input those parms when we were doing testing, copied from a test ARSSOCKD:

XXARSSOC95 EXEC PGM=ARSSOCKD,REGION=0M,TIME=NOLIMIT, 
* PARM='ENVAR(GSK_PROTOCOL_TLSV1_2=ON,GSK_V3_CIPHER_SPECS=3C)  Pick one, can't both be active
* PARM='ENVAR(GSK_PROTOCOL_TLSV1_2=ON,GSK_PROTOCOL_TLSV1=0)    Pick one, can't both be active 
             /-S -I ARCH950 -v'          

Ed