Security prevalidation makes three calls to CAISSF: VSIGNON, VRESCHECK, and VSIGNOFF. When CA JCLCheck encounters a JOB statement, it makes a virtual signon call to CAISSF that sets up a security environment appropriate to the security user who executes the JCL. If necessary, CA JCLCheck provides you with user exit CAZ1SSFX, which allows site-specific customization of the security user ID. CA JCLCheck only uses this security environment for validation checks, and it is not possible to use it to obtain access to protected resources. It is possible, therefore, for an individual in production control to validate the JCL security environment, and not have any form of access to the secured resources.
Once a VSIGNON request completes successfully, CA JCLCheck processes each JCL statement and performs virtual resource checks (VRESCHEK). These calls perform the appropriate security environment checks, which are appropriate according to the JCL and active security product. CA JCLCheck checks the DATASET, PROGRAM, DASDVOL, and SMS class resource levels.
CA JCLCheck performs virtual signoff (VSIGNOFF) once it makes all the VRESCHECKs. This call defines all acquired storage and the security environment defined at VSIGNON time.
In an SMS environment, access to the SMS classes is based on the resource owner of the data set and not the person actually allocating the data set. In this situation, CA JCLCheck performs a VSIGNON call for the resource owner of the data set, if it is someone different than you running the job. This resource owner may or may not be the same as the high-level qualifier of the data set, and if not, the VSIGNON is held in the DFP portion of the security profile. The high-level qualifier of the data set is only available to this interface, and CA JCLCheck assumes this is the resource owner. CA JCLCheck performs the VSIGNON call for SMS classes using only the high-level qualifier as the resource owner for new data sets.
|
Copyright © 2014 CA.
All rights reserved.
|
|