OnDemand User Group
Support Forums => z/OS Server => Topic started by: Ed_Arnold on May 25, 2017, 09:53:05 AM
-
CMOD V10.1 is compiled with option ARCH( 8 ), meaning a z10 processor or newer is required.
Running on any processor prior to a z10 is likely to result in a S0C1.
Note: z/OS 2.2 pre-reqs a z10 processor.
Also, CMOD V10.1 is compiled with the option TARGET(zOSV2R2).
Bottom line: don't try to run CMOD V10.1 on z/OS 2.1.
Ed
-
The 64 bit admin client does not work with PDF graphical indexer.
https://www.ibm.com/support/knowledgecenter/SSQHWE_10.1.0/com.ibm.ondemand.ir.doc/dodig087.htm (https://www.ibm.com/support/knowledgecenter/SSQHWE_10.1.0/com.ibm.ondemand.ir.doc/dodig087.htm)
Ed
-
If you see this:
2018-06-21 08:48:47.176639: ARS5481I TRIGGER1=*,1,X'F1',TYPE=(GROUP)
2018-06-21 08:48:47.176654: ARS5481I FIELD1=0,2,8,(TRIGGER=1,BASE=0)
2018-06-21 08:48:47.176663: ARS5481I INDEX1='SEGMENT_NUMBER',FIELD1,(TYPE=GROUP,BREAK=NO)
2018-06-21 08:48:47.176677: ARS5481I INDEX2='REPORT_DATE',FIELD1,(TYPE=GROUP,BREAK=NO)
2018-06-21 08:48:47.176685: ARS5481I INDEX3='PAGE_NO',FIELD1,(TYPE=GROUPRANGE)
2018-06-21 08:48:47.176746: ARS1146I Loaded 0 rows into the database
2018-06-21 08:48:47.176646: ARS5488E INVALID INDEXING PARM. ERROR OCCURS NEAR TYPE
Note the message, error occurs near TYPE. (This really should be a mixed case message, it's in the works.)
Then the solution is to change
TRIGGER1=*,1,X'F1',TYPE=(GROUP)
to
TRIGGER1=*,1,X'F1',(TYPE=GROUP)
Ed
-
APAR PI98845 adds the following to V10.1:
****************************************************************
* USERS AFFECTED: All Content Manager OnDemand for z/OS *
* 10.1 using arsusec *
****************************************************************
* PROBLEM DESCRIPTION: Provide an AMODE 64 sample arsusec *
****************************************************************
* RECOMMENDATION: *
****************************************************************
With CMOD 10.1, the ARSSOCKD server runs as a 64-bit
application. In order to support existing AMODE 31 exits, glue
code is provided at the cost of additional overhead. In order
to eliminate that cost for the arsusec exit, a sample AMODE 64
arsusec assembler exit is provided.
-
LE storage usage completely changes in V10.1 compared to V9.x because of the exploitation of 64 bit.
Ref: Content Manager OnDemand for z/OS - Initial Recommended LE Settings
http://www-01.ibm.com/support/docview.wss?uid=swg22011284 (http://www-01.ibm.com/support/docview.wss?uid=swg22011284)
If you have overridden the default values you will want to run the LE storage tuning exercise again.
If you are not overriding the default values make sure you aren't choking off the values to a lesser amount.
How can you tell what values you're using and whether anything is being overridden?
Run with RPTOPTS(ON). It costs nothing, just writes the LE options to SYSOUT.
There's more than one way to run with RPTOPTS(ON). My favorite is to use the following parm line:
// PARM='RPTOPTS(ON)/-S -I ARCHIVE -v'
I recommend if you have a test ARSSOCKD started task to change that now, adding RPTOPTS(ON).
Ed
-
Following up on the previous append ----
As long as you have a test ARSSOCKD in addition to RPTOPTS(ON) please specify the -v for verbose option.
It lists the CMOD parms in effect in the output of the started task.
Neither RPTOPTS(ON) nor -v cost a thing as far as performance goes.
All either do is write options in effect to the output.
I consider both to be a definite good practice when sending output to support.
Ed
-
If you're using the old style parms on ARSSOCKD - or no parms at all - it's time to use the new parms when you roll out V10.1.
For example:
If you start ARSSOCKD with no parms at all that's fine, it means you're taking all of the defaults:
//ONMVS222 EXEC PGM=ARSSOCKD,REGION=0M,TIME=NOLIMIT
Recommend you change that when you initially bring up V10 to the following:
//ONMVS222 EXEC PGM=ARSSOCKD,REGION=0M,TIME=NOLIMIT,
// PARM='/-S -I ARCHIVE -v'
Why? Two reasons.
1. The -v means verbose. All it does is echo the parms in effect to SYSOUT. It costs nothing in performance, no traces, nothing like that. It makes seeing what parms you have in effect (and communicating to that support) far easier than copying the ars.cfg and ars.ini files.
2. If requested to add a trace, it now becomes simple:
//ONMVS222 EXEC PGM=ARSSOCKD,REGION=0M,TIME=NOLIMIT,
//* PARM='/-S -I ARCHIVE -v'
// PARM='/-S -I ARCHIVE -v -1 /tmp/ed.trc -2 ALL=15'
The -1 parm gives the path and file name for where to put the trace and the ALL=15 tells it trace everything.
In the preceding example to start a trace all you have to do is comment out the first parm line and uncomment the second and recycle ARSSOCKD. Easy!
________________________________________________
If you start ARSSOCKD with parms that look something this
//ONMVS222 EXEC PGM=ARSSOCKD,REGION=0M,TIME=NOLIMIT,
// PARM=('/NEWARCH ARSSOCKD')
then change that to
//ONMVS222 EXEC PGM=ARSSOCKD,REGION=0M,TIME=NOLIMIT,
// PARM=('/-S -I NEWARCH -v')
Some shops already have VERBOSE on the old style parm line:
//ONMVS222 EXEC PGM=ARSSOCKD,REGION=0M,TIME=NOLIMIT,
// PARM=('/INSTANCE ARSSOCKD VERBOSE')
then change that to effectively the same thing, but still, the way to pre-position tracing parameters:
//ONMVS222 EXEC PGM=ARSSOCKD,REGION=0M,TIME=NOLIMIT,
// PARM=('/-S -I INSTANCE -v')
//*PARM=('/-S -I INSTANCE -v -1 /tmp/ed.trc -2 ALL=15')
Ed
-
If you do a 3.12 and compare
ARS.ARSV1010.SARSINST(ARSTSPAC)
with
ARS.ARSV950.SARSINST(ARSTSPAC)
you'll see the addition of
MAXPARTITIONS 2
in each CREATE TABLESPACE statement.
Per https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/sqlref/src/tpc/db2z_sql_createtablespace.html (https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/sqlref/src/tpc/db2z_sql_createtablespace.html)
Table space type to create Clauses to specify
Partition-by-growth MAXPARTITIONS
Ed
-
In the 8.5 readme doc there was mention there was a newer module,
ARSZ390I , that going forward would be used in the newer sample code
for newer exits ... but that the ARSSTGET module in existing exit pgms
would still be supported.
But ARSSTGET is no longer shipped as of V10.1.
You can change your exits to use ARSZ390I (or ARSZ390F) instead of
ARSSTGET. Refer to the shipped samples for ARSEXINP,
ARSE2INP, or ARSEXANY.
So the question is can we still use the ARSSTGET load module in our older user exits
without issue in V10.1?
Since CMOD development doesn't test ARSSTGET anymore there are no guarantees.
Ed
07/16/2019 Update - was just talking with a CMOD shop that recently updated to V10. They said that neither ARSZ390I nor ARSZ390F worked in their exit. Their solution? Call the C library functions like FREAD and FOPEN directly from the COBOL.
-
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
-
PH09636 / UI61995
No action required, just install the PTF.
Ed
07/16/2019 update: and be sure to add PH10168 / UI62202 which fixes the PE of PH09636 / UI61995.
-
Had two reports recently of problems with the ANYEXIT moving to CMOD V10.1.
Both were resolved by changing the code in the exit.
1. In the first ANYEXIT a file was not being closed, resulting in the following:
ARS4328E ARSSAPIR failed: return code is 00000006 00000000(04200000).
The "ARS4328E ARSSAPIR failed: return code is 00000006 00000000(04200000)" is a dynamic unallocation failure, 0420 being the reason code:
Meaning: Specified ddname or dsname associated with an open data set. (ddname allocation, concatenation, deconcatenation, unallocation, dsname allocation).
2. In the second ANYEXIT, the following was encountered:
$HASP708 QUIKLOAD SYSIN OPEN FAILED
RC=03 DATA SET ALREADY OPENED
DSNAME=FEFG.QUIKLOAD.JOB12234.D0000101.?
IEC141I 013-C0,IGG0199G,QUIKLOAD,ARSLOAD,SYSIN
BPXP018I THREAD 16BAD00000000000, IN PROCESS 16780854, ENDED WITHOUT BEING UNDUBBED WITH COMPLETION CODE 04013000, AND REASON CODE 000000C0.
The report received on the resolution of that issue was "I changed the ACCEPT by on OPEN FILE and that works, please add
somewhere in the DOC that the behavior of the ARSLOAD changed and you can't use SYSIN anymore with EXIT called by ARSLOAD."
Ed
-
If you do a 3.12 and compare
ARS.ARSV1010.SARSINST(ARSTSPAC)
with
ARS.ARSV950.SARSINST(ARSTSPAC)
you'll see the addition of
MAXPARTITIONS 2
in each CREATE TABLESPACE statement.
Per https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/sqlref/src/tpc/db2z_sql_createtablespace.html (https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/sqlref/src/tpc/db2z_sql_createtablespace.html)
Table space type to create Clauses to specify
Partition-by-growth MAXPARTITIONS
Ed
Ed, how would you change this post install? Does this need to be done during an upgrade/install process, or can it be changed after the fact?
-
Ed, how would you change this post install? Does this need to be done during an upgrade/install process, or can it be changed after the fact?
* action taken
Development has just shipped a new function PTF which I believe resolves this issue.
APAR PH12893 / PTF UI63542
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: All Content Manager OnDemand for z/OS 10.1 *
* and above *
****************************************************************
* PROBLEM DESCRIPTION: 1. The applgrp data tablespaces are *
* created with SEGSIZE 64. SEGSIZE is *
* deprecated. *
* 2. The applgrp data tablespaces are *
* created with MAXPARTITIONS 1. *
****************************************************************
1 ARGSEG was specifying SEGSIZE 64
2 ARGSEG was always using 1 for the MAXPARTITIONS value
COMMENTS:
1. ARGSEG will no longer specify SEGSIZE 64
2. ARGSEG is enhanced to determine a MAXPARTITIONS value when a
new ars.cfg setting is specified:
ARSMVS_DB_DSSIZE
Specifies the value to use for the DSSIZE value for the
application group data table tablespaces. This must be a
power-of-two in the range of 1 - 256.
When not specified, the application group data table tablespaces
\ will be created with a MAXPARTITIONS 1, and the PRIQTY and
SEQTY will be chosen based on the max rows for the application
group. The INDEX will be created with a PRIQTY and SECQTY also
based on the max rows.
When ARSMVS_DB_DSSIZE specifies a valid value, that value will
be used in the DSSIZE N G clause when creating the application
group data table tablespace. Additionally, the PRIQTY and
SECQTY will default to -1, and the MAXPARTITIONS will be set
based on the application group max rows value. Any index
created will specify a PIECESIZE based on the max rows, and
default to a PRIQTY and SECQTY of -1
Regardless of ARSMVS_DB_DSSIZE being specified or not, the
ARSMVS_MAXROWS_PRIQTY, ARSMVS_MAXROWS_SECQTY,
ARSMVS_NOMAXROWS_PRIQTY, ARSMVS_NOMAXROWS_SECQTY,
ARSMVS_MAXROWS_INDEX_PRIQTY, ARSMVS_MAXROWS_INDEX_SECQTY,
ARSMVS_NOMAXROWS_INDEX_PRIQTY, and ARSMVS_NOMAXROWS_INDEX_SECQTY
can be used to override the PRIQTY and SECQTY values chosen by
CMOD.
For example, with ARSMVS_DB_DSSIZE=4 and an applgrp with a max
rows of 50,000,000, the tablespace might get created with:
CREATE TABLESPACE DAA23 IN ARSDBA10 USING STOGROUP SYSDEFLT
PRIQTY -1 SECQTY -1 MAXPARTITIONS 2 DSSIZE 4 G BUFFERPOOL BP0
and the index with:
CREATE INDEX ARSUSE10.DAA23_0 ON ARSUSE10.DAA23
( REPORT_NUMBER ) USING STOGROUP SYSDEFLT PRIQTY -1 SECQTY -1
BUFFERPOOL BP0 PIECESIZE 512 M
How this works is it figures out the number of bytes for a row for the applgrp, then the number of those size rows in a 4K or 32K page. From the number of rows per page and applgrp max rows it calculates how many pages it needs. The number of pages times page size is the amount of space it needs. It divides that by the dssize to get the max partitions.
This is heavier into Db2 than I usually get. Hopefully your DBA's can sort this all out for you.
Ed
-
Starting in 10.1.0.1,
if -h HOST:PORT is used
(i.e. a colon [:] is used as a separator between hostname and port),
the connection will fail.
Use a comma instead.
Ed
-
We implemented this in our V10 Level 2 test system :
APAR PI98845.
****************************************************************
* USERS AFFECTED: All Content Manager OnDemand for z/OS *
* 10.1 using arsusec *
****************************************************************
* PROBLEM DESCRIPTION: Provide an AMODE 64 sample arsusec *
****************************************************************
* RECOMMENDATION: *
****************************************************************
With CMOD 10.1, the ARSSOCKD server runs as a 64-bit
application. In order to support existing AMODE 31 exits, glue
code is provided at the cost of additional overhead. In order
to eliminate that cost for the arsusec exit, a sample AMODE 64
arsusec assembler exit is provided.
Not only did we implement it but we changed the source assembler. Our test system is V2.3 so we updated the operating system parms in the assembler source as a test.
Originally:
ARSUSEC4 TITLE 'Assembler arsusec'
sysstate archlvl=3,OSREL=ZOSV2R2,amode64=YES
New:
ARSUSEC4 TITLE 'Assembler arsusec'
sysstate archlvl=6,OSREL=ZOSV2R3,amode64=YES
Ref: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa900/state.htm (https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa900/state.htm)
Originally - everywhere there's a racroute macro, for example:
racroute request=VERIFY, validate user id and pw +
envir=CREATE, +
passchk=YES, +
acee=wkaceep, +
userid=ansi_cur_useridl, +
passwrd=ansi_cur_passwdl, +
worka=wkracwka, +
release=77A0, +
...
New:
racroute request=VERIFY, validate user id and pw +
envir=CREATE, create an acee +
passchk=YES, +
acee=wkaceep, +
userid=ansi_cur_useridl, +
phrase=ansi_cur_passwdl, +
newphrase=ansi_new_passwdl, +
worka=wkracwka, +
release=77B0, +
...
Ref: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ichc600/racrout.htm (https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ichc600/racrout.htm)
Ed
-
If you try to compile and execute the COBOL ARSUTBL exit sample you'll get the following:
ARS0160E ODV733 Unable to load module >/usr/lpp/ars/V10R1M0/bin/exits/arsutbl<. The return code is 103587 Srvr->MVS222<-
This is a 31/64 compatibility mismatch.
What the arsutbl exit is probably used for has been supplanted by new function available in PH12893.
Ed
-
I've been getting a few questions lately about falling back from V10.1 during an upgrade.
I consulted with the lead architect who had this to say:
We support a customer trying to upgrade to 10.1, changing the db (e.g arsdb –u) – then if issues, they can fall back to 9.5 [executables - SARSLOAD and HFS] without restoring the database.
However, always recommended to have db backup
Ed
-
The PTF includes this ACTION HOLD item:
SPECIAL CONDITIONS:
ACTION:
This SYSMOD ships a gson-2.8.1.jar . After applying
this SYSMOD, the path to gson-2.8.1.jar must be added
to all ODWEK java API classpaths. This includes the
arsMSVR.sh midserver invocation script.
The sample in /usr/lpp/ars/V10R1M0/samples/arsMSVR.sh has been updated with the following:
OD_ODAPI=${OD_PATH}/www/api/ODApi.jar:${OD_PATH}/jars/gson-2.8.1.jar
export OD_ODAPI
Ed
-
If you're considering implementing CMOD's Encryption at Rest, be sure that you're working from the September 5th, 2019 or later white paper.
It contains an update specifically for z/OS.
IBM Content Manager OnDemand Native Encryption
https://www-01.ibm.com/support/docview.wss?uid=swg27049568&aid=1 (https://www-01.ibm.com/support/docview.wss?uid=swg27049568&aid=1)
And a great companion doc:
Transporting AES encrypted data keys
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102736 (http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102736)
Ed
-
Starting in 10.1.0.1,
if -h HOST:PORT is used
(i.e. a colon [:] is used as a separator between hostname and port),
the connection will fail.
Use a comma instead.
Ed
Is this just on z/OS, or all platforms?
-JD.
-
Is this just on z/OS, or all platforms?
-JD.
All platforms.
Ed
-
Is there further guidance for CMOD exits for V10.1 beyond what's in the readme?
Now there is.
https://www.ibm.com/support/pages/node/1165276 (https://www.ibm.com/support/pages/node/1165276)
Suggestions for improvement are welcome.
Ed
-
Adding to Indexer parm tightened up for NODX
If you see this:
ARS5488E INVALID INDEXING PARM. ERROR OCCURS NEAR NAME
Then the solution is to change
INDEX03=PAGE_NO,FIELD1,(TYPE=GROUPRANGE)
to
INDEX03='PAGE_NO',FIELD1,(TYPE=GROUPRANGE)
Quotes are now enforced on the index name.
We found all of ours to clean up using this query.
select name from $DBOWNER$.arsapp
where indexer like '%INDEXSTYLE=NODX%' and indexer like '%INDEX%=P%'
-
If you try to compile and execute the COBOL ARSUTBL exit sample you'll get the following:
ARS0160E ODV733 Unable to load module >/usr/lpp/ars/V10R1M0/bin/exits/arsutbl<. The return code is 103587 Srvr->MVS222<-
This is a 31/64 compatibility mismatch.
What the arsutbl exit is probably used for has been supplanted by new function available in PH12893.
Ed
IBM Enterprise COBOL V6.3 is AMODE 64 capable.
https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&appname=gpateam&supplier=877&letternum=ENUSZP19-0488 (https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&appname=gpateam&supplier=877&letternum=ENUSZP19-0488)
Can I use that for my ARSUTBL exit?
Sadly, no.
Down in the fine print is, “No support for building AMODE 64 applications containing … or using the THREAD compiler option.”
THREAD is required.
Ed
-
Sample JCL to compile a 64-bit arsutbl C exit:
https://www.ibm.com/support/pages/node/3380061 (https://www.ibm.com/support/pages/node/3380061)
Ed
-
Twice recently I've had problems reported where people had carried forward their LE overrides from V9.5 to V10.1, causing abends in ARSSOCKD and in ARSODF.
Do not override the default LE settings anywhere in V10.1 unless you have re-run the LE tuning exercise.
Ed
-
Report from the field of a tightening of the code:
This works in Version 9.5 and does not work in Version 10 – from the OS/390 Indexer.
The following line is missing the comma between “NO’” AND “(TYPE”
TRIGGER2=*,2,'THERE WAS NO' (TYPE=GROUP)
Ed
-
PROBLEM: Indexer Field definitions can no longer have an asterisk (*) as an offset.
The Application Indexer used to look like this:
TRIGGER1=*,1,'1',(TYPE=GROUP) /* ANS: Skip to channel 1 and print line */
FIELD1=5,3,9,(TRIGGER=1,BASE=0)
FIELD2=*,13,40,(TRIGGER=1,BASE=0)
FIELD3=*,98,10,(TRIGGER=1,BASE=0)
It needed to be changed to this:
TRIGGER1=*,1,'1',(TYPE=GROUP) /* ANS: Skip to channel 1 and print line */
FIELD1=5,3,9,(TRIGGER=1,BASE=0)
FIELD2=5,13,40,(TRIGGER=1,BASE=0)
FIELD3=5,98,10,(TRIGGER=1,BASE=0)
_________________________________________________
This used to be acceptable to the indexer:
TYPE=GROUP,BREAK=Y
Now you have to spell out the BREAK=YES
TYPE=GROUP,BREAK=YES
________________________________________________
This comment line………last line in the indexer parms. Period caused failure:
/* WARNING: APP VALUES HAVE NOT BEEN CHECKED/UPDATED */.
Ed
-
This worked on 9,5
INDEX1='INDEX_1',FIELD1,(TYPE=GROUP,BREAK=YES) /* INDEX_1 */
INDEX2='INDEX_2',FIELD2,(TYPE-GROUP,BREAK=NO)
INDEX3='INDEX_3',FIELD3,(TYPE-GROUP,BREAK=NO)
For version 10 TYPE-GROUP had to change to TYPE=GROUP
Ed
-
Adding to the stricter rules.
Comments must be /* comment */ - No space between forward slash and the asterisk.
The error message was
ARS5481I INDEX1='SEC_ID',FIELD1,(TYPE=GROUP,BREAK=YES) / *SEC ID */
ARS5488E INVALID INDEXING PARM. ERROR OCCURS NEAR BREAK
The issue was the comment!!!
-
Problem summary
****************************************************************
* USERS AFFECTED: All Content Manager OnDemand for z/OS 10.1 *
* and above customers *
****************************************************************
* PROBLEM DESCRIPTION: When calling 31-bit arsusec and *
* arsuperm, there is no DB2 connection *
* established when the exit is invoked. *
****************************************************************
Although not documented as part of the arsusec and arsuperm
APIs, it so happened in 9.5 and below that the exits were
invoked with a DB2 connection. The support in 10.1 for calling
the 31-bit exits did not invoke the exits with a DB2 connection.
In order to ease the process of upgrading, support is being
added to allow the arsuperm and arsusec exits with a DB2
connection established.
Problem conclusion
A new ars.cfg setting, ARSMVS_EXIT31_DB2_SECPERM, is being
provided. If specified as ARSMVS_EXIT31_DB2_SECPERM=1, the
arsusec and arsuperm exits will be invoked with an ODBC DB2
connection. Note that these will be additional DB2 batch
connections above that implied by ARS_NUM_DBSRVR.
-
https://www.ibm.com/support/pages/apar/PH23110?mhsrc=ibmsearch_a&mhq=ph23110 (https://www.ibm.com/support/pages/apar/PH23110?mhsrc=ibmsearch_a&mhq=ph23110)
Error description
For an application group, if a new index field is added or if
an existing filter field is changed to an index field ARSSOCKD
will abend under the following two conditions:
1) The existing tablespaces are non-UTS.
2) ARSMVS_DB_DSSIZE=n in ars.cfg
Also, its possible that the tablespace could be incorrectly
created with 1 for MAXPARTITIONS. Note: This APAR will only
specify the correct MAXPARTITONS for new table spaces. The
arstblsp commmand can be used to close the existing table and
cause a new tablespace. Alternatively, an ALTER TABLESPACE
can be used to increase the MAXPARTITIONS.
-
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(UI74251) SYSTEM FMID(H272A10) 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
-
CMOD V10.1 is compiled with option ARCH( 8 ), meaning a z10 processor or newer is required.
Running on any processor prior to a z10 is likely to result in a S0C1.
Note: z/OS 2.2 pre-reqs a z10 processor.
Also, CMOD V10.1 is compiled with the option TARGET(zOSV2R2).
Bottom line: don't try to run CMOD V10.1 on z/OS 2.1.
Ed
Is this still the case. We have other problems with 10.1, OAM issues, but not S0C1.
Release z/OS 2.1.0 (SPLevel 7.2.1)
-
Is this still the case. We have other problems with 10.1, OAM issues, but not S0C1.
Release z/OS 2.1.0 (SPLevel 7.2.1)
Yes. I hope you can get to z/OS 2.2.0 soon.
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 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