AutoSys Workload Automation

We are looking to move to RACF as our external security to avoid bouncing CA7 for updates to take affect. One question - the ESNAME is the same for several different things. When I RDEFINE L2DB1 to RACF do I also need to add DBMENU, JOB, etc... or just RDEFINE the ESNAMES?

DB.A.M.C SDM0 00 L2DB1

DB.A.M.D SDM0 00 L2DB1

DBMENU   SDM0 00 L2DB1

FTPMENU  SDM0 00 L2DB1

JAVAMENU SDM0 00 L2DB1

JOB      SDM0 00 L2DB1

OMMENU   SDM0 00 L2DB1

ORACMENU SDM0 00 L2DB1

SAPMENU  SDM0 00 L2DB1

SNMPMENU SDM0 00 L2DB1

XPJOB    SDM0 00 L2DB1

XPSMENU  SDM0 00 L2DB1

DB.2     SDM0 00 L2DB2

SCHD     SDM0 00 L2DB2

You're right. You just have to RDEF once the RESNAME.

How would you handle externally with RACF the following:

The "Schedule Group" can only add, update, and delete the jobs from the JOB or AGJOB Panel but the "Operators Group" can only update these Panels to point to the JCL override lib, EXEC=N, etc...?

Thanks,

Stephen

In your case the "Schedule Group" will need CONTROL on the resource L2DB1 and "Operators Group" needs UPDATE on the same resource.
See below how you can determine that.

You need to look at the Security Guide, Appendix A Security Tables.  Here you will have 4 tables.

* Panel-ID and Command tables will provide you the link between Resource names and panels / commands.

* Function and Service Level Table:  here CA provides you the link between what they call Functions and what they call a Service Level.
For example on DB.1 you can ADD,DELETE,DD,PURGE,DELPRRN,FORMAT,LIST,UPD so these actions are called Functions.  They will be linked to the a specific Service Level.
ADD     >> ADD
DELETE  >> DELETE
DD      >> DELETE
PURGE   >> PURGE
DELPRRN >> UPDATE
FORMAT  >> N/A
LIST    >> READ
UPD     >> UPDATE

* Access Level Translation Table:  here CA translates the above Service Level to the different Security Product (RACF, ACF2,Top Secret, ...) access level (so for RACF: NONE, READ, UPDATE, CONTROL, ALTER)
So the Service Level for
ADD    is CONTROL
DELETE is CONTROL
UPDATE is UPDATE

...

HTH,
Alx.

That makes it very clear.

Thanks for the info.

Stephen

As I look deeper into our conversion from Internal CA7 Security to External CA7 Security using RACF, another question based on the above answer -

On the JOB screen we only want the "Operators" to be able to UPDATE the JOB screen to set the USE-OVRD-LIB=Y, etc... so they will need UPDATE authority but we don't want them to be able to DELPRRN which also uses UPDATE authority. Is there a way to control that? I believe the same applies to the JOB SCHEDULING screen. If we only give READ access to DB.2.1-E - L2DB21E - will that prevent "UPDATES" on this screen? I have some cloudiness and was wondering also if I allow read only access to L2DB27 (schdmod) command. Will this prevent the Operator from doing an UPDATE?

There is no 'field level' security for any screen in CA 7--the access (READ, UPD, etc.) is to the FUNCTION on that screen--and as you stated, once UPD authority is given, you can update any field.  There is an exit point called when adding or updating jobs that you can use to disallow if you want (according to input)...Job Data Verification - SASSXX10 (documented in the CA 7 System Programmer Guide).

Giving only READ type access to any panel will only allow LIST type functions (FE or EDIT for JCL or schedules--you would be able to FE a schedule or JCL member, but not SR it).

Yes, only giving READ access to the L2DB27 resource will allow LIST on the SCHDMOD screen and no UPD.

Thanks Marysue for the clarity. DELPRRN is only cleaning up a trailer queue so it shouldn't be of any concern.

Once again, thanks for the excellent customer support!

Stephen