CA7 load fails with an ACF2 security violation if the job prefix is renamed
Article ID: 441505
Updated On:
Products
Issue/Introduction
When LOAD is performed in CA 7, the load fails with security violations if the job is renamed to a different prefix. The job appears in the ready queue with JCLERR under a different name, such as ABCD#### (where #### matches the CA 7 job number). The CA 7 stc logs show multiple security violations for these renamed jobs, resulting in task cancellation due to lacking the necessary security permissions in ACF2.
Example of security violation messages in the CA 7 STC when using ACF2.
ACF99913 ACF2 VIOLATION-08,06,####,,####.####.####.####.####,N/A
Environment
Release: 12.0, 12.1
Component: WA CA 7 Edition
Cause
The issue arises from the LDJOBNM keyword in the DBASE statement of the CA 7 initialization file. When this keyword is set (for example, to ABCD), CA 7 renames load-only jobs to a format consisting of that prefix followed by a four-digit job number.
Because these renamed jobs often execute under a default or specific batch ID that lacks the necessary ACF2 security permissions for the datasets mentioned in the original job, the system triggers security violations and cancels the task execution.
Resolution
To resolve the load failing issues, you must stop CA 7 from renaming the load-only jobs so that they execute under their original names and security contexts.
- Locate your CA 7 initialization deck (init file).
- Find the DBASE statement.
- Remove the LDJOBNM keyword and its assigned value (e.g., LDJOBNM=ABCD).
- Save the changes to the initialization deck.
- Restart the CA 7 started task to apply the configuration change.
Once removed, load jobs retain their original job names and run under their intended batch IDs, satisfying ACF2 security rules.
Additional Information
Feedback
