OnDemand User Group
Support Forums => z/OS Server => Topic started by: doliver1 on December 17, 2014, 07:30:22 AM
-
I am preparing to upgrade to CMOD 9.5.1 on our z/OS 2.1 operating systems. Are there release notes for 9.5? All I found on the CMOD 9.5 site was what's new.
Thanks in advance
-
Hi Doug - you absolutely positively want to go to here:
http://www.odusergroup.org/forums/index.php?board=5.0 (http://www.odusergroup.org/forums/index.php?board=5.0)
The very first append is a link to all sorts of CMOD doc.
What you're most interested in right now is the 9.5 README.
Ed
-
This has been observed a couple times now:
ARSLOAD always wrote its program messages to SYSPRINT. We're now
seeing output on SYSOUT as well. Is this the long term plan? Anyway to
force all messages to SYSPRINT or another DD?
A possible workaround, not guaranteed:
ARSLOAD was changed so that error messages go to stderr, non-error
messages go to stdout. In a non-shell environment, the runtime sends
stderr to the LE MSGFILE specification, which defaults to the SYSOUT DD.
You can redirect stderr to stdout possibly via:
// PARM='/-V //DD:PARMDD 2>&1'
I think the 2>&1 has to be at the end of all the parms.
Ed
-
This came up in our CMOD webinar held today:
Just FYI --- starting at 9.5 you can now have multiple levels of the admin client on the same pc.
What allows that is now there's an extra qualifier on the install for Version 9.5.
So when you do a Start -> All Programs -> you'll see both
IBM OnDemand32 (just like you always have)
and now additionally
IBM OnDemand Clients V9.5
Note: only one prior-to-V9.5 client as always and only one V9.5 client..... for example you can't have 9.5.0.1 and 9.5.0.2 and 9.5.0.3 all at the same time.
Ed
-
The LONGPARM option comes with Z/OS 2.1 and a toleration PTF is needed to allow the parameter during link-edit.
OA41887 is needed to allow the OPTION LONGPARM. LONGPARM is a new option with z/OS 2.1
R750 PSY UA69330 UP13/06/11
R760 PSY UA69331 UP13/06/11
R770 PSY UA69321 UP13/06/13
R780 PSY UA69322 UP13/06/19
The module failing, ARSYSPIN, was changed at the 9.5 level to include the LONGPARM option.
Version 9.5
LINK-EDIT CONTROL STATEMENTS
---------------------------------------------------
SETOPT PARM(LONGPARM)
SETCODE AC(1)
ENTRY ARSYSPIN
Version 9.0
LINK-EDIT CONTROL STATEMENTS
---------------------------------------------------
SETCODE AC(1)
ENTRY ARSYSPIN
-
New in V9.5:
CICS client unified login
To allow CICSŪ users to logon without a password, define a profile in the FACILITY class to protect the ARS.CICSUNIF resource and grant users READ access. Only users that are allowed to view documents by using the CICS client should be allowed access to this resource. Specifically, users with Content Manager OnDemand administrative capabilities should be prohibited from using this resource. That is because the authentication used for the CICS client is not as strong as PassTickets. More specifically, the UTOKEN of the CICS client is sent to the server. This UTOKEN is then converted to external format by using a RACROUT REQUEST=TOKENMAP and examined. If the UTOKEN appears correct and is permitted read access to the ARS.CICSUNIF resource in the FACILITY class, the login is allowed.
https://www.ibm.com/support/knowledgecenter/SSQHWE_9.5.0/com.ibm.ondemand.configuringzos.doc/dodzc646.htm (https://www.ibm.com/support/knowledgecenter/SSQHWE_9.5.0/com.ibm.ondemand.configuringzos.doc/dodzc646.htm)
Ed
-
Starting at 9.5.0.3 SMP/E is going to call for updated LE PTFs.
I talk about that here:
http://www.odusergroup.org/forums/index.php?topic=1734.0 (http://www.odusergroup.org/forums/index.php?topic=1734.0)
Ed
-
If CMOD V2.1 migrated documents exist on the system you need to run the bind steps from SARSINST(ARSCTBL1):
//ARSLDOCG EXEC ARSBPLAN,MBR=ARSLDOCG ** BIND DOC RETRIEVAL PLAN
//ARSKDOCG EXEC ARSBPKG,MBR=ARSKDOCG ** BIND DOC RETRIEVAL PACKAGE
The error received when trying to view one of the migrated documents will look like this:
ARS0024E #1965 Object >7LLGA< in Application Group >RHA< not found in
node >OD390V21< Srvr->9.56.0.250 9.56.0.250 non-SSL<-
ARS0432E #1965 V2/IAFC OAM Error: ARSZDOCG: 00000017(00000010) SQL
ERROR: SQLCODE = 00000812 VARIABLES = ARSZDOCG.19BABFE407618C71
ARSZDOCG, Return Code=23, Reason=0, File=arssmsms.cpp, Line=1893 Srvr-
>9.56.0.250 9.56.0.250 non-SSL<-
Ed
-
Here's one that tripped us up.
Contained in this doc is info that's not in the HOLD ACTION inside the PTF:
http://www-01.ibm.com/support/docview.wss?uid=swg1PI41677 (http://www-01.ibm.com/support/docview.wss?uid=swg1PI41677)
As part of the rollup, the way docids are formed has been
changed to prevent them from being inadvertently manipulated.
This functionality makes use of the CSNBOWH ICSF callable
service. All users (preferably groups) of these docids need
to have READ access to the CSFOWH profile in the CSFSERV
class. Lack of access will be indicated by ICH408I messages
for CSFOWH CL(CSFSERV ).
This currently impacts users of the Java ODWEK API.
We had one little used test system that after it was upgraded to 9.5.0.3 we couldn't see at first why Java ODWEK API testcases were failing.
It's because we needed to define READ access to the CSFOWH profile.
Ed
-
This doc is in addition to what's inside the PTF:
http://www-01.ibm.com/support/docview.wss?uid=swg21978908 (http://www-01.ibm.com/support/docview.wss?uid=swg21978908)
Ed
-
Had a report from a customer upgrading to V9.5.
ARSSOCKD abends immediately after starting with S0C4 and -924.
Also noted was a S0C4 in DB2, in DSNAOCLX.
A S0C4 dump was captured and DB2 analyzed that the PSW was pointing here:
....ACTIVMON++TSBAHDRV++
++10.05.02++20141226++09.53+++
+++Copyright (c) 2011-2014
Tomium Software LLC. Use and/or
distribution of this proprietar
y program product is prohibited
without express, written permiss
ion of Tomium Software LLC. 1-51
2-241-7300 ..}..........{
The Imperva product was disabled and everything worked fine thereafter.
I have no news on a fix for this. If you're in this situation you'll have to contact that vendor.
Ed
-
I learned today that at least at the latest service levels:
CMOD V9.0 will start and run without the CSF started task being up and crypto initialized (though you won't be able to use a stash file)
CMOD V9.5 will suffer the following abend if crypto isn't up:
CEE3204S The system detected a protection exception (System Completion Code=0C4).
From entry point ArcGSKOD_Init at compile unit offset +000011A8 at entry offset +000011A8 at address 0EF757A8
Ed
-
arsdoc went from 31-bit in 9.0 to 64-bit in 9.5. All the pointers doubled in size, so it takes more 31-bit memory.
V9.5 arsdoc will also use memory above the bar (64-bit land) which V9.0 did not, so do not limit that storage if virtual storage is a concern.
Ed
-
In 9.5, arsload (running in batch) puts out a lot more informational messages then previous levels - so many messages that if they all showed up in SYSPRINT running development determined they would or could be overwhelming.
So only a subset of the 9.5 arsload messages are displayed when running as an STC unless there is a load failure.
If the load fails then all of the messages are put out to aid diagnosis of the load failure.
-
ARSODF proc - starting at 9.5 the "-S" parm is required to start ODF.
Ed
-
Seeing this at logon time after implementing a new ARSUSECX -
Error message at logon
"The server failed while accessing folder data"
Error in the system log
"The userexit >/usr/lpp/ars/ed/exits/arsuperm< failed. The return code is -1"
If you have defined in your ars.cfg a custom location for exits, for example:
ARS_USER_EXITS_DIR=usr/lpp/ars/ed/exits/
And of course, there was no arsuperm in that directory of any kind.
But - if you have a modified ARSUSECX, ARSUSECX calls arsuperm and because of the config setting it will look for an arsuperm in that location.
Use SARSINST(ARSUPERJ) on sample exit SARSINST(ARSUPERM) to create member arsuperm in that directory.
After an arssockd recycle voila!, problem resolved.
So the net of it is that if you have a custom ARSUSECX you must ensure that your ARS_USER_EXITS_DIR is populated with an arsuperm.
Ed
-
Symptom: arsload fails with U4088 rc=78 in ArcCSX_UpdtExit program ARNCSX
Cause: Pre 9.5, the arsuupdt DLL was non-xplink, and the rest of arsload was
xplink, requiring a stack swap. Starting at 9.5, both arsload and arsuupdt are
xplink, avoiding the swap.
Quick cure: Recompile a non-XPLINK version of ARSUUPDT. Using the COBOL ARSUUPDC for the arsuupdt executable makes that dll non-xplink again.
Longer term: Whoever provided the custom code will have to update their version according to this doc:
https://www-01.ibm.com/support/docview.wss?uid=swg21978908 (https://www-01.ibm.com/support/docview.wss?uid=swg21978908)
Ed
-
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