CA Workload Automation Administrators Guide

Security Guide r11.3

CA Workload Automation EE

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 [email protected].

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.

http://www.ca.com/support

mailto:[email protected]

http://www.ca.com/docs



Contents 5

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

6 Security Guide

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

Contents 7

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

8 Security Guide

SYMLIB.symname ........................................................................... 89

TJD.jobname ............................................................................... 90

UTIL.cmd ................................................................................... 90

UTIL.UTIL .................................................................................. 90

VARTABLE.tablename ....................................................................... 91

Glossary 93

Index 105


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

How To Use This Guide

10 Security 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: (/* */).

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-

Examples

12 Security Guide

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

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


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 Meaning

Quote marks '' or ' Must be entered as shown.

Comma , Must be entered as shown.

Ellipsis … The operand can be repeated. Do not enter ellipsis.

Lower Case Italics

operand

An operand must be substituted. User supplied variable

or character string.

Uppercase operand The operand must be spelled as shown. You can enter

the command and the operand in either upper or lower

case.

OR-bar ( | ) Indicates an exclusive value on left or right of bar. You

must enter one of the items. You cannot enter more than

one.

Underline _______ If you do not enter one of the operands, the system

supplies the underlined operand, this is the default

Parentheses ( ) and

special characters

Operand enclosed in parentheses is mandatory and must

be entered as shown.

Single operand in

square brackets [ ]

Optional operand, do not type the brackets.


14 Security Guide

Notation Meaning

Stacked operands in

braces

{ }

{ }

Mandatory, you must enter one of the operands. You

cannot enter more than one.

Stacked operands in

square brackets

[ ]

[ ]

Optional operand, you can enter one value, or none.

Operands with

OR-bars ( | ) and

square brackets

[ ]|[ ]

Optional, mutually exclusive operands. Enter one or

none.

Stacked operands in

square brackets

within braces {[ ]}

Mandatory, you must enter one of these operands. You

can enter more than one.


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.


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.

SAF Security

16 Security Guide

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.

SAF Security


Information Flow between CA Workload Automation and SAF

Information flows between CA Workload Automation and the database as

follows:

SAF Security

18 Security Guide

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 Interpretation

0 ■ The security system is operating

■ A security profile exists for the

access requested

■ Access is granted

4 ■ The security system is not

operating or no security profile

exists for the access requested

■ Access is denied

SAF Security


SAF Return Code Interpretation

8 ■ 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:


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.

SAF Security

20 Security Guide

More information:


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.

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 ACID = CESP

CESPF ACID = CESP

CWSS ACID = CESP

Started Task Acid

ACCESSORID = CESP NAME = ESP SCHEDULING SOFTWARE ID

TYPE = CENTRAL SIZE = 1024 BYTES

FACILITY = ESP

PROFILES = XXXXFC04 XXXXTSD1 XXXXVL06 XXXXVL07

PROFILES = XXXXLO01 XXXXLO02 XXXXFC01 ESPRES1

BYPASSING = NODSNCHK,NOVOLCHK,NOSUBCHK,NOSUSPEND

----------- ADMINISTRATION AUTHORITIES

RESOURCE = REPORT

ACID = REPORT

LIST DATA = *ALL*,PROFILES,PASSWORD,SESSKEY

SAF Security

22 Security Guide

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' OWNER(XXX1234)

ACCESS = UPDATE

XA DATASET = 'DSN.CESP.APPL.PROCLIB.BACKUP' OWNER(XXX1234)

ACCESS = UPDATE

XA DATASET = 'DSN.CESP.APPL.PROCLIB.RUNTIME' OWNER(XXX1234)

ACCESS = UPDATE

XA DATASET = 'DSN.CESP.DOCLIB' OWNER(XXX1234)

ACCESS = UPDATE

XA DATASET = 'DSN.CESP.JCLLIB' OWNER(XXX1234)

ACCESS = UPDATE

XA DATASET = 'DSN.CESP.OVERRIDE.JCLLIB' OWNER(XXX1234)

ACCESS = UPDATE

