Actually the only possibility to control the events for external security is the parameter EXTSECSHOW who should be set to on, resulting in the messages OPS2109T.
OPS2109T *CKSAF: <userid> <class> <prefix>.<rname>[.<ext>] <access> RC=<SAF rc> REASON:<reason>
In the design, SMF records 80 for RACF and RACF messages (ICH - IRR) are suppressed.
More in the design of OPS/MVS the resource (<prefix>.<rname>[.<ext>]) in the message OPS2109T is truncated to 44 positions.
But the design of external security OPS/MVS provide the possibility to implement the full control on some resources by profiles as:
Using this possibility 44 positions is too short, the more that the message is based upon the resource.
As final result of a case, we received the answer:
The 44 limit is an integral part of the design of the resource handling so extending it would be a major architectural change we cannot undertake as a defect.
Personally I see 3 possibilities for enhancement
- Provide us the possibility to obtain SMF records 80 for RACF users (if possible combined with the RACF messages)
(as asked before)
- Extension of the 44 limit. That's also the reason why we use the RACF Class XFACILIT instead of the proposed
FACILITY Class (limited to 39 positions) for OPS/MVS (both external and internal rules)
- Possibility to create SMF records without the need for a message rule on a translated OPS2109T message (OPS2109J).
Turning the parameter EXTSECSHOW to ON results in happy vendors of external memory, but without the parameter
OFF we have no possibility to solve problems with external security
Actually we create SMF records for both external and internal security, based upon the instructions of OPS/MVS with
As Result of the PTF, solving the broken link in the SECURITYLOG-parameter, we don't use the EXTSECSHOW anymore, as we encountered problems with the OPSLOG.
But the problem stay the same, especially with the GLOBAL Variables. The resource is truncated and SAF checking is done on the truncated resource. (We use RACF, but TSS-users has the same problem)
For the Global Variables we already need 24 characters for the base resource (OP$MVS.OPSGLOBAL.GLOBAL.), leaving us only 20 characters, including decimal points for the variable.