You are on page 1of 111

CA Workload Automation EE

Security Guide
r11.3

This documentation and any related computer software help programs (hereinafter referred to as the "Documentation") are for your informational purposes only and are subject to change or withdrawal by CA at any time. This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. This Documentation is confidential and proprietary information of CA and may not be used or disclosed by you except as may be permitted in a separate confidentiality agreement between you and CA. Notwithstanding the foregoing, if you are a licensed user of the software product(s) addressed in the Documentation, you may print a reasonable number of copies of the Documentation for internal use by you and your employees in connection with that software, provided that all CA copyright notices and legends are affixed to each reproduced copy. The right to print copies of the Documentation is limited to the period during which the applicable license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed. TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION "AS IS" WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO THE END USER OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE. The use of any software product referenced in the Documentation is governed by the applicable license agreement and is not modified in any way by the terms of this notice. The manufacturer of this Documentation is CA. Provided with "Restricted Rights." Use, duplication or disclosure by the United States Government is subject to the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.227-7014(b)(3), as applicable, or their successors. Copyright 2010 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

CA Product References
This document references the following CA products: CA Workload Automation (formerly known as CA ESP Workload Automation)

Contact CA
Contact Technical Support For your convenience, CA provides one site where you can access the information you need for your Home Office, Small Business, and Enterprise CA products. At http://ca.com/support, you can access the following: Online and telephone contact information for technical assistance and customer services Information about user communities and forums Product and documentation downloads CA Support policies and guidelines Other helpful resources appropriate for your product

Provide Feedback If you have comments or questions about CA product documentation, you can send a message to techpubs@ca.com. If you would like to provide feedback about CA product documentation, complete our short customer survey, which is also available on the CA Support website, found at http://ca.com/docs.

Contents
Chapter 1: About This Guide 9
Overview ........................................................................................ 9 Who Should Read This Guide ..................................................................... 9 How To Use This Guide.......................................................................... 10 Entering Commands ............................................................................ 10 Entering Statements ............................................................................ 10 Continuation ................................................................................ 10 Comments .................................................................................. 11 Data Sets................................................................................... 11 Delimiters .................................................................................. 11 Indentation ................................................................................. 11 Wildcards in CA Workload Automation EE ........................................................ 11 Examples ....................................................................................... 12 Issuing Console Commands ................................................................. 12 Issuing OPER Commands .................................................................... 12 Issuing Commands in Batch ................................................................. 12 Subsystem Name ........................................................................... 12 Steplib ..................................................................................... 13 Conventions Used in This Guide ................................................................. 13 Input ....................................................................................... 13 Syntax Conventions ......................................................................... 13

Chapter 2: Introduction to CA Workload Automation Security

15

Types of Security Used in CA Workload Automation .............................................. 15 SAF Interface Security ...................................................................... 15 Standard Data Set Security ................................................................. 16 SAF Security.................................................................................... 16 Information Flow between CA Workload Automation and SAF ................................ 17 How the Security Process Works ............................................................. 18 How CA Workload Automation Interprets SAF Return Codes .................................. 18 Resource Rules ............................................................................. 19 Using SAF with CA ACF2 .................................................................... 19 SAF/ACF2 Support .......................................................................... 19 ACF2 SAF Examples ......................................................................... 20 Using SAF with CA Top Secret ............................................................... 20 Control Options File ......................................................................... 21 Started Task Table .......................................................................... 21

Contents 5

Started Task Acid ........................................................................... 21 ESPRES Profile .............................................................................. 22 Production Coordinators Profile .............................................................. 24

Chapter 3: Setting Up Security for CA Workload Automation

25

Getting Started ................................................................................. 25 User Access to CA Workload Automation ..................................................... 26 Basic Event and Application Security ......................................................... 26 Identifying the Batch Job User ID ............................................................ 26 How the User ID is Chosen for Batch Jobs .................................................... 27 Access to an Event Group ................................................................... 29 Execute-only Access to an Event Group ...................................................... 30 Access to Calendars ......................................................................... 31 Additional Event and Application Security ........................................................ 32 Access to an Application ..................................................................... 33 Access to a Job Within an Application ........................................................ 34 Execute-only Access to a Job Within An Application ........................................... 35 Access to View Entries In CSF ............................................................... 36 Access to Specific CSF Line Commands ...................................................... 37 Access to Specify an Event Initiator Class .................................................... 38 Access to Specify the USER(userid) Operand ................................................. 38 Access to Specify Data Sets In an Event ..................................................... 39 Access to Specify the OWNER(userid) Operand ............................................... 40 Distributed Workload Security ................................................................... 40 Host Security ............................................................................... 41 Access to Agents............................................................................ 42 Access to Passwords and Encryption Keys for Using Agents ................................... 43 Access to OPER Command MAPUSER ........................................................ 44 Communication Security .................................................................... 44 Agent Platform Security ..................................................................... 48 Command Security ............................................................................. 57 Access to Issue OPER Commands ............................................................ 58 Access to Issue z/OS Commands ............................................................ 60 Access to Utility Mode ....................................................................... 62 Access to Specific Utility Mode Commands ................................................... 63 Controlling CA Workload Automation Resources ................................................. 63 Access to Use the RESDEF Command ........................................................ 64 Access to Use the ABSORB Statement ....................................................... 64 Security for Variables ........................................................................... 65 Access to a Symbolic Variable Library ........................................................ 65 Access to a Global Variable Table ............................................................ 66 Security for Procedure Statements .............................................................. 66

6 Security Guide

Access to Use the EXPEDITE Statement ...................................................... 67 Access to Invoke REXX ...................................................................... 67 Job-Tracking Security ........................................................................... 68 Access to Job-tracking Information .......................................................... 68 Access to Job-tracking Models ............................................................... 69 Access to pnodes ........................................................................... 69 Access to Job-tracking Commands ........................................................... 70

Chapter 4: CA Workload Automation Security Profile Reference

71

About Security Profiles for CA Workload Automation .............................................. 71 Security Profile Access Levels ................................................................ 71 Undefined Profiles ........................................................................... 71 Using Wildcards to Specify Security Profiles .................................................. 72 Summary of CA Workload Automation Security Profiles .......................................... 72 CA Workload Automation Security Profiles ....................................................... 74 AGENT.agentname .......................................................................... 74 AGENTMSG.verbsubverb.agentname ......................................................... 74 AGENTUSR.userid.agentname ............................................................... 75 APPL.applname ............................................................................. 75 APPL.applname.jobname .................................................................... 76 APPLX.applname.jobname ................................................................... 77 CALENDAR.calendarname ................................................................... 78 CSF.CHECK.CMDS .......................................................................... 78 CSF.LC.cmd ................................................................................ 79 DSALLOC.dsname ........................................................................... 79 EVENTINITCLASS.nnn ....................................................................... 80 EXPEDITE.policyname ....................................................................... 80 GROUP.event_groupname ................................................................... 81 GROUPX.event_groupname ................................................................. 82 JOB.racid.jobname .......................................................................... 83 MODEL.modelname ......................................................................... 83 MVSCMD.mvs_cmd.options... ............................................................... 84 ONLINE..................................................................................... 85 OPER ....................................................................................... 85 OPERCMD.cmdname ........................................................................ 86 PASSWORD.userID.agentname .............................................................. 86 PNODE.pnodename ......................................................................... 87 RACID.userid ............................................................................... 87 RESABSORB ................................................................................ 88 RESOURCE.resname ........................................................................ 88 REXXON .................................................................................... 88 SETOWNER.userid .......................................................................... 89

Contents 7

SYMLIB.symname ........................................................................... 89 TJD.jobname ............................................................................... 90 UTIL.cmd ................................................................................... 90 UTIL.UTIL .................................................................................. 90 VARTABLE.tablename ....................................................................... 91

Glossary Index

93 105

8 Security Guide

Chapter 1: About This Guide


This section contains the following topics: Overview (see page 9) Who Should Read This Guide (see page 9) How To Use This Guide (see page 10) Entering Commands (see page 10) Entering Statements (see page 10) Wildcards in CA Workload Automation EE (see page 11) Examples (see page 12) Conventions Used in This Guide (see page 13)

Overview
The CA Workload Automation EE Security Guide covers setting up, administering and maintaining security for CA Workload Automation at your installation. CA Workload Automation EE (CA Workload Automation ) is a very powerful and versatile system for scheduling jobs and managing workload. To ensure that you can control access to your workload effectively, the Security Guide helps you set up basic security and then guides you through a more detailed set-up, if needed. Each procedure heading covers a task from a security administrator's point-of-view. This guide also has an introduction section and reference sections to support the procedures. This guide was written with the assumption that CA Workload Automation is already installed at your site. If CA Workload Automation was installed prior to 1995 and you are still using the original internal security, continue to refer to the Administrator's Guide Version 5.3.

Who Should Read This Guide


This guide helps those who set up, administer, and maintain CA Workload Automation security at your installation, including: Central security administrators CA Workload Automation administrators CA Workload Automation installers

Chapter 1: About This Guide 9

How To Use This Guide

How To Use This Guide


For background information on CA Workload Automation security, see the chapter Introduction to CA Workload Automation Security. For instructions on how to set up security for CA Workload Automation , see the chapter Setting Up Security for CA Workload Automation . For details on the security profiles used for CA Workload Automation , see the chapter CA Workload Automation Security Profile Reference.

Entering Commands
CA Workload Automation commands can be entered in line mode, page mode, batch, loaded from a data set (using the LOAD command) or CA Workload Automation Workstation. Many commands can also be entered from a system console. CA Workload Automation statements must be entered in a data set specific to the type of statement used.

Entering Statements
The content of this section also applies to commands and initialization parameters when contained in a data set.

Continuation
Type either a hyphen or a plus sign as the last non-blank character on a line to continue a line of input. The hyphen attaches the next line including any leading blank position. The plus sign strips leading blanks from a continuation line. Blanks preceding the hyphen or the plus sign are retained. Statements cannot extend beyond column 72. The continuation character can be placed in columns 72 or before. Note: A hyphen can also be used as a wildcard character. If the wildcard hyphen is the last character on the line, it will be interpreted as a continuation character and not as a wildcard. For the hyphen to be interpreted as a wildcard, it must be followed by a semicolon or something else on the line such as a comment: (/* */).

10 Security Guide

Wildcards in CA Workload Automation EE

Comments
Enclose comments between /* and */. Comments can be written anywhere in a CA Workload Automation procedure.

Data Sets
Enclose all data set names in single quotation marks, otherwise CA Workload Automation adds your TSO data set prefix to the name.

Delimiters
Use single quotation marks when you want to denote character strings and literal data in expressions, in assignment statements, and in built-in functions. You must include single quotation marks around a string that contains blanks.

Indentation
You can use indentation to improve readability.

Wildcards in CA Workload Automation EE


Many statements, commands, or initialization parameters permit the use of the following wildcard characters (also called masking): An asterisk matches a specific single character. A hyphen matches zero or more characters. It must be used as the last character of the operand. If the wildcard hyphen is the last character on the line, it will be interpreted as a continuation character and not as a wildcard. For the hyphen to be interpreted as a wildcard, it must be followed by a semicolon or something else on the line such as a comment: (/* */).

Example: Wildcards in CA Workload Automation To display all calendars, use the following command:
LISTCAL

To display all calendars with names containing XY in character positions three and four, use the following command:
LISTCAL **XY-

Chapter 1: About This Guide 11

Examples

To display all calendars with two-character names, use the following command:
LISTCAL **

Examples
This section contains command syntax examples.

Issuing Console Commands


To issue a command from the system console, use the MODIFY command, as in F ESP, where ESP is the started task name. For example:
F ESP, STATUS

Issuing OPER Commands


To issue a command that requires OPER authority, precede it with OPER. For example:
OPER STATUS

Issuing Commands in Batch


To issue a command in batch, use the following JCL after your job card:
//EXEC PGM=ESP,REGION=4000K //SYSPRINT DD SYSOUT=* //SYSIN DD * ESP WA command . . . ESP WA command

Subsystem Name
If the subsystem name for CA Workload Automation is not ESP, you need to type the subsystem name when entering a command in batch. For example, if the subsystem name is ESPA, type:
//EXEC PGM=ESP,PARM='SUBSYS(ESPA)',REGION=4000K

12 Security Guide

Conventions Used in This Guide

Steplib
If the TSO command processor is not in a LINKLIST library, you need a STEPLIB or JOBLIB statement in your JCL. Your statement looks like the following:
//STEPLIB DD DSN=CYB.ESP.LOAD,DISP=SHR

Conventions Used in This Guide


This section describes the conventions used in this guide.

Input
CA Workload Automation is not case sensitive. Even though commands are shown in uppercase, when you type a command on the command line, you do not need to type the command in uppercase letters.

Syntax Conventions
The syntax diagrams in this guide use the following conventions:

Notation Quote marks '' or ' Comma , Ellipsis

Meaning Must be entered as shown. Must be entered as shown. The operand can be repeated. Do not enter ellipsis. An operand must be substituted. User supplied variable or character string. The operand must be spelled as shown. You can enter the command and the operand in either upper or lower case. Indicates an exclusive value on left or right of bar. You must enter one of the items. You cannot enter more than one. If you do not enter one of the operands, the system supplies the underlined operand, this is the default

Lower Case Italics operand Uppercase operand

OR-bar ( | )

Underline _______

Parentheses ( ) and Operand enclosed in parentheses is mandatory and must special characters be entered as shown. Single operand in square brackets [ ] Optional operand, do not type the brackets.

Chapter 1: About This Guide 13

Conventions Used in This Guide

Notation

Meaning

Stacked operands in Mandatory, you must enter one of the operands. You braces cannot enter more than one. { { } }

Stacked operands in Optional operand, you can enter one value, or none. square brackets [ ] [ ] Operands with OR-bars ( | ) and square brackets [ ]|[ ] Stacked operands in Mandatory, you must enter one of these operands. You square brackets can enter more than one. within braces {[ ]} Optional, mutually exclusive operands. Enter one or none.

14 Security Guide

Chapter 2: Introduction to CA Workload Automation Security


This chapter gives you background information on CA Workload Automation security, so you can better understand the security setup chapters that follow. You'll learn how your host security package controls access to CA Workload Automation 's objects through the SAF (System Authorization Facility) interface. This section contains the following topics: Types of Security Used in CA Workload Automation (see page 15) SAF Security (see page 16)

Types of Security Used in CA Workload Automation


The host security package provides security to CA Workload Automation using the SAF interface.

SAF Interface Security


CA Workload Automation provides security for its objects through the SAF interface. The following are some CA Workload Automation objects: Events Applications Job information Calendars Resources CSF commands z/OS commands OPER commands Symbol libraries Agents

There are security profiles available in your host security package that control access to CA Workload Automation objects.

Chapter 2: Introduction to CA Workload Automation Security 15

SAF Security

More information: CA Workload Automation Security Profiles (see page 74) SAF Security (see page 16)

Standard Data Set Security


All CA Workload Automation data sets are protected by standard data set security. These data sets include the following: Operational data sets A JCL library that CA Workload Automation uses to submit jobs Procedure libraries where schedules are stored Job documentation libraries

SAF Security
CA Workload Automation uses the System Authorization Facility (SAF) to apply a consistent level of security to objects and functions. SAF is an IBM-supplied facility that is part of z/OS. Using SAF allows CA Workload Automation security administration to do the following: Conform to your installation standards. Provide a granular level of security. Provide a central point of administration.

16 Security Guide

SAF Security

Information Flow between CA Workload Automation and SAF


Information flows between CA Workload Automation and the database as follows:

Chapter 2: Introduction to CA Workload Automation Security 17

SAF Security