XA DATASET = DSN.CESP.REPORT.PROCESS. OWNER(XXX1234)

ACCESS = UPDATE

XA DATASET = 'DSN.CESP.STAGE.JCLLIB' OWNER(XXX1234)

ACCESS = UPDATE

XA IBMFAC = ESP. OWNER(XXX1234)

ACCESS = ALL

XA IBMFAC = ESP.DSALLOC OWNER(XXX1234)

ACCESS = NONE

XA IBMFAC = ESP.DSALLOC.ESPJCLIB OWNER(XXX1234)

ACCESS = ALL

XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.GLOBALS OWNER(XXX1234)

ACCESS = ALL

XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.PROCLIB OWNER(XXX1234)

ACCESS = ALL

XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.PROCLIB.BACKUP OWNER(XXX1234)

ACCESS = ALL

XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.PROCLIB.RUNTIME OWNER(XXX1234)

ACCESS = ALL

XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.STAGE OWNER(XXX1234)

ACCESS = ALL

XA IBMFAC = ESP.DSALLOC.DSN.CESP.DOCLIB OWNER(XXX1234)

ACCESS = ALL

XA IBMFAC = ESP.DSALLOC.DSN.CESP.REPORT.PROCESS OWNER(XXX1234)

ACCESS = ALL

XA IBMFAC = ESP.DSALLOC.DSN.CESP.STAGE.JCLLIB OWNER(XXX1234)

ACCESS = ALL

XA IBMFAC = ESP.DSALLOC.SYSV.CESP OWNER(XXX1234)

ACCESS = ALL

XA IBMFAC = ESP.DSALLOC.SYSV.CYMATION OWNER(XXX1234)

ACCESS = ALL

SAF Security


XA IBMFAC = ESP.DSALLOC.SYS3.CESP OWNER(XXX1234)

ACCESS = ALL

XA IBMFAC = ESP.DSALLOC.SYS3.CYMATION OWNER(XXX1234)

ACCESS = ALL

XA IBMFAC = ESP.MVSCMD OWNER(XXX1234)

ACCESS = NONE

XA IBMFAC = ESP.MVSCMD OWNER(XXX1234)

ACCESS = NONE

XA IBMFAC = ESP.MVSCMD.$CJ OWNER(XXX1234)

ACCESS = READ

ACIDS = CESP

SAF Security

24 Security Guide

Production Coordinators Profile

ACCESSORID = ESPCOORD NAME = ESP SCHED-PROD COORD

TYPE = PROFILE SIZE = 1024 BYTES

FACILITY = ESP

XA DATASET = DSN.CESP.* OWNER(XXX1234)

ACCESS = UPDATE,CREATE

XA IBMFAC = ESP.DSALLOC.ESPJCLIB OWNER(XXX1234)

ACCESS = READ

XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.GLOBALS OWNER(XXX1234)

ACCESS = READ

XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.PROCLIB OWNER(XXX1234)

ACCESS = READ

XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.PROCLIB.OVERRIDE OWNER(XXX1234)

ACCESS = READ

XA IBMFAC = ESP.DSALLOC.DSN.CESP.APPL.STAGE OWNER(XXX1234)

ACCESS = READ

XA IBMFAC = ESP.DSALLOC.DSN.CESP.DOCLIB OWNER(XXX1234)

ACCESS = READ

XA IBMFAC = ESP.DSALLOC.DSN.CESP.REPORT.PROCESS OWNER(XXX1234)

ACCESS = READ

XA IBMFAC = ESP.DSALLOC.DSN.CMESP.STAGE.JCLLIB OWNER(XXX1234)

ACCESS = READ

XA IBMFAC = ESP.DSALLOC.SYSV.CMESP.DSN OWNER(XXX1234)

ACCESS = READ

XA IBMFAC = ESP.DSALLOC.SYSV.CMESP.TEST OWNER(XXX1234)

ACCESS = READ

XA IBMFAC = ESP.GROUP.CMESP OWNER(XXX1234)

ACCESS = UPDATE

XA IBMFAC = ESP.JOB OWNER(XXX1234)

