Do you allow everyone in your site to access your production CV's SYSCTL file or just certain group(s) of people?
If you have it secured from access by anyone, why?
What are you accomplishing by restricting access to the file?
If you do not restrict access, do you have security measures in place within the CV to stop unauthorized rununits from being started in the CV?
If so, what mechanism are you using to determine a batch rununit's worthiness of being allowed to access the CV?
Thanks to any and all that answer.
We give READ access ONLY to IDs defined as batch production – NO USER has ANY access
We have a system setup called ONE-SHOTS where a user can run an adhoc update vs prod – but under a prod ID (with mgr approval)
Technology Architect, Database Infrastructure Services
Technology Solution Services
123 East Main Street
Louisville, KY 40202
(502) 714-8615, (502) 476-2538
SYSCTL is secured in the production environments, except for the DBA group and production batch ID's. We further secure database files for production to batch ID's only. Batch ID's can only be submitted thru our scheduling utility.
The site I (until recently) worked at secured rununits via ACF2 using exit 14. I'm not sure what restrictions were on the SYSCTL file, but I think it was fairly open.
On a BIND Run unit, Exit 14 would issue a #SECHECK on a special resource type with the resource name of the subschema. The user needed execute authority to proceed. On a ready area, exit 14 would check that the user had select authority (if readied in ret) or update authority (when readied in update) on a different resource type with the resource name of the area. If the user failed the #SECHECK, a message was written to the log and the run unit terminated with a xx10 error code.
This required special entries in the SRTT to map the resource types to external security.
There were different resource types for batch and online, though they only had it active for online in one application. The overhead of all the security checks for a busy online environment was too much and the application & OLQ security was sufficient anyway. Each CV could have different rule types, though they shared some across similar CV's to reduce admin effort.
This did allow quite fine control over what each user could do. It could be setup so that a user could only bind batch run-units using certain subschemas and/or ready only certain areas. But the reality was that it was not necessary to have that level of control and most of the security definitions would have been wild carded and authority granted to groups to keep admin overhead to a minimum. The authority to ready areas in update was quite restricted.