IMS access to ACF2 LIDREC via MFS exits
search cancel

IMS access to ACF2 LIDREC via MFS exits

book

Article ID: 253286

calendar_today

Updated On:

Products

ACF2 - z/OS

Issue/Introduction

We have some user fields in the LIDREC (and also implemented to the compressed LIDREC) that we need to access in IMS MFS exits to provide detail to the transaction users via the transaction data. At present, the compressed LIDREC is anchored off the CTB in field CTBRACFT making it relatively simple to obtain the LIDREC details

it can be seen that the CTBRACFT field is no longer used to point to any ACF2 control blocks (the address is zero) - where is the LIDREC detail now kept? As we are setup as a SYSPLEX is it all stored in the structure? Is there anyway we are able to obtain the detail we require? 

Would you have any suggestions/recommendations on how we would be able to obtain the LIDREC detail. The only way I can think of is to perform RACFROUTE VERIFY and DELETE calls in the MFS exits which is not an ideal place to perform this type of processing.

Environment

Release : 16.0

Resolution

Looking through older cases, seen reference to using the ACF2/IMS signon exit to locate the ACMCB and MLID and then populate the addresses into the CTB.
Will need to test this, as it relies upon getting access to the CTB in the exit which is not a standard control block that is passed to the exit.
The logonid would be an MLID that is referenced by the @MLID macro in the ACFFDR.
May be able to issue an ACFSVC request to list the logonid - using an ACALT request block, but there may be serialization or performance concerns.

You could use the logon post exit to locate the logonid which will be in mlid format and passed in the exit parameter list.
You could then locate ctbbase and store the address of the mlid for future use in the same field you used to use CTBRACFT.

Client can use the SIGNON-Sign-on exit,  should contain the information they need to be able to store the logonid information.

 

At present the client is going to continuing with the RACROUTE VERIFY/DELETE solution however they will keep this suggestion in mind if we need to change