ACCESS = READ

XA IBMFAC = ESP.ONLINE OWNER(XXX1234)

ACCESS = READ

XA IBMFAC = ESP.OPERCMD.ALERTDEF OWNER(XXX1234)

ACCESS = READ

XA IBMFAC = ESP.OPERCMD.DAB OWNER(XXX1234)

ACCESS = READ

XA IBMFAC = ESP.OPERCMD.ENQUEUE OWNER(XXX1234)

ACCESS = READ

XA IBMFAC = ESP.OPERCMD.LAX OWNER(XXX1234)

ACCESS = READ

XA IBMFAC = ESP.RESOURCE OWNER(XXX1234)

ACCESS = ALL

XA IBMFAC = ESP.REXXON OWNER(XXX1234)

ACCESS = READ


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.


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:


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)

Getting Started

26 Security Guide

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:


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.

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 Triggering user ID from

Manually triggered User that triggered the Event

Implicit data set trigger JCL job name or started task that

updated the data set

FTP data set trigger User associated with the local FTP

partner

Explicit data set trigger User or started task that submitted the

ESPDST utility or issued the

Getting Started

28 Security Guide

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.

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)

Getting Started

30 Security Guide

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.


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:


GROUPX.event_groupname (see page 82)

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.



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.

Additional Event and Application Security

32 Security Guide


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



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.



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.


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.


34 Security Guide

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.



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.


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


is on the APPL statement in the PAYROLL application. Finally, grant Frank

UPDATE access to profile ESP.APPL.PAYROLL.JOB01.



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.


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


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)


36 Security Guide

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)



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.


38 Security Guide

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.


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)



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.


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.

Distributed Workload Security

40 Security Guide

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.


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.



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:


Additional Event and Application Security (see page 32)


42 Security Guide

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.


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.



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.


44 Security Guide

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.



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)


46 Security Guide

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

method

ALL/NOALL operand

setting

ENCRYPT/NOENCRYPT

operand setting

Encrypt with the key

from the ENCRYPT

initialization

parameter.

ALL

NOALL

ENCRYPT or none

ENCRYPT

Encrypt with the key

from the AGENT

initialization

parameter.

ALL or NOALL ENCRYPT (key)

Do not encrypt. ALL

NOALL

NOENCRYPT

NOENCRYPT or none



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


UNIX ASCII TCPIP ENCRYPT


UNIX ASCII TCPIP ENCRYPT(X'1111222233334444')


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')





ENCRYPT KEY(X'0807060504030201')






UNIX ASCII TCPIP


48 Security Guide


X'0102030405060708' (the key from the first ENCRYPT initialization

parameter).


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.



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.


50 Security Guide

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.



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 Description

command 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 Identifies the user ID on CA Workload

Automation that the rule applies to

serveruserID Identifies the user ID on the server

that the central_manageruserID is

allowed to submit jobs under

path Identifies the path the

central_manageruserID is allowed to

submit jobs from using the

serveruserID.

userid Identifies the user ID issuing a

message to an Agent

verb Identifies the verb issued (the action

to be taken).

For example, CONTROL

subverb Identifies the subverb of the verb

issued.

For example, SHUTDOWN, CANCEL


52 Security Guide

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 Description

Asterisk (*) Represents 0 or more character

matches at the current level only

Plus sign (+) 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.

A generic rule is a rule that contains

wildcards.

Path /u1/jsmith

overrides

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*



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.

If there is still ambiguity after these

rules have been applied, a deny rule

will override an allow rule.

Rule c d root * *

overrides

rule c a root * *

Security File Created at Installation

The security.txt file created during installation contains the following rules:

c a * * *

x 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 a * * +

x d * root +

c a * * *

Note: Both resource class x and resource class c must be specified, even if there

is no change to one or the other class.


54 Security Guide

Examples of Local Agent Security File Rules

Line Security File Example #1

1 # Example 1

2 * These rules were last updated on August01, 2002

3 x a * * +

4 x d * gem* +

5 x a manager1 root /prod/employee+