How the Security Process Works


The security check process works as follows: 1. When access to a CA Workload Automation object is required, CA Workload Automation creates a security profile check request and passes it to the SAF router. 2. The SAF router passes the request to your host security system. 3. The host security system checks security for the profile and passes the appropriate return code back to the SAF router. 4. The SAF router passes the return code back to CA Workload Automation . 5. CA Workload Automation grants or denies access based on the return code passed back. Example: A security check Bob (user ID XR2101) wants to add a holiday to the CA Workload Automation SYSTEM calendar. To do this, he needs UPDATE access to security profile ESP.CALENDAR.SYSTEM. CA Workload Automation creates a request to check Bob's access to the SYSTEM calendar and passes it via the SAF router to the host security system. Since Bob has UPDATE access to the profile for the SYSTEM calendar, the host security system passes the appropriate return code back to CA Workload Automation through the SAF router. CA Workload Automation then grants Bob's request to update the system calendar.

How CA Workload Automation Interprets SAF Return Codes


CA Workload Automation interprets a SAF return code 4 in a non-standard way to prevent a security exposure. Return codes from SAF calls are interpreted as follows:

SAF Return Code 0

Interpretation The security system is operating A security profile exists for the access requested Access is granted The security system is not operating or no security profile exists for the access requested Access is denied

18 Security Guide

SAF Security

SAF Return Code 8

Interpretation The security system is operating A security profile exists for the access requested Access is denied

Normally, a return code 4 means there is no way of determining the access and so access is allowed. However, to prevent a security exposure, CA Workload Automation treats return code 4 the same as return code 8 and denies access.

Resource Rules
Resource rules are in the security profiles that CA Workload Automation supports. More information: CA Workload Automation Security Profiles (see page 74)

Using SAF with CA ACF2


SAF can be used with CA ACF2 to provide security for CA Workload Automation .

SAF/ACF2 Support
To implement SAF 1. Create SAFPROT records for CA Workload Automation . 2. Define ACF2 rules for the different CA Workload Automation profiles. To implement SAF/ACF2 support 1. Run the CLASMAP conversion utility (ACFCLSMP). 2. Run the SAFDEF conversion utility (ACFSAFCV). 3. Verify the output. 4. Run ACFBATCH. 5. Remove redundant SAFDEFs. 6. Write security rules. 7. Rebuild the directories. 8. Refresh GSO records.

Chapter 2: Introduction to CA Workload Automation Security 19

SAF Security

More information: CA Workload Automation Security Profiles (see page 74)

ACF2 SAF Examples


The following are examples of ACF2 SAF rules to control access to CA Workload Automation applications: Example 1
$KEY(ESP.APPL.*******) TYPE(SAF) $USERDATA(THIS RULE ALLOWS CONTROLLING THE APPL) UID(CYBSCH) SERVICE(READ,UPDATE) ALLOW UID(CYBOPS) SERVICE(READ,UPDATE) ALLOW UID(CYBPGR) SERVICE(READ) ALLOW UID(*) SERVICE(READ) PREVENT

Example 2
$KEY(ESP.APPL.*******.*******************) TYPE(SAF) UID(CYBSCH) SERVICE(READ,UPDATE) ALLOW UID(CYBOPS) SERVICE(READ,UPDATE) ALLOW UID(CYBPGR) SERVICE(READ) ALLOW UID(*) SERVICE(READ) PREVENT

Using SAF with CA Top Secret


CA Workload Automation SAF interface can be used with all currently supported versions of CA Top Secret. Following is an example of a CA Top Secret security setup. You may need to change your settings based on your environment. Note: For more information, see your CA Top Secret documentation.

20 Security Guide

SAF Security

Control Options File


FAC(USER25=NAME=ESP) FAC(ESP=ACTIVE) FAC(ESP=AUTHINIT) FAC(ESP=MULTIUSER) FAC(ESP=NOABEND) FAC(ESP=PGM=CYB) FAC(ESP=RES) FAC(ESP=SHRPRF) FAC(ESP=SIGN(M))

Started Task Table


CESP CESPF CWSS ACID ACID ACID = CESP = CESP = CESP

Started Task Acid


ACCESSORID = CESP NAME = ESP SCHEDULING SOFTWARE ID TYPE = CENTRAL SIZE = 1024 BYTES FACILITY PROFILES PROFILES BYPASSING = ESP = XXXXFC04 XXXXTSD1 XXXXVL06 XXXXVL07 = XXXXLO01 XXXXLO02 XXXXFC01 ESPRES1 = NODSNCHK,NOVOLCHK,NOSUBCHK,NOSUSPEND

----------- ADMINISTRATION AUTHORITIES RESOURCE = REPORT ACID = REPORT LIST DATA = *ALL*,PROFILES,PASSWORD,SESSKEY

Chapter 2: Introduction to CA Workload Automation Security 21

SAF Security

ESPRES Profile
ACCESSORID = ESPRES1 NAME = ESP SCHED-RESOURCES TYPE = PROFILE SIZE = 1280 BYTES FACILITY = ESP DEPT ACID = XXX1234 DEPARTMENT = ***:RSRCS-TECHNICAL SERVICES XA DATASET = 'DSN.CESP.APPL.GLOBALS' OWNER(XXX1234) ACCESS = UPDATE XA DATASET = 'DSN.CESP.APPL.PROCLIB' ACCESS = UPDATE XA DATASET = 'DSN.CESP.APPL.PROCLIB.BACKUP' ACCESS = UPDATE XA DATASET = 'DSN.CESP.APPL.PROCLIB.RUNTIME' ACCESS = UPDATE XA DATASET = 'DSN.CESP.DOCLIB' ACCESS = UPDATE XA DATASET = 'DSN.CESP.JCLLIB' ACCESS = UPDATE XA DATASET = 'DSN.CESP.OVERRIDE.JCLLIB' ACCESS = UPDATE XA DATASET = DSN.CESP.REPORT.PROCESS. ACCESS = UPDATE XA DATASET = 'DSN.CESP.STAGE.JCLLIB' ACCESS = UPDATE XA IBMFAC = ESP. ACCESS = ALL XA IBMFAC = ESP.DSALLOC ACCESS = NONE XA IBMFAC = ESP.DSALLOC.ESPJCLIB ACCESS = ALL XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.GLOBALS ACCESS = ALL XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.PROCLIB ACCESS = ALL XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.PROCLIB.BACKUP ACCESS = ALL XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.PROCLIB.RUNTIME ACCESS = ALL XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.STAGE ACCESS = ALL XA IBMFAC = ESP.DSALLOC.DSN.CESP.DOCLIB ACCESS = ALL XA IBMFAC = ESP.DSALLOC.DSN.CESP.REPORT.PROCESS ACCESS = ALL XA IBMFAC = ESP.DSALLOC.DSN.CESP.STAGE.JCLLIB ACCESS = ALL XA IBMFAC = ESP.DSALLOC.SYSV.CESP ACCESS = ALL XA IBMFAC = ESP.DSALLOC.SYSV.CYMATION ACCESS = ALL OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234)

22 Security Guide

SAF Security

XA IBMFAC = ESP.DSALLOC.SYS3.CESP ACCESS = ALL XA IBMFAC = ESP.DSALLOC.SYS3.CYMATION ACCESS = ALL XA IBMFAC = ESP.MVSCMD ACCESS = NONE XA IBMFAC = ESP.MVSCMD ACCESS = NONE XA IBMFAC = ESP.MVSCMD.$CJ ACCESS = READ ACIDS = CESP

OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234)

Chapter 2: Introduction to CA Workload Automation Security 23

SAF Security

Production Coordinators Profile


ACCESSORID = ESPCOORD NAME = ESP SCHED-PROD COORD TYPE = PROFILE SIZE = 1024 BYTES FACILITY = ESP XA DATASET = DSN.CESP.* ACCESS = UPDATE,CREATE XA IBMFAC = ESP.DSALLOC.ESPJCLIB ACCESS = READ XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.GLOBALS ACCESS = READ XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.PROCLIB ACCESS = READ XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.PROCLIB.OVERRIDE ACCESS = READ XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.STAGE ACCESS = READ XA IBMFAC = ESP.DSALLOC.DSN.CESP.DOCLIB ACCESS = READ XA IBMFAC = ESP.DSALLOC.DSN.CESP.REPORT.PROCESS ACCESS = READ XA IBMFAC = ESP.DSALLOC.DSN.CMESP.STAGE.JCLLIB ACCESS = READ XA IBMFAC = ESP.DSALLOC.SYSV.CMESP.DSN ACCESS = READ XA IBMFAC = ESP.DSALLOC.SYSV.CMESP.TEST ACCESS = READ XA IBMFAC = ESP.GROUP.CMESP ACCESS = UPDATE XA IBMFAC = ESP.JOB ACCESS = READ XA IBMFAC = ESP.ONLINE ACCESS = READ XA IBMFAC = ESP.OPERCMD.ALERTDEF ACCESS = READ XA IBMFAC = ESP.OPERCMD.DAB ACCESS = READ XA IBMFAC = ESP.OPERCMD.ENQUEUE ACCESS = READ XA IBMFAC = ESP.OPERCMD.LAX ACCESS = READ XA IBMFAC = ESP.RESOURCE ACCESS = ALL XA IBMFAC = ESP.REXXON ACCESS = READ OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234) OWNER(XXX1234)

24 Security Guide

Chapter 3: Setting Up Security for CA Workload Automation


This chapter shows you how to set up the security profiles required to implement security in CA Workload Automation . Each section of this chapter covers a different area of CA Workload Automation security. The Getting Started section shows you how to set up basic security. After you set up basic security, you can extend and refine the protection for CA Workload Automation objects to provide more granular security. This section contains the following topics: Getting Started (see page 25) Additional Event and Application Security (see page 32) Distributed Workload Security (see page 40) Command Security (see page 57) Controlling CA Workload Automation Resources (see page 63) Security for Variables (see page 65) Security for Procedure Statements (see page 66) Job-Tracking Security (see page 68)

Getting Started
This section shows you how to set up the following basic security for CA Workload Automation : User access to CA Workload Automation Basic Event and application security Access to calendars (optional)

Each security set-up procedure involves creating a security profile. Note: The examples use ESP as the prefix for the security profiles, for example, ESP.ONLINE and ESP.GROUP.PROD. More information: CA Workload Automation Security Profiles (see page 74) Identifying the Batch Job User ID (see page 26) Access to an Event Group (see page 29) Execute-only Access to an Event Group (see page 30)

Chapter 3: Setting Up Security for CA Workload Automation 25

Getting Started

User Access to CA Workload Automation


Security profile: ONLINE You can access CA Workload Automation through ISPF panels, CA Workload Automation Workstation, or CA Workload Automation Web Interface. The ONLINE profile controls access for all three interfaces. To grant users access to CA Workload Automation 1. Create a security profile named prefix.ONLINE. 2. Grant READ access to users.

Basic Event and Application Security


Basic security for Events and applications controls access to an Event group and all the applications and jobs created from that Event. To create basic Event and application security 1. Decide what user ID you will use to execute batch work. 2. Set up security for Event Groups. 3. (Optional) Set up execute-only security to Event Groups. More information: Identifying the Batch Job User ID (see page 26) Execute-only Access to an Event Group (see page 30)

Identifying the Batch Job User ID


Each site must decide what user ID to use to execute batch work. This user ID is used as the prefix for your Event names (known as a group prefix) in most cases. For example, if you run batch jobs under user ID PROD, your PAYROLL and ACCTREC Events are called PROD.PAYROLL and PROD.ACCTREC. In most cases, the CA Workload Automation Event prefix is used as the batch work user ID. However, in some cases a different user ID is chosen.

26 Security Guide

Getting Started

How the User ID is Chosen for Batch Jobs


The following diagram illustrates how CA Workload Automation chooses the user ID for batch jobs:

The following process describes the flowchart: 1. If RACROUTE is OFF, CA Workload Automation uses its started task ID. 2. If USER(userid) is specified in the Event command, CA Workload Automation uses the userid. 3. The following conditions are checked: ITU (Inherit Trigger User) is specified in the Event definition, in the RACROUTE initialization parameter, or in the RACROUTE command. The Event is triggered manually, triggered by a global variable, or triggered by a data set trigger (DSTRIG).

If both conditions are true, CA Workload Automation uses the triggering user ID corresponding to the Event type listed in the following table:

Event trigger type Manually triggered Implicit data set trigger FTP data set trigger Explicit data set trigger

Triggering user ID from User that triggered the Event JCL job name or started task that updated the data set User associated with the local FTP partner User or started task that submitted the ESPDST utility or issued the

Chapter 3: Setting Up Security for CA Workload Automation 27

Getting Started

Event trigger type

Triggering user ID from EXPDSTRG command

Global variable trigger

User that modified the global variable table

4. If an EVENTSAF user exit exists, CA Workload Automation uses the returned user ID. 5. If the JCL contains a USER and PASSWORD parameter, CA Workload Automation uses the user ID specified in the JCL USER parameter. 6. If steps 1-5 have been checked, CA Workload Automation uses the Event Prefix.

28 Security Guide

Getting Started

Access to an Event Group


Security profile: GROUP The GROUP profile controls access to a CA Workload Automation Event group (for example, PROD) and to applications generated from those Events (for example, PROD.ACCTPAY and PROD.PAYROLL). If the SAF_PROF_APPL operand has been specified in the CA Workload Automation procedure, more granular security checks can be done. To set up access to Event groups For each Event group name you want to secure: 1. Confirm that the Event group name is a valid user ID under which batch jobs can execute. 2. Create a security profile named prefix.GROUP.event_groupname. 3. Grant the appropriate access to users. Example: UPDATE access Bob wants to create Events in the PROD Event group. PROD is a valid user ID under which the batch work can execute. Create the ESP.GROUP.PROD security profile, and grant Bob UPDATE authority to it. Assume Bob creates and triggers a PROD Event to invoke a procedure containing an APPL statement. With UPDATE authority to the PROD Event Group, he can issue any type of command against this group of jobs. Bob can create, edit, delete, and trigger an Event. He can also manipulate the workload, in any way, once the schedule has been built. Example: READ access Mary wants to view Bob's work in Event group PROD, but she should not be allowed to alter anything. She requires READ access to profile ESP.GROUP.PROD. More information: Access to an Application (see page 33) Execute-only Access to a Job Within An Application (see page 35)

Chapter 3: Setting Up Security for CA Workload Automation 29

Getting Started

Execute-only Access to an Event Group


Security profile: GROUPX The GROUPX profile controls execute-only access to a CA Workload Automation Event group (for example, PROD) and to applications generated from those Events (for example, PROD.ACCTPAY, and PROD.PAYROLL). Execute-only access allows users to work with existing Events, applications, and jobs. GROUPX access provides more authority than GROUP READ access but less authority than GROUP UPDATE access. If the SAF_PROF_APPL operand has been specified in the CA Workload Automation procedure, more granular security checks can be done. To set up execute-only access to Event groups For each Event group name you want to secure: 1. Confirm that the Event group name is a valid user ID under which batch jobs can execute. 2. Create a security profile named prefix.GROUPX.event_groupname. 3. Grant READ access to users. Example Frank needs to trigger Events and manipulate workload in the PROD Event group. However, he should not be allowed to modify Events (for example, delete Events or insert new jobs into applications). Frank requires READ access to ESP.GROUPX.PROD. More information: Access to an Application (see page 33) GROUPX.event_groupname (see page 82)

30 Security Guide

Getting Started

