Under which circumstances message TSS7188I is generated
search cancel

Under which circumstances message TSS7188I is generated


Article ID: 95050


Updated On:


Top Secret Top Secret - LDAP


The command  TSS REFRESH[(acid) [JOBNAME(job|*)]] is used to renew the ACIDs in any address space in the security environment.
Once the acid has been refreshed the following message is generated:
TSS7188I J=jobname A=aceeusi @AC=xxxxxxxx @NSR=xxxxxxxx @OSR=xxxxxxxx
However there are times where the message TSS7188I seems not related to any TSS REFRESH command.

Under which circumstances is the message TSS7188I issued?


Component: TSSMVS


The command TSS REFRESH is used to renew the ACIDs in any address space in the security environment. As a result, the user does not need to log off and log back on for administrative changes to take effect. The message TSS7188I is issued when the acid is refreshed, which is the next time a security call is made for that acid. This can be significantly later than when the TSS REFRESH command was issued.

The following 4 scenarios describes when a REFRESH of an ACID can be driven. The first one is explicit based on the entry of a TSS
command, the other 3 are all implicit and are driven when a change to an ACID is noted along with a desire to immediately bring that change into core if the user is currently logged on:

1. TSS REFRESH command - This is the only explicit form of a REFRESH and can take several forms. A TSS REFRESH with no other operands refreshes the current user, and this form is NOT written out to the recovery file. A TSS REFRESH with the ACID(xxxxxx) operand targets a specific user, and this form will always write a change record out to the recovery file.

2. Application Interface FLDUPD - An implicit REFRESH is performed if an application interface request is made to update an FDT defined field (FLDUPD), we set the REFRESH bit to insure the target ACID is updated to reflect the field change.

3. Auto UID assignment - An implicit REFRESH is performed if our internal SAF processing determines that a user is attempting to use USS / OMVS services and they do not have an OMVS segment / UID assigned. The REFRESH bit is set to insure the current user reflects all the required OMVS segment data to correctly initiate OMVS processing.

4. RACROUTE VERIFYX - An implicit REFRESH is performed when certain conditions are met during handling of a RACROUTE VERIFYX request.

All of the above scenarios will drive REFRESH processing at the next resource validation event for the user, triggering the TSS7188I message.

These are the only 'expected' forms of REFRESH. We say this because the REFRESH flag is contained in the user ACEE storage block and any unintentional update of this bit by TSS or any other application could cause a REFRESH when it is not expected. Of course this would be difficult to detect and would require tracing and trapping if we thought it was happening.