6 x d manager1 root /prod/employee*

7 x a manager2 root /prod/+

8 x d manager2 root /prod/expense

9 x a manager3 root /prod/*

10 x d manager3 root /prod/+

11 c a * CONTROL *

An explanation of Example 1 follows:

Line Explanation

1 Comment line

2 Comment line

3 Allows all central_manageruserIDs to submit jobs using any

serveruserID, from all directories

4 Prohibits all central_manageruserIDs from submitting jobs as gem

or any serveruserIDs that begin with gem, from all directories



Line Explanation

5 Allows manager1 to submit the following

jobs as root:

Job Example

A job called employee from

directory /prod/

/prod/employee

All jobs beginning with

employee from directory /prod/

/prod/employee_pay

/prod/employee_vacation

All jobs from the subdirectory

/prod/employee/ and its

subdirectories

/prod/employee/fulltime_pay

/prod/employee/sales/fulltime_p

ay

All jobs from all subdirectories

under

/prod/, where the first

subdirectory name under prod

begins with employee

/prod/employee1999/fulltime-pa

y

/prod/employee1999/sales/fullti

me_pay

6 Denies manager1 the ability to submit any jobs called employee, or

any jobs that begin with employee, as root in directory /prod/

7 Allows manager2 to submit all jobs as root from directory /prod/ or

all subdirectories of /prod/

8 Denies manager2 the ability to submit the job called expense as root

from directory /prod/

9 Allows manager3 to submit all jobs as root in directory /prod/

10 Denies manager3 the ability to submit any jobs as root from

directory /prod/ or all subdirectories of /prod/

11 Allows all central_manageruserIDs to issue the CONTROL command

with all subverbs


56 Security Guide

Line Example

1 # Example 2

2 * Last updated on September 28, 2002.

3 x a rob* root /prod/+

4 x a pat* root* /prod/*

5 x a jsmith * /prod/+

6 c a MFUSER1 CONTROL *

7 c a MFUSER2 CONTROL MGRADDR

An explanation of Example 2 follows:

Line Explanation

1 Comment line

2 Comment line

3 Allows any central_manageruserID (beginning with rob) to submit

jobs as root from the directory /prod/ or all subdirectories of /prod/

4 Allows any central_manageruserID (beginning with pat) to submit

jobs as root, or as any server user ID beginning with root, in directory

/prod/

5 Allows jsmith to submit jobs using any server user ID from directory

/prod/ or all subdirectories of /prod/

6 Allows MFUSER1 to issue the CONTROL command with all subverbs to

this Agent

7 Allows MFUSER2 to issue the CONTROL Mgraddr command to this

Agent

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

Command Security

58 Security Guide

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.


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.


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

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)

Command Security

60 Security Guide

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.


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.


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.

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.

Command Security

62 Security Guide

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.


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)

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.


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.


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


64 Security Guide

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.



Bob wants to modify the attributes for the SCRATCH resource. He requires

UPDATE access to CA Workload Automation profile ESP.RESOURCE.SCRATCH.


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.

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.



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.


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.


Brenda wants to create a symbolic variable library called DATSYM to store date

variables. Brenda needs ALTER access to profile ESP.SYMLIB.DATSYM.

Security for Procedure Statements

66 Security Guide

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.


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.


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.


Brenda wants to create a global variable table called DATSYM to store date

variables. Brenda needs ALTER access to profile ESP.VARTABLE.DATSYM.


This section shows you how to control the use of statements in procedures:

■ Access to use the EXPEDITE statement

■ Access to invoke REXX



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.

Job-Tracking Security

68 Security Guide


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.


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:




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.



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.



Frank wants to post JOB01 from a pnode called DISTRIB. Frank needs READ

access to profile ESP.PNODE.DISTRIB.


Bob wants to create a new pnode called BURST. Bob needs ALTER access to

profile ESP.PNODE.BURST.


70 Security Guide

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.


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)


Brenda wants to use the DEFTJ command to define job-tracking parameters for

JOB01. She needs ALTER access to ESP.TJD.JOB01.


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.


About Security Profiles for CA Workload Automation (see page 71)

Summary of CA Workload Automation Security Profiles (see page 72)


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 .

Summary of CA Workload Automation Security Profiles

72 Security Guide

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.


A table of CA Workload Automation Security Profiles follows:

Profile Controls

AGENT.agentname A user's ability to submit jobs to an

Agent

AGENTMSG.verbsubverb.agentname A user's ability to issue commands and

send messages to Agents

AGENTUSR.userid.agentname A user's ability to submit jobs to an

Agent under a specified user ID

APPL.applname Access to an application and all jobs

generated by the application

APPL.applname.jobname Access to an application and a specific

job within the application

APPLX.applname.jobname Execute access to a specific job in an

application

CALENDAR.calendarname Access to a calendar

CSF.CHECK.CMDS CSF line command checking with the

CSF.LC.cmd profile

CSF.LC.cmd Access to specific CSF line commands

DSALLOC.dsname The data sets that can be invoked from

within an Event

EVENTINITCLASS.nnn A user's ability to define an Event with

a particular Event initiator class

EXPEDITE.policyname A user's ability to trigger an Event with

an application containing an EXPEDITE

statement

GROUP.event_groupname Access to an Event group and to

applications generated from those

Events



Profile Controls

GROUPX.event_groupname Execution access to an Event group

and to applications generated from

those Events

JOB.racid.jobname Access to job-tracking information

MODEL.modelname Access to job-tracking models

MVSCMD.mvs_cmd.options... A user's ability to issue a specific

z/OS command and its options from an

Event

ONLINE Access to the CA Workload Automation

ISPF interface, CA Workload

Automation Web Interface, and the CA

Workload Automation Workstation

interface

OPER 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

OPERCMD.cmdname A user's ability to issue a specific OPER

command

PASSWORD.userID.agentname Access to passwords and encryption

keys for using Agents

PNODE.pnodename A user's ability to post a job from a

pnode and define a pnode

RACID.userid A user's ability to specify the

USER(userid) operand in an Event

definition

RESABSORB A user's ability to use the ABSORB

statement

RESOURCE.resname A user's ability to issue the RESDEF

command

REXXON A user's ability to invoke REXX within a

procedure

SETOWNER.userid A user's ability to specify the

OWNER(userid) operand in an Event

definition

SYMLIB.symname Access to a symbolic-variable library

TJD.jobname Access to job-tracking commands for

the specified job

CA Workload Automation Security Profiles

74 Security Guide

Profile Controls

UTIL.cmd Access to a specific UTIL mode

command

UTIL.UTIL Access to utility mode, and the END

and ENDREC commands

VARTABLE.tablename Access to a global variable table


This section describes the security profiles.

AGENT.agentname

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

Access Description

READ Allows the user to submit jobs to an Agent.

Example

ESP.AGENT.HP_51

AGENTMSG.verbsubverb.agentname

AGENTMSG.verbsubverb.agentname controls the user's ability to issue

commands and send messages to Agents using the AGENTMSG command.

Access Description

READ Allows the user to issue the AGENTMSG command

Example

ESP.AGENTMSG.CONTROL SHUTDOWN.HP_51



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 Description

READ 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 Description

READ Allows the user to view the application applname and

all jobs generated from applname.

UPDATE 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:



76 Security Guide

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 Description

READ Allows the user to view the job jobname in application

applname

UPDATE 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:





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 Description

READ 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:




78 Security Guide

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 Description

UPDATE 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

ALTER Allows the user to create and delete a calendar, as well

as update the attributes of the calendar, such as the

default workdays

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 Description

READ Enables CSF line command checking with the

CSF.LC.cmd profile



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 Description

READ 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 Description

READ Allows the user to include the data set specified by


80 Security Guide

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 Description

READ 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 Description

READ Allows a user to trigger an Event with an application

containing an EXPEDITE statement for Expedite policy

policyname

Example

ESP.EXPEDITE.FAST_BAT



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 Description

READ 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


82 Security Guide

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

GROUPX Profile

Access

Create an Event Trigger an Event

UPDATE NONE Y Y

READ NONE N N

READ READ 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 Description

READ 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



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 Description

READ Allows a user to view job-tracking information

Example

ESP.JOB.PROD.JOB01

More information:


MODEL.modelname

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

Access Description

ALTER Allows the user to create, replace and delete models,

and gives the user administrator control of the profile

Example

ESP.MODEL.JOB01TK


84 Security Guide

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 Security Profile

D U, TAPE, ONLINE MVSCMD.D.U.TAPE.ONLINE

S LWTRL.L , , , L MVSCMD.S.LWTRL.L.*.*.L

F CATALOG, OPEN(DUMP01) MVSCMD.F.CATALOG.OPEN(DUMP0

1)

The access options are as follows:

Access Description

READ 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



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 Description

READ 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 Description

READ Allows the user to issue any OPER command or any

z/OS command

More information:

Access to Use the RESDEF Command (see page 64)


86 Security Guide

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 Description

READ 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 Description

UPDATE Allows userID to modify or delete the password to

access agentname without specifying the current

password



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 Description

READ Allows the user to post a job from a CA Workload

Automation pnode

ALTER 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 Description

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

Example

ESP.RACID.XR2105 to allow statement USER(XR2105)

More information:



88 Security Guide

RESABSORB

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

application.

Access Description

READ 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 Description

UPDATE Allows the user to set and display CA Workload

Automation job scheduling resources with the RESDEF

command

ALTER Gives the user create and delete authorities on job

scheduling resources with the RESDEF command

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 Description

READ Allows the user to invoke REXX from within a CA

Workload Automation procedure



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 Description

READ Allows an owner to be specified for an Event

Example

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 Description

READ Allows the user to display a CA Workload Automation

SYMLIB

UPDATE Allows the user to create and delete SYMLIB variables

and change their values

ALTER Allows the user to create and delete SYMLIBs

Example

ESP.SYMLIB.GENSYM for the GENSYM symbolic variable library


90 Security Guide

TJD.jobname

TJD.jobname controls access to CA Workload Automation job-tracking

commands (ALTTJ, DEFTJ, and DELTJ) for the job specified by jobname.

Access Description

UPDATE Allows the user to use the ALTTJ command to change

job-tracking definitions

ALTER 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 Description

READ 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 Description

READ Allows the user to access CA Workload Automation

utility mode and issue commands END and ENDREC



VARTABLE.tablename

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

tablename.

Access Description

READ Allows a user to list a table with the VTLIST command

and to retrieve a variable with the VGET command

UPDATE 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

Glossary 93

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).

94 Security Guide

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.

Glossary 95

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.

96 Security Guide

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.

Glossary 97

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


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

■ Shadow manager (see page 101).

■ IBM Automatic Restart Management (ARM) function support.

■ XCF status monitoring (see page 103).

■ Universal login (see page 102).

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:

Condition Format

JES2 not running in z2 mode (with large

job numbers disabled)

JOBnnnnn

JES2 running in z2 mode (with large job

numbers enabled)

Jnnnnnnn

JES3 For job numbers less than 100000:

JOBnnnnn

98 Security Guide

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.

Glossary 99

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.

100 Security Guide

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

Glossary 101

■ 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).

Shadow manager

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


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.

102 Security Guide

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 object—Serves 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 variable—A 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.

Glossary 103

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.

Index 105

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

106 Security Guide

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

Index 107

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 job user ID • 26

indentation, statements • 11

initial run

definition • 97

initialization parameter

definition • 97

initiator class, Event, access to specify • 38

108 Security Guide

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

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

K

key, determining the encryption, for an Agent •

46

keys, access to encryption, for using Agents • 43

L

link

definition • 98

local

Agent security • 50

security file, comment lines • 52

security file, rule starting point and spacing •

52

security file, wildcards in • 52

security-file entries syntax • 51

long name

definition • 98

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

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

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

Index 109

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

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

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

110 Security Guide

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

T

tag

definition • 101

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

Index 111

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

Documents

CA Workload Automation Administrators Guide