9.5 Release notes

[Ed_Arnold]

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 

[Ed_Arnold]

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

Ed

[Ed_Arnold]

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