Access to Calendars
Security profile: CALENDAR You can protect a CA Workload Automation calendar by setting up a CALENDAR profile. Note: All users can browse any calendar by default. To set up access to a CALENDAR profile 1. Create a security profile named prefix.CALENDAR.calendar_name. 2. Grant the appropriate access to users. Example: UPDATE access Bob wants to create a new holiday in the FISCAL Calendar. He needs UPDATE access in profile ESP.CALENDAR.FISCAL. Example: ALTER access Brenda wants to create a new calendar called FISCAL. She needs ALTER access in profile ESP.CALENDAR.FISCAL.

Chapter 3: Setting Up Security for CA Workload Automation 31

Additional Event and Application Security

Additional Event and Application Security


The GROUP and GROUPX profiles that you set up in Basic control access to an Event group and all the applications and jobs generated by Events in a group. This section shows you how to provide more granular protection for some applications, such as PAYROLL. You can provide security at the application or job level: Access to an application Access to a job within an application Execute-only access to a job within an application

You can provide security for entries on the CSF screen: Access to view entries in CSF Access to specific CSF line commands

You can provide security for entries in an Event: Access to specify an Event initiator class Access to specify the USER(userid) operand Access to specify data sets in an Event Access to specify the OWNER(userid) operand

32 Security Guide

Additional Event and Application Security

Access to an Application
Security profile: APPL.applname The APPL.applname profile controls access to an application and all jobs generated by the application. To grant users access to an application 1. Add the SAF_PROF_APPL operand to the APPL statement in a CA Workload Automation procedure. 2. Create a security profile named prefix.APPL.applname. 3. Grant the appropriate access to users. Example: READ access Mary needs access to view all the PAYROLL application jobs. PAYROLL runs under Event group PROD. To set up access, confirm that Mary has at least READ access to profile ESP.GROUP.PROD. Next, confirm that SAF_PROF_APPL is specified in the APPL statement in the PAYROLL procedure. Finally, grant Mary READ access to profile ESP.APPL.PAYROLL. Example: UPDATE access Mary wants to make a change to a procedure that generates the PAYROLL application. Assuming the procedure is cached, she needs to delete the cached version so that the new version will be used. To delete the cached procedure, Mary must be authorized in the APPL profile. To set up access, confirm that Mary has at least READ access to profile ESP.GROUP.PROD. Next, confirm that SAF_PROF_APPL is on the APPL statement in the PAYROLL application. Finally, grant Mary UPDATE access to profiles ESP.APPL.PAYROLL.

Chapter 3: Setting Up Security for CA Workload Automation 33

Additional Event and Application Security

Access to a Job Within an Application


Security profile: APPL.applname.jobname To grant users access to a job within an application 1. Confirm that the user has at least READ access to the GROUP profile that protects the Event generating the application. 2. Confirm that the user has at least READ access to the APPL profile for the application. 3. Ensure that the SAF_PROF_APPL operand is on the APPL statement in the CA Workload Automation procedure. 4. Create a security profile named prefix.APPL.applname.jobname. 5. Grant the appropriate access to users. Example: READ access Mary needs access to view the PAYROLL application jobs JOB01 and JOB02. She should not be allowed view JOB03. PAYROLL runs under Event group PROD. To set up access, confirm that Mary has at least READ access to profiles ESP.GROUP.PROD and ESP.APPL.PAYROLL. Next, confirm that SAF_PROF_APPL is on the APPL statement in the PAYROLL application. Finally, grant Mary READ access to profiles ESP.APPL.PAYROLL.JOB01 and ESP.APPL.PAYROLL.JOB02. Do not give Mary access to profile ESP.APPL.PAYROLL.JOB03. Example: UPDATE access Frank wants to resubmit PAYROLL application JOB01 from a different production JCL library than the normal one. PAYROLL runs under Event group PROD. To allow access, first confirm that Frank has at least READ access to profiles ESP.GROUP.PROD and ESP.APPL.PAYROLL. Next, confirm that SAF_PROF_APPL is on the APPL statement in the PAYROLL application. Finally, grant Frank UPDATE access to profile ESP.APPL.PAYROLL.JOB01.

34 Security Guide

Additional Event and Application Security

Execute-only Access to a Job Within An Application


Security profile: APPLX.applname.jobname Execute-only access allows users to work with existing jobs within an application. APPLX.applname.jobname access provides more authority than APPL.applname.jobname READ access but less authority than APPL.applname.jobname UPDATE access. To grant users execute-only access to a job within an application Confirm that the user has at least READ access to the GROUP profile that protects the Event generating the application. 1. Confirm that the user has at least READ access to the APPL profile for the application. 2. Ensure that the SAF_PROF_APPL operand is specified in the APPL statement in the CA Workload Automation procedure. 3. Create a security profile named prefix.APPLX.applname.jobname. 4. Grant READ access to users. Example Lee wants to resubmit JOB01 in the PAYROLL application. He should not be allowed to change the JCL source. PAYROLL runs under Event group PROD. To allow access, first confirm that Lee has at least READ access to profiles ESP.GROUP.PROD and ESP.APPL.PAYROLL. Next, confirm that SAF_PROF_APPL is on the APPL statement in the PAYROLL application. Finally, grant Lee READ access to profile ESP.APPLX.PAYROLL.JOB01. More information: APPLX.applname.jobname (see page 77)

Chapter 3: Setting Up Security for CA Workload Automation 35

Additional Event and Application Security

Access to View Entries In CSF


Security Profiles: APPL, APPLX or GROUP, GROUPX You can control the display of entries in CSF by adding the SECURE operand to the SCHDFILE initialization parameter. With the SECURE operand, CSF lists only the applications and jobs that a user has access to. If the SECURE operand is not used, users can see all jobs, even those they do not have access to. Note: The SECURE operand improves CA Workload Automation Workstation performance by reducing the amount of data being transmitted. This is because the Workstation Server sends only the workload data that the user has authorization for. To control the display of entries on CSF 1. Confirm that the SECURE operand is added to the SCHDFILE initialization parameter. 2. Set up the appropriate access for those users that need to see jobs on CSF. If the SAF_PROF_APPL operand was specified in the APPL statement in the ESP procedure, use the APPL and APPLX profiles. If the SAF_PROF_APPL operand was not specified in the APPL statement in the ESP procedure, use the GROUP and GROUPX profiles.

More information: Basic Event and Application Security (see page 26)

36 Security Guide

Additional Event and Application Security

Access to Specific CSF Line Commands


Security Profiles: CSF.CHECK.CMDS, CSF.LC If you want to limit access to specific CSF line commands, use the CSF.CHECK.CMDS profile in combination with the CSF.LC. cmd profile. The CSF.CHECK.CMDS profile specifies the users for which CSF line command checking is done. The CSF.LC.cmd profile specifies the users that have access to the CSF line command specified by cmd. Note: If you don't set up a profile for a specific line command, then all users are authorized to issue that CSF line command. Even if you can access a CSF line command, you still need access to the Event group, application, or job the command is issued against. CSF line commands generate an underlying CA Workload Automation command. The CSF.LC profile protects only the CSF command, not the underlying command. For example, the profile can protect CSF command CA but not the underlying command APPLJOB or AJ. Some underlying commands, such as the RESDEF command or OPER commands, have security profiles available to control access. In the case of underlying commands with no security profiles, you should protect the Event Group, application, or job the command is issued against.

To turn on CSF line command security checking 1. Create a security profile named prefix.CSF.CHECK.CMDS. 2. Grant UACC(READ). To grant users access to specific CSF line commands 1. Confirm that CSF line command security checking is turned on with the prefix.CSF.CHECK.CMDS profile. 2. Create a security profile named prefix.CSF.LC.cmd for each CSF line command you want to protect. 3. Grant READ access to the users requiring access to a specific CSF line command. Example Frank needs to resubmit a job using CSF line command R. Assume that Frank has access to the job and the CSF.CHECK.CMDS profile. Frank requires READ access to the ESP.CSF.LC.R profile or READ access to ESP.CSF.LC.**, which gives him access to all CSF line commands.

Chapter 3: Setting Up Security for CA Workload Automation 37

Additional Event and Application Security

Access to Specify an Event Initiator Class


Security profile: EVENTINITCLASS If you want to control the use of the EICLASS operand to define an Event with a particular Event initiator class nnn (where nnn is a number between 0 and 255), use the EVENTINITCLASS.nnn profile. To grant users access to define an Event initiator class 1. Create a security profile named prefix.EVENTINITCLASS .nnn. 2. Grant READ access to users who want to set up an Event with Event initiator class nnn. Example Bob wants to use the EICLASS operand to specify initiator class 1 for an Event he is creating. Bob needs READ access to profile ESP.EVENTINITCLASS.1.

Access to Specify the USER(userid) Operand


Security profile: RACID The RACID.userid profile controls the user's ability to specify the USER( userid) operand in an Event definition. The USER(userid) operand specifies an overriding user ID for an Event to execute with. To grant users access to specify the USER(userid) operand 1. Confirm that the user has UPDATE access to the Event through the GROUP profile. 2. Create a security profile named prefix.RACID.userid. 3. Grant READ access to users. Example Bob is creating a special manually-triggered Event in the CA Workload Automation subsystem and the PROD Event group. He wants to include a USER(userid) statement in the Event definition to allow the special jobs to run under user ID XR2105 (an on-call production support analyst). Assume PROD is a valid user ID for which the batch work can execute and Bob has UPDATE authority to Event group ESP.GROUP.PROD. Bob needs READ access to profile ESP.RACID.XR2105. More information: How CA Workload Automation Interprets SAF Return Codes (see page 18)

38 Security Guide

Additional Event and Application Security

Access to Specify Data Sets In an Event


Security profile: DSALLOC You can use the DSALLOC.dsname profile to control which data sets can be invoked from within an Event. For example, you can control what libraries can be dynamically allocated. This is useful if you don't want users to invoke schedules from their personal libraries. To allow users to include a data set name within an Event 1. Confirm that the DSALLOC operand is specified in the SAFOPTS initialization parameter. Note: For more information on the SAFOPTS parameter, see the Installation and Configuration Guide. 2. Create a security profile named prefix.DSALLOC.dsname. 3. Grant READ access to users. Example Bob wants to add data set PROD.PAYROLL.MASTER to an Event he is creating. Assume that the DSALLOC operand is specified in the SAFOPTS initialization parameter. Bob needs READ access to profile ESP.DSALLOC.PROD.PAYROLL.MASTER.

Chapter 3: Setting Up Security for CA Workload Automation 39

Distributed Workload Security

Access to Specify the OWNER(userid) Operand


Security profile: SETOWNER The SETOWNER.userid profile controls access to specify the OWNER(userid) operand in an Event definition. The OWNER(userid) operand specifies an overriding owner for an Event. Ownership in a SAF environment affects only the TSO user who receives the failure messages. The default owner is the last user to modify the Event. Important! If a Mailbox is set up, failure messages go to the Mailbox, even if there is an OWNER operand specified. To grant users access to specify the OWNER(userid) operand 1. Confirm that the user has UPDATE access to the Event through the GROUP profile. 2. Create a security profile named prefix.SETOWNER.userid. 3. Grant READ access to users who need to use the OWNER(userid) operand in an Event definition. Example Bob is creating an Event in the PROD Event group. He wants to include an OWNER(userid) statement in the Event definition to notify Mary (an on-call programmer with user ID XR5504) of any failures in jobs triggered by the Event. Assume Bob has UPDATE authority to Event group ESP.GROUP.PROD. Bob needs READ access to profile ESP.SETOWNER.XR5504.

Distributed Workload Security


This section shows you how to set up security for using Agents with CA Workload Automation . There are three types of distributed workload security: Host security Communication security between CA Workload Automation and the agents Agent platform security

These security points are not mutually exclusive. They work together to provide a secure distributed workload environment.

40 Security Guide

Distributed Workload Security

Host Security
The first level of authorization in distributed workload is the host security. CA Workload Automation provides the initial control over Agent work. With host security, you can control the following: Access to agents Access to passwords and encryption keys for using agents Access to OPER command MAPUSER

Note: Events and applications for distributed workload are protected by the GROUP and APPL profiles. More information: Basic Event and Application Security (see page 26) Additional Event and Application Security (see page 32)

Chapter 3: Setting Up Security for CA Workload Automation 41

Distributed Workload Security

Access to Agents
Security Profiles: AGENT, AGENTMSG, AGENTUSR To control a user's ability to submit work to an Agent 1. Create profile prefix.AGENT.agentname. For example, you can create ESP.AGENT.HP_51. 2. Grant READ access to users. Example To allow a user to submit work to Agent HP_51, grant READ access to profile ESP.AGENT.HP_51. To control a user's ability to issue commands and send messages to an Agent using the AGENTMSG command 1. Create profile prefix.AGENTMSG.verbsubverb.agentname. 2. Grant READ access to users who need to use the AGENTMSG command. Example To allow a user to issue a shutdown command to Agent HP_51 in the CA Workload Automation subsystem, grant READ access to profile ESP.AGENTMSG.CONTROL SHUTDOWN.HP_51. To control a user's ability to include the USER(userid) operand within a procedure that submits jobs to an Agent 1. Create profile prefix.AGENTUSR.userid.agentname. 2. Grant READ access to users who need to use the USER(userid) operand. Example To allow a user to specify USER(XR2101) for Agent HP_51 in a procedure, grant READ access to profile ESP.AGENTUSR.XR2101.HP_51.

42 Security Guide

Distributed Workload Security

Access to Passwords and Encryption Keys for Using Agents


Security Profile: PASSWORD The PASSWORD profile controls a user's ability to do the following: Delete or update a password for communicating with an Agent without supplying the old password. To delete or update the password, you use the PASSWORD command. If you supply the old password, it must be correct or the request will fail, regardless of whether you have UPDATE authority in the PASSWORD security profile or not. Delete or update an encryption key protected by the CRYPTKEY command without supplying the old encryption key. To delete or update the an encryption key, you also use the CRYPTKEY command.

Note: For more information, see the Command Reference Guide. If you supply the old encryption key, it must be correct or the request will fail, whether you have UPDATE authority for the PASSWORD profile or not. If you update an encryption key, make sure that you load the Agent definition data set so that CA Workload Automation is aware of the change. More information: Message Encryption (see page 45) Hiding Message Encryption Keys With the CRYPTKEY Command (see page 48)

The PASSWORD Command


The PASSWORD command defines and securely stores a mainframe user ID and password pair. Passwords defined using this command are encrypted and stored in a data set for later use. For example:
PASSWORD DEFINE USER(jdoe) PASSWORD(A2B3C) TYPE(NT_JOB)

When a USER statement is coded in an NT_JOB definition, a search takes place for an entry matching the specified mainframe user ID with a type of NT_JOB and a qualifier equal to the Agent name specified in the CA Workload Automation procedure. This search returns the password that most closely matches these parameters. If there are no matching entries, an entry with no type or qualifier is returned.

Chapter 3: Setting Up Security for CA Workload Automation 43

Distributed Workload Security

Security for the PASSWORD and CRYPTKEY Commands


To control a user's ability to modify or delete a password or encryption key without specifying the old password or encryption key 1. Create profile prefix.PASSWORD.userID.agentname. For example, create ESP.PASSWORD.JDOE.HP_51. 2. Grant UPDATE access to users. Example ESP.PASSWORD.JDOE.HP_51

Access to OPER Command MAPUSER


Security Profiles: OPER, OPERCMD The MAPUSER command maps a distributed system user ID to a mainframe user ID. This mapping is used for authorizing messages sent to CA Workload Automation using the ESPmgr command. Note: For more information, see ESPmgr in the Command Reference Guide. You can specify the MAPUSER command in the Agent definition file. For example:
MAPUSER jdoe TO(XR2101) AGENT(HP_51)

