After the security group granted access to trace access issues, then took it away and issued the security reload on all LPARs, thousands of the GSV4204I messages started to appear on the other LPARS in the SYSPLEX in STC SYSVUSER.
The only way to resolve it was to recycle SYSVUSER on the other LPARS.
Release : 15.0
Component : SYSVIEW
From the STC log that was Sent in we can see: (Take note of the AET)
userid Ent: FACILITY/SV.USER.XXXX.YYYY.OPSOSF AA: 02 RC: 04-04-00 NOLOG AET
userid Ent: FACILITY/SV.USER.XXXX.YYYY.OPSOSF AA: 04 RC: 04-04-00 NOLOG AET
The AET field entries come from SECURITY;
In the External Security Section of the group to which the UserId belongs
Access Entity Table Size (KB) 256
The field description states: Access Entity Table Size :
The initial size of the SAF Access Entity Table (AET).
The AET is used to cache responses to SAF calls so they can be retrieved by subsequent calls for the same entity name.
Using the AET will improve performance. The size of the AET is specified in K. AET storage is allocated above the 2G bar.
If you specify a value of zero, no AET will be used.
Since the internal customer was executing Cross System commands the XSDS task was being used inside of the SYSVUSER STCs on each LPAR that is connected in the PLEX. The SYSVIEW XSDS subtask runs in the SYSVUSER address space. An alternative to stopping all of the SYSVUSER address spaces would have been to STOP / RESTART the XSDS tasks inside of the SYSVUSER STCs from the ASADMIN primary command on each of the LPARs.