Special Usage Considerations › Security Prevalidation

Security Prevalidation

This section describes:

• Security prevalidation
• CA JCLCheck checking with security prevalidation
• Overview of calls to CAISSF
• Interface limitations

Security prevalidation is available for CA ACF2, CA Top Secret, and any SAF-compatible product (for example IBM RACF).

CA JCLCheck uses the CA Standard Security Facility, CAISSF, (a CA Common Services for z/OS common service) to make generic service calls to prevalidate the security environment for a job. This allows CA JCLCheck to verify access authority to resources ahead of time, based on the actual security user who executes the JCL, not the security environment of the person running CA JCLCheck. This feature is especially useful for the on-demand requests that use special data sets and resources.

CA JCLCheck only performs this validation if you specify the SECURITY option.

Note: For more information about this option, see the Command Reference Guide.

CA JCLCheck, using service calls to CAISSF, dynamically recognizes the appropriate security environment. Therefore, you do not need customized installation procedures as long as you install the appropriate level of CA ACF2. The dynamic installation of the CAS9SAFC module (which is provided with CA Common Services for z/OS) provides SAF support (also IBM RACF support). See the cover letter for the appropriate service level and genlevel of CA Common Services.

CA JCLCheck provides the following types of security prevalidation on these products:

CA JCLCheck imposes limitations on the security calls that are made ahead of time. CA JCLCheck performs security checks in this prevalidation process based on information derived from the JCL it is scanning. This is the only information CA JCLCheck has available. For example, CA JCLCheck only knows the job-step level program and cannot know the actual program in control, or the RB structure, when it opens a data set. This limits the ability to perform program pathing resource checks at DATASET OPENS. Another example is that CA JCLCheck cannot interpret the type of OPEN to perform when a program accesses a data set from the DISPOSITION alone. In the cases where the program specifies DISP=OLD/SHR, CA JCLCheck assumes the most restrictive access level and makes that call accordingly. If UPDATE access is not granted, CA JCLCheck assumes READ ACCESS and makes another call to validate this access level, with messages indicating these assumptions.

There are also many variances in security calls based on operating system levels and the actual products and programs that are executing. This imposes limitations on security calls, as well. For example, limitations of SAF and parameters supported on the RACROUTE macro make it impossible to do certain prevalidation checks, which are available by the simulation services available in CA ACF2 r6.0. SAF/RACROUTE cannot validate the date and time of signon for some future date, but these features are available with CA ACF2. The restrictions are noted following.