The distributed system user ID is case sensitive. It accepts the first match (be careful of masking). You can issue multiple MAPUSER commands, and you can also issue MAPUSER without operands to show the current user ID mappings. To control a user's ability to issue the OPER command MAPUSER Set up the appropriate access to the OPER or OPERCMD.cmdname profiles for the user to issue the MAPUSER command. More information: Access to Issue OPER Commands (see page 58)

Communication Security
This section describes the various types of communication security.

44 Security Guide

Distributed Workload Security

Message Encryption
Message encryption safeguards communications between CA Workload Automation and the following: Agents CA Workload Automation AE

Message encryption is done using DES (Data Encryption Standard), Blowfish encryption, or AES 128 encryption. Agents support all three encryption methods. CA Workload Automation AE supports AES message encryption only. Starting with Release 5 of the agents, message encryption became mandatory. Authentication takes place in two cases: When an encrypted message is received by CA Workload Automation When an encrypted message is received by an agent or CA Workload Automation AE.

To authorize communication between CA Workload Automation and an agent, two keys are compared: The security.cryptkey parameter in the agentparm.txt file A key from the CA Workload Automation agent definition data set (AGENTDEF).

If the keys don't match, communication is not allowed. Note: All agent receivers can decrypt an encrypted message, but if you code the ENCRYPTEDONLY keyword in the AGENTRCV initialization parameter, that agent receiver will accept only encrypted messages. The host system user ID and the agent name are extracted from the encrypted message, and a security check is done against existing CA Workload Automation security profiles to verify read or update authority. To activate message encryption for agents 1. Add the security.cryptKey parameter to the agentparm.txt file. Encryption is turned on for the agent. 2. Set up message encryption keys for agents in the AGENTDEF data set. More information: Setting Message Encryption Keys in the AGENTDEF Data Set (see page 46)

Chapter 3: Setting Up Security for CA Workload Automation 45

Distributed Workload Security

Setting Message Encryption Keys in the AGENTDEF Data Set


In the CA Workload Automation Agent definition data set (AGENTDEF), you can specify keys for encrypting Agent messages. You can specify an encryption key for individual Agents or for groups of Agents. For individual Agents, you specify the key in the ENCRYPT operand of the AGENT initialization parameter. For example: AGENT CYBUNIX ADDRESS(113.11.11.11) Port(3990)+ UNIX ASCII TCPIP ENCRYPT(X'1111222233334444') For a group of Agents, you specify the key in the KEY operand of the ENCRYPT initialization parameter. For example:
ENCRYPT KEY(X'0102030405060708') ALL

The ENCRYPT initialization parameter affects all subsequent Agent initialization parameters until the next ENCRYPT initialization parameter is encountered. Note: For details about the ENCRYPT initialization parameter and AGENT initialization parameter, see the Installation and Configuration Guide. The ALL/NOALL operand in the ENCRYPT initialization parameter and the ENCRYPT/NOENCRYPT operand of the AGENT initialization parameter determine the key used for message encryption. The following table shows how to get the desired encryption for each Agent in your AGENTDEF file:

Message encryption ALL/NOALL operand method setting Encrypt with the key from the ENCRYPT initialization parameter. Encrypt with the key from the AGENT initialization parameter. Do not encrypt. ALL NOALL

ENCRYPT/NOENCRYPT operand setting ENCRYPT or none ENCRYPT

ALL or NOALL

ENCRYPT (key)

ALL NOALL

NOENCRYPT NOENCRYPT or none

46 Security Guide

Distributed Workload Security

Examples of Message Encryption


Example 1 This example shows you a message encryption setup for a group of Agents (A1 and A2) and an individual Agent (A3). It also shows you how to prevent message encryption for an Agent (A4).
MANAGER [NAME(MANAGERID)]TCPIP ENCRYPT KEY(X'0102030405060708') ALL AGENT A1 ADDRESS(111.11.11.11) Port(3990)+ UNIX ASCII TCPIP AGENT A2 ADDRESS(112.11.11.11) Port(3990)+ UNIX ASCII TCPIP ENCRYPT AGENT A3 ADDRESS(113.11.11.11) Port(3990)+ UNIX ASCII TCPIP ENCRYPT(X'1111222233334444') AGENT A4 ADDRESS(114.11.11.11) Port(3990)+ UNIX ASCII TCPIP NOENCRYPT

Messages are encrypted as follows: For Agents A1 and A2, messages are encrypted with key X'0102030405060708' (the key from the ENCRYPT initialization parameter). For Agent A3, messages are encrypted with key X'1111222233334444' (the key from the AGENT initialization parameter). For Agent A4, messages are not encrypted.

Example 2 This example shows you a message encryption setup for two groups of Agents (A1, A2, and A3, A4) and an individual Agent (A5). Note the use of the additional ENCRYPT initialization parameter that applies to the second group of Agents (A3 and A4). Since the ALL/NOALL operand is missing from both ENCRYPT initialization parameters, the default value of NOALL is used.
MANAGER [NAME(MANAGERID)]TCPIP ENCRYPT KEY(X'0102030405060708') AGENT A1 ADDRESS(111.11.11.11) Port(3990)+ UNIX ASCII TCPIP ENCRYPT AGENT A2 ADDRESS(112.11.11.11) Port(3990)+ UNIX ASCII TCPIP ENCRYPT ENCRYPT KEY(X'0807060504030201') AGENT A3 ADDRESS(113.11.11.11) Port(3990)+ UNIX ASCII TCPIP ENCRYPT AGENT A4 ADDRESS(114.11.11.11) Port(3990)+ UNIX ASCII TCPIP ENCRYPT AGENT A5 ADDRESS(115.11.11.11) Port(3990)+ UNIX ASCII TCPIP

Chapter 3: Setting Up Security for CA Workload Automation 47

Distributed Workload Security

For Agents A1 and A2, messages are encrypted with key X'0102030405060708' (the key from the first ENCRYPT initialization parameter). For Agents A3 and A4, messages are encrypted with key X'0807060504030201' (the key from the second ENCRYPT initialization parameter). For Agent A5, messages are not encrypted.

Hiding Message Encryption Keys With the CRYPTKEY Command


You can protect the Agent message encryption keys by hiding them with the CRYPTKEY command. The CRYPTKEY command allows you to assign a name to a key. Then, wherever you specify the key name, the actual key is substituted. Note: For more information, see the CRYPTKEY command in the Command Reference Guide.

Agent Platform Security


This section describes the various types of platform security.

Default Security (UNIX)


When a message arrives at the Agent, the following occurs: If the Agent is running as root authority, an SU (switch user) is performed to the user ID of the owner of the script. If the Agent runs as non-root, it is restricted to the authority under which the Agent is executing.

48 Security Guide

Distributed Workload Security

Default security (Windows NT) Default security (NT)


If the Agent is running in debug (console) mode, it runs under the user ID of the user that started the Agent. If the Agent is running as a service, it runs with the authority of the service account under which the Agent is installed. Note the following: The SYSTEM has null credentials by default. A specific user ID does not have a true user environment (that is, there are no mappings). The Agent cannot perform the equivalent of UNIX SU.

You need to run multiple Agents to get different permissions. The USER statement allows Agents to run with different user characteristics, even under SYSTEM. Note the following: The USER statement does not provide a true user environment. The USER statement reduces the need for multiple Agents.

Chapter 3: Setting Up Security for CA Workload Automation 49

Distributed Workload Security

Local Agent Security


The local security file (security.txt) provides a third layer of security. The security file contains two types of entries: The first security file entry type specifies whether CA Workload Automation can submit jobs on the server under a specific server user ID, from a specific directory. The syntax is:
command rule central_manageruserID serveruserID path

For example:
c a XR2101 jdoe /temp/+

In this example, user ID XR2101 is authorized to submit jobs under server user ID jdoe from the /temp/ directory and any subdirectories of /temp/. The second security file entry type specifies whether a user ID has the authority to issue CONTROL messages to the Agent. The syntax is as follows:
command rule userID verb subverb

For example:
c a XR2101 CONTROL SHUTDOWN

In this example, user ID XR2101 is authorized to issue the SHUTDOWN subverb of the CONTROL message. Note: Security must be turned on in the agentparm.txt file as follows:
security.level=on

The corresponding CA Workload Automation application must be configured to check the server user ID. For example, to check server user ID UNIXUSR1, the application would be coded as follows:
APPL UNIXJOB UNIX_JOB A AGENT UNIX50 RUN DAILY CMDNAME /temp/test1 USER UNIXUSR1 ENDJOB

At startup, the Agent security file is read and formats the authorization rules. If the security file is not present, the default UNIX or NT security rules are automatically applied. If the security file is present, all access requests that do not have a match in the security file are denied. The default UNIX or NT security rules are not applied.

50 Security Guide

Distributed Workload Security

More information: Local Security-file Entries Syntax (see page 51)

Local Security-file Entries Syntax


Local security-file entries syntax follows:
command rule central_manageruserID serveruserID path command rule userid verb subverb

The following table describes each element of a security-file entry:

Entry command

Description Identifies the resource class x: control execution of scripts and commands c: control operational commands to an Agent

rule

Identifies the rule a: allow access d: deny access

central_manageruserID serveruserID

Identifies the user ID on CA Workload Automation that the rule applies to Identifies the user ID on the server that the central_manageruserID is allowed to submit jobs under Identifies the path the central_manageruserID is allowed to submit jobs from using the serveruserID. Identifies the user ID issuing a message to an Agent Identifies the verb issued (the action to be taken). For example, CONTROL

path

userid verb

subverb

Identifies the subverb of the verb issued. For example, SHUTDOWN, CANCEL

Chapter 3: Setting Up Security for CA Workload Automation 51

Distributed Workload Security

Wildcards in the Local Security File


Security file entries central_manageruserID, serveruserID, path, verb, and subverb can contain a single wildcard character only at the end of the field. The following table describes the wildcards:

Wildcard Asterisk (*) Plus sign (+)

Description Represents 0 or more character matches at the current level only Represents 0 or more character matches at the current level and all sublevels. Interpreted as starting with

Security Rule Starting Point and Spacing


Every security rule starts in column 1. Items on a line: Are separated by one or more blanks or tab characters. End with a new-line character.

Comment Lines in the Local Security File


