Auditability Restrictions with Batch Applications

Shared user IDs present an auditability concern when used in conjunction with VM's alternate user ID function, which is implemented by Diagnose D4.
  • VM's batch processing does not consider that a user submitting a job may be shared.
  • Because jobs are submitted using SPOOL files, it is possible that the submitting user has logged off before the SPOOL file gets processed by the batch machine. In this case, the batch machine does not have the option of issuing a Diagnose 26C subcode 4 to obtain the surrogate user ID. Therefore, if worker machines work on behalf of shared user IDs, the result is a loss of auditability for the user ID that is logged on to the alternate user ID as shared.

An installation can decide whether shared user IDs can be used as alternate user IDs.

  • If the installation chooses to ignore this auditing concern, no action is necessary.
  • If the installation wants to prevent a shared user ID from submitting a batch job, you can do this by:
    1. Turning on control for the Diagnose D4 event in the currently active VMXEVENT profile. This ensures that RACF controls the use of Diagnose D4.
    2. Defining the VMBATCH profile for that shared user ID so that no user ID can access it. This prevents a Diagnose D4 from successfully specifying the shared user ID as an alternate user ID (see CP Programming Services for a description of Diagnose D4).
Note: An installation may want to enforce this restriction only for certain batch applications. In this case, you can create individual VMXEVENT profiles for the user IDs running these batch applications without Diagnose D4 being controlled. If Diagnose D4 is controlled in the system-wide VMXEVENT profile, the batch restriction is bypassed only for those few applications.

If an installation wants to enforce this restriction only on certain shared user IDs, you can modify only the VMBATCH profile for those specific shared user IDs, assuming Diagnose D4 is being controlled.

Attention:

If Diagnose D4 is not controlled by a given installation, this type of auditability is not possible for that installation when the SURROGAT class is activated, unless the appropriate steps are taken.