Security checking in JCLCheck Workload Automation.
Article ID: 53738
Updated On:
Products
Issue/Introduction
JCLCheck requires READ access to all input sources on the validating JCL. By default, the userid submitting the JCLCheck job will be used for security pre-validation. This Knowledge Document describes the effect of using the SECURITY and USER runtime options, and what error messages to expect when security pre-validation fails.
Environment
Release: 12.0
Component: JCLCheck Workload Automation
Resolution
JCLCheck performs security pre-validation for security products such as ACF2, Top Secret, and IBM RACF. There are two phases of security check in JCLCheck:
- Phase 1 - syntax validation if the runtime option SYNTAX is used.
- Phase 2 - runtime validation if the runtime option RUNTIME is used.
Phase 1 runs under the security ID of the caller that initiated the JCLCheck job. The security system must allow JCLCheck READ access to all input sources such as JCL, procedure libraries, utility control members, catalogs, joblib, steplib, linklist libraries etc.
Phase 2 works the same as phase 1, unless the JCLCheck runtime option SECURITY is used.
If the SECURITY option is specified, this phase will run under the following security id:
- USER= id specified on the current JOB statement or
- userid on the JCLCheck runtime option USER(uid)
If a security violation is found during phase 1, error message "CAY6329W ACCESS DENIED TO dataset name BY SECURITY RC=nn ACCESS LEVEL=READ FOR ACID=userid" is issued.
If a security violation is found during phase 2, error message "CAY6321W POTENTIAL SECURITY VIOLATION DETECTED text ACID=userid" is issued.
To prevent USERID suspensions caused by security violations, use runtime option SECURITY(NOLOG).
Additional Information
Feedback
