This may happen the system protects JES2 resources by having resource class JESSPOOL active in RACF and also the JCL for the Web Services started task has any DD statement defined as SYSOUT. For example, //BSTERR DD SYSOUT=*
The reason is that the spool datasets defined in the STC JCL are owned by the userid assigned to the started task (because they are allocated by MVS during the initialization of the STC). Later on, during processing of the Web Services requests, the userid is swapped to that of the client (for example, the MVS userid specified in the Eclipse Plugin).
If endevor or any user program (processor step program or user exit) try to write to any of these ddnames, it means that aone user (the client's ID) is trying to update spool dataset(s) owned by another user (the started task user). If the client is not authorized to do that, this will result in a security violation similar to the following:
ICH408I USER(USER01 ) GROUP(GROUP01) NAME(DOE, JOHN) 150
INSUFFICIENT ACCESS AUTHORITY
FROM MVS01.** (G)
ACCESS INTENT(UPDATE ) ACCESS ALLOWED(READ )
$HASP708 WSEWSSTC EN$DPMSG OPEN FAILED 151
RC=11 AUTHORIZATION FAILURE
IEC150I 913-74,IGG0199G,WSEWSSTC,WSEWSSTC,EN$DPMSG 152
The violations can be cleared by giving the client userids authority to update spool datasets owned by the STC userid as described in RACF Security Administration Guide.
For reference, the resource names in the JESSPOOL resource class are built as follows:
- JES2 node ID
- Owner ID (the userid associated with the Web Services STC)
- Jobname (name of the Web Services STC)
- Jobid (specific to each particular run of the STC)
- Spool dataset ID (specific to each ddname within the JCL)
- (optional) Value specified in DSN= parameter in the DD statement. If none, contains a question mark.