91
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
Ed
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
92
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
Ed
93
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.
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.
94
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.
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.
95
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.
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.
96
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
Just don't try to share the STOGROUPs.
They can step on each other.
Ed
97
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 doesnt 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, its so fast you dont 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 isnt 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.
Dont 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 xAD and xBD:
***********************
έ@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
On the EXEC PGM=ARSSOCKD, the / in the parm= line is required to ensure that LE doesnt 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, its so fast you dont 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 isnt 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.
Dont 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 xAD and xBD:
***********************
έ@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
98
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
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
99
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
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
100
MP Server / Re: Error with V10.1 - Loading to HCP
« on: November 12, 2021, 11:35:29 AM »
Just grabbed a couple things off related problems. Can you give these look? No guarantees.
1. ...stack size (kbytes, -s) 8192
819200 or higher should work.
2. ARS_ICOS_FORCE_COMPLIANCE=0 parameter, add to ars.icos config file
3. Current CMOD NonProd server/client are on 10.5.0.1.
Both need to be upgrade to 10.5.0.2 and then apply PH37296 fix.
Ed
1. ...stack size (kbytes, -s) 8192
819200 or higher should work.
2. ARS_ICOS_FORCE_COMPLIANCE=0 parameter, add to ars.icos config file
3. Current CMOD NonProd server/client are on 10.5.0.1.
Both need to be upgrade to 10.5.0.2 and then apply PH37296 fix.
Ed
101
MP Server / Re: Error with V10.1 - Loading to HCP
« on: November 11, 2021, 01:33:52 PM »
Hmmm - PH37296, you have that on?
https://www.ibm.com/support/pages/node/6454823?mhsrc=ibmsearch_a&mhq=ph37296
And you're still seeing ARS1159E resource error message?
Ed
https://www.ibm.com/support/pages/node/6454823?mhsrc=ibmsearch_a&mhq=ph37296
And you're still seeing ARS1159E resource error message?
Ed
102
Content Navigator / Re: referentiel not available
« on: November 05, 2021, 10:49:10 AM »
Sylvain - thanks for posting that your issue was resolved and for the details of the resolution.
Ed
Ed
103
z/OS Server / Adding Team Members to New and Existing Cases
« on: October 19, 2021, 08:43:46 AM »104
MP Server / Re: arssockd server job starts and terminates immediately
« on: October 06, 2021, 07:59:55 PM »
Joe - have you tried this?
Here's an article I published in the CMOD Newsletter.
Linux 101 How to debug when ARSSOCKD fails to start and no messages are produced
What usually causes this is either ARSSOCKD ends before it can write to the System Log or the console is not set up correctly.
Before doing anything else ensure that Db2 is up.
If that doesnt resolve the problem capture the Linux system trace info thusly:
strace -s 256 -f /full/path/to/arssockd -I MyInstance -S 2> strace.out
Browse strace.out. Look for arslog
Often behind arslog will be a CMOD message with the error.
Heres an example from a recent problem record (yes, the line is very long in the trace output)
[pid 1927] execve("/opt/ibm/ondemand/V10.1/bin/arslog", ["/opt/ibm/ondemand/V10.1/bin/arslog", "ARCHIVE", "2021-06-08 19:41:32.980988", "0", "ARSSOCKD", "", "4", "213", "ARS0213I Unable to load the OnDemand DB2 dynamic load library (arsdb2). Check to make sure DB2 is installed and that the db2ln command has been run", ""], [/* 74 vars */] <unfinished ...>
Note the ARS0213I message which in this case also gave the problem resolution:
ARS0213I Unable to load the OnDemand DB2 dynamic load library (arsdb2). Check to make sure DB2 is installed and that the db2ln command has been run
If that doesnt resolve the issue do the following:
You can use the "ldd" command to check if there are other dependency issues with arssockd.
Example: As the userid that would start arssockd, run "ldd /opt/ibm/ondemand/V10.1/bin/arssockd "
If at this point there are still issues then open up a problem record with support.
Ed
Here's an article I published in the CMOD Newsletter.
Linux 101 How to debug when ARSSOCKD fails to start and no messages are produced
What usually causes this is either ARSSOCKD ends before it can write to the System Log or the console is not set up correctly.
Before doing anything else ensure that Db2 is up.
If that doesnt resolve the problem capture the Linux system trace info thusly:
strace -s 256 -f /full/path/to/arssockd -I MyInstance -S 2> strace.out
Browse strace.out. Look for arslog
Often behind arslog will be a CMOD message with the error.
Heres an example from a recent problem record (yes, the line is very long in the trace output)
[pid 1927] execve("/opt/ibm/ondemand/V10.1/bin/arslog", ["/opt/ibm/ondemand/V10.1/bin/arslog", "ARCHIVE", "2021-06-08 19:41:32.980988", "0", "ARSSOCKD", "", "4", "213", "ARS0213I Unable to load the OnDemand DB2 dynamic load library (arsdb2). Check to make sure DB2 is installed and that the db2ln command has been run", ""], [/* 74 vars */] <unfinished ...>
Note the ARS0213I message which in this case also gave the problem resolution:
ARS0213I Unable to load the OnDemand DB2 dynamic load library (arsdb2). Check to make sure DB2 is installed and that the db2ln command has been run
If that doesnt resolve the issue do the following:
You can use the "ldd" command to check if there are other dependency issues with arssockd.
Example: As the userid that would start arssockd, run "ldd /opt/ibm/ondemand/V10.1/bin/arssockd "
If at this point there are still issues then open up a problem record with support.
Ed
105
z/OS Server / Re: CMOD 10.5 Release Notes
« on: September 23, 2021, 06:57:38 AM »
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
Ed
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
Ed