Security violations when allocating by JCL temp datasets to be used by Endevor processors

Products

• Endevor

Issue/Introduction

A site might choose to allocate ddnames for workfiles that are frequently used in Endevor processors (like SYSMDECK or SYSUTnn) via JCL instead of letting them be dynamically allocated by Endevor. The reason would be to save the overhead related to dynamic allocation and deallocation.

This practice may cause security violations (messages ICH408I INSUFFICIENT ACCESS AUTHORITY and IEC150I with abend S913-38)

Cause

These violations and open errors are expected when:

• The datasets are defined as temporary in the JCL
• RACF TEMPDSN resource class is active to protect temporary datasets
• The ddname is opened by an user other than the one that runs the JCL

The ddname is expected to be opened by a different user in the following situations

• In batch actions, for processor steps executed with ALTID=Y (the default) which causes disk datasets to be opened under the security scope of the alternate ID
• At any time for actions executed via the Web services.

The background reason is that RACF considers the temporary datasets to be owned by the userid that allocated them. For batch actions, this is the userid assigned to the job. For web services, this is the userid assigned to the web services STC. The violation occurs when any other userid tries to access the dataset (either the alternate ID or, in the case of Web Services, the requester ID) 

Resolution

There are two possible ways to solve this issue

• Allocate the DDs as permanent datasets with DISP=(,DELETE,DELETE) with a high-level qualifier that any userid (including the alternate ID) is allowed to read or update
• Allocate the work datasets with UNIT=VIO

To allocate permanent datasets, the DSN must be designed to be unique to prevent dataset name contention, which is especially possible for Web Services started tasks as the "STC pooling" feature is known to start several tasks during the same second.

A DSN like DSN=hlq.&DYYMMDD,&THHMMSS.&SYSJOBID will comply with this requirement since &SYSJOBID resolves to the MVS jobid (JOBnnnnn or STCnnnnn) which is unique within a particular second

UNIT=VIO will also work as VIO datasets simulate disk I/O using the paging space without actually creating any dataset and therefore without triggering RACF protection.

It's important to note that, even though UNIT=VIO is requested in the JCL, DFSMS component might still change the allocation to DASD. You need to ask your disk administrator what to specify in the JCL to ensure that your temporary dataset is not changed to DASD