Abend S0C1 in module TSSD130 Using a SVC to call TSSAI.

Products

• Top Secret
• Top Secret - LDAP

Issue/Introduction

SVC 235 is calling the TSSAI to validate if the program is authorized for use this SVC or not.

The SVC 235 is issuing TSS application interface call with the following parms:

TSSHEAD=TCPLV4L4
TSSCLASS=$AXY
TSSRNAME=SVC.DFSRRC00

When there are several SVC 235 executed concurrently it is possible to see an abend S0C1 in module TSSD130.

For example:

TCB 899400 starts the call to SVC 235 (X’EB’) and at the same time invoke TSS (TSSAI module). During this sequence GETMAIN returns the address x'7A000 '.

Then TCB 899500 call to SVC 235, invoking TSSAI too, and GETMAIN returns the address x'7B000 '

Later, when the TCB 899400 is ending its execution, once the access to TSS is done, the FREEMAIN releases the address x'7B000 ' ,which corresponds to the TCB 899500,  instead of the address x'7A000 '.

This produces an abend 0C4 or 0C1, because when the memory area is released, its content is undefined when the TCB 899500 tries to use it.

 

Environment

Z/OS 2.2
CA Top Secret 16.0
IMS V13

Cause

Although TSSAI is RENT module, the TSS/IMS module that it calls to locate an ACEE is NORENT thus the problem you are running into.

Resolution

Instead of a TSSAI call, issue a RACROUTE REQ=AUTH, for CLASS=$AXY, ENTITY=SVC.DFSRRC00,USERID=xxxxx where xxxx is the ACID that you want be validated.  Internally when TSS process the third-party racroute call will drive a signon for the acid specified.