ACF79542, ACF79540 and ACF79508 seen after GSO REFRESH command issued.

Products

• ACF2 - z/OS

Issue/Introduction

When attempting to perform a GSO refresh of STCs across all LPARs on an ACF2 SysPlex, a contention issue is apparent.  One or more of the following messages are seen in the syslog:

o   ACF79542 SHORT TERM USER(S) OF ACF2 CONTROL BLOCKS RUNNING    

o   ACF79540 GSO REFRESH CAN NOT BE SERVICED AT THIS TIME         

o   ACF79508 ERRORS DETECTED DURING GSO PROCESSING                

Environment

Release : 16.0

Component : ACF2 for z/OS

Cause

It is possible that the execution of code developed based on code samples provided in the CAX1SAMP dataset is the cause.

One example of such code centers around the use of the ACALT SVC. The user/vendor developed code issues an ACALT call with a masked UID and requests that ACF2 return userIDs which match the mask value.  This causes the SVC to read a large part of the LOGONIDS database until a match is found there are no more records to read. In this example, the ACF2 GSO REFRESH processing suspends any new ACF2 SVC's from being issued and waits for up to 5 seconds for any active ACF2 SVC's to flush out.  The GSO REFRESH failure is direct result of the long-running ACALT SVC.

Resolution

To alleviate potential contention issues, it is advised the user/vendor code specify individual userID's (instead of masking) to ensure rapid entry and exit from the ACF2 SVC. The code then compares the UID-string returned to see if it matches the search criteria.  Much less time is spent in the ACF2 SVC - this provides greater opportunity for the GSO REFRESH to take effect without needing to stop user/vendor coded processing. The ACALT PLIST now appears as:

ACASFCN = ACASIRT
ACACNTL = ACACMSK
ACALID = ********