The security file can contain comment lines. Comment lines must start with either an asterisk (*) or a number sign (#) in column 1. For example:
* Here is a comment line

Understanding Security-rule Interpretation


For the rule to be considered a match, three components of the rule have to match. If two or more rules match, the closest match will override the others according to the following table:

Security-Rule Interpretation

Explanation

A specific rule overrides a generic rule. Path /u1/jsmith A generic rule is a rule that contains overrides wildcards. path /u1/jsmith* If both rules are generic, the more specific rule overrides the other. Path /u1/jsmith/scripts/* overrides path /u1/jsmith* Path /u1/jsmith/scripts/a*

52 Security Guide

Distributed Workload Security

Security-Rule Interpretation

Explanation overrides path /u1/jsmith/scripts*

The central_manageruserID takes precedence over the serveruserID, and the serveruserID takes precedence over path.

A rule is considered a closer match if the central_manageruserID is a closer match. If the central_manageruserID of two rules are the same, the rule with the closest matching serveruserID overrides the other. Rule c d root * * overrides rule c a root * *

If there is still ambiguity after these rules have been applied, a deny rule will override an allow rule.

Security File Created at Installation


The security.txt file created during installation contains the following rules: c x a d * * * * * +

Default Security Rules


The following security rules apply by default if the security.txt file is not present, or there is an error in the security.txt file: x x c a d a * * * * root * + + *

Note: Both resource class x and resource class c must be specified, even if there is no change to one or the other class.

Chapter 3: Setting Up Security for CA Workload Automation 53

Distributed Workload Security

Examples of Local Agent Security File Rules


Line 1 2 3 4 5 6 7 8 9 10 11 Security File Example #1 # Example 1 * These rules were last updated on August01, 2002 x x x x x x x x c a d a d a d a d a * * manager1 manager1 manager2 manager2 manager3 manager3 * * gem* root root root root root root CONTROL + + /prod/employee+ /prod/employee* /prod/+ /prod/expense /prod/* /prod/+ *

An explanation of Example 1 follows:

Line 1 2 3 4

Explanation Comment line Comment line Allows all central_manageruserIDs to submit jobs using any serveruserID, from all directories Prohibits all central_manageruserIDs from submitting jobs as gem or any serveruserIDs that begin with gem, from all directories

54 Security Guide

Distributed Workload Security

Line 5

Explanation Allows manager1 to submit the following jobs as root: Job A job called employee from directory /prod/ Example /prod/employee

All jobs beginning with /prod/employee_pay employee from directory /prod/ /prod/employee_vacation All jobs from the subdirectory /prod/employee/ and its subdirectories All jobs from all subdirectories under /prod/, where the first subdirectory name under prod begins with employee 6 7 8 9 10 11 /prod/employee/fulltime_pay /prod/employee/sales/fulltime_p ay /prod/employee1999/fulltime-pa y /prod/employee1999/sales/fullti me_pay

Denies manager1 the ability to submit any jobs called employee, or any jobs that begin with employee, as root in directory /prod/ Allows manager2 to submit all jobs as root from directory /prod/ or all subdirectories of /prod/ Denies manager2 the ability to submit the job called expense as root from directory /prod/ Allows manager3 to submit all jobs as root in directory /prod/ Denies manager3 the ability to submit any jobs as root from directory /prod/ or all subdirectories of /prod/ Allows all central_manageruserIDs to issue the CONTROL command with all subverbs

Chapter 3: Setting Up Security for CA Workload Automation 55

Distributed Workload Security

Line 1 2 3 4 5 6 7

Example # Example 2 * Last updated on September 28, 2002. x x x c c a a a a a rob* pat* jsmith MFUSER1 MFUSER2 root root* * CONTROL CONTROL /prod/+ /prod/* /prod/+ * MGRADDR

An explanation of Example 2 follows:

Line 1 2 3 4

Explanation Comment line Comment line Allows any central_manageruserID (beginning with rob) to submit jobs as root from the directory /prod/ or all subdirectories of /prod/ Allows any central_manageruserID (beginning with pat) to submit jobs as root, or as any server user ID beginning with root, in directory /prod/ Allows jsmith to submit jobs using any server user ID from directory /prod/ or all subdirectories of /prod/ Allows MFUSER1 to issue the CONTROL command with all subverbs to this Agent Allows MFUSER2 to issue the CONTROL Mgraddr command to this Agent

5 6 7

56 Security Guide

Command Security

Command Security
This section shows you how to control a user's access to issue commands: Access to issue OPER commands Access to issue z/OS commands Access to utility mode Access to specify utility mode commands

Chapter 3: Setting Up Security for CA Workload Automation 57

Command Security

Access to Issue OPER Commands


Security Profiles: OPER, OPERCMD CA Workload Automation has a special subset of commands called operator commands or OPER commands. You can control access to OPER commands in two ways: Use the OPER profile to control access to all OPER commands except RESDEF and its alias, RSD. Access to the RESDEF command is controlled by the RESOURCE.resname profile. Use the OPERCMD.cmdname profile to control access to specific CA Workload Automation operator commands.

To grant users access to issue any OPER command 1. Confirm that the NOOPERCMDS operand (the default) is specified in the SAFOPTS initialization parameter. Note: For more information on the SAFOPTS initialization parameter, see the Installation and Configuration Guide . 2. Create a security profile named prefix.OPER. 3. Grant READ access to users. Example Bob wants to issue OPER command L LEVEL(PROD) to list the names and execution times of all Events in the PROD Event Group. Assuming that the security policy is to protect all OPER commands with one profile, Bob needs READ access to profile ESP.OPER. The SAFOPTS initialization parameter must also include the NOOPERCMDS operand (the default). To grant users access to issue a specified OPER command 1. Confirm that the OPERCMDS operand is specified in the SAFOPTS initialization parameter. Note: For more information on the SAFOPTS initialization parameter, see the Installation and Configuration Guide . 2. Create a security profile named prefix.OPERCMD.cmdname. 3. Grant READ access to users. Note: If a command has a short form, you should create a profile for the command and another profile for the short form of the command. For example, create profile ESP.OPERCMD.LIST to control access to the LIST command and profile ESP.OPERCMD.L to control access to L, the short form of LIST. Example

58 Security Guide

Command Security

Bob wants to issue OPER command LIST LEVEL (PROD) to list the names and execution times of all Events in the PROD Event Group. Assuming that the security policy is to protect each OPER command individually, Bob needs READ access to profile ESP.OPERCMD.LIST. The SAFOPTS initialization parameter must also include the OPERCMDS operand. Bob should also get READ access to ESP.OPERCMD.L in case he wants to use the short form of the LIST command. More information: Access to Use the RESDEF Command (see page 64)

Chapter 3: Setting Up Security for CA Workload Automation 59

Command Security

Access to Issue z/OS Commands


Security Profiles: OPER, MVSCMD Security for issuing z/OS commands from CA Workload Automation is provided as follows: The OPER profile controls a user's ability to issue any z/OS command. The MVSCMD.mvs_cmd.options profile controls the user's ability to issue a specified z/OS command.

To grant users access to issue any z/OS command 1. Confirm that the NOMVSCMD operand is specified in the SAFOPTS initialization parameter. Note: See the Installation and Configuration Guide . 2. Create a security profile named prefix.OPER. 3. Grant READ access to users. Example Bob wants to include a z/OS send command in an Event to notify users that a job will be running. The security policy is to protect all z/OS commands with one profile, so Bob needs READ access to profile ESP.OPER. The SAFOPTS initialization parameter must also include the NOMVSCMD operand. To grant users access to issue a specified z/OS command 1. Confirm that the MVSCMD operand is specified in the SAFOPTS initialization parameter. Note: For more information, see the Installation and Configuration Guide . 2. Create a security profile named prefix.MVSCMD.mvs_cmd.options. For example, you can create ESP.MVSCMD.D.A.L for z/OS command D A, L. 3. Grant READ access to users. Note: Some z/OS commands have long and short forms for the command and its options. For example, the z/OS DISPLAY command can be issued as D A,L or DISPLAY A,L or D ALL,L, and so on. If you want to protect each command option individually, create a security profile for each possible combination of long and short forms. For example, create profiles ESP.MVSCMD.D.A.L, ESP.MVSCMD.DISPLAY.A.L, ESP.MVSCMD.D.ALL.L, and so on.

60 Security Guide

Command Security

If you want to protect the command only, create a generic profile for the long form of the command and another generic profile for the short form. For example, create profiles ESP.MVSCMD.DISPLAY.** and ESP.MVSCMD.D.** to control access to the DISPLAY command and its short form, D. Users with access to the command will be able to use any of its options.

Example: Grant access to all options of a command Bob wants to include an z/OS send command in an Event to notify users that a job will be running. The Event will run under user ID PROD. The security policy is to protect each z/OS command individually, but to allow access to all options for each command. User ID PROD must be granted READ access to profile ESP.MVSCMD.SE.**. The SAFOPTS initialization parameter must also include the MVSCMD operand. Example: Restrict access to commands using wildcards Lucy is a security administrator who needs to restrict access to z/OS commands with EX in the second and third positions in the command name string, such as MEX, TEXAN, and LEX. The z/OS commands are REXX execs. Lucy checks that the SAFOPTS initialization parameter includes the MVSCMD operand and creates the profile ESP.MVSCMD.%EX*. Note: In the profile, the percent sign (%) matches any single character and the asterisk (*) matches zero or more characters. Bob wants to issue the MVS command %EXCMD CCAMVSB MAILESP from an Event. Since CA Workload Automation uses the percent sign as a variable symbol introducer, Bob needs to code an extra percent sign:
VS %%EXCMD CCAMVSB MAILESP

To convert this command to a resource name, CA Workload Automation strips the first percent sign, prefixes the command with the subsystem name and the SAFOPTS operand, and converts the blanks to periods. Since the z/OS security server does not allow percent signs and other special characters that it uses in resource names, CA Workload Automation also converts the percent sign (%) into a question mark (?):
ESP.MVSCMD.?EXCMD.CCAMVSB.MAILESP

The z/OS security server matches the question mark with the percent sign in the profile and checks if Bob has READ access to the profile before issuing the command.

Chapter 3: Setting Up Security for CA Workload Automation 61

Command Security

Access to Utility Mode


Security profile: UTIL.UTIL The UTIL.UTIL profile controls access to CA Workload Automation utility mode and access to two utility mode commands: END and ENDREC. The UTIL. cmd profile provides access to other utility mode commands. To grant users access to utility mode and the END and ENDREC commands 1. Create a security profile named prefix.UTIL.UTIL. 2. Grant READ access to users. Example Lucy is a security administrator who needs to set up access to CA Workload Automation utility mode. Lucy creates the ESP.UTIL.UTIL profile with UACC(READ). She then sets up a UTIL.cmd profile to control access to specific utility mode commands. More information: Access to Specific Utility Mode Commands (see page 63)

62 Security Guide

Controlling CA Workload Automation Resources

Access to Specific Utility Mode Commands


Security profile: UTIL The UTIL.cmd profile controls access to the UTIL mode command specified by cmd. To grant users access to a specified utility mode command 1. Confirm that the user has READ access to profile prefix.UTIL.UTIL. 2. For each utility mode command that users need access to, create a security profile named prefix.UTIL.cmd. 3. Grant READ access to users. Example: specific commands Serge needs to issue a DUMPKEY command from within the CA Workload Automation utility mode. Assume that Serge has READ access to the ESP.UTIL.UTIL profile. He needs READ access to the ESP.UTIL.DUMPKEY profile. Example: all commands Serge wants to issue any CA Workload Automation utility mode command. Assume that Serge has READ access to the ESP.UTIL.UTIL profile. He needs READ access to profile ESP.UTIL.**, which covers all CA Workload Automation utility mode commands.

Controlling CA Workload Automation Resources


CA Workload Automation allows you to specify both real and abstract resources within the scope of a job. This ensures that jobs in an application are submitted only when all of their resource requirements are met. This section shows you how to control a user's ability to specify job resources: Access to use the RESDEF command Access to invoke REXX

Chapter 3: Setting Up Security for CA Workload Automation 63

Controlling CA Workload Automation Resources

Access to Use the RESDEF Command


Security profile: RESOURCE The RESOURCE.resname profile controls the use of the RESDEF command as follows: Control who can specify a CA Workload Automation resource as part of their job scheduling requirements. Control who can create, delete, or modify usage counts associated with specific resources.

To grant users access to use the RESDEF operator command 1. Create a security profile named prefix.RESOURCE.resname. 2. Grant the appropriate access to users. Example: UPDATE access Bob wants to modify the attributes for the SCRATCH resource. He requires UPDATE access to CA Workload Automation profile ESP.RESOURCE.SCRATCH. Example: ALTER access Brenda wants to create a job scheduling resource called DB2TAB1. She requires ALTER access to CA Workload Automation profile ESP.RESOURCE.DB2TAB1.

Access to Use the ABSORB Statement


Security profile: RESABSORB To grant users access to use the ABSORB statement in a CA Workload Automation procedure 1. Create a security profile named prefix.RESABSORB. 2. Grant READ access to users that need to use the ABSORB statement. Example: Bob wants to use the ABSORB statement in an application he is creating to reserve resources specified in a RESOURCE statement. The application will run under user ID PROD. The PROD user ID must have READ access to profile ESP.RESABSORB.

64 Security Guide

Security for Variables

Security for Variables


This section shows you how to control user access to CA Workload Automation symbolic variable storage: Access to a symbolic variable library Access to a global variable table

Access to a Symbolic Variable Library


Security profile: SYMLIB The SYMLIB.symname profile controls access to the CA Workload Automation symbolic-variable library specified by symname. To grant users access to a CA Workload Automation symbolic variable library 1. Create a security profile named prefix.SYMLIB.symname. 2. Grant the appropriate access to users. Example: READ access Frank wants to check the value of the PRFX symbolic variable in the GENSYM symbolic variable library to make sure PRFX is set to PROD. Frank needs READ access to profile ESP.SYMLIB.GENSYM. Example: UPDATE access Bob wants to add a symbolic variable called TAPE with a value of 3480 to the RESSYM symbolic variable library. Bob needs UPDATE access to profile ESP.SYMLIB.RESSYM. Example: ALTER access Brenda wants to create a symbolic variable library called DATSYM to store date variables. Brenda needs ALTER access to profile ESP.SYMLIB.DATSYM.

Chapter 3: Setting Up Security for CA Workload Automation 65

Security for Procedure Statements

Access to a Global Variable Table


Security profile: VARTABLE The VARTABLE.tablename profile controls access to the global variable table specified by tablename. To grant users access to a global variable table 1. Create a security profile named prefix.VARTABLE.tablename. 2. Grant the appropriate access to users who need to work with a global variable table. Example: READ access Frank wants to check the value of the PRFX symbolic variable in the GENSYM global variable table to make sure PRFX is set to PROD. Frank needs READ access to profile ESP.VARTABLE.GENSYM. Example: UPDATE access Bob wants to add a symbolic variable called TAPE with a value of 3480 to the RESSYM global variable table. Bob needs UPDATE access to profile ESP.VARTABLE.RESSYM. Example: ALTER access Brenda wants to create a global variable table called DATSYM to store date variables. Brenda needs ALTER access to profile ESP.VARTABLE.DATSYM.

Security for Procedure Statements


This section shows you how to control the use of statements in procedures: Access to use the EXPEDITE statement Access to invoke REXX

66 Security Guide

Security for Procedure Statements

Access to Use the EXPEDITE Statement


Security profile: EXPEDITE The EXPEDITE.policyname profile controls a user's ability to trigger an Event with an application containing an EXPEDITE statement for Expedite policy policyname. Note: To use the EXPEDITE statement, your host system must have CA Workload Automation Service Governor. To grant users access to use the EXPEDITE statement 1. Create a security profile named prefix.EXPEDITE.name. 2. For applications that include the EXPEDITE statement, grant READ access to the user ID the application runs under. Example Bob wants to use the EXPEDITE statement in an application he is creating to specify an Expedite policy of FAST_BAT. The application will run under user ID PROD. The PROD user ID must have READ access to profile ESP.EXPEDITE.FAST_BAT.

Access to Invoke REXX


Security profile: REXXON The REXXON security profile enables you to control the user's ability to include REXX statements in a procedure. Note: If you do not create the REXXON profile, all users can invoke REXX from within a procedure. To control the user's ability to use REXX within a CA Workload Automation procedure 1. Create a security profile named prefix.REXXON. 2. Grant READ access to users who need to invoke REXX.

Chapter 3: Setting Up Security for CA Workload Automation 67

Job-Tracking Security

Job-Tracking Security
CA Workload Automation provides a job-tracking facility that can track job data in real time. The job-tracking facility can track jobs and keep information on their progress. This section show you how to control job-tracking: Access to job-tracking information Access to job-tracking Models Access to pnodes Access to job-tracking commands

Note: For information about job tracking, see Introduction to CA Workload Automation Concepts, Tracking Jobs, in the User Guide and Advanced Tracking in the Advanced User Guide.

Access to Job-tracking Information


Security profile: JOB The JOB.racid.jobname profile controls the user's access to job-tracking information. The racid parameter is the user ID that the job runs under. Unless you need to do otherwise, consider setting up a generic profile to cover all jobs run under a given racid. For example, ESP.JOB.PROD.* protects all jobs running under the PROD racid. To grant access to view job-tracking information 1. Create a security profile named prefix.JOB.racid.jobname. 2. Grant READ access to users. Example Frank wants to view job-tracking data for JOB01 and JOB02 in the PAYROLL application. These jobs run under the user ID PROD. Frank needs READ access to profile ESP.JOB.PROD.JOB01 and ESP.JOB.PROD.JOB02. More information: Identifying the Batch Job User ID (see page 26)

68 Security Guide

Job-Tracking Security

Access to Job-tracking Models


Security profile: MODEL The MODEL.modelname profile controls the user's access to job-tracking models. To grant users access to job-tracking models 1. Create a security profile named prefix.MODEL.modelname. 2. Grant the appropriate access to users. Example: ALTER access Brenda needs to add a new job-tracking model JOB02TK. She requires ALTER access to profile ESP.MODEL.JOB02TK.

Access to pnodes
Security profile: PNODE The PNODE.pnodename controls the user's ability to post a job from a CA Workload Automation pnode (processing node) and to define pnodes. To grant users access to a pnode 1. Create a security profile named prefix.PNODE.pnodename. 2. Grant the appropriate access to users. Example: READ access Frank wants to post JOB01 from a pnode called DISTRIB. Frank needs READ access to profile ESP.PNODE.DISTRIB. Example: ALTER access Bob wants to create a new pnode called BURST. Bob needs ALTER access to profile ESP.PNODE.BURST.

Chapter 3: Setting Up Security for CA Workload Automation 69

Job-Tracking Security

Access to Job-tracking Commands


Security profile: TJD The TJD.jobname profile controls access to CA Workload Automation job-tracking commands (ALTTJ, DEFTJ, and DELTJ) for the job specified by jobname. To grant users access to job-tracking commands 1. Create a security profile named prefix.TJD.jobname. 2. Grant the appropriate access to users who need to issue job-tracking commands. Example: UPDATE access Bob wants to issue the ALTTJ command to change the job-tracking model that all PAYROLL application jobs are associated with. He wants to change the association from model JOBTK to model PAYROTK. Assume that profile ESP.TJD.PA* was set up to control job-tracking commands for all jobs starting with PA. Bob needs UPDATE access to this profile. He can then issue the ALTTJ command to change the job-tracking model for all payroll jobs:
ALTTJ PA- MODEL(PAYROTK)

Example: ALTER access Brenda wants to use the DEFTJ command to define job-tracking parameters for JOB01. She needs ALTER access to ESP.TJD.JOB01.

70 Security Guide

Chapter 4: CA Workload Automation Security Profile Reference


To control access to CA Workload Automation objects, you need to create some or all of the security profiles described in this chapter. This section contains the following topics: About Security Profiles for CA Workload Automation (see page 71) Summary of CA Workload Automation Security Profiles (see page 72) CA Workload Automation Security Profiles (see page 74)

About Security Profiles for CA Workload Automation


This section describes security profiles for CA Workload Automation .

Security Profile Access Levels


You can grant READ, UPDATE, and ALTER access to CA Workload Automation objects. CA Workload Automation accepts a user's request only if the user has sufficient access to the CA Workload Automation object. With ALTER access to an object, a user can create and delete the object. In addition, the user is a Security Administrator for the object. That is, they can give other users access to the object.

Undefined Profiles
By default, CA Workload Automation denies a user access to an object if the security profile protecting the object is not defined. The only exception is for the REXXON profile. If the REXXON profile is not defined, all users can use REXX in CA Workload Automation . You must define the REXXON profile to the security product before the system can control the use of REXX in CA Workload Automation .

Chapter 4: CA Workload Automation Security Profile Reference 71

Summary of CA Workload Automation Security Profiles

Using Wildcards to Specify Security Profiles


You can use wildcards to specify security profiles for CA Workload Automation objects. To use the ** wildcard, you first need to activate the RACF enhanced generic naming facility (available in RACF 1.9 and higher) for the security profile class.

Summary of CA Workload Automation Security Profiles


A table of CA Workload Automation Security Profiles follows:

Profile AGENT.agentname AGENTMSG.verbsubverb.agentname AGENTUSR.userid.agentname APPL.applname APPL.applname.jobname APPLX.applname.jobname CALENDAR.calendarname CSF.CHECK.CMDS CSF.LC. cmd DSALLOC.dsname EVENTINITCLASS.nnn EXPEDITE.policyname

Controls A user's ability to submit jobs to an Agent A user's ability to issue commands and send messages to Agents A user's ability to submit jobs to an Agent under a specified user ID Access to an application and all jobs generated by the application Access to an application and a specific job within the application Execute access to a specific job in an application Access to a calendar CSF line command checking with the CSF.LC. cmd profile Access to specific CSF line commands The data sets that can be invoked from within an Event A user's ability to define an Event with a particular Event initiator class A user's ability to trigger an Event with an application containing an EXPEDITE statement Access to an Event group and to applications generated from those Events

GROUP.event_groupname

72 Security Guide

Summary of CA Workload Automation Security Profiles

Profile GROUPX.event_groupname

Controls Execution access to an Event group and to applications generated from those Events Access to job-tracking information Access to job-tracking models A user's ability to issue a specific z/OS command and its options from an Event Access to the CA Workload Automation ISPF interface, CA Workload Automation Web Interface, and the CA Workload Automation Workstation interface A user's ability to issue any OPER command except RESDEF and its alias RSD, and a user's ability to issue any z/OS command A user's ability to issue a specific OPER command Access to passwords and encryption keys for using Agents A user's ability to post a job from a pnode and define a pnode A user's ability to specify the USER(userid) operand in an Event definition A user's ability to use the ABSORB statement A user's ability to issue the RESDEF command A user's ability to invoke REXX within a procedure A user's ability to specify the OWNER(userid) operand in an Event definition Access to a symbolic-variable library Access to job-tracking commands for the specified job

JOB.racid.jobname MODEL.modelname MVSCMD.mvs_cmd.options...

ONLINE

OPER

OPERCMD.cmdname PASSWORD.userID.agentname PNODE.pnodename RACID.userid

RESABSORB RESOURCE.resname REXXON SETOWNER.userid

SYMLIB.symname TJD.jobname

Chapter 4: CA Workload Automation Security Profile Reference 73

CA Workload Automation Security Profiles

Profile UTIL.cmd UTIL.UTIL VARTABLE.tablename

Controls Access to a specific UTIL mode command Access to utility mode, and the END and ENDREC commands Access to a global variable table

CA Workload Automation Security Profiles


This section describes the security profiles.

AGENT.agentname
AGENT.agentname controls the user's ability to submit jobs to an Agent.

Access READ Example ESP.AGENT.HP_51

Description Allows the user to submit jobs to an Agent.

AGENTMSG.verbsubverb.agentname
AGENTMSG.verbsubverb.agentname controls the user's ability to issue commands and send messages to Agents using the AGENTMSG command.

Access READ Example

Description Allows the user to issue the AGENTMSG command

ESP.AGENTMSG.CONTROL SHUTDOWN.HP_51

74 Security Guide

CA Workload Automation Security Profiles

AGENTUSR.userid.agentname
AGENTUSR.userid.agentname controls the user's ability to submit jobs to an Agent under a user ID specified in the USER(userid) statement of the CA Workload Automation procedure.

Access READ

Description Allows the user to run a job under a user ID specified in the USER statement

Example ESP.AGENTUSR.XR2101.HP_51

APPL.applname
APPL.applname controls access to the application applname and all jobs generated by applname if the application includes the SAF_PROF_APPL operand in the APPL statement. The user must have at least READ access to the Event GROUP that invokes the application applname. When a user issues a command against a job in an application, CA Workload Automation checks the user's access to the application containing the job.

Access READ UPDATE

Description Allows the user to view the application applname and all jobs generated from applname. Allows the user to do a procedure cache delete using the CPROC command. Note: For more information, see the Command Reference Guide and Caching a CA Workload Automation procedure in the User Guide.

Example ESP.APPL.PAYROLL More information: Identifying the Batch Job User ID (see page 26)

Chapter 4: CA Workload Automation Security Profile Reference 75

CA Workload Automation Security Profiles

APPL.applname.jobname
APPL.applname.jobname controls access to the job jobname in application applname if the application includes the SAF_PROF_APPL operand in the APPL statement. The user must have at least the following: READ access to the Event GROUP that invokes the application applname READ access to APPL.applname

Access READ UPDATE

Description Allows the user to view the job jobname in application applname Allows the user to execute any CA Workload Automation command against the job jobname in application applname. These commands include inserting the job and resubmitting the job from a different JCL library

Example ESP.APPL.PAYROLL.JOB01 More information: Basic Event and Application Security (see page 26) Access to an Application (see page 33)

76 Security Guide

CA Workload Automation Security Profiles

APPLX.applname.jobname
APPLX.applname.jobname controls execute-only access to the job jobname in application applname if the application includes the SAF_PROF_APPL operand in the APPL statement. The user must have at least the following: READ access to the Event GROUP that invokes the application applname READ access to APPL.applname

Note: The user has more authority than READ access to APPL. applname.jobname but less authority than UPDATE access to the same profile. You can not use this profile to allow a user to insert a job into an application or resubmit a job from a different JCL library. To allow this type of access, grant UPDATE access to the APPL.applname.jobname profile. If a user is holding or completing an entire application, a pseudo job name of ALL is built and used in the security profile.

Access READ

Description Allows the user to issue control commands against applications or jobs within applications. Examples of control commands are hold, release, request, complete, and resubmit without changing the JCL source

Example ESP.APPLX.PAYROLL.JOB01

More information: Basic Event and Application Security (see page 26) Access to an Application (see page 33)

Chapter 4: CA Workload Automation Security Profile Reference 77

CA Workload Automation Security Profiles

CALENDAR.calendarname
CALENDAR.calendarname controls access to the CA Workload Automation calendar specified in calendarname. Note: All users can browse any calendar by default.

Access UPDATE

Description Allows the user to update the CA Workload Automation calendar specified by calendarname. The user can define holidays and special days within the calendar but cannot update the attributes of the calendar, such as the default workdays Allows the user to create and delete a calendar, as well as update the attributes of the calendar, such as the default workdays

ALTER

Example ESP.CALENDAR.SPECIAL

CSF.CHECK.CMDS
If you want to limit access to specific CSF line commands, use the CSF.CHECK.CMDS profile in combination with the CSF.LC. cmd profile. The CSF.CHECK.CMDS profile specifies the users for which CSF line command checking is done.

Access READ

Description Enables CSF line command checking with the CSF.LC.cmd profile

78 Security Guide

CA Workload Automation Security Profiles

CSF.LC.cmd
CSF.LC. cmd controls access to the CSF line command denoted by cmd. Users can access the CSF line command if their user ID is specified in the CSF.CHECK.CMDS profile and the CSF.LC.cmd profile. Note: If you don't set up a profile for a specific line command, then all users on CSF can issue that CSF line command. Even if you can access a CSF line command, you still need access to the Event group, application, or job the command is issued against. CSF line commands generate an underlying CA Workload Automation command. The CSF.LC profile protects only the CSF command, not the underlying command. For example, the profile can protect CSF command CA but not the underlying command APPLJOB or AJ. Some underlying commands, such as the RESDEF command or OPER commands, have security profiles available to control access. In the case of underlying commands with no security profiles, you should protect the Event group, application, or job the command is issued against.

Access READ

Description Allows the user to issue the CSF line command specified by cmd

Example ESP.CSF.LC.R for CSF line command R ESP.CSF.LC.** for all CSF line commands

DSALLOC.dsname
The DSALLOC.dsname profile controls which data sets can be invoked from within an Event. For example, you can control what libraries can be dynamically allocated. This is useful if you don't want users to invoke schedules from their personal libraries. The DSALLOC operand must be specified in the SAFOPTS initialization parameter or command.

Access READ

Description Allows the user to include the data set specified by

Chapter 4: CA Workload Automation Security Profile Reference 79

CA Workload Automation Security Profiles

Access

Description dsname in an Event. This check is performed in addition to the normal data set access control by the system security product

Example ESP.DSALLOC.PROD.PAYROLL.MASTER

EVENTINITCLASS.nnn
EVENTINITCLASS.nnn controls the user's ability to use the Event definition EICLASS operand to define an Event with a particular Event initiator class nnn.

Access READ

Description Allows the user to define an Event with an initiator class of nnn, where nnn is a number between 0 and 255

Example ESP.EVENTINITCLASS.1 for Event initiator class 1

EXPEDITE.policyname
The EXPEDITE.policyname profile controls a user's ability to trigger an Event with an application containing an EXPEDITE statement for Expedite policy policyname. To use the EXPEDITE statement, your host system must have CA Workload Automation Service Governor.

Access READ

Description Allows a user to trigger an Event with an application containing an EXPEDITE statement for Expedite policy policyname

Example ESP.EXPEDITE.FAST_BAT

80 Security Guide

CA Workload Automation Security Profiles

GROUP.event_groupname
GROUP.event_groupname controls access to a CA Workload Automation Event group (for example, PROD) and to CA Workload Automation applications generated from those Events (for example, PROD.ACCTPAY and PROD.PAYROLL). If the user wants to issue a command against an Event and does not have UPDATE access, the GROUPX profile is checked for READ access.

Access READ

Description Allows a user to: Browse and simulate Events View Events and applications the user created View jobs within the applications

UPDATE

Allows a user to: Issue commands against Events and applications the user created Issue commands against jobs within the applications Create Events Edit Events Delete Events Be sure to grant UPDATE access to the user ID used to execute workload

Example ESP.GROUP.PROD

Chapter 4: CA Workload Automation Security Profile Reference 81

CA Workload Automation Security Profiles

GROUPX.event_groupname
GROUPX.event_groupname controls execute-only access to a CA Workload Automation Event group (for example, PROD) and to CA Workload Automation applications generated from those Events (for example, PROD.ACCTPAY, and PROD.PAYROLL). Note: The user has more authority than READ access to GROUP. event groupname but less authority than UPDATE access to the same profile. The following table illustrates the relationship between the GROUP and GROUPX profiles:

GROUP Profile Access UPDATE READ READ

GROUPX Profile Access NONE NONE READ

Create an Event Y N N

Trigger an Event Y N Y

Note: The GROUPX profile is checked only if the user wants to issue a command against an Event and does not have UPDATE access to the GROUP profile.

Access READ

Description Allows the user to: Trigger, hold, release, suspend, and resume Events Manipulate applications the user created as well as jobs within the applications

Users cannot insert jobs into the application or resubmit a job with a different JCL data set name. Users are not allowed to change the Event definition or delete it, but they can trigger it. Example ESP.GROUPX.PROD

82 Security Guide

CA Workload Automation Security Profiles

JOB.racid.jobname
JOB.racid.jobname controls the user's access to job-tracking information. The racid parameter is the user ID that the job runs under.

Access READ Example ESP.JOB.PROD.JOB01 More information:

Description Allows a user to view job-tracking information

Identifying the Batch Job User ID (see page 26)

MODEL.modelname
MODEL.modelname controls the user's access to job-tracking models.

Access ALTER

Description Allows the user to create, replace and delete models, and gives the user administrator control of the profile

Example ESP.MODEL.JOB01TK

Chapter 4: CA Workload Automation Security Profile Reference 83

CA Workload Automation Security Profiles

MVSCMD.mvs_cmd.options...
MVSCMD.mvs_cmd.options controls the user's ability to issue the specified z/OS command and its options from an Event. The MVSCMD operand must be specified in the SAFOPTS initialization parameter Note: For more information see the Installation and Configuration Guide . When CA Workload Automation passes a request to issue an z/OS command to the security product, the RACHECK is formatted in the following way: All commas are changed to blanks. All occurrences of one or more blanks are changed to a period.

You can create generic profiles by using wildcard characters in the command and options string of the profile to specify a group of items. For example: The security profile to control access to all z/OS display commands is MVSCMD.D.**. The security profile to control the ability to vary active VTAM LUs with the prefix RLU is MVSCMD.V.NET.ACT.ID=RLU*.

The following table gives examples of z/OS commands and security profiles that will control access to these commands.

z/OS Command D U, TAPE, ONLINE S LWTRL.L , , , L F CATALOG, OPEN(DUMP01)

Security Profile MVSCMD.D.U.TAPE.ONLINE MVSCMD.S.LWTRL.L.*.*.L MVSCMD.F.CATALOG.OPEN(DUMP0 1)

The access options are as follows:

Access READ

Description Allows the user to issue z/OS commands from an Event if the MVSCMD profile is active

Example ESP.MVSCMD.SE.** for the z/OS send command and all its options

84 Security Guide

CA Workload Automation Security Profiles

ONLINE
ONLINE controls user access to CA Workload Automation ISPF interface, the CA Workload Automation Workstation interface, and the CA Workload Automation Web Interface.

Access READ

Description Allows a user to use CA Workload Automation through one of the available interfaces

OPER
OPER controls the user's ability to issue Any OPER command except RESDEF and its alias RSD. Access to the RESDEF command is controlled by the RESOURCE. resname profile. Make sure that the SAFOPTS initialization parameter has NOOPERCMDS (the default) set. Any z/OS command. Make sure that the SAFOPTS initialization parameter has NOMVSCMD (the default) set. Note: For more information on the SAFOPTS initialization parameter, see the Installation and Configuration Guide .

Access READ

Description Allows the user to issue any OPER command or any z/OS command

More information: Access to Use the RESDEF Command (see page 64)

Chapter 4: CA Workload Automation Security Profile Reference 85

CA Workload Automation Security Profiles

OPERCMD.cmdname
OPERCMD.cmdname controls the user's ability to issue the specified OPER command if the OPERCMDS operand is specified in the SAFOPTS initialization parameter. Specify the command only, not the command operands. For example, specify L not L LEVEL(PROD). If a command has a short form, you should create a profile for the command and another profile for the short form of the command. For example, create profile ESP.OPERCMD.LIST to control access to the LIST command and profile ESP.OPERCMD.L to control access to L, the short form of LIST. For more information on the SAFOPTS initialization parameter, see the Installation and Configuration Guide .

Access READ

Description Allows the user to issue the CA Workload Automation operator command cmdname

Example ESP.OPERCMD.LIST for the long form of OPER command LIST LEVEL (PROD) ESP.OPERCMD.L for the short form of OPER command LIST LEVEL (PROD)

PASSWORD.userID.agentname
The PASSWORD profile controls the ability of the mainframe user given by userID to Delete or update the password for using the Agent given by agentname without supplying the old password. To delete or update the password, you use the PASSWORD command. Delete or update an encryption key for using the Agent given by agentname without supplying the old encryption key. To delete or update the an encryption key, you use the CRYPTKEY command.

Access UPDATE

Description Allows userID to modify or delete the password to access agentname without specifying the current password

86 Security Guide

CA Workload Automation Security Profiles

Example ESP.PASSWORD.JDOE.HP_51

PNODE.pnodename
PNODE.pnodename controls the user's ability to post a job from a CA Workload Automation pnode (processing node) and to define pnodes.

Access READ ALTER

Description Allows the user to post a job from a CA Workload Automation pnode Allows the user to create and delete pnodes, and gives the user administrator control of the profile

Example ESP.PNODE.DISTRIB

RACID.userid
RACID.userid controls the user's ability to specify the USER(userid) operand in an Event definition. USER(userid) specifies an overriding user ID for an Event to execute with. Note: To specify USER(userid) on an Event, you must have READ access to RACID.userid and UPDATE access to the Event through the GROUP profile.

Access READ Example

Description Allows the user to assign a RACID(userid) to an Event

ESP.RACID.XR2105 to allow statement USER(XR2105) More information: Identifying the Batch Job User ID (see page 26)

Chapter 4: CA Workload Automation Security Profile Reference 87

CA Workload Automation Security Profiles

RESABSORB
RESABSORB controls the user's ability to use the ABSORB statement in an application.

Access READ

Description Allows the user to use the ABSORB statement

RESOURCE.resname
The RESOURCE.resname profile controls the use of the RESDEF command as follows: Controls who can specify a CA Workload Automation resource as part of their job scheduling requirements. Controls who can create, delete, or modify usage counts associated with specific resources.

Access UPDATE

Description Allows the user to set and display CA Workload Automation job scheduling resources with the RESDEF command Gives the user create and delete authorities on job scheduling resources with the RESDEF command

ALTER

Example ESP.RESOURCE.SCRATCH for resource SCRATCH

REXXON
The REXXON security profile enables you to control the user's ability to include REXX statements in a procedure. Note: If you do not create the REXXON profile, all users can invoke REXX from within a procedure.

Access READ

Description Allows the user to invoke REXX from within a CA Workload Automation procedure

88 Security Guide

CA Workload Automation Security Profiles

SETOWNER.userid
SETOWNER.userid controls the user's ability to specify the OWNER(userid) operand in an Event definition. OWNER(userid) specifies an overriding owner for an Event. Ownership in a SAF environment affects only the TSO user who receives the failure messages. The default owner is the last user to modify the Event. Note: To specify OWNER(userid) in an Event, you must have READ access to SETOWNER.userid and UPDATE access to the Event through the GROUP profile. Important! If a Mailbox is set up then failure messages go to the Mailbox, even if there is an OWNER operand specified.

Access READ Example

Description Allows an owner to be specified for an Event

ESP.SETOWNER.XR5504 for statement OWNER(XR5504)

SYMLIB.symname
SYMLIB.symname controls access to the CA Workload Automation symbolic-variable library specified by symname.

Access READ UPDATE ALTER Example

Description Allows the user to display a CA Workload Automation SYMLIB Allows the user to create and delete SYMLIB variables and change their values Allows the user to create and delete SYMLIBs

ESP.SYMLIB.GENSYM for the GENSYM symbolic variable library

Chapter 4: CA Workload Automation Security Profile Reference 89

CA Workload Automation Security Profiles

TJD.jobname
TJD.jobname controls access to CA Workload Automation job-tracking commands (ALTTJ, DEFTJ, and DELTJ) for the job specified by jobname.

Access UPDATE ALTER

Description Allows the user to use the ALTTJ command to change job-tracking definitions Allows the user to issue the DEFTJ and DELTJ commands to define and delete job-tracking definitions

Example ESP.TJD.PA* to control job-tracking commands for all jobs starting with PA

UTIL.cmd
UTIL.cmd controls access to the UTIL mode command specified by cmd.

Access READ

Description Allows a user to issue the command specified by cmd in CA Workload Automation utility mode

Example ESP.UTIL.DUMPKEY for the DUMPKEY command

UTIL.UTIL
UTIL.UTIL controls access to CA Workload Automation utility mode and access to two utility mode commands: END and ENDREC.

Access READ

Description Allows the user to access CA Workload Automation utility mode and issue commands END and ENDREC

90 Security Guide

CA Workload Automation Security Profiles

VARTABLE.tablename
VARTABLE.tablename controls access to the global variable table specified by tablename.

Access READ UPDATE

Description Allows a user to list a table with the VTLIST command and to retrieve a variable with the VGET command Allows a user to: Store a variable with the VPUT command Set the value of a variable with the VSET command Increment a variable with the VINCR command Define a trigger with the VTRDEF command

ALTER

Allows a user to: Define a table with the VTDEFINE command Delete a table with the VTDELETE command Delete a variable with the VDEL command Delete a trigger with the VTRDEL command

Example ESP.VARTABLE.GENSYM for the GENSYM global variable table

Chapter 4: CA Workload Automation Security Profile Reference 91

Glossary
AFM Automated Framework Message. A structured message used to communicate commands and statuses between components in CA Workload Automation . Agent A program residing on a distributed server that allows CA Workload Automation or CA Workload Automation DE to automate and manage workload running on operating systems, such as Windows, Linux, and UNIX, and ERPs, such as SAP, PeopleSoft, and Oracle E-Business Suite. AGENT_MONITOR A workload object that monitors the status of CA Workload Automation agents. Alert Used to trigger an Event when a job reaches a particular stage in processing, such as job submission, job start, or job failure. For example, you can set up an Alert to trigger an Event when a job in an application becomes overdue. To monitor at the step level, use job monitoring instead. Application A group of related workload objects that run under CA Workload Automation control. Applications allow you to group jobs that might run on different platforms and at different times into a single workflow. You define an application in a procedure. Application Monitor An CA Workload Automation facility for monitoring and controlling applications in ISPF. From Application Monitor, you can issue commands, for example to insert a job into an application, complete an application or release a held application. Audit log The Audit log is an audit trail of CA Workload Automation activity. The audit log stores information on administrative activities, operator commands, and application and Event processing. Each entry has a date and time stamp, a message number, a message class (indicating the creator of the log entry), and a message. You can reference message details in the Message Reference Guide. The audit log can be found in the CA Workload Automation started task job output. Automated Framework Message See AFM (see page 93).

Glossary 93

Backout The act of deleting all data sets a job previously created. For example, if a job abnormally terminates (abends), you can use CA Workload Automation Restart Option EE to back out the failed job's processing as if the job had never executed. CA Workload Automation Console Manager CA Workload Automation Console Manager is a console automation tool that allows you to reduce the message traffic to the console. You can use CA Workload Automation Console Manager to monitor all console activity, review commands and messages, provide real-time statistics, automate responses and procedures, and perform simulations. CA Workload Automation DE (formerly ESP dSeries) An Enterprise Job Scheduling solution that runs on distributed systems and offers Event-based automation across both mainframe and distributed systems. CA Workload Automation EE CA Workload Automation EE acts as the central point of control for your workload-handling and directing all incoming messages from CA Workload Automation Workstation and agents. Through agents, CA Workload Automation manages workload on distributed systems. CA Workload Automation Restart Option EE CA Workload Automation Restart Option EE is an advanced rerun and restart product that works with CA Workload Automation EE to restart batch jobs. CA Workload Automation Restart Option EE recommends the restart point in failed jobs, can make the necessary adjustments to batch JCL, and can perform the necessary data set cleanups for an error-free restart. CA Workload Automation Workstation A graphical user interface that you use to define, monitor, and control your workload. CA Workload Automation Workstation runs on Microsoft Windows and communicates with CA Workload Automation EE. Calendar A collection of definitions for holidays and special days that are unique to your installation. The calendar also identifies workdays and the first day of the week. CCCHK A statement used to specify job processing based on condition codes. If a job produces a specified condition code, the CCCHK statement determines whether CA Workload Automation considers the job as failed and whether the job continues to run. For example, you can immediately stop a failing job without running any subsequent steps regardless of the conditional operands in the JCL. CCFAIL Condition code fail. CCFAIL statements identify which condition codes cause CA Workload Automation to consider a job as failed, preventing successor jobs from being submitted.

94 Security Guide

CLANG Control language. CLANG is a high-level programming language developed for CA Workload Automation . Cleanup The act of deleting data sets prior to a job being run or restarted. For example, before CA Workload Automation Restart Option EE restarts a job, it can delete the data sets created by that job in its previous run. Command A request made of CA Workload Automation . For example, the LOADAGDF command loads the Agent Definition file. Consolidated Status Facility (CSF) See CSF (see page 95). COPYJCL A user data set containing a working copy of the submitted JCL with the variables resolved. Using the COPYJCL statement, if a job fails, you can modify the working copy of the JCL and resubmit the job, without affecting the JCL source. Critical path The longest path, based on historical execution time, to a workload object representing a critical point in the CA Workload Automation application. The critical path is dynamic; it changes as the application runs. A CA Workload Automation application can have multiple critical paths. A critical path can cross applications if an application has external jobs. CSF A CA Workload Automation facility for monitoring and controlling the workload in ISPF. From CSF, you can issue commands, for example to bypass a job, restart a failed job or edit a job's JCL. Data object See Variable (see page 102). DJC Dependent Job Control. A product that controls resources and job networks at the initiator level. DJC job network A group of related jobs where dependencies are controlled at the initiator level. DOCLIB A user data set containing job documentation entries. Each entry consists of control information-information CA Workload Automation uses directly when processing a job, such as the JCL library-and user description-other information you want to store about a job, such as restart instructions.

Glossary 95

DSTRIG Used to trigger an Event based on data set activity at the Event level or release a job based on data set activity at the job level. For example, using DSTRIG, you can trigger an Event or release a job based on the creation or FTP transfer of a data set. Enqueue Allows a job to request exclusive or shared use of a resource without the need for the user to define the resource explicitly in advance. CA Workload Automation will prevent jobs with mutually exclusive requests from executing concurrently. CA Workload Automation enqueues behave like the z/OS enqueues. Event Runs the workload defined by your applications. When an event is triggered, CA Workload Automation invokes the procedure that contains your application definition. You can use events to schedule workload, trigger workload manually or trigger workload based on data set activity such as the arrival of a file. You can also use events to send messages and issue operator commands. EXH data set Execution history data set. CA Workload Automation Restart Option EE stores all its job history information in the EXH data set. Job history records are stored as job groups. A job group consists of an initial run and all the restart runs. Expedite Specifies how a job should be accelerated based on your criteria. Requires CA Workload Automation Service Governor. External job A job defined in an application that CA Workload Automation submits from another application. You use external jobs to establish dependencies between jobs in different applications. The application that submits the job is known as the home application. The application where the job is defined as external is known as the distant application. EXTMON A workload object used to monitor a job executed by an external scheduler, such as CA Workload Automation DE. File trigger A workload object used to release a job based on file activity. For example, you can release a job based on the creation of a file or a change in file size.

96 Security Guide

Full name A full name is a 1 to 64 character identifier for any distributed or mainframe workload. Valid full name characters are alphanumeric (A to Z, 0 to 9), national (@, #, $), underscores, and periods. The first character must be alphabetic or national. There cannot be consecutive periods or a period as the last character. The full name for mainframe workload must start with a valid mainframe job name. Global variable See Variable (see page 102). HAO High Availability Option. See High Availability Option (HAO) (see page 97). High Availability Option (HA0) High Availability Option takes full advantage of the IBM clustering sysplex technology to increase enterprise IT performance by improving the availability of system resources throughout the organization. HAO includes Initial run The first time a job is submitted for execution. Initialization parameter A CA Workload Automation setting applied at initialization time. The initialization parameters define the CA Workload Automation environment at startup. JCLLIB A user data set containing the JCL for z/OS jobs CA Workload Automation submits. Job ID An identification assigned automatically to every job by JES. The format of the Job ID varies according to the following rules: Shadow manager (see page 101). IBM Automatic Restart Management (ARM) function support. XCF status monitoring (see page 103). Universal login (see page 102).

Condition

Format

JES2 not running in z2 mode (with large JOBnnnnn job numbers disabled) JES2 running in z2 mode (with large job numbers enabled) JES3 Jnnnnnnn For job numbers less than 100000: JOBnnnnn

Glossary 97

Condition

Format For job numbers greater than 99999: Jnnnnnnn

Note: The same format used for the JES job ID is used by JOBONQ. Job monitoring Used to trigger an Event when a job reaches a particular stage in processing, such as at the end of a step, at the end of a job or when a job is purged. Unlike Alert processing, job monitoring supports step-level checking. Job name A job name is the first eight characters of a full name or the first one to eight characters before the first period in a full name. Job names are shown in the user interface and in reports and are available in variables. Valid job name characters are alphanumeric (A to Z, 0 to 9), national (@, #, $), and underscores (for distributed workload only). The first character must be alphabetic or national. Link A workload object in an application that is automatically marked complete when its predecessor and time dependencies are met. You can use a link, for example, to simplify job relationships, keep an application active, and notify someone when something happens or does not happen. Long name A long name is a 1-to-64-character description for distributed workload only. A long name is case sensitive and can include any character. You specify a long name in the LONGNAME operand of the job definition statement. Long name can be displayed in CSF, included in reports, and coded in CLANG through the %ESPLONGNAME variable. By default, if The long name specified meets the standards for a full name

The full name specified is a job name or job name and qualifier long name, not full name, identifies the workload. In this case, the long name replaces the full name in the user interface, reports, and variables and you must specify the long name wherever the a full name is required. Your administrator can override this default by applying usermod 59. Manual job Used to create dependencies on jobs that are submitted outside of CA Workload Automation , for example a job that a user manually submits. When the manually submitted job completes, CA Workload Automation releases the manual job's successors. Master A CA Workload Automation subsystem that centrally controls the workload across multiple z/OS images.

98 Security Guide

On-request job An on-request job is a job run on demand; it is not a regularly scheduled job. You can identify certain jobs as on-request jobs in an application and define their relationships to other jobs. Operand A parameter of a statement, command or initialization parameter. For example, the LOADAGDF command has an optional operand that identifies the AGENTDEF data set you want to load. Page mode A command line interface for entering CA Workload Automation commands in ISPF. Page mode produces scrollable output. Pnode Processing node. CA Workload Automation uses the INPUT, EXEC, and OUTPUT pnodes to track a job. In CSF, pnodes represent the processing states of a job such as PREDWAIT, RESWAIT, WAITING, READY, and COMPLETE. You can define additional manual pnodes, for example to represent the distribution phase of output. Procedure A data set containing statements and commands. You define applications in procedures and invoke procedures using an event. Procedures can contain CLANG, symbolic variables, built-in functions, and REXX. PROCLIB A user data set that contains CA Workload Automation procedures. You define your applications in procedures. Proxy A CA Workload Automation subsystem that captures SMF data for the workload running on that z/OS image and transmits that data to the master. Qualifier A qualifier is the one to eight characters after a job name and period in a full name. If there are more than eight characters after the period or if there is another period in the full name, qualifier is a system-generated number, for example, ~0000001. Qualifiers are shown in the user interface and in reports and are available in variables. Valid qualifier characters are alphanumeric (A to Z, 0 to 9), national (@, #, $), and underscores. A qualifier can be used to distinguish a job from other jobs with the same job name, give a more descriptive name to a job, and pass symbolic variables. Rerun To re-execute a job as an initial run. Before running the job, CA Workload Automation resets the job to the state before it ran.

Glossary 99

Resource Any type of real or abstract object that affects a job's ability to run successfully and can be quantified. Resources are classified into the following three types: Renewable resource - A borrowed resource. When CA Workload Automation submits a workload object, it removes the renewable resource from the resource pool. The resource, however, is not permanently used up. Instead, the resource returns to the resource pool when the workload object finishes running, whether it was successful or not. You can use a renewable resource, for example, to represent tape drives, a database or sort workspace. Depletable resource - A consumed resource. When CA Workload Automation submits a workload object, it permanently removes the depletable resource from the resource pool. You can replenish the resource using a CA Workload Automation command, so other jobs can use the resource. You can use a depletable resource, for example, to represent the number of scratch tapes available or a permanent DASD space. Threshold resource - A sizing resource. CA Workload Automation sizes the workload object against the threshold resource's current level. For example, if the threshold resource is set to two, CA Workload Automation only submits workload objects that require two or fewer units of the resource. You can use a threshold resource, for example, to prevent certain workload objects from executing until a NITESHIFT period begins. Note: Enqueues are implicit resources. Restart To re-initiate a run of a job using information from the previous execution. For example, you can use CA Workload Automation Restart Option EE to restart a job from the point of failure to the end of the job. SADGEN A user data set containing scheduled activity information on jobs. You use this data set for schedule-activity reports. Schedule criteria Specification of scheduling requirements for Events and jobs. You use free-format, everyday English as scheduling terms to specify schedule criteria. CA Workload Automation has a built-in understanding of general scheduling terms. You can add your own unique scheduling terms, special processing periods, holidays, and other special days using calendars. Service Governor Service Governor optimizes workload to significantly increase the performance of the enterprise IT environment. Service Governor includes

100 Security Guide

Shadow manager

Expedite (see page 96). Resource balancing, which monitors all the resources in the resource topology for availability and usage. Workload balancing (see page 102). XCF status monitoring (see page 103). Universal login (see page 102).

Allows your environment to shift the workload to another CA Workload Automation master so processing can continue should your system fail. Requires High Availability Option. Statement Gives information to CA Workload Automation about an object. For example, the RUN statement specifies a job's run criteria in a job definition. You always code statements within a procedure. Subapplication Groups of workload objects that belong to a CA Workload Automation application. You can use subapplications to break up a large application into smaller, easier-to-manage job groups. Symbolic variable See Variable (see page 102). SYMLIB A user data set that contains symbolic variables. Sysmsg Used to intercept system messages written to the JES system message data set. The JES system message data set consists of the job's log. After CA Workload Automation intercepts a system message, you can cancel a job, fail a job, trigger an Event or issue a WTO (write-to-operator) message. Tag A user-defined field used to filter jobs with a common characteristic in CSF or to pass information to JCL. For example, you can tag high-priority jobs and filter these jobs in CSF. Task A workload object in an application that can require manual completion or can complete automatically when its dependencies are met (self-completing). You can use a task to represent a process that requires manual intervention, such as the checking of a report during application processing, or a process that can be automated.

Glossary 101

TEMPLIB A user data set that contains temporary or override JCL. In an application definition, use the TEMPLIB statement to specify the temporary JCL library you want to use as the default for all jobs following this statement. Tracking model A centralized definition of the attributes and processing phases of a group of jobs. CA Workload Automation uses job-tracking models to track jobs and store job history for reporting. Universal login Allows CA Workload Automation clients connected to a CA Workload Automation proxy to route subsystem requests to the CA Workload Automation master (XCF routing service) and to view the CSF and Application Monitor scoreboards (XCF scoreboard service). Requires High Availability Option (HA0) or Service Governor. User data sets See COPYJCL (see page 95), DOCLIB (see page 95), JCLLIB (see page 95, see page 97), PROCLIB (see page 99), SADGEN (see page 100), SYMLIB (see page 101) and TEMPLIB (see page 102). Variable Data objectServes as a data repository. A data object is coded in an application as any other workload object. You can store variables in a data object and retrieve those variables from a data object in another application. You can also store, update, and delete data in a data object at run time using AFMs. Global variableA variable available across applications. You store global variables in global variable tables. A global variable trigger triggers an Event when a designated global variable changes. Symbolic variable An integer or a character string whose value can change during CA Workload Automation processing. When CA Workload Automation encounters a symbolic variable, it substitutes the current value of that variable. You can use symbolic variables to define date operands, job names, job dependencies, and so on. You can use CA Workload Automation built-in symbolic variables or define your own. Workday A calendar definition defines a site's workdays. The default workdays are Monday through Friday, excluding any holiday that has been defined for the site. Workload balancing Selects where to run workload using IBM WLM workload balancing for z/OS workload and Agent workload balancing for Agent workload. Requires Service Governor.

102 Security Guide

Workload object A representation of work to be scheduled. An application consists of workload objects. Workload objects include jobs that execute programs, such as mainframe JCL, Windows command files, UNIX scripts, and AS/400 programs, objects that monitor for conditions, such as data set and file activity, and objects that run on CA Workload Automation , such as links and tasks. XCF status monitoring Monitors CA Workload Automation XCF members' activity for any possible problems. Requires High Availability Option (HA0) or Service Governor.

Glossary 103

Index
A
about security profiles for ESP Workload Manager 71 ABSORB statement, access to use 64 abstract resources, access to specify 64 access execute-only to a job within an Application 35 execute-only, to an Event group 30 levels for security profiles 71 access to a global variable table 66 a job within an Application 34 a symbolic variable library 65 an Application 33 an Event group 29 calendars 31 ESP Workload Manager 26 invoke REXX 67 issue commands and send messages to an Agent 42 issue OPER commands 58 issue z/OS commands 60 job-tracking commands 70 job-tracking information 68 job-tracking models 69 OPER command MAPUSER 44 passwords and encryption keys for using Agents 43 pnodes 69 specific CSF line commands 37 specific utility mode commands 63 specify an Event initiator class 38 specify data sets in an Event 39 specify real and abstract resources 64 specify the OWNER(userid) operand 40 specify the USER(userid) operand 38, 42 submit work to an Agent 42 the RESDEF command 58, 64 use the ABSORB statement 64 use the EXPEDITE statement 67 utility mode 62 view entries in CSF 36 ACF2 SAF examples 19 SAF support 19 using SAF with 19 additional Event and Application security 32 AFM definition 93 Agent access to 42 access to issue commands and send messages to 42 access to submit work to 42 communication security 44 default security for UNIX 48 default security for Windows NT 49 determining the encryption key for 46 distributed workload security 40 examples of local Agent security file rules 54 local security 50 message encryption 45 platform security 48 AGENT profile 42, 74 AGENT_MONITOR definition 93 AGENTDEF member 45, 46 AGENTMSG profile 42, 43, 74 agentparm.txt file 45 AGENTRCV initialization parameter 45 Agents host part of distributed workload security 41 AGENTUSR profile 42, 75 Alert definition 93 Application Monitor definition 93 audit log definition 93 Automated Framework Message definition 93

B
backout definition 94 basic Event and Application security 26 batch

Index 105

issuing commands in 12 jobs, identifying the user ID for 26 Blowfish encryption 45

C
calendar definition 94 CALENDAR profile 31, 78 calendars, access to 31 CCCHK definition 94 CCFAIL definition 94 CLANG definition 95 cleanup definition 95 command access to issue OPER 58 access to issue z/OS commands 60 access to specific utility mode 63 definition 95 ESPmgr 44 security 57 TSO, processor 13 commands ALTTJ job-tracking, access to 70 console, issuing 12 CRYPTKEY 43 DEFTJ job-tracking, access to 70 DELTJ job-tracking, access 70 END utility mode 62 ENDREC utility mode 62 entering 10 issuing in batch 12 job-tracking, access 70 masking 11 OPER, issuing 12 OPER, MAPUSER 44 RESDEF, access to 58, 64 security for 57 wildcards 11 comments in statements 11 in the local security file 52 communication security 44 console commands, issuing 12 Consolidated Status Facility (CSF) definition 95

continuation of statements 10 controlling ESP Workload Manager resources 63 conventions input 13 syntax 13 used in this guide 13 COPYJCL definition 95 critical path definition 95 CRYPTKEY command 43 CSF definition 95 entries, access to view 36 line commands, access to specific 37 CSF.CHECK.CMDS profile 78 CSF.LC profile 37

D
Data Encryption Standard 45 data object definition 95 data set security, standard 16 data sets in an Event, access to specify 39 statements 11 default security for UNIX 48 for Windows NT 49 rules 53 DEFTJ job-tracking command, access to 70 delimiters in statements 11 DELTJ job-tracking command, access to 70 depletable resource definition 100 DES 45 distributed workload security 40 DJC definition 95 DJC job network definition 95 DOCLIB definition 95 DSALLOC profile 39, 79 DSTRIG definition 96

106 Security Guide

E
ENCRYPTEDONLY keyword 45 encryption AGENTDEF member 45, 46 agentparm.txt file 45 AGENTRCV initialization parameter 45 Blowfish 45 DES 45 ENCRYPTEDONLY keyword 45 key, determining for an Agent 46 keys for using Agents, access to 46 of a message 45 security.cryptkey parameter 45 END utility mode command 62 ENDREC utility mode command 62 enhanced generic naming facility, RACF wildcards 72 enqueue definition 96 entering commands 10 statements 10 ESP Agent definition 93 ESP Application definition 93 ESP Console Manager definition 94 ESP dSeries definition 94 ESP Encore definition 94 ESP Procedure definition 99 ESP Workload Manager definition 94 ESP Workload Manager High Availability Option definition 97 ESP Workload Manager Service Governor definition 100 ESP Workload Manager, improving performance with the SECURE operand 36 ESP Workstation definition 94 ESP Workstation access 26 ESPmgr command 44 Event access to specify data sets in 39 definition 96

group, access to an 29 initiator class, access to specify an 38 security, additional 32 security, basic 26 EVENTINITCLASS profile 38, 80 EVENTSAF, effect on batch job user ID 27 execute-only access to a job within an Application 35 to an Event group 30 EXH data set definition 96 Expedite definition 96 profile 67, 80 statement, access to use 67 statement, Service Governor requirement 67 External job definition 96 EXTMON definition 96

F
file trigger definition 96 full name definition 97

G
getting started 25 global variable definition 97 global variable table, access to 66 GROUP profile 29, 36, 81 GROUPX profile 30, 36, 82

H
HAO definition 97 host security 41

I
identifying the batch j ob user ID 26 indentation, statements 11 initial run definition 97 initialization parameter definition 97 initiator class, Event, access to specify 38

Index 107

input conventions 13 installation, security file created at 53 interface, SAF 15 introduction to ESP Workload Manager security 15 ISPF panel access 26 issue commands and send messages to an Agent, access to 42 ITU, effect on batch job user ID 27

M
manual job definition 98 masking commands 11 statements 11 master definition 99 message encryption 45 MODEL profile 69, 83 MVSCMD operand 60 MVSCMD profile 60, 84

J
JCLLIB definition 97 job within an Application, access to 34 within an Application, execute-only access to 35 job ID definition 97 job monitoring definition 98 job name definition 98 JOB profile 68, 83 jobs, identifying the user ID for batch execution 26 job-tracking commands, access to 70 information, access to 68 models, access to 69 security 68

N
NOMVSCMD operand 60 NOOPERCMDS operand 58

O
ONLINE profile 26, 85 OPER command MAPUSER, access to 44 command, access to issue 58 commands, issuing 12 profile 44, 58, 60, 85 operand definition 99 OPERCMD profile 44, 58, 86 OPERCMDS operand 58 OWNER(userid) operand, access to specify 40

K
key, determining the encryption, for an Agent 46 keys, access to encryption, for using Agents 43

P
page mode definition 99 PASSWORD command 43 PASSWORD, JCL parameter, effect on batch job user ID 27 profile 43, 86 passwords for using Agents, access to 43 percent sign, uses of 60 pnode definition 99 PNODE profile 69, 87 pnodes, access to 69 post a job from a pnode, access to 69 procedure statements, security for 66 PROCLIB definition 99

L
link definition 98 local Agent security 50 security file, comment lines 52 security file, rule starting poin t and spacing 52 security file, wildcards in 52 security-file entries syntax 51 long name definition 98

108 Security Guide

profile reference, security 71 profiles AGENT 42, 74 AGENTMSG 42, 74 AGENTUSER 42, 75 APPL.applname 33, 75 APPL.applname.jobname 33, 76 APPLX 35, 77 CALENDAR 31, 78 CSF.CHECK.CMDS 37, 78 CSF.LC 37, 79 DSALLOC 39, 79 EVENTINITCLASS 38, 80 EXPEDITE 67, 80 GROUP 29, 36, 81 GROUPX 30, 36, 82 JOB 68, 83 MODEL 69, 83 MVSCMD 60, 84 ONLINE 26, 85 OPER 44, 58, 60, 85 OPERCMD 44, 58, 86 PASSWORD 43, 86 PNODE 69, 87 RACID 38, 87 RESABSORB 64, 88 RESOURCE 64, 88 REXXON 67, 88 SETOWNER 40, 89 SYMLIB 65, 89 TJD 70, 90 UTIL.cmd 63, 90 UTIL.UTIL 62, 90 VARTABLE 66, 91 proxy definition 99

renewable resource definition 100 rerun definition 100 RESABSORB profile 64, 88 RESDEF command, access to 58, 64 resource definition 100 RESOURCE profile 64, 88 resources, controlling ESP Workload Manager 63 restart definition 100 REXX execs, restrict access to using wildcards 60 REXX, access to invoke 67 REXXON profile 67, 88 profile, exception to undefined profile access 72

S
SADGEN definition 100 SAF 11 ACF2 examples 19 ACF2 support 19 interface 15 using with ACF2 19 using with Top Secret 20 SAF_PROF_APPL operand 29, 30, 33, 34 SAFOPTS parameter 58 SCHDFILE initialization parameter 36 schedule criteria definition 100 SECURE operand 36 security file created at installation 53 file rules, examples of local Agent 54 for procedure statements 66 for symbolic variables 65 host 41 job-tracking 68 profile access levels 71 profile reference 71 profiles, summary 72 profiles, using wildcards to specify 72 rule starting point and spacing 52 rules, default 53

Q
qualifier definition 99

R
RACF wildcards and enhanced generic naming facility 72 RACID profile 38, 87 RACROUTE, effect on batch job user 27 real resources, access to specify 63 reference, security profiles 71

Index 109

setting up for ESP Workload Manager 25 types used in ESP Workload Manager 15 security profiles 72 security.cryptkey parameter 45 security-rule interpretation 52 Service Governor, requirement to use EXPEDITE statement 67 SETOWNER profile 40, 89 setting up security for ESP Workload Manager 25 shadow manager definition 101 standard data set security 16 statement definition 101 statements comments 11 continuation 10 data sets 11 delimiters 11 entering 10 EXPEDITE, Service Governor requirement 67 indentation 11 masking 11 procedure, security for 66 wildcards 11 steplib, TSO command processor 13 subApplication definition 101 submit work to an Agent, access to 42 subsystem name 12 symbolic variable definition 101 symbolic variable library, access to 65 symbolic variables, security for 65 SYMLIB definition 101 SYMLIB profile 65 syntax conventions 13 local security-file entries 51 sysmsg definition 101 System Authorization Facility 16

task definition 101 TEMPLIB definition 102 threshold resource definition 100 TJD profile 70, 90 Top Secret using SAF with 20 tracking model definition 102 tracking, job, security 68 trigger method, effect on batch job user ID 27 TSO command processor, steplib 13 types of security used in ESP Workload Manager 15

U
undefined profiles 71 undefined profiles, access, REXXON profile exception 71 universal login definition 102 UNIX, default security 48 USER JCL parameter, effect on batch job user ID 27 statement in NT job definition 43 user access to ESP Workload Manager 26 user data sets definition 102 user ID, identifying for batch jobs 26 USER(userid) operand access to specify 38, 42 effect on batch job user ID 27 UTIL.cmd profile 63 UTIL.UTIL profile 62, 90 utility mode access to 62 commands, access to specific 63 END command 62 ENDREC command 62

V
variable definition 102 variables, security for 65 VARTABLE profile 66, 91

T
tag definition 101

110 Security Guide

W
web interface access 26 wildcards commands 11 in the local security file 52 RACF enhanced generic naming facility 72 restrict access to commands using 60 statements 11 wildcards, using to specify security profiles 72 Windows NT, default security 49 workday definition 102 Workload balancing definition 102 workload object definition 103

X
XCF status monitoring definition 103

Z
z/OS commands, access to issue 60

Index 111

You might also like