CA 7 Workload Automation - CA Technologies Global Search ... · PDF fileThis documentation and...

CA 7™ Workload Automation

Security Reference Guide r11.1

This documentation and any related computer software help programs (hereinafter referred to as the“Documentation”) is for the end user's informational purposes only and is subject to change orwithdrawal by CA at any time.

This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, inwhole or in part, without the prior written consent of CA. This Documentation is confidential andproprietary information of CA and protected by the copyright laws of the United States and internationaltreaties.

Notwithstanding the foregoing, licensed users may print a reasonable number of copies of thedocumentation for their own internal use, and may make one copy of the related software as reasonablyrequired for back-up and disaster recovery purposes, provided that all CA copyright notices and legendsare affixed to each reproduced copy. Only authorized employees, consultants, or agents of the userwho are bound by the provisions of the license for the product are permitted to have access to suchcopies.

The right to print copies of the documentation and to make a copy of the related software is limited tothe period during which the applicable license for the Product remains in full force and effect. Shouldthe license terminate for any reason, it shall be the user's responsibility to certify in writing to CA that allcopies and partial copies of the Documentation have been returned to CA or destroyed.

EXCEPT AS OTHERWISE STATED IN THE APPLICABLE LICENSE AGREEMENT, TO THE EXTENTPERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION “AS IS” WITHOUTWARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT. IN NOEVENT WILL CA BE LIABLE TO THE END USER OR ANY THIRD PARTY FOR ANY LOSS ORDAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDINGWITHOUT LIMITATION, LOST PROFITS, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA,EVEN IF CA IS EXPRESSLY ADVISED OF SUCH LOSS OR DAMAGE.

The use of any product referenced in the Documentation is governed by the end user's applicablelicense agreement.

The manufacturer of this Documentation is CA.

Provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government issubject to the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) andDFARS Section 252.227-7014(b)(3), as applicable, or their successors.

All trademarks, trade names, service marks, and logos referenced herein belong to their respectivecompanies.

Copyright © 2007 CA. All rights reserved.

CA Product References

This document references the following CA products:

■ CA 7™ Workload Automation (CA 7)

■ CA 11™ Workload Automation Restart and Tracking (CA 11)

■ CA 1® Tape Management (CA 1)

■ CA ACF2™ (CA ACF2)

■ CA APCDDS™ Automated Report Balancing (CA APCDDS)

■ CA ASM2® Backup and Restore (CA ASM2)

■ CA AutoSys® Workload Automation (CA AutoSys)

■ CA Earl™ (CA Earl)

■ CA Easytrieve® Report Generator (CA Easytrieve)

■ CA JCLCheck™ Utility (CA JCLCheck)

■ CA Jobtrac™ Job Management (CA Jobtrac)

■ CA Librarian® (CA Librarian)

■ CA Netman™ (CA Netman)

■ CA Opera™ (CA Opera)

■ CA Panvalet® (CA Panvalet)

■ CA Scheduler® Job Management (CA Scheduler)

■ CA Top Secret® (CA Top Secret)

■ CA Roscoe® Interactive Environment (CA Roscoe)

■ Unicenter® Network and Systems Management (CA Unicenter NSM)

■ Unicenter® NSM Job Management Option (Unicenter NSM JM Option)

■ CA Unicenter® Service Desk (CA Unicenter Service Desk)

■ Unicenter® Universal Job Management Agent (Unicenter Universal JobManagement Agent)

■ Unicenter® Workload Control Center (Unicenter WCC)

■ CA 7™ Job Management Smart Console Option (CA 7 Smart ConsoleOption)

Contact Technical Support

For online technical assistance and a complete list of locations, primary servicehours, and telephone numbers, contact Technical Support athttp://ca.com/support.

3

4 Security Reference Guide

Contents

Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Chapter 2. Implementation Considerations . . . . . . . . . . . . . . . . . 11System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Identify Your Security Requirements . . . . . . . . . . . . . . . . . . . . . . . 13Security Structure Using External Security . . . . . . . . . . . . . . . . . . . 14

Logon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Data Set Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Command Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Panel Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Job Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15External Communicators . . . . . . . . . . . . . . . . . . . . . . . . . . . 16USERID Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16UID Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Multi-CPU Security Environments . . . . . . . . . . . . . . . . . . . . . . 17CA 7 Submit Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Security Structure Using Internal Security . . . . . . . . . . . . . . . . . . . . 18Security Considerations for ARF . . . . . . . . . . . . . . . . . . . . . . . . . 19Security Considerations for Cross-Platform Scheduling . . . . . . . . . . . . 20

CA 7 As Cross-Platform Client (XPJOB Definitions) . . . . . . . . . . . 20CA 7 As Cross-Platform Client (CA7TOUNI Batch Program) . . . . . . 21CA 7 As Cross-Platform Server . . . . . . . . . . . . . . . . . . . . . . . 23

Security Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Chapter 3. Security Initialization Options . . . . . . . . . . . . . . . . . . 25SECURITY Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26/DISPLAY,ST= . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Chapter 4. Implementing Security with CA Top Secret . . . . . . . . . . 41Define CA 7 to CA Top Secret . . . . . . . . . . . . . . . . . . . . . . . . . . 42Define the CA 7 Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Define the CA 7 ACID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Define ICOM to CA Top Secret . . . . . . . . . . . . . . . . . . . . . . . . . . 46Control User Access to CA 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Define CA 7 Command Security . . . . . . . . . . . . . . . . . . . . . . . . . 49Secure the /MVS Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Calendar Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Control Job Submission Under CA 7 . . . . . . . . . . . . . . . . . . . . . . 53Program Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Batch Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Job Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Satisfy the R-NOUID Requirement . . . . . . . . . . . . . . . . . . . . . 57USERID Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57JCL USERID Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

UID Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Contents 5

CA7RTBL Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Usage Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61UID Resource Table - SASSRTBL Source . . . . . . . . . . . . . . . . 61

CA 7 Logon and UID Resource Validation . . . . . . . . . . . . . . . . . 62/UID Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64/REFRESH Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65External Communicators with CA Top Secret . . . . . . . . . . . . . . . . . 66

Terminal Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 67SASSTRLR and External Security . . . . . . . . . . . . . . . . . . . . . . 68SASSBSTR and CAL2X2W0 and External Security . . . . . . . . . . . 69U7SVC and External Security . . . . . . . . . . . . . . . . . . . . . . . . 70

U7SVC with D= PARM . . . . . . . . . . . . . . . . . . . . . . . . . . . 70U7SVC with an Input Stream . . . . . . . . . . . . . . . . . . . . . . . . 71

Data Set Posting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Sample Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Chapter 5. Implementing Security with CA ACF2 . . . . . . . . . . . . . 75Define CA 7 to CA ACF2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Define CA 7 As a Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Define CA 7 Command Security . . . . . . . . . . . . . . . . . . . . . . . . . 80

Resource Rule Masking . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Secure the /MVS Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Define ICOM to CA ACF2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Define SUBMIT Resource Rules . . . . . . . . . . . . . . . . . . . . . . . . . 85Calendar Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Job Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Satisfy the R-NOUID Requirement . . . . . . . . . . . . . . . . . . . . . 89USERID Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90JCL USERID Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

UID Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91CA7RTBL Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Usage Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93UID Resource Table - SASSRTBL Source . . . . . . . . . . . . . . . . 93

CA 7 Logon and UID Resource Validation . . . . . . . . . . . . . . . . . 94/UID Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96/REFRESH Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Program Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98CA 7 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Batch Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

External Communicators with CA ACF2 . . . . . . . . . . . . . . . . . . . . . 99Terminal Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 100SASSTRLR and External Security . . . . . . . . . . . . . . . . . . . . . 101SASSBSTR and CAL2X2W0 and External Security . . . . . . . . . . 102U7SVC and External Security . . . . . . . . . . . . . . . . . . . . . . . 103

U7SVC with D= PARM . . . . . . . . . . . . . . . . . . . . . . . . . . 103U7SVC with an Input Stream . . . . . . . . . . . . . . . . . . . . . . . 104

Data Set Posting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Sample Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106


Chapter 6. Implementing Security with IBM RACF . . . . . . . . . . . 107Define Security to RACF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108RACF Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Resource Class Descriptor Table - ICHRRCDE . . . . . . . . . . . . . 109

ICHERCDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110RACF Router Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Activate the New Resource Classes . . . . . . . . . . . . . . . . . . . 111Started Procedures Table - ICHRIN03 . . . . . . . . . . . . . . . . . . 112

Define the CA 7 Started Task to RACF . . . . . . . . . . . . . . . . . . . . 113Define CA 7 ICOM to RACF . . . . . . . . . . . . . . . . . . . . . . . . . . 114CA 7 and CA 7 ICOM Data Set Access Requirements . . . . . . . . . . . 115Define the CA 7 Application Resource Profile . . . . . . . . . . . . . . . . 116Define CA 7 Command and Panel Security to RACF . . . . . . . . . . . . 118Secure the /MVS Command . . . . . . . . . . . . . . . . . . . . . . . . . . 120Control Job Submission Under RACF . . . . . . . . . . . . . . . . . . . . . 121Surrogate Usage for Job Submission Under RACF . . . . . . . . . . . . . 123Job Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

RACF USERID Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Satisfy the R-NOUID Requirement . . . . . . . . . . . . . . . . . . . . 125USERID Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

UID Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127CA7RTBL Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Usage Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129UID Resource Table - SASSRTBL Source . . . . . . . . . . . . . . . 129

CA 7 Logon and UID Resource Validation . . . . . . . . . . . . . . . . 130/UID Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132/REFRESH Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Program Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

CA 7 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Batch Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Group Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135External Communicators with IBM-RACF . . . . . . . . . . . . . . . . . . . 136

Terminal Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 137SASSTRLR and External Security . . . . . . . . . . . . . . . . . . . . . 138SASSBSTR and CAL2X2W0 and External Security . . . . . . . . . . 139U7SVC and External Security . . . . . . . . . . . . . . . . . . . . . . . 141

U7SVC with D= PARM . . . . . . . . . . . . . . . . . . . . . . . . . . 141U7SVC with an Input Stream . . . . . . . . . . . . . . . . . . . . . . . 141

Data Set Posting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Sample Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Chapter 7. Internal Security . . . . . . . . . . . . . . . . . . . . . . . . . 145Security Use Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 146Define Security Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Terminal/Operator Security . . . . . . . . . . . . . . . . . . . . . . . . . 147Operator/Application Security . . . . . . . . . . . . . . . . . . . . . . . 147Application/Command Security . . . . . . . . . . . . . . . . . . . . . . . 147Command/Function Panel Security . . . . . . . . . . . . . . . . . . . . 151

Contents 7

UID/External Data Set Security . . . . . . . . . . . . . . . . . . . . . . 153SECURITY Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156USERID Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Chapter 8. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 161Diagnostic Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Problem Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Verifying the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Collecting Diagnostic Data . . . . . . . . . . . . . . . . . . . . . . . . . 163Interpreting Diagnostic Data . . . . . . . . . . . . . . . . . . . . . . . . 164

Accessing the Online Support System . . . . . . . . . . . . . . . . . . . . . 165Requirements for Using SupportConnect . . . . . . . . . . . . . . . . . 165CA-TLC: Total License Care . . . . . . . . . . . . . . . . . . . . . . . . 165

Contact Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Product Releases and Maintenance . . . . . . . . . . . . . . . . . . . . . . 167Requesting Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Appendix A. Security Tables . . . . . . . . . . . . . . . . . . . . . . . . . 169Panel-ID Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Command Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Function and Service Level Table . . . . . . . . . . . . . . . . . . . . . . . 183Access Level Translation Table . . . . . . . . . . . . . . . . . . . . . . . . 185

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187


Chapter 1. Introduction

This guide describes the steps necessary to implement CA 7™ WorkloadAutomation (CA 7) security.

Note: Because this document contains sensitive information, we recommendthat distribution of this guide be limited to those responsible for implementationand maintenance of CA 7 security.

CA 7 security provides a control structure that enables each installation toprotect data and resources being accessed through CA 7. Two options areavailable when implementing CA 7 security:

■ External security interface

■ CA 7 internal security

Use of external security to control access to CA 7 resources allowsmaintenance of security to be centralized. Existing USERID definitions and dataset access rules may be extended for use in the CA 7 environment if theexternal security interface is used.

CA 7 internal or "native" security can be used to control data and resourcesthat are unique to the CA 7 processing environment.

Chapter 1. Introduction 9

Chapter 2. ImplementationConsiderations

This section contains the following topics:

System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Identify Your Security Requirements . . . . . . . . . . . . . . . . . . . . . . . 13Security Structure Using External Security . . . . . . . . . . . . . . . . . . . 14Security Structure Using Internal Security . . . . . . . . . . . . . . . . . . . . 18Security Considerations for ARF . . . . . . . . . . . . . . . . . . . . . . . . . 19Security Considerations for Cross-Platform Scheduling . . . . . . . . . . . . 20Security Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

This chapter identifies implementation considerations including identifying yoursecurity requirements and CA 7 security structure and cross-platformscheduling security considerations.

Chapter 2. Implementation Considerations 11

System Requirements

System Requirements

CA 7 interfaces with your external security product.

The external security interface requires CA Common Services CAIRIM andCAISSF at a currently supported level. (CA Common Services is composed ofthe services formerly known as CA90s and Unicenter TNG Framework.)

Your external security product can be CA ACF2, CA Top Secret, or RACF.Your external security product must be at a currently supported level.


Identify Your Security Requirements

Identify Your Security Requirements

The user can define the security structure and level of authority for eachindividual accessing CA 7. A careful evaluation should be made of yoursecurity requirements prior to implemention of CA 7 security.

When a variable number of people are involved in handling the work flow, somemethod must be used to control who performs specific tasks and anauthorization level must be defined to protect your data and resources.Facilities provided by CA 7 for accessing and maintaining the database, as wellas monitoring and controlling the production process, require performance ofspecialized tasks by different people with varying levels of responsibility.

To ensure integrity of the CA 7 system, provisions have been made to alloweach installation to define a control structure or hierarchy required within theirenvironment. Levels of responsibility are then assigned to specific individualsdepending on that individuals activities within the hierarchy.

When defining the control structure, the following considerations should bemade:

1. Which security options will be used?

2. Who can access and use CA 7?

3. Do individual users need access to only certain commands or applicationsunder CA 7?

4. On formatted panels, should users be restricted from certain functions (Add,Update, Delete)?

5. Will USERIDs exist in the JCL for a job or will the USERIDs be inserted byCA 7 or a user exit?

6. Can users issue commands or submit jobs that contain a USERID otherthan their own?


Security Structure Using External Security


The CA 7 External Security Interface provides key functional control points thatare used to determine access authority for users of CA 7. The control pointsare as follows:

■ Logon

■ Data Set

■ Command Authority

■ Panel Access

■ Job Submission

■ External Communicators

■ USERID Protection

■ Multi-CPU Security Environments

■ CA 7 Submit Data Sets

When access to a given resource is attempted, a security check is performed todetermine the authority of the user initiating the request. The user's authority toaccess the data or resource is determined by the security definitions in place atthe time of the access. For a description of the control points, see the followingtopics.

Logon

Logon security provides a means to control access to CA 7 and its facilities.Each user requesting access to CA 7 requires validation by the externalsecurity system. Assuming that the logon information is valid, the user is signedon to CA 7. One additional step in the logon validation process can beimplemented. By defining CA 7 to the external security package as a resource,an additional check is made, after the user is validated, to determine the user'sauthorization to access the CA 7 resource. There are some differencesbetween security packages when implementing this secondary check for theLOGON process. For specific details that relate to the security package youhave installed at your site, see the appropriate chapter in this guide.

Note: To use any of the CA 7 External Security Interface control pointsthrough external security, Logon security must be implemented. Logon securityestablishes the security environment for each user of CA 7 and allowscommunication with the external security package.

The use of the MVS console from CA 7 (using the modify command) requires alogon user ID, but no password is required.



Data Set Security

Data set security is used to control access to data sets by users signed on toCA 7. Each attempt to access data through CA 7 will be validated by security.Access authorization to data sets through CA 7 should not differ from theaccess you have defined for users outside of the CA 7 environment. Access isdone under the CA 7 USERID.

Command Authority

Command security provides a means to control access to the wide range ofcommand options available under CA 7. Because CA 7 offers some verypowerful commands, it is very important that the command authority for eachuser of CA 7 be restricted to individual areas of responsibility.

Panel Access

Panel security is provided to control access to the various application menusand panels throughout CA 7. Each panel within CA 7 has a unique panel-IDthat can be used to restrict access based on each user's area of responsibility.Additionally, any functions that appear on the panels can be restricted byspecifying access levels, such as READ and WRITE, for each panel.

Job Submission

External security packages generally require a USERID and password to beassociated with every batch job that executes on the system. Based on specialkeywords, specified in the initialization file, you can set up a hierarchy ofcandidate USERID sources from which CA 7 selects IDs for USERID insertionprior to submission.



External Communicators

The External Communicators (SASSBSTR, SASSTRLR, U7SVC, andSASSBCLP) provide a means for users outside the CA 7 address space tosend terminal transactions or post data set creations to CA 7. For moreinformation about the secure use of the External Communicators, see thechapters of this guide that specifically target implementation considerations foryour security environment (that is, CA ACF2, CA Top Secret, or IBM RACF).

USERID Protection

In the standard security environment, each user is assigned a USERID thatrestricts the users' access to resources related to their areas of responsibilities.To prevent users from using a USERID other than their own, submit checkingcan be implemented to restrict access to USERIDs. Submit checking isperformed for the following conditions:

■ Requests for jobs, such as DEMANDs, LOADs, or RUNs when the job'sJCL contains a USERID.

■ Attempts to add USERIDs to JCL through the CA 7 text editor or queueJCL editor.

■ Attempts to add, update, or delete the OWNER field associated with a jobon the DB.1 or DB.10 panel.

■ Executions of the SASSTRLR or SASSBSTR facilities when a USERID issupplied on a /LOGON card. If the USERID supplied is different than theUSERID identified in the external environment, a submit check is performedto validate the user's authority to submit for the supplied USERID.

For users to use a USERID other than their own, specific authorization must begranted through the external security package.

UID Assignment

The UID assignment for users of CA 7 can now be controlled through externalsecurity using UID Resources. A UID Resource Table (default - SASSRTBL)allows sites to define a resource name to a UID value relationship that can bevalidated through external security during logons to CA 7. This eliminates theneed to maintain the CA 7 internal security module with all USERIDs andprovides the UID level security assignment to be controlled by external security.For more information about implementing UID Resources, see the section onthe appropriate security package.



Multi-CPU Security Environments

CA 7 identifies the external security processing environment during initializationon the host CPU. The format for JCL USERID insertion, during job submission,is dependent on the security package present at startup. CA 7 does notsupport multiple security environments for remote job submission due to theJCL USERID format restrictions imposed by the individual security packages.

CA 7 Submit Data Sets

The CA 7 Submit data sets are used in nonshared spool, shared DASD,multi-CPU MVS systems. The JCL is written to the Submit data set by CA 7and then read by CA 7 ICOM for submission on the appropriate system. WithUSERID insertion during job submission, the JCL USERID format is determinedbased on the external security environment CA 7 identified during initialization.Due to JCL USERID format restrictions related to each external securitypackage, CA 7 does not support multiple security environments for USERIDinsertion.

Note: For SAF compatible systems, such as RACF, CA 7 ICOM does notsupport the use of Submit data sets and USERID propagation.


Security Structure Using Internal Security

Security Structure Using Internal Security

Five distinct levels of security may be defined using CA 7 internal security:

■ Terminal/Operator

■ Operator/CA 7 Application

■ CA 7 Application/Command

■ Command/Function

■ UID/External Data Set

For additional information, see Chapter 7, “Internal Security” on page 145.


Security Considerations for ARF

Security Considerations for ARF

ARF for CA 7 allows automation of customized recovery procedures forproduction jobs. The recovery procedures for an ARF condition may include:sending a message to a specified TSO user or to the MVS console, executingCA 7 commands or scheduling and tracking special recovery (ARFJ) jobs. Formore information, see the chapter about ARF in the Database MaintenanceGuide.

In the definition of an ARF condition, you may code up to seven recovery actionstatements. When an ARF condition is detected, CA 7 scans the ARF definitionto determine the recovery actions to process.

Each recovery action statement (except AW statements) may cause one ormore CA 7 terminal commands to be executed. Although the format of thecommand must follow conventions used for batch terminal or SASSTRLR input,neither of these terminal types is used for ARF responses. Instead, ARFrequires that one or more terminals be defined in the initialization file asDEVICE=TRXDV. These TRX terminals are similar to the trailer terminal(DEVICE=TRLDV), except they are dedicated for use by functions internal toCA 7 such as ARF.

Because ARF recovery actions are processed as CA 7 terminal commands, avalid logon is required for each ARF recovery transaction. The ID for this logonis supplied on the AR.3 panel in the RESPONSE-ID field. This ID must havethe authority for all transactions that are executed in response to the ARFcondition with which they are associated. If several TRX terminals are coded inthe initialization file then the ID must be valid for ALL of these terminalsbecause ARF transactions may be scheduled on any of these terminals.

If the RESPONSE-ID does not have the authority to execute the responses inits ARFSET then ARF recovery will not be handled properly.


Security Considerations for Cross-Platform Scheduling


CA 7 can send and receive job requests to and from other CA schedulingsystems on a variety of platforms. Cross-platform scheduling with CA 7 isdocumented in the Interface Reference Guide. This section reviews the securityconsiderations of cross-platform scheduling and directs you to relevantdocumentation in this and other CA 7 guides.

Beginning with r11.1, CA 7 supports two forms of cross-platform scheduling.Jobs defined using the XPJOB command can be submitted to a CA schedulingsystem or agent directly. Jobs can also be submitted using the CA7TOUNIbatch program. The security considerations for each are completely different.

Note: For more information about each mode of submission, see the InterfaceReference Guide.

CA 7 As Cross-Platform Client (XPJOB Definitions)

Using XPJOB definitions, sites can take advantage of the hierarchical securitydesigned especially for these jobs. Four supported security modes are definedon the XPDEF file initialization statement PSWDLOC keyword. They are asfollows:

DATABASECreates an owner security record in the database using the XPSWD command.User ID, password, and domain information can be associated to the owner.Any XPJOB definition containing the same owner will use the information in thisrecord when building the request to be transmitted to the remote platform.Password information provided using the XPSWD command is encrypted andnon-displayable.

OWNERUses the OWNER field in the XPJOB definition as the user ID that is passed tothe remote node. No password or domain information is provided.

NODECreates a node security record in the database using the XPSWD command.User ID, password, and domain information can be associated to the node. AnyXPJOB definition containing the same node will use the information in thisrecord when building the request to be transmitted to the remote platform.Password information provided using the XPSWD command is encrypted andnon-displayable.

USERSupplies SUBUSER and SUBPASS information in an external file associated tothe XPJOB definition. You can use the standard facilities of your MVS securitysystem to secure this external file for READ and WRITE access.



The DATABASE and NODE modes are the most secure. In addition, theyprovide an alternative to supplying a user ID and password to each jobdefinition. With these two modes, all XPJOBs whose OWNER or NODE matcha DATABASE or NODE security record will use the information in that securityrecord.

Note: For more information about the XPDEF PSWDLOC statement, see theSystems Programmer Guide. For more information about the XPSWDcommand, see the Database Maintenance Guide.

If you want to supply the user ID of ROOT, you must create an XPSWD Owneror Node security record. In addition, the SUBROOT keyword of the XPDEF fileinitialization statement must be set to Y.

XPJOB definitions are defined, scheduled, and/or demanded in the samemanner as any other CA 7 batch job. A user ID is always passed to the targetsystem with password and domain being optional. The source of thisinformation is dependant upon the XPDEF PSWDLOC file initializationstatement definition.

CA 7 As Cross-Platform Client (CA7TOUNI Batch Program)

The primary security considerations for CA7TOUNI cross-platform jobdefinitions relate to the CA 7 SUBMIT function.

1. The MVS USERID under which the CA 7 cross-platform tracking functionruns must have both READ and UPDATE access to the CA 7 XPSPROFILE partitioned data set. It creates and updates a member for eachremote system to which cross-platform requests are sent.

2. All MVS USERIDs under which the CA 7 cross-platform submit functionruns must have READ access to the CA 7 XPS PROFILE partitioned dataset. It reads member CACCENV for global submit parameters. If the SYSINdata for a particular submit job is in a distinct data set, the MVS USERIDunder which the submit job runs must have READ access to the data set.

3. CA 7 cross-platform submit jobs are defined, scheduled, and/or demandedin the same manner as any other CA 7 batch job. The MVS USERID underwhich the batch submit job runs is assigned in the same manner as yourother CA 7 batch jobs.

4. A USERID is always passed to the target system. You can specify theUSERID explicitly by the SUBUSER parameter in PROFILE or SYSIN. If noSUBUSER parameter is specified, the MVS USERID under which the batchjob is running is extracted and used as a default for SUBUSER.



5. A security call may be made to the external security system to determine ifthe MVS USERID under which the batch job is running is authorized tosubmit on behalf of the USERID specified in the SUBUSER parameter. Thisis the same Submit Check that may be done in CA 7 (see the specificchapter for your external security system to define rules for Submitauthorization). If the SUBUSER parameter is more than eight characters,the value used for the Submit Check is the first eight characters ofSUBUSER.

The Submit Check security call is made under the following circumstances:

a. If the MVS USERID under which the batch job is running does notexactly match the SUBUSER USERID,

- and -

b. Either the value of BSUBCHK for this instance is Y or theSUBCHECK=YES parameter is set in the CA 7 XPS PROFILE memberCACCENV. The BSUBCHK value controls CA 7 security checking forprocesses outside of the CA 7 address space (BTI, U7SVC, and soforth). The SUBCHECK= parameter cannot be used to suppress SubmitChecking if the value of the BSUBCHK is Y.

CAIRIM sets the value of BSUBCHK for each instance. For additionalinformation, see the chapter "Execution" in the Systems ProgrammerGuide.

If the return code from the external security system indicates that theMVS USERID does not have authority to submit on behalf of theSUBUSER USERID, the cross-platform request is not sent to the targetsystem and the batch Submit job fails.

6. If the USERID assigned to SUBUSER is the value ROOT, an additionalsecurity check is made. The SUBROOT= parameter in the CA 7 XPSPROFILE member CACCENV must be set to YES to authorize use of theROOT USERID. The USERID 'ROOT' has special meaning on UNIXplatforms and should be tightly controlled. If SUBROOT=YES is notspecified, the cross-platform request is NOT sent to the target system, andthe batch submit job fails.

7. The target system may require that you supply a password with theUSERID specified in SUBUSER. Use the SUBPASS parameter to specify apassword to the target system. The MVS system makes no check tovalidate the password. To prevent unintended mismatches of USERIDs andpasswords, the SUBPASS parameter is only honored if it comes from thesame source as the SUBUSER parameter. That is, both SUBUSER andSUBPASS must be in the SYSIN data, or they must both be in thePROFILE data.



The password value is encrypted before being sent across the network withthe cross-platform request. If you want to use passwords, we recommendyou specify the SUBUSER and SUBPASS parameters in a distinct filepointed to by the SYSIN DD statement. You can use the standard facilitiesof your MVS security system to secure this file for READ and WRITEaccess.

CA 7 As Cross-Platform Server

When CA 7 receives a cross-platform request from a CA scheduling system onanother platform, it acts as a cross-platform server. This process is fullydocumented in the Interface Reference Guide. The primary securityconsiderations relate to the assignment of a CA 7 USERID under which therequested CA 7 job will be initiated.

1. Cross-platform requests sent to CA 7 may or may not have an explicitUSERID sent with it. If an explicit USERID is sent, it may or may not havean associated password sent with it.

If a USERID is sent with a request, you can require that a password also besent based upon the system that sent the request, the USERID, or both thatis specified on the request. See the subsection Cross-Platform ServerPassword Requirements in the Interface Reference Guide fordocumentation about controlling password requirements. If a request doesnot satisfy the password requirements, it is rejected (submit failure) by theCross-Platform Router before it is passed to CA 7 itself.

2. If no USERID is sent with a request, it may be assigned a default CA 7USERID based upon the setting of the XPSSID= keyword on the CA 7SECURITY statement. For further information, see “SECURITY Statement”on page 26.

3. Once a cross-platform request is passed to CA 7, processing takes placebased upon the explicit or defaulted CA 7 USERID. This USERID is 'loggedonto' a CA 7 internal terminal. If a password was passed with an explicitUSERID, it is specified on the logon command. This logon is handled thesame as other logons in your CA 7 system. That is, it is handled usinginternal or external security based upon the global parameters you havespecified on your CA 7 SECURITY statement. If the logon is successful, theCA 7 job specified in the cross-platform request is initiated using aDEMAND or RUN command and is subject to the security restrictionsdefined for the USERID under which the command is being issued.


Security Choice

Security Choice

The implementation and structure of CA 7 security differs based on your choiceof internal or external security. For a discussion of each of the various securityoptions to determine which options meet your installation's securityrequirements, see the appropriate chapter in this guide.


Chapter 3. Security InitializationOptions


SECURITY Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26/DISPLAY,ST= . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Chapter 3. Security Initialization Options 25

SECURITY Statement

SECURITY Statement

The CA 7 initialization file contains control statements that define theprocessing configuration of CA 7 during startup. The SECURITY controlstatement determines the security environment for CA 7 based onuser-selected keywords.


SECURITY Statement

This statement has the following format:

��─ ──SECURITY,NAME=SASSSECI ──┬ ┬───────────────────────── ───────────────� │ │┌ ┐─JOBFROM─

└ ┘──,ACF2CARD= ──┴ ┴─LOGONID─

�─ ──┬ ┬─────────── ──┬ ┬───────────────────── ──┬ ┬──────────────────── ─────�└ ┘──,APPL=CA7 │ │┌ ┐─,─── │ │┌ ┐─YES─

└ ┘──,BYPSEC=( ───� ┴┬ ┬─1─ ) └ ┘──,DISPLAY= ──┴ ┴─NO── ├ ┤─2─ └ ┘─3─

�─ ──┬ ┬────────────────────────── ──┬ ┬──────────────────── ───────────────�└ ┘──,EXTERNAL= ──┬ ┬─CALENDAR─ │ │┌ ┐─NO──

├ ┤─COMMAND── └ ┘──,HIDEGRP= ──┴ ┴─YES─ ├ ┤─DATASET── ├ ┤─LOGON──── ├ ┤─SUBCHECK─ └ ┘─SUBOWNER─

�─ ──┬ ┬─────────────────── ──┬ ┬──────────────────── ──────────────────────� │ │┌ ┐─NO── │ │┌ ┐─NO──

└ ┘──,HIDEPW= ──┴ ┴─YES─ └ ┘──,HIDEUPD= ──┴ ┴─YES─

�─ ──┬ ┬───────────────────── ──┬ ┬─────────────────── ─────────────────────� │ │┌ ┐─NO── │ │┌ ┐─YES─

└ ┘──,HIDEUSER= ──┴ ┴─YES─ └ ┘──,JCLUID= ──┴ ┴─NO──

�─ ──┬ ┬───────────────────── ──┬ ┬──────────────────── ────────────────────� │ │┌ ┐─YES─ │ │┌ ┐─YES─

└ ┘──,LOADSUBC= ──┴ ┴─NO── └ ┘──,LOGOPID= ──┴ ┴─NO──

�─ ──┬ ┬────────────────── ──┬ ┬────────────────── ─────────────────────────�│ │┌ ┐─NO── └ ┘──,PCLASS=xxxxxxxx└ ┘──,MIXPW= ──┴ ┴─YES─

�─ ──┬ ┬────────────────────── ──┬ ┬──────────────────── ───────────────────� │ │┌ ┐─NO── │ │┌ ┐─YES─

└ ┘──,PROPAGATE= ──┴ ┴─YES─ └ ┘──,PSOWNER= ──┴ ┴─NO──

�─ ──┬ ┬────────────────── ──┬ ┬───────────────────── ──────────────────────�└ ┘──,RCLASS=xxxxxxxx │ │┌ ┐─YES─

└ ┘──,RESLOGON= ──┴ ┴─NO──

�─ ──┬ ┬──────────────────── ──┬ ┬──────────────────── ─────────────────────� │ │┌ ┐─YES─ │ │┌ ┐─YES─

└ ┘──,RLOGUID= ──┴ ┴─NO── └ ┘──,STATSID= ──┴ ┴─NO──

�─ ──┬ ┬──────────────────── ──┬ ┬───────────────────── ────────────────────�│ │┌ ┐─NO── └ ┘──,SUBUID= ──┬ ┬─OWNER─└ ┘──,SUBNOID= ──┴ ┴─YES─ ├ ┤─REQ───

├ ┤─QJCL── └ ┘─CA7───

�─ ──┬ ┬─────────────── ──┬ ┬──────────────── ──────────────────────────────�└ ┘──,UID=xxxxxxxx └ ┘──,USER=xxxxxxxx

�─ ──┬ ┬──────────────────────── ────────────────────────────────────────�� │ │┌ ┐─��NONE��─

└ ┘──,XPSSID= ──┴ ┴─xxxxxxxx─


SECURITY Statement

SECURITYIdentifies the CA 7 SECURITY statement that describes the CA 7 securityenvironment.

NAMEIdentifies the load module that contains the CA 7 Security definitions builtusing the SECURITY macro. This parameter is required for both internaland external security. If you are implementing full external security controlfor CA 7, the default security module SASSSECI can be used. This moduleis supplied in the CA 7 Load library. If you are using CA 7 internal security,see Chapter 7, “Internal Security” on page 145 for a discussion on buildingand modifying the CA 7 security module to meet your installation's securityrequirements.

ACF2CARD(Optional) For USERID insertion at CA ACF2 sites, CA 7 will add a controlstatement to the JCL immediately following the JOB statement. This optioncontrols what type of CA ACF2 control statement is used. JOBFROM is thedefault. The only other valid value is LOGONID. For more information, see“JCL USERID Format” on page 90.

APPL(Optional) Identifies the CA 7 Security Application ID. The application ID, ifspecified, is used as an additional check during Logons. A resource checkis performed, using the Security Application ID as the resource name, tovalidate the user's authority to access CA 7.

BYPSEC(Optional) Specifies functions for which UID security is to be bypassedwhen accessing jobs in the CA 7 database or queues.

Important! We do not recommend the use of these options. If selected,serious security exposures may result. The decision to use these optionsshould be made only after careful consideration of the possibleconsequences of bypassing the CA 7 security interface.

If more than one of these subparameters is used, enclose in parenthesesand separate them with commas.

1Indicates that security access to predecessor jobs will not be validatedduring job predecessor definition (DB.3.2). Access to the job for whichpredecessors are defined will still be validated.

2Indicates that security access to jobs will not be validated duringforecast processing.


SECURITY Statement

3Indicates that security access to requirement successor jobs is notvalidated during job 'purge' delete processing (DB.1 or DB.10). That is,if a user is deleting job A with the PURGE function and job B has job Alisted as a predecessor, job B is updated to remove the predecessorentry for job A without a security check to determine if the current userhas update access to job B.

DISPLAY(Optional) Determines whether the USERID is displayed when it is enteredon the Logon panel.

YESIndicates that the USERID is displayed. This is the default.

NOIndicates that the USERID is not displayed.

EXTERNAL(Optional) Identifies the security functions (calls) that are to be controlled byexternal security. Required for external security. Any security functions thatare not specified on the external keyword are controlled by CA 7 internalsecurity. This would require the presence of a CA 7 security module builtusing the CA 7 SECURITY macro. For more information, see “SECURITYMacro” on page 154.

If more than one of these subparameters is used, enclose in parenthesesand separate them with commas.

CALENDARIndicates that any attempt to access a CA 7 base calendar is validatedthrough external security. The security resource class used for suchvalidation is CALENDAR.

COMMANDIndicates all command functions are validated through external security.This includes panel access throughout CA 7.

DATASETIndicates that any attempt to access a data set while signed on to CA 7is validated through external security.

LOGONIndicates that logons to CA 7 are validated through external security.This parameter is the minimum requirement for the EXTERNALkeyword when implementing external security. The security calls toexternal security during CA 7 LOGONs establishes the securityenvironment for each CA 7 user.


SECURITY Statement

SUBCHECKValidates the usage of USERIDs under CA 7. Requires that SUBUIDbe coded.

When a user requests a job through a DEMAND, LOAD, or RUN, CA 7attempts to determine the USERID with which the job runs. Externalsecurity is used to validate the requesters authority to submit for thatUSERID. Submit checking is also performed during both JCL and QJCLedits. If a user attempts to add a USERID to the JCL, the user'sauthority to submit for that ID is checked. This prevents unauthorizedusage of USERIDs.

If this option is used, CA 7 will also validate attempts to add, change orupdate the RESPONSE ID associated with an ARFSET.

SUBOWNERPerforms the same function as Submit checking except that it relatesonly to the OWNER ID associated with a job. If a job has an OWNERID defined, validation is performed for attempts to add, change, ordelete the OWNER ID.

HIDEGRP(Optional) Used to cause user security group values coded in JCLstatements to be overlaid with @ characters whenever JCL is listed withone of the inquiry commands.

NOIndicates the values are to be displayed. This is the default.

YESCauses the following to be hidden in inquiry output:

GROUP keyword value in JOB statements

For a list of the affected inquiry commands, see keyword HIDEUSER.

HIDEPW(Optional) Causes user security password values coded in JCL statementsto be overlaid with @ characters whenever JCL is listed with one of theinquiry commands.


YESCauses the following to be hidden in inquiry output:

PASSWORD keyword value in JOB statements//�PASSWORD statement values

For a list of the affected inquiry commands, see keyword HIDEUSER.


SECURITY Statement

HIDEUPD(Optional) Used to suppress the last updater on several of the listingcommands.

Note: After enabling this, an update will need to be performed on theelement. When this element is updated, *SECURE* will be placed in theupdater field.

NOIndicates values are to be displayed. This is the default.

YESCauses *SECURE* to be placed in the updater field after the nextupdate.

HIDEUSER(Optional) Causes user security ID values coded in JCL statements to beoverlaid with @ characters whenever JCL is listed with one of the inquirycommands.


YESValue of YES causes the following to be hidden in inquiry output:

USER keyword value in JOB statements//�LOGONID statement values//�JOBFROM statement values

These values are hidden when the following inquiries are used:

LACT,LIST=JCL LPRRN,LIST=JCL

LJCK LQ,LIST=JCL

LJCL LQUE,LIST=JCL

LLIB LRDY,LIST=JCL

LPDS LREQ,LIST=JCL

JCLUID(Optional) This option can be used to prevent submission of jobs whoseJCL contains a USERID. This parameter is only applicable if a SUBUIDhierarchy is also specified. The default is YES.

YESIndicates that CA 7 will submit the job after validating that CA 7 hasauthority to submit for the USERID in the JCL.

NOCA 7 will not submit a job that has a USERID in the JCL. Instead, thejob is requeued to the request queue with the status of R-NOUID atsubmission time.


SECURITY Statement

LOADSUBC(Optional) Suppresses the submit check on the LOAD(H) command. Thisoption only has meaning if the EXTERNAL options include SUBCHECK.

YESValidates the LOAD(H) commands with SUBCHECK. This is the default.

NOExempts the LOAD(H) commands from the SUBCHECK validation.

LOGOPID(Optional) Specifies whether the transaction log records for /LOGONcommands should include operator ID. In either case, password values arenot logged.

YESIndicates that transaction log records for /LOGON commands shouldinclude operator ID. This is the default.

NOIndicates that transaction log records for /LOGON commands shouldnot include operator ID.

MIXPW(Optional) Specifies whether the logon password can validly containlowercase characters.

NOIndicates that passwords are translated to uppercase. This is thedefault.

YESIndicates that passwords are not translated to uppercase, allowing forlowercase characters to be in the password. Ensure that the securityinterface being used (CA ACF2, CA Top Secret, or RACF) supportslowercase passwords.

PCLASS(Optional) Specifies the resource class being used for security calls that aremade from CA 7 to validate a user's authority to access CA 7 commandsand panels. The default resource class is PANEL. This field can be up to 8characters.

Note: If you change this value, check the RCLASS keyword. The defaultfor the RCLASS keyword is PANEL.


SECURITY Statement

PROPAGATE(Optional) Pertains only to RACF (and other SAF environments). Thisdetermines the method that CA 7 will use to associate a USERID with a jobwhen it is submitted. This parameter is only applicable if a SUBUIDhierarchy is also specified.

NOIndicates that CA 7 will insert a USER= parameter in the JOBstatement when a job is submitted. This is the default.

YESIndicates that CA 7 will not modify the JCL being submitted. Instead,the USERID will be propagated to the submitted job because the job'sUSERID will be used when the internal reader is opened to write theJCL. This process is similar to a job submitted through TSO inheritingthe USERID of the person who submitted it.

PSOWNER(Optional) Determines whether a USERID is required to be the same as thejob's OWNER to access a job on the CA 7/PERSONAL SCHEDULINGpanel.

YESIndicates that the validation is done. The check requires that theUSERID match the OWNER in order to allow access to the job. This isthe default.

NOThe validation is not done.

RCLASS(Optional) Specifies the resource class being used for security calls that aremade from CA 7 to validate a user's authority to access a UID Resourceduring CA 7 logon and when issuing the /UID,R= command. The defaultresource class is PANEL. (The access level is READ.)

RESLOGON(Optional) After an online terminal is logged on, subsequent LOGONs fromthe command line are not allowed unless RESLOGON=NO.

YESAny /LOGON command from the top line is treated as an error requiringa logon from the formatted logon panel. This is the default.

NO/LOGON command is allowed.


SECURITY Statement

RLOGUID(Optional) Determines whether the LRLOG command (List Run Log)subjects job-related events to CA 7 UID internal security checks. For moreinformation about the LRLOG command, see the Command ReferenceGuide.

YESIndicates UID checking should be performed for LRLOG. It causesLRLOG to display only jobs that the LRLOG requestor has access to.This is the default.

NOIndicates UID checking should not be performed for LRLOG.

STATSID(Optional) Controls disposition of USERID in PDS directory data when usingthe CA 7 editor. YES is the default. Members built with CA Endevor in anCA Endevor library do not have the USERID placed in the STATS.

YESIndicates that the USERID is written to the PDS directory.

NOIndicates that the USERID is not written to the PDS directory but iswritten out as all @s.

SUBNOID(Optional) Specifies the disposition of jobs that do not have a valid USERIDavailable at job submission time.

NOIndicates that jobs without a USERID cannot be submitted. Jobs withouta valid USERID are moved back to the request queue and are markedwith a requirement status of R-NOUID (No USERID). A requirement ofR-NOUID can be satisfied in two ways. If the QJCL subparameter wasselected on the SUBUID parameter, edit and replace the Queue JCL toset the USERID of the Queue JCL editor. The second method is tomanually insert a USERID into the JCL from the Queue JCL Edit panel.The USERID will be identified by CA 7 and thereby satisfy theR-NOUID requirement. This is the default.

Note: For nonexecutable jobs with R-NOUID, a top line QJCL and aREPLACE function can be done. If QJCL is in the hierarchy, theR-NOUID is satisfied. SUBUID must be coded if SUBNOID=NO iscoded.

YESIndicates that jobs can be submitted without a USERID.


SECURITY Statement

SUBUID(Optional) Specifies a hierarchy of candidate USERID sources for USERIDinsertion during job submission. If CA 7 will be inserting USERIDs into JCLduring submission, this list prioritizes the potential sources for USERIDs.The order of specification in the list determines the priority of the USERIDsto be selected.

If the SUBUID keyword is added to the SECURITY statement and CA 7 isrecycled, any jobs already in the request queue are not affected. They needto be canceled and demanded back in to use the new security data.

OWNERIndicates the Job OWNER ID is to be selected for insertion into the JCLfor a Job during submission.

REQIndicates the requester's ID is a candidate for USERID insertion. TheRequester ID can be the ID of a user issuing a DEMAND, LOAD, orRUN command to request a job. The Requester ID can also be theUSERID selected for a job (requester) that then triggers additional jobs.The USERID is inherited by the triggered jobs. In the case of data settriggers, jobs that create or "post" a data set to CA 7 will have theirassociated USERID propagated to any subsequently triggered jobs. Forthe U7SVC and SASSBCLP facilities, the USERID is extracted from thecurrent environment from which the user issues the data set creation orpost request.

QJCLIndicates that the USERID of any user editing Queue JCL for a job is acandidate for USERID insertion. This would be the USERID of the lastperson to edit Queue JCL for a job.

CA7Indicates the USERID assigned to CA 7 can be selected for USERIDinsertion. If selected, the CA 7 USERID will be inserted into the job'sJCL during job submission. For CA ACF2, if started task checking isactivated, this option cannot be used.

UID(Optional) Specifies a UID Resource Table that was built using theCA7RTBL macro. If this parameter is specified, the UID Resource Table isloaded during CA 7 initialization.

The SAMPJCL member UL2B109 can be used to build a table. A sampletable (SASSRTBL) is also supplied in the CAILOAD.


SECURITY Statement

USER(Optional) Specifies the name of the load module link edited from theUSERID macro assembly.

XPSSID(Optional) Defines the one- to eight-character USERID to be used in theterminal logon for XPS job submission if no USERID is supplied on thesubmission request from the XPS CLIENT (typically Unicenter NSM JMOption or CA AutoSys). This is regarded as the requester ID for purposesof USERID insertion and propagation. The default value is **NONE** thatmeans there is no default USERID, and any XPS submission requests thatdo not have an explicit USERID are rejected.


/DISPLAY,ST=

/DISPLAY,ST=

The /DISPLAY,ST=SEC command displays the current security options in effectfor CA 7. The options displayed are based on parameters selected for theSecurity statement in the CA 7 initialization file. The /DISPLAY,ST= commandhas a STATUS keyword subparameter, SEC, which is shortened fromSECURITY.

This command has the following format:

��─ ──/DISPLAY,ST= ──┬ ┬─SEC────── ───────────────────────────────────────�� └ ┘─SECURITY─

This is the /DISPLAY,ST=SEC panel.

� �� SECURITY OPTIONS ��

ENVIRONMENT EXTERNAL CONTROL --------------- ----------------

EXTERNAL SECURITY : CA-TOP SECRET LOGON : ACTIVESECURITY APPL NAME: �NONE� COMMAND : ACTIVE

SECURITY MODULE : SASSSECI SUBCHK : ACTIVE USERID MODULE : �NONE� DATASET : ACTIVE SUBOWN : ACTIVE

CALENDAR : ACTIVE

JOB SUBMISSION USERID HIERARCHY ------------------ ---------------- UPDATER USERID REQUIRED : YES REQUESTER

USERIDS IN JCL : YES OWNER GLOBAL

� �

This panel contains the following fields:

ENVIRONMENTIdentifies the options listed indicate the external security package present, ifany, and the Security Application name for CA 7 defined to externalsecurity.

EXTERNAL SECURITYIndicates the external security package found during CA 7 initialization. Thepossible values are:

CA Top Secret

CA ACF2

OTHER (SAF) *

NONE


/DISPLAY,ST=

* - Indicates an SAF-compatible security system, (such as, RACF).

SECURITY APPLIdentifies the application name for CA 7, defined to the external securitypackage.

SECURITY MODULEIdentifies the security module built using the CA 7 SECURITY macro andidentified by the NAME= parameter on the SECURITY statement in theCA 7 initialization file.

USERID MODULEIdentifies the USERID module built using the CA 7 USERID macro thatdefines any correspondence between various UID values under CA 7Internal Security.

EXTERNAL CONTROLIdentifies the status of external security control for specific security functionsunder CA 7. The status is ACTIVE for each function that is controlled byexternal security and INACTIVE for those functions under the control ofCA 7 internal security.

LOGONIndicates sign on and sign off.

COMMANDIndicates command and panel security.

SUBCHKIndicates job submission authority.

DATASETIndicates data set security.

SUBOWNIndicates job owner ID security.

CALENDARIndicates CA 7 base calendar security.

JOB SUBMISSIONIndicates whether a USERID is required for a job to be submitted.

USERID REQUIREDUSERID required in job.

YESUSERID required. Jobs are not submitted without a USERID.

NOUSERID not required. Jobs are submitted without a USERID.


/DISPLAY,ST=

USERIDS IN JCLIndicates whether a USERID is coded in JCL.

YESUSERID can be coded in JCL.

NOJobs are not submitted if a USERID is coded in JCL.

USERID HIERARCHYSpecifies a list of candidate USERID sources, in priority order, from which aUSERID can be selected for JCL insertion during job submission.

UPDATERSpecifies the USERID of the last Queue JCL updater.

REQUESTERSpecifies the USERID of a user requesting a job or the USERID from atriggering job.

OWNERSpecifies the job owner USERID.

GLOBALSpecifies the CA 7 USERID.


Chapter 4. Implementing Security withCA Top Secret


Define CA 7 to CA Top Secret . . . . . . . . . . . . . . . . . . . . . . . . . . 42Define the CA 7 Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Define the CA 7 ACID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Define ICOM to CA Top Secret . . . . . . . . . . . . . . . . . . . . . . . . . . 46Control User Access to CA 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Define CA 7 Command Security . . . . . . . . . . . . . . . . . . . . . . . . . 49Secure the /MVS Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Calendar Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Control Job Submission Under CA 7 . . . . . . . . . . . . . . . . . . . . . . 53Program Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Job Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56UID Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59/UID Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64/REFRESH Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65External Communicators with CA Top Secret . . . . . . . . . . . . . . . . . 66Sample Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

This chapter describes the steps necessary to implement the CA 7 ExternalSecurity Interface with CA Top Secret. A working knowledge of the securitystructure for CA Top Secret and its associated command syntax is required. Allof the CA Top Secret commands shown in this chapter must be executed underCA Top Secret.

Chapter 4. Implementing Security with CA Top Secret 41

Define CA 7 to CA Top Secret

Define CA 7 to CA Top Secret

The following topics provide examples of CA Top Secret commands that can beused to implement CA 7 External Security. For more information about thecommands listed in this chapter, see the CA Top Secret Command FunctionGuide (for z/OS).

Note: The security definitions provided in this section are recommendations forestablishing your CA 7 security environment. It is the responsibility of each siteto determine whether these recommendations meet local auditing and securitystandards.


Define the CA 7 Facility

Define the CA 7 Facility

The CA Top Secret Facility Matrix allows installations to define CA 7 as aspecial facility to be protected by CA Top Secret. The facility definition is usedto define specific execution requirements for CA 7 such as authorization tosubmit jobs, identify CA 7 as a multiuser single address space system, and toprevent abends due to single user security violations. The following commandcan be used to define the CA 7 facility:

Note: The definition of the CA 7 facility using the TSS modify command is notpermanent. We recommend that you add the CA 7 facility definition commandsto the CA Top Secret startup parameter file to ensure that the CA 7 facility isdefined during CA Top Secret initialization. For a discussion of the TSSPARM0parameter file, see the CA Top Secret Getting Started.


TSS MODIFY(FAC(CA7=ASUBM,MULTIUSER,NOABEND,PGM=SAS,LOG(ALL)))

TSS MODIFYSpecifies the CA Top Secret command identifier (TSS). The MODIFY optionmust be used when referencing the CA Top Secret Facilities Matrix.

FACSpecifies the CA Top Secret command parameter used to add, change, ordelete facilities.

CA7Specifies the name used in this example for the CA 7 facility.

ASUBMIdentifies the CA 7 facility as authorized for Job Submission.

MULTIUSERIdentifies the CA 7 facility as a multiuser address space.

NOABENDSpecifies that the CA 7 facility does not abend if one user in the CA 7multiuser address space causes a security violation.

PGM=SASIdentifies the first three characters of the program name that issues SVCcalls for security validations under the CA 7 facility. Required.

LOG(ALL)Specifies that CA Top Secret logs all security events for the CA 7 facility.


Define the CA 7 ACID


CA 7 requires an ACID definition to execute under CA Top Secret security.This definition identifies CA 7 as a started task, names the procedure fromwhich CA 7 executes, and associates the CA 7 facility with the CA 7 ACID.


TSS CREATE(CA7ONL) NAME('CA 7 ONLINE ACID') FAC(STC,BATCH) +TYPE(USER) PASS(NOPW) DEPT(CA7OPS) MASTFAC(CA7) NOSUBCHK

TSS CREATEIndicates the CA Top Secret command used to create ACIDs.

CA7ONLIndicates the name chosen in this example for the CA 7 online ACID.

NAMESpecifies the CA Top Secret Create command parameter used to describethe ACID you are creating. In this case, the CA 7 online ACID.

FAC(STC,BATCH)Specifies the CA Top Secret command parameter used to define the CA 7ACID as a started task and to allow batch job submission.

TYPE(USER)Identifies the CA 7 ID as a User ACID.

PASS(NOPW)Indicates that the CA 7 ACID does not require a password.

DEPT(CA7OPS)Establishes the owning department for the CA 7 ACID.

MASTFAC(CA7)Identifies the "master facility" for the CA 7 online ACID. This is the facilityID defined previously.

NOSUBCHKIndicates to CA Top Secret that CA 7 is exempted from authorizationchecking during job submission. This parameter is optional butrecommended. Without this parameter, each USERID in JCL submitted byCA 7 must be defined to the CA 7 ACID with a PERMIT command orCA 7 abends during job submission.



The following command adds the CA 7 ACID to the CA Top Secret StartedTask facility and identifies the CA 7 procedure name.

TSS ADDTO(STC) PROCNAME(CA7ONL) ACID(CA7ONL)

TSS ADDTO(STC)Specifies the CA Top Secret command used to add information to theStarted Task Facility.

PROCNAME(CA7ONL)Identifies the procedure name to be used for the CA 7 started task.

ACID(CA7ONL)Associates the started task procedure name with the CA 7 ACID.


Define ICOM to CA Top Secret


The CA 7 Independent Communications Manager (ICOM) must also be definedto CA Top Secret. ICOM is responsible for handling SMF data for jobssubmitted through CA 7, and therefore requires an ACID to execute in a CATop Secret secured environment. The following command example may beused to define CA 7 ICOM to CA Top Secret.


TSS CREATE(CA7ICOM) NAME('CA 7 ICOM') FAC(STC) TYPE(USER) +PASS(NOPW) DEPT(CA7OPS) MASTFAC(CA7) NOSUBCHK

TSS CREATESpecifies the CA Top Secret command used to create ACIDs.

CA7ICOMSpecifies the name chosen in this example for the CA 7 ICOM ACID.

NAMESpecifies the CA Top Secret Create command parameter used to describethe ACID you are creating. In this case, the CA 7 ICOM ACID.

FAC(STC)Specifies the CA Top Secret command parameter used to define the ICOMACID as a started task.

TYPE(USER)Identifies the CA 7 ID as a User ACID.

PASS(NOPW)Indicates that the CA 7 ACID does not require a password.

DEPT(CA7OPS)Establishes the owning department for the CA 7 ACID.

MASTFAC(CA7)Identifies the master facility for the ICOM ACID. This is the facility IDdefined previously.

NOSUBCHKIndicates to CA Top Secret that CA 7 is exempted from authorizationchecking during job submission. This parameter is optional butrecommended. Without this parameter, each USERID in JCL submitted byCA 7 must be defined to the CA 7 ACID with a PERMIT command orCA 7 abends during job submission.



The following command adds the CA 7 ICOM ACID to the CA Top SecretStarted Task Facility and identifies the CA 7 ICOM procedure name.

TSS ADDTO(STC) PROCNAME(CA7ICOM) ACID(CA7ICOM)

TSS ADDTO(STC)Specifies the CA Top Secret command used to add information to theStarted Task Facility.

PROCNAME(CA7ICOM)Identifies the procedure name to be used for the CA 7 ICOM started task.

ACID(CA7ICOM)Associates the started task procedure name with the CA 7 ICOM ACID.


Control User Access to CA 7

Control User Access to CA 7

Because CA 7 is a VTAM application with access to system resources, sign-onor logon to it must be controlled. This control is accomplished through theFacility definition previously presented, the CA Standard Security Facility (SSF),and a CA 7 initialization parameter. For a discussion of the CA 7 initializationparameters, see Chapter 3, “Security Initialization Options” on page 25.

With TSS controlling access to CA 7, each user must be granted authority tolog on to CA 7. This authority is provided with the following CA Top Secretcommand.


TSS ADDTO(USER) FAC(CA7)

TSSIdentifies a CA Top Secret command.

ADDTOSpecifies the CA Top Secret command used to grant access to resources.

(USER)Specifies the User ACID to be permitted access to the CA 7 facility.

FACSpecifies the CA Top Secret keyword used to identify a facility.

(CA7)Specifies the name used in this example for the CA 7 facility as definedpreviously.


Define CA 7 Command Security


CA 7 command security includes security for top line commands, panel access,and functions within a panel. All commands have a unique resource name thatcan be secured using the CA Top Secret PERMIT command. This permits orauthorizes users to access a given command.

The same is true for panels in CA 7. Panels have a unique panel-ID that canbe specified under CA Top Secret as a resource name to restrict access toCA 7 applications. Permitting access to a resource does not grant full functionalauthority for a given command or panel. Each panel may require an additionalaccess level to have the authority for a function. The ACCESS keyword onPERMIT commands is used to grant additional authority levels for resources.The valid Access levels for CA Top Secret are READ, CREATE, SCRATCH,UPDATE, and CONTROL.

For a list of CA 7 commands and panels and their associated resource names,see Appendix A, “Security Tables.” The following examples illustrate the use ofthe CA Top Secret PERMIT command to authorize access to CA 7 commandsand panels.

Note: When defining access to command and panel resources for CA 7, theresource type must be PANEL. This is the resource type used during securitycalls to external security.


TSS PERMIT(CA7USER) PANEL(L2DB1)

TSS PERMITSpecifies the CA Top Secret command used to authorize access to aresource.

CA7USERSpecifies the user ACID to be granted READ access to panel resourceL2DB1.

PANEL(L2DB1)Specifies the resource type followed by the resource name to which thiscommand applies. The L2DB1 is the resource name associated with theDB.1 panel in CA 7. If you have specified a resource type other thanPANEL (see the SECURITY statement PCLASS keyword), substitute thatvalue for PANEL.

Note: The default access granted in the example PERMIT command shownpreviously is READ.




TSS PERMIT(CA7USER) PANEL(L2DB1) + ACCESS(READ,CREATE,SCRATCH,UPDATE,CONTROL)

TSS PERMITSpecifies the CA Top Secret command used to grant access to a resource.

CA7USERSpecifies the user ACID to be granted access to panel resource L2DB1.

PANEL(L2DB1)Specifies the resource type followed by the resource name to which thiscommand applies. The L2DB1 is the resource name associated with theDB.1 panel in CA 7.

ACCESSSpecifies the CA Top Secret keyword used to indicate specific access to aresource.

READGrants READ access only to the indicated resource.

CREATEGrants creation authority to the indicated resource.

SCRATCHGrants scratch authority to the indicated resource.

UPDATEGrants update authority to the indicated resource.

CONTROLLets you specify certain controlled accesses such as a time of day. Formore information about the CONTROL parameter, see the CA TopSecret Command Options Guide (for z/OS).


Secure the /MVS Command


The /MVS command allows a CA 7 user to issue an MVS console commandfrom a CA 7 terminal. Although such a facility may prove indispensable incertain situations, the risks associated with an indiscriminate use of thecommand are obvious. This section discusses security considerations regardingthe use of the command. For more information about the /MVS command, seethe Command Reference Guide.

The /MVS command text is sent to MVS using SVC 34. The user ID that isassociated with the CA 7 address space is the user ID in control when the SVCis issued.

CA 7 does not perform any special validation to verify the terminal user'sauthority for the MVS command attempted. If the user is allowed to issue the/MVS command, the specified command text is sent to MVS.

We recommend that CA 7 command security be employed to restrict /MVScommand access to a limited class of privileged users.


Calendar Security

Calendar Security

To protect access to the CA 7 calendars, use the CALENDAR option in theEXTERNAL keyword values on the SECURITY statement in the CA 7initialization file.

The resource name of $CALNDR will need to be set up. The only service levelchecked is READ.

The following is an example of setting up a rule to access a calendar:

TSS PERMIT(ca7user) $CALNDR(calendar-name) ACCESS(READ)


Control Job Submission Under CA 7

Control Job Submission Under CA 7

Depending on your security options, submit checking may be done. For theseoptions, see “SECURITY Statement” on page 26.


TSS PERMIT(USERID1) ACID(USERID2)

TSSIdentifies a CA Top Secret command.

PERMITSpecifies the CA Top Secret command used to grant access to resources.

(USERID1)Specifies the User ACID to be permitted submission authority foranother ACID.

ACIDSpecifies the CA Top Secret keyword used to identify a USERID.

(USERID2)Specifies the ACID for which another USER has submission authority.


Program Protection

Program Protection

CA Top Secret, by default, restricts access to all programs. CA 7 requiresaccess to numerous programs that are critical to production processing. Due tothe number of modules required during execution, a program name prefix ofSASS can be used when defining program access for CA 7. The main drivermodule UCC7 is also required. Use the following CA Top Secret PERMITcommands to grant program access to CA 7.


TSS PERMIT(CA7ONL) PROG(UCC7)

TSSIdentifies the following data as a CA Top Secret command.

PERMIT(CA7ONL)Specifies the CA Top Secret keyword used to grant access to the specifiedresource for the CA 7 online ACID.

PROG(UCC7)Specifies the CA Top Secret keyword that identifies the resource to whichthis command applies.

UCC7Identifies the CA 7 main driver module.


Program Protection


TSS PERMIT(CA7ONL) PROG(SAS)

TSSIdentifies the following data as a CA Top Secret command.

PERMIT(CA7ONL)Specifies the CA Top Secret keyword used to grant access to the specifiedresource for the CA 7 online ACID.

PROG(SAS)Identifies a program prefix of SAS. This command grants CA 7 theauthority to execute any program with a prefix of SAS.

Batch Users

All batch USERIDs that are associated with jobs submitted through CA 7require access to the program SASSJJCL. This is the LOAD program thatidentifies resources used by a job to CA 7.

To prevent the unauthorized use of CA 7, we recommend that access to thefollowing programs be secured:

SASSBCLP - Batch Card Load Program

SASSBSTR - Batch Terminal Interface

SASSTRLR - Trailer Step Facility

U7SVC - CA 7 SVC Facility

CAL2X2W0 - CA 7 CAICCI Interface


Job Submission

Job Submission

CA 7 maintains a record of USERIDs that can be associated with a CPU jobfrom queue entry to job submission. This association is not applicable toXPJOB definitions. XPJOB job submission security is described in “SecurityConsiderations for Cross-Platform Scheduling” on page 20.

If requested, a USERID can be inserted into a job's JCL, before submission, tosatisfy batch security requirements on your system. CA 7 has five potentialsources for USERIDs:

Job OwnerSpecifies a USERID from the OWNER field for a job on the job definitionpanel. (SUBUID value of OWNER)

JCL IDSpecifies a USERID that exists in a job's JCL at entry into the requestqueue. If a job's JCL contains a USERID at queue entry, USERID insertiondoes not take place. The JCL ID overrides all other USERIDs.

RequesterSpecifies the USERID of the user that requests a job through the DEMAND,LOAD, or RUN commands. (SUBUID value of REQ)

Queue JCLSpecifies the USERID of a user editing a job's queued JCL in the CA 7request queue. (SUBUID value of QJCL)

CA-7Specifies the USERID assigned to CA 7 at startup. If requested the CA 7ID is propagated to submitted jobs. (SUBUID value of CA7)

The priority of USERID sources is determined by the specification of theSUBUID keyword on the SECURITY statement in the CA 7 initialization file.The SUBUID keyword specifies a hierarchy of USERIDs for JCL insertion.

At submission time, CA 7 scans the USERID hierarchy to determine if aUSERID is available from the first hierarchy entry. If an ID is found, it isinserted into the job's JCL and the job is submitted, assuming all otherrequirements have been met. If an ID was not found, the next source entry ischecked for an available ID.

This process continues until an ID is found and inserted into the JCL. If allpotential sources have been checked and a USERID is not available, CA 7checks the status of the SUBNOID flag. The SUBNOID flag is set by theSUBNOID keyword specified on the SECURITY statement in the CA 7initialization file. If SUBNOID=YES, a job may be submitted without a USERID.If SUBNOID=NO, jobs may not be submitted without a valid USERID and aremoved back to the request queue with a requirement status of R-NOUID. TheR-NOUID status indicates that all USERID sources were checked and no validUSERID was found for JCL insertion.


Job Submission

Satisfy the R-NOUID Requirement

There are two ways to satisfy the R-NOUID requirement.

■ If you have specified the QJCL keyword on the SUBUID parameter, you canFETCH/EDIT the job's queued JCL and immediately do a SAVE/REPLACE.CA 7 saves the USERID of the user editing the queued JCL. This wouldsatisfy the R-NOUID requirement because an ID is now available from oneof the candidate USERID sources and the job is now eligible forsubmission.

■ The second method is to manually add a USERID to the job's queued JCL.CA 7 recognizes the addition of the USERID to the JCL and the R-NOUIDrequirement would be satisfied.

Note: If a job's JCL contains a USERID at queue entry time, this USERIDoverrides all other USERIDs and USERID insertion will not take place.

You may not manually satisfy or POST an R-NOUID requirement. If you try tosatisfy the requirement by any method other than those listed previously, therequest is ignored.

USERID Propagation

Establishing USERIDs to be associated with jobs when submitted by CA 7 is acritical aspect of security. Defining the USERID hierarchy requires carefulplanning to ensure that each job is submitted with the correct ID and thereforethe proper security. If Requester (REQ) is specified in the SUBUID hierarchy,USERIDs are propagated to any jobs triggered by the original request. Thismeans that USERID propagation of a requesting ID occurs for the followingconditions:

■ The USERID of a user requesting work through the DEMAND, LOAD, orRUN commands.

■ The USERID associated with a job that triggers any additional jobs.

■ For data set triggers, the USERID associated with a job that was submittedby CA 7 and created the data set.

■ For data set triggers that are initiated through U7SVC and SASSBCLP, theUSERID associated with the user posting the creation of the data set.


Job Submission

JCL USERID Format

For USERID insertion, CA 7 modifies the last statement of the JCL JOBstatement to add the USERID. A comma is added to the last statement toindicate continuation and is followed by a USER= statement to supply theUSERID. The following example illustrates the JCL statement format usedduring ID insertion.

// USER=userid

Note: The USERID password is inserted, if required, by CA Top Secret. Thisis an automatic function related to Job Submission and the ASUBM keywordspecified on the CA 7 facility that was previously defined.


UID Resources

UID Resources

Access to information about the CA 7 database is controlled through UIDsecurity validation. When a user attempts to access a job on the database,regardless of whether internal or external security is in control, the user's UIDvalue is checked against the UID value associated with the job. This providesjob-level security for the CA 7 database. External security does not provide anequivalent JOB level protection; therefore, it is important that each CA 7 userbe assigned a UID that relates to the user's area of responsibility.

Note: UID resource security is only valid in an environment where externalsecurity controls CA 7 logons. Calls are made to the external security packageto validate a user's authority to access the resource. The resources have nomeaning to CA 7 internal security.

The UID value (0-255) can be obtained from the USERID entry in the CA 7internal security module, through UID resource validation during logons to CA 7or through the /UID top line command issued under a CA 7 session. If youwant to maintain USERIDs in the CA 7 internal security module, seeChapter 7, “Internal Security” for information about defining USERIDs in theinternal security module. The following information outlines the steps necessaryto implement UID resource validation and describes the security processinginvolved.

UID resource security requires a UID Resource Table that CA 7 referencesduring UID resource validation. This table contains resource names andassociated UID value entries to be used during the UID validation process. Asample resource table, SASSRTBL, is provided in both source and load moduleformat and may be used to implement UID resource security. To create asite-specific UID Resource Table with unique resource names and UID values,use the CA7RTBL macro to generate the table.

Note: The default resource class for UID resources is PANEL. You maychange the resource class for calls to external security using the RCLASS=parameter on the CA 7 initialization file SECURITY statement.

You may use the /PROF command to establish and maintain a default UIDresource for users logging on to CA 7. For a description of the /PROFcommand, see the Command Reference Guide.

If using COIDs, the CA 7 USERID security module described in “USERIDMacro” on page 157 is required.


UID Resources

CA7RTBL Macro

The CA7RTBL macro is used to generate the UID Resource Table. For themacro's required parameters, see the following descriptions. Once the newsource has been created, see member UL2B109 in the CA 7 SAMPJCL file forapplying the USERMOD.

The following is an example of the CA7RTBL macro statement:

CA7RTBL RSRC=CA7�255,UID=255

CA7RTBLThis is the UID Resource Table generation macro. It is used to build theUID Resource Table.

RSRCThe resource name to be generated in this entry of the table. The resourcename can be a one- to eight-character name that meets site-specificexternal security resource naming conventions.

Note: Resource names must not conflict with existing panel or commandnames if the default PANEL resource class is used. For more information,see the description of the RCLASS keyword in the chapter "SECURITYStatement."

UIDThe value that will be associated with the resource name supplied on theRSRC= parameter. The value can be from 0 to 255.


UID Resources

Usage Notes

■ The UID Resource Table name must be a valid PDS member name.

■ The CA7RTBL macro must be coded starting in column 10.

■ Duplicate resource names are not allowed, but duplicate UID values areallowed in the table.

■ The UID Resource Table source must be assembled and link edited into aload library accessible by CA 7.

■ The last entry in the table must be specified with a resource name of LAST(RSRC=LAST) to indicate the end of the table. The UID= parameter is notnecessary on the last statement.

■ The UID Resource Table name must be identified on the CA 7 initializationfile SECURITY statement using the UID= parameter. see “SECURITYStatement” on page 26. for a discussion of the SECURITY statement andits associated parameters.

■ The resource names coded in the UID Resource Table must be defined toexternal security.

UID Resource Table - SASSRTBL Source

Example UID Resource Table - SASSRTBL Source

TITLE 'CA 7 EXTERNAL SECURITY UID/RESOURCE TABLE' ��1��8SASSRTBL START � ��2��SASSRTBL CA7RTBL RSRC=CA7��,UID=�� 4��8 CA7RTBL RSRC=CA7��1,UID=��1 ��5��8 CA7RTBL RSRC=CA7��2,UID=��2 ��7��8 CA7RTBL RSRC=CA7��3,UID=��3 ��9��8 CA7RTBL RSRC=CA7��4,UID=��4 ��1�1��8 CA7RTBL RSRC=CA7��5,UID=��5 ��1�3��8 CA7RTBL RSRC=CA7��6,UID=��6 ��1�5��8 CA7RTBL RSRC=CA7��7,UID=��7 ��1�7��8 CA7RTBL RSRC=CA7��8,UID=��8 ��1�9��8 CA7RTBL RSRC=CA7��9,UID=��9 ��1�92�8 CA7RTBL RSRC=CA7��1�,UID=�1� ��1�94�8 . ��1�96�8 . ��1�98�8 . ��11��8 CA7RTBL RSRC=CA7�254,UID=254 ��1428�8 CA7RTBL RSRC=CA7�255,UID=255 ��1429�8 CA7RTBL RSRC=LAST ��143��8 END ��15��


UID Resources

CA 7 Logon and UID Resource Validation

When a user signs on to CA 7, the user can optionally supply a UID resourcename in the UID RESOURCE field on the CA 7 Logon panel. If no UIDresource name is supplied, a check is made to see whether one is defined inthe user's CA 7 profile record. If present, the profile resource name is used asif it were entered on the Logon panel. The USERID and PASSWORD suppliedare first validated through external security and then a lookup is performed todetermine whether the user is defined in the CA 7 Internal Security module.

If the user is defined in the Internal Security module, any UID resource namepassed on the Logon panel is ignored. If the user is not defined in the InternalSecurity module, the UID Resource Table is searched to find a matchingresource entry.

If the resource name is not found in the UID Resource Table, the user is signedon to CA 7 with a UID value of 0. If a matching resource entry is found, a callis made to external security to validate the user's authority to access theresource.

If the user is not authorized to access the resource, a message is displayedindicating the failure and the logon attempt fails. If the user is authorized toaccess the resource, the associated UID value in the UID Resource Table isassigned to the user.

This process allows external security to control UID assignment to CA 7 usersand eliminates the need to maintain all USERIDs in the CA 7 Internal Securitymodule.

Note: The UID resource validation process is the same under the CA 7 ISPFInterface; however, no password is required.


UID Resources

CA-7 Logon Panel: The following is a sample CA-7 Logon panel:

� � -----------------------------CA-7 PRODUCTION SYSTEM----------------------------

PLEASE ENTER LOGON DATA OR PRESS PF3 TO DISCONNECT

USERID : TERMINAL NAME : TRM��1 DATE : �7.�7�PASSWORD : VTAM APPLID : CA7 TIME : 12:�2:52NEW PASSWORD : LUNAME : A99L1�� LEVEL : r11.1(SPn )UID RESOURCE :PARMS : CCCCCCCCCCC AAAAAAAAAA 77777777777 CCCCCCCCCCC AAAAAAAAAA 77777777777 CCC AAA AAA 7777 CCC AAAAAAAAAA 7777 CCC AAAAAAAAAA 7777 CCC AAA AAA 7777 CCCCCCCCCCC AAA AAA 7777 CCCCCCCCCCC AAA AAA 7777

Copyright (c) 2��7 CA.All rights reserved.

� �

CA-7 ISPF Interface Primary Option Menu: The following is a sample CA-7ISPF Interface Primary Option Menu panel:

� � ------------------------- CA-7 PRIMARY OPTION MENU -------------------------- OPTION ===> USERID - USERA PREFIX - USERA TIME - 11:37

� PF KEYS - Specify CA-7 TSO-ISPF PF keys DATE - �7/�2/1�1 ONLINE - CA-7 TSO-ISPF Terminal Session

- UID Resource =>

X EXIT - Terminate CA-7 TSO-ISPF Interface

� �

Enter the END command to terminate CA 7 TSO-ISPF.


/UID Command

/UID Command

The /UID command is used to change a user's current UID processing valuethrough UID resource validation. The /UID command requires that the UIDResource Table option be implemented and that the resources and theappropriate security authorization are defined to external security.


��──/UID──,─ ──┬ ┬──R=resname ───────────────────────────────────────────�� └ ┘──LIST ─────

R=Identifies a resource name that exists in the UID Resource Table. Theuser's authorization to access the resource is validated through externalsecurity and if authorized, the user's current UID value is updated to reflectthe UID value found in the UID Resource Table associated with theresource name that was supplied.

LISTDisplays all resource entries and the associated UID values in the UIDResource Table.


/REFRESH Command

/REFRESH Command

The /REFRESH command is used to refresh the UID Resource Table that wasloaded during CA 7 initalization without cycling CA 7. The definitions codedwithin the specified module will completely replace the definitions currentlybeing used. However, any changes made in the actual CA Top Secretdefinitions (using CA Top Secret commands) may not take effect until CA 7 isrecycled.


��──/REFRESH──,──MOD──=──xxxxxxxx─────────────────────────────────────��

MOD=Identifies a UID Resource Table in load module format that was built usingthe CA7RTBL macro.

xxxxxxxxThis must be the member name of the UID Resource Table, and it mustreside in a load library accessible to CA 7.


External Communicators with CA Top Secret


The external communicators (SASSBSTR, SASSTRLR, U7SVC, CAL2X2W0,and SASSBCLP) provide a means for users outside the CA 7 address space tocommunicate with CA 7. Because the use of these programs may allow accessto production jobs, we recommend that careful consideration be given to thequestion of access to these facilities. Users of the Batch Terminal Interfacerequire access to the program SASSBSTR. Users of the Trailer step, the BatchCard Load Program and U7SVC must be given access to SASSTRLR,SASSBCLP, and U7SVC respectively. Once the question of program access issettled, additional controls may be implemented to prevent unauthorized use ofthese facilities. This section describes those controls.

Users of the CA 7 CAICCI Interface require access to the program CAL2X2W0.This is true regardless of whether this interface is invoked in batch (programCAL2X2WB), REXX (program CAL2X2WR), or program-to-program(CAL2X2WP).

Two types of communication with CA 7 are supported with the externalcommunicators:

■ Terminal communication (Batch Terminal Interface, Trailer, CA 7 CAICCIInterface, and U7SVC)

■ Data set posting (U7SVC and SASSBCLP)



Terminal Communication

The Batch Terminal Interface (SASSBSTR), the Trailer facility (SASSTRLR), theCA 7 CAICCI Interface (CAL2X2W0), and U7SVC each allow the user to sendterminal commands to CA 7. Although no online terminal is used with thismode of communication, input from these programs is treated as terminal inputby CA 7. Command security in these environments is handled as it is for allCA 7 terminals. CA Top Secret controls access to CA 7 commands ifEXTERNAL=COMMAND is specified on the SECURITY statement in the CA 7initialization file. CA Top Secret determines a user's access to CA 7 terminalcommands based on the USERID supplied on the /LOGON command. Thus,when using an External Communicator, a /LOGON command must be precededby any command input.

CA Top Secret normally requires a password at logon. But including passwordsin command input for the External Communicators would obviously represent aserious security exposure. Several checks may be made to avoid the need toinclude passwords in command input when using these facilities. If no /LOGONcommand is found in the command input, a /LOGON statement is built usingthe USERID associated with the current user. Under certain conditions it maynot be possible to extract the USERID associated with the user of the ExternalCommunicator. In that event, a /LOGON statement is built using a defaultUSERID of CA7DUMMY. If a /LOGON statement is found in the commandinput, the current user's authority to use the USERID found on the /LOGONstatement may be checked. If the USERID found on the /LOGON statementmatches the USERID of the current user, it is assumed that the user has theauthority to use the USERID. If the USERIDs differ, a check may be made tovalidate the user's READ access to an entity whose name is the USERID foundon the /LOGON statement. The CA Top Secret PERMIT command can be usedto define this relationship in the same way shown in “Control Job SubmissionUnder CA 7” on page 53. If a /LOGON statement was generated or if theuser's authority to use a USERID was successfully validated, CA 7 allows theuser to LOGON without a password.

Note: The USERID of the current user is determined by using CAS9 SSFservices. For more information about SSF, see the CA Common Servicesdocumentation.

Submit checking for External Communicators is controlled by the value ofBSUBCHK that is set by CAIRIM. For more information, see the chapter"Execution" in the Systems Programmer Guide.



SASSTRLR and External Security

The following information is intended to show the actions that are performed bySASSTRLR during execution with relation to security.

A security EXTRACT is done to determine the USERID of the submitted job.This USERID is later used to generate a full logon statement or optionallyperform a submit check. The input stream is then read to determine whether alogon statement was supplied. If no logon statement was supplied or if a logonstatement was supplied without an OPID, one is generated for the execution.The logon statement resembles the following:

/LOGON extid �GENERATED LOGON�

The extid is the EXTRACTed ID of the job. This logon statement is passed toCA 7 indicating that no password is needed with this particular logon attempt.

If a logon statement with an OPID is found and the OPID is the same as theEXTRACTed ID, the logon statement is passed to CA 7 indicating that nopassword is needed with this particular logon attempt.

If the OPID is not the same as the EXTRACTed ID, other checks are done. Acheck is made to see whether the value of BSUBCHK for the instance is Y. Ifso, a submit check is performed. The check is done to see whether theEXTRACTed ID has the authority to submit on behalf of the OPID in the logonstatement. If the check is okay, the logon statement is passed to CA 7indicating that no password is needed with this particular logon attempt.

If the value of BSUBCHK for the instance is not Y, no submit checks are done.The logon statement is passed as it is coded with no special indication to CA 7.If CA 7 has EXTERNAL=LOGON coded in the initialization file, a logon checkis performed trying to supply a password. If the password was entered on thelogon statement, it is validated by the external security package. If no passwordwas coded, the logon fails due to a missing password.



In general, a password is needed only two times:

■ User exit SASSXXLX is coded by the user to require a password.

■ The value of BSUBCHK is not Y and the OPID is different from theEXTRACTed ID.

Note: Values of SVDSNCHK and BSUBCHK are set using CAIRIM. This isdiscussed in the chapter "Execution" in the Systems Programmer Guide. Thereyou can also find information about CAL2ENVR, a utility that reports currentoptions used by each instance of CA 7 supported on the LPAR. CAL2ENVRcan be used to determine the current settings of keywords such as SVDSNCHKand BSUBCHK.

SASSBSTR and CAL2X2W0 and External Security

The following information is intended to show the actions that are performed bySASSBSTR and CAL2X2W0 during execution with relation to security.

A security EXTRACT is done to determine the USERID of the submitted job oruser environment. This USERID is later used to generate a full logon statementor optionally perform a submit check. The input stream is then read todetermine whether a logon statement was supplied. If no logon statement wassupplied, one is generated for the execution. The logon statement resemblesthe following:




If the OPID is not the same as the EXTRACTed ID, other checks are done. Acheck is made to see whether the value of BSUBCHK for the instance is Y. If itis, a submit check is performed. The check is done to see whether theEXTRACTed ID has the authority to submit on behalf of the OPID in the logonstatement. If the check is okay, the logon statement is passed to CA 7indicating that no password is needed with this particular logon attempt.



If the value of BSUBCHK for the instance is not Y no submit checks are done.The logon statement is passed as it is coded with no special indication to CA 7.If CA 7 has EXTERNAL=LOGON coded in the initialization file, a logon checkis performed trying to supply a password. If the password was entered on thelogon statement, it is validated by the external security package. If no passwordwas coded, the logon fails due to a missing password.





U7SVC and External Security

The following information is intended to show the actions that are performed byU7SVC during execution with relation to security. Two different paths can betaken. It depends on whether there is an input stream with the U7SVC or if it isjust a D= to post a data set.

U7SVC with D= PARM

A security EXTRACT is done to determine the USERID that invoked U7SVC.This USERID is later used to generate a full logon statement or optionallyperform a data set create check.

If the value of SVDSNCHK for the instance not Y, the D= command is passedthrough to CA 7 with no further security checking to be done by U7SVC.

If the value of SVDSNCHK is Y, a security call is made by U7SVC. This calldetermines if the EXTRACTed ID has CREATE authorization for the data setspecified on the D=. If the EXTRACTed ID does have authorization, the D=command is passed to CA 7 for processing.



U7SVC with an Input Stream

A security EXTRACT is done to determine the USERID that invoked U7SVC.This USERID is later used to generate a full logon statement or optionallyperform a submit check. The input stream is then read to determine whether alogon statement was supplied. If no logon statement was supplied or if a logonstatement was supplied without an OPID, one is generated for the execution.The logon statement resembles the following:





If the value BSUBCHK is not Y, no submit checks are done. The logonstatement is passed as it is coded with no special indication to CA 7. If CA 7has EXTERNAL=LOGON coded in the initialization file, a logon check isperformed trying to supply a password. If the password was entered on thelogon statement, it is validated by the external security package. If no passwordwas coded, the logon fails due to a missing password.







Data Set Posting

The Batch Card Load Program (SASSBCLP) and U7SVC allow the user to postthe creation of a data set to CA 7. Because such posting may satisfyrequirements or cause job triggering, the need to secure the use of thesefacilities is critical. There are two features of these facilities that should bementioned in this connection: data set access validation and USERIDpropagation.

The USERID associated with the user of U7SVC or SASSBCLP is extracted todetermine the user's authority to create the data set. Under certain conditions itmay not be possible to extract the USERID for the user of the ExternalCommunicator. In that event, a default USERID of CA7DUMMY is used.

If REQ is specified in the SUBUID hierarchy on the SECURITY statement in theCA 7 initialization file, the USERID associated with the data set creation can bepropagated to triggered jobs.

For example, suppose that a user whose USERID is XXX submits a batch jobthat uses U7SVC to post the creation of data set A.B to CA 7. Suppose alsothat the creation of this data set triggers job Z. Further suppose that REQ is inthe first position in the SUBUID hierarchy. In such a case, USERID XXX couldbe propagated to job Z when the job is submitted.

Note: Each of the External Communicators attempts to extract the USERID ofthe current user, SASSBCLP and U7SVC can be made to verify the authority ofthe user to create that data set whose creation is to be posted to CA 7. Formore information about the CAIRIM keywords that cotnrol this user IDverification, see the chapter "Execution" in the Systems Programmer Guide.


Sample Definitions

Sample Definitions

The member TSSSAMP in the CA 7 Sample JCL file (SAMPJCL) on theinstallation media contains sample TSS commands that can be used to securethe CA 7 processing environment under CA Top Secret. The definitions areintended as examples only and should be reviewed and modified to meet yourinstallations security requirements. Once tailored to your site's specifications,the definitions can be used as batch input to CA Top Secret.

Note: For more information about executing CA Top Secret commands inbatch, see the CA Top Secret Command Function Guide (for z/OS).


Chapter 5. Implementing Security withCA ACF2


Define CA 7 to CA ACF2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Define CA 7 As a Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Define CA 7 Command Security . . . . . . . . . . . . . . . . . . . . . . . . . 80Secure the /MVS Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Define ICOM to CA ACF2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Define SUBMIT Resource Rules . . . . . . . . . . . . . . . . . . . . . . . . . 85Calendar Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Job Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88UID Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Program Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98External Communicators with CA ACF2 . . . . . . . . . . . . . . . . . . . . . 99Sample Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

This chapter describes the steps necessary to implement the CA 7 ExternalSecurity Interface with CA ACF2. A working knowledge of the security structurefor CA ACF2 and its associated command syntax is required. All of the CAACF2 commands shown in this chapter must be executed under CA ACF2.


Chapter 5. Implementing Security with CA ACF2 75

Define CA 7 to CA ACF2


CA 7 requires a LOGONID defined to CA ACF2 to establish access authority todata sets and to allow for job submission. The LOGONID must be defined as astarted task using the procedure name that invokes CA 7. Because multipleusers can be logged on to CA 7 at the same time, it is referred to as aMUSASS - Multi-User Single Address Space Subsystem and requires theMUSASS attribute when defining the LOGONID.

CA 7 also requires the authorization to submit jobs. This can be accomplishedby adding the JOBFROM privilege to the CA 7 LOGONID. This exempts CA 7Submit Validation and provides uninterrupted production scheduling. The CAACF2 command example shown below can be used to define the CA 7LOGONID to CA ACF2.

Note: This command must be entered under CA ACF2. You may use online orbatch CA ACF2 processing to define the CA 7 LOGONID.



The following is an example CA ACF2 command used to define the CA 7LOGONID:

INSERT CA7 NAME(CA 7 Production ID) STC MUSASS DUMPAUTH JOBFROM

INSERTSpecifies the CA ACF2 command used to add a LOGONID to the CA ACF2database.

CA7Specifies the name chosen in this example for the CA 7 LOGONID.

NAMEIndicates a comment field used to describe the LOGONID being added.

STCIdentifies the CA 7 LOGONID as a started task ID.

MUSASSDefines the CA 7 LOGONID as a Multi-User Single Address SpaceSubsystem.

DUMPAUTHPermits the CA 7 LOGONID to generate complete dumps of its addressspace in the event of an abend.

JOBFROMAllows CA 7 to use the JOBFROM statement for USERID insertion at jobsubmission time.

Note: If you already have a started task LOGONID with similar privileges andattributes, you may use the INSERT USING command option when defining theCA 7 LOGONID. For a complete description of the USING command optionand the additional privileges and attributes shown in this example, see the CAACF2 Administrator Guide (for z/OS).


Define CA 7 As a Resource


You can define CA 7 to CA ACF2 as a resource to control LOGON access.The resource definition for CA 7 under CA ACF2 is not required; however, itdoes provide an additional level of security for restricting access to CA 7. IfLOGON security for CA 7 is to be controlled through CA ACF2, a resourcecheck is to be made during LOGON to determine whether the user isauthorized to access CA 7.

The steps required to implement the application resource checking for LOGONsto CA 7 are as follows:

1. Define a Resource Rule under CA ACF2 identifying CA 7 as a resource. Ifyou are using CA ACF2 6.0 or higher, you should define a CLASMAP forAPPL:

CLASMAP.CA7 RESOURCE(APPL) RSRCTYPE(APP)

2. Compile and store the resource rule under CA ACF2.

3. Add the APPL= keyword to the SECURITY statement in the CA 7initialization file and specify the resource name.

4. Add the LOGON keyword to the EXTERNAL= parameter list on theSECURITY statement in the CA 7 initialization file.

The following is an example CA ACF2 application resource rule for CA 7:

$KEY(CA7) TYPE(APP) �.........allow access comment statement

UID(local UID string) ALLOW �.........disallow access comment statement

UID(local UID string) PREVENT �

$KEY(CA7)Specifies the CA ACF2 keyword used to name the resource to beprotected. CA7 is the name used in this example and must match theAPPL= value on the SECURITY statement.

TYPEIdentifies the type of resource rule. (APP = Application resource type)



UIDIdentifies the UID string of users to be allowed or prevented from accessingthis resource.

ALLOWSpecifies the CA ACF2 keyword used to grant access to a resource.

PREVENTSpecifies the CA ACF2 keyword used to deny access to a resource.

Note: The Application Resource rule does not take effect until the rule iscompiled and stored under CA ACF2. For more information about compilingand storing rules, see the CA ACF2 Administrator Guide (for z/OS).




Implementation of CA 7 command security includes securing top linecommands, application panel access and panel functions. Each CA 7 panelhas a unique panel-ID that can be defined as a resource to CA ACF2. Forsubsequent functions on each panel, which may involve multiple access types(READ, ADD, UPDATE, and DELETE), a service level can be specified on theresource rule to provide an additional level of protection.

For example, a user enters the DB top line command to access the DatabaseMaintenance Menu. CA 7 first checks the user's authority to access theDatabase Maintenance Menu (panel-ID = L2DB). If the user has theauthorization, the panel is displayed. The user now selects option 1 - JobDefinition from the Database Maintenance Menu. This equates to a panel-ID ofL2DB1. If the user has the appropriate authority, the panel is displayed. Theuser now enters the LIST option from the Job Definition panel to list JOBA. Thisrequires a service level of READ on panel L2DB1 to perform the LISTcommand. If the user has the required authorization, JOBA is listed. The usernow attempts the UPD option to update JOBA on the CA 7 database. Thisrequires a service level of UPDATE for panel L2DB1 to perform the update. Ifthe user has the proper authority, the job is updated.

Remember that protection is provided not only for panels within CA 7 but forthe additional functions on each panel. Each command requires a service levelentry on the resource rule definition to perform that function. For a list of theCA 7 panel-IDs, commands, and access level requirements, see theAppendix A, “Security Tables” on page 169.

Resource Rule Masking

CA ACF2 provides the ability to "mask" resource names to simplify thespecification of access rules for a group of users. To mask a resource rule, youmust enter asterisks for each level of access you want to generically specify forusers.

For example, to allow users access to all panels within the CA 7 DatabaseMaintenance Application, you could define the resource key name as L2DB****.The asterisks mask the panel-IDs to L2DBxxxx that would include any panel-IDthat has a DB prefix. This does not authorize the users to perform all functionsfrom each panel for Database Maintenance. Authority for each function must bespecified by a service level on the resource rule.

Note: CA ACF2 requires the use of Resident Directories to use Resource Rulemasking. Resident Directories may also be required for other CA ACF2 options.For a discussion of Resource Rule Resident Directories, see the CA ACF2Administrator Guide (for z/OS).



The following is an example CA 7 panel resource rule:

$KEY(L2DB1) TYPE(PAN) �

UID(Local UID string) SERVICE(READ,ADD,UPDATE,DELETE) ALLOW �� The above rule allows users with matching UID strings to� access the Database Maintenance - Job Definition� panel (L2DB1) with full function authority.

�UID(Local UID string) SERVICE(READ) ALLOW

�� The above rule allows users with matching UID strings to� access the Database Maintenance - Job Definition panel� (L2DB1) with READ access authority only.

�UID(Local UID string) PREVENT

�� The above rule prevents access to the Database Maintenance -� Job Definition panel (L2DB1) for users with a matching UID

� string.

$KEY(L2DB1)Identifies the Database Maintenance - Job Definition panel. The L2preceding the DB1 is the CA 7 product code and is required.

TYPE(PAN)Identifies the type of resource rule. If you have specified a resource typeother than PANEL (see the SECURITY statement PCLASS keyword),substitute the CA ACF2 SAFDEF assigned to this resource type for PAN.

UIDIdentifies the UID string of users for which this resource rule applies.

ALLOWAllows users with a matching UID string access to the indicated resource.

PREVENTPrevents users with a matching UID string access to the indicated resource.

SERVICESpecifies authority for service level access to functions on each panel.Access to a panel does not grant full access to the functions contained onthat panel. The valid service levels are READ, ADD, UPDATE, andDELETE.

Note: All CA 7 panel and command resource rules under CA ACF2 require aresource type of PAN.



The following is an example CA 7 "masked" panel resource rule:

� $KEY(L2DB��) TYPE(PAN) �

UID(Local UID string) SERVICE(READ) ALLOW �� The rule above uses Resource Rule "masking." The Resource name� has been "masked" using asterisks. This rule would allow any users� with a matching UID string access to all CA 7 Database Maintenance� panels with a service level of READ.

�

$KEY(L2DB****)Identifies any CA 7 Database Maintenance panel by using Resource Rulemasking. The asterisks mask the last four characters of the resource nameallowing access to any panel with a prefix of L2DB.

TYPE(PAN)Identifies the UID string of users for which this resource applies.

SERVICE(READ)Identifies the level of access to this resource.

ALLOWSpecifies the CA ACF2 keyword used to grant access to this resource.

Note: CA ACF2 requires the use of Resident Directories to use Resource Rulemasking. Other CA ACF2 options may also require Resident Directories. For adiscussion of Resource Rule Resident Directories, see the CA ACF2Administrator Guide (for z/OS).





The /MVS command text is sent to MVS using SVC 34. The LOGONID that isassociated with the CA 7 address space is the LOGONID in control when theSVC is issued.

CA 7 does not perform any special validation to verify the terminal user'sauthority for the MVS command attempted. If the user is allowed to issue the/MVS command, the specified command text will be sent to MVS.



Define ICOM to CA ACF2

Define ICOM to CA ACF2

The CA 7 Independent Communications Manager (ICOM) must also be definedto CA ACF2. ICOM is responsible for handling SMF data for jobs submittedthrough CA 7, and therefore requires an ACID to execute in an CA ACF2secured environment. The following command example can be used to defineCA 7 ICOM to CA ACF2.


INSERT CA7ICOM NAME(CA 7 Production ID) STC DUMPAUTH JOBFROM

INSERTSpecifies the CA ACF2 command used to add a LOGONID to the CA ACF2database.

CA7ICOMSpecifies the name chosen in this example for the CA 7 LOGONID.

NAMEIndicates a comment field used to describe the LOGONID being added.

STCIdentifies the CA 7 LOGONID as a started task ID.

DUMPAUTHPermits the CA 7 LOGONID to generate complete dumps of its addressspace in the event of an abend.

JOBFROMAllows CA 7 to use the JOBFROM statement for USERID insertion at jobsubmission time.


Define SUBMIT Resource Rules


To prevent unauthorized access to LOGONIDs under CA 7, you can defineSUBMIT resource rules to CA ACF2 to restrict the ability of users to accessLOGONIDs other than their own. Generally LOGONIDs that are associated witha given user have established access authority that restricts their access tospecific areas of responsibility. The following CA ACF2 commands can be usedto define a SUBMIT resource rule under CA ACF2 for a LOGONID to be usedunder CA 7. The following is an example CA 7 SUBMIT resource rule:

$KEY(CA7USER) TYPE(SUB) �

UID(Local UID string) ALLOW � � The above rule allows users with matching UID strings access � to the LOGONID CA7USER. �

UID(Local UID string) PREVENT � � The above rule disallows users with matching UID strings access � to the LOGONID CA7USER. �

$KEY(CA7USER)Identifies the LOGONID, used in this example, for which this SUBMITresource rule applies.

TYPE(SUB)Identifies the resource rule type. In this case SUB for SUBMIT.

UIDIdentifies the UID string for which this resource rule applies.



This example illustrates giving SUBMIT authority from one USERID to another.

� $KEY(USERID2) TYPE(SUB) �

UID(Local UID string) SERVICE(READ) ALLOW � �

$KEY(USERID2)Identifies the USERID for which the local UID string has submit authority.

TYPE(SUB)Identifies as submit authority.

UIDSTRINGIdentifies the UID string of users for which this resource applies.

SERVICE(READ)Identifies the level of access to this resource.

ALLOWSpecifies the CA ACF2 keyword used to grant access to this resource.


Calendar Security

Calendar Security

To protect access to the CA 7 calendars, use the CALENDAR option in theEXTERNAL keyword values on the SECURITY statement in the CA 7initialization file.

The resource name of CALENDAR will need to be set up. The only servicelevel checked is READ.

An example of CLASMAP follows:

CLASMAP.CA7 RESOURCE(CALENDAR) RSRCTYPE(CAL)

The following is an example of setting up a rule to access a calendar:

$KEY(calendar-name or mask) TYPE(CAL) UID(uid-mask) ALLOW SERVICE(READ)


Job Submission

Job Submission



Job OwnerSpecifies a USERID in the OWNER field for a job on the job definitionpanel. (SUBUID value of OWNER)


RequesterSpecifies the USERID of the user that requests a job through the DEMAND,LOAD, or RUN commands. (SUBUID value of REQ)


CA-7Specifies the USERID assigned to CA 7 at startup. If requested the CA 7ID is propagated to submitted jobs. If started task checking is activated, thisoption should not be used. (SUBUID value of CA7)


At submission time, CA 7 scans the USERID hierarchy to determine whether aUSERID is available from the first hierarchy entry. If an ID is found, it isinserted into the job's JCL and the job is submitted, assuming all otherrequirements have been met. If an ID was not found, the next source entry ischecked for an available ID.


Job Submission

This process continues until an ID is found and inserted into the JCL. If allpotential sources have been checked and a USERID is not available, CA 7checks the status of the SUBNOID flag. The SUBNOID flag is set by theSUBNOID keyword specified on the SECURITY statement in the CA 7initialization file. If SUBNOID=YES, a job may be submitted without a USERID.If SUBNOID=NO, jobs may not be submitted without a valid USERID and aremoved back to the request queue with a requirement status of R-NOUID. TheR-NOUID status indicates that all USERID sources were checked and no validUSERID was found for JCL insertion.



■ If you have specified the QJCL keyword on the SUBUID parameter, you canFETCH/EDIT the job's queued JCL and immediately do a SAVE/REPLACE.CA 7 saves the USERID of the user editing the queued JCL. This wouldsatisfy the R-NOUID requirement because an ID is now available from oneof the candidate USERID sources and the job is now eligible forsubmission.

■ The second method is to manually add a USERID to the job's queued JCL.CA 7 recognizes the addition of the USERID to the JCL and the R-NOUIDrequirement would be satisfied.


You may not manually satisfy or POST an R-NOUID requirement. If you try tosatisfy the requirement by any method other than those listed previously, therequest is ignored.


Job Submission

USERID Propagation


■ The USERID of a user requesting work through the DEMAND, LOAD orRUN commands.




JCL USERID Format

For USERID insertion, CA 7 inserts a JOBFROM statement or a LOGONIDstatement immediately following the JOB statement. The ACF2CARD keywordon the SECURITY statement can control the type of statement used.(JOBFROM is the default.) The following example illustrates the JOBFROM andLOGONID JCL statement formats used during ID insertion for CA ACF2.

//�JOBFROM useridor //�LOGONID userid


UID Resources

UID Resources

Access to information about the CA 7 database is controlled through UIDsecurity validation. When a user attempts to access a job on the database,regardless of whether internal or external security is in control, the user's UIDvalue is checked against the UID value associated with the job. This providesjob-level security for the CA 7 database. External security does not provide anequivalent JOB level protection; therefore, it is important that each CA 7 userbe assigned a UID that relates to the user's area of responsibility.


The UID value (0-255) can be obtained from the USERID entry in the CA 7internal security module, through UID resource validation during logons to CA 7or through the /UID top line command issued under a CA 7 session. If youwant to maintain USERIDs in the CA 7 internal security module, seeChapter 7, “Internal Security” for information about defining USERIDs in theinternal security module. The following information outlines the steps necessaryto implement UID resource validation and describes the security processinginvolved.

UID resource security requires a UID Resource Table that CA 7 referencesduring UID resource validation. This table contains resource names andassociated UID value entries to be used during the UID validation process. Asample resource table, SASSRTBL, is provided in both source and load moduleformat and may be used to implement UID resource security. To create a sitespecific UID Resource Table with unique resource names and UID values, usethe CA7RTBL macro to generate the table.

Note: The default resource class for UID resources is PAN. You may changethe resource class for calls to external security using the RCLASS= parameteron the CA 7 initialization file SECURITY statement.

You may use the /PROF command to establish and maintain a default UIDresource for users logging on to CA 7. For a description of the /PROFcommand, see the Command Reference Guide.



UID Resources

CA7RTBL Macro

The CA7RTBL macro is used to generate the UID Resource Table. For moreinformation about the macro's required paramaters, see the followingdescriptions. Once the new source has been created, see member UL2B109 inthe CA 7 SAMPJCL file for applying the USERMOD.

The following is an example of the CA7RTBL macro statement:


CA7RTBLThis is the UID Resource Table generation macro. It is used to build theUID Resource Table.

RSRCThe resource name to be generated in this entry of the table. The resourcename can be a 1- to 8-character name that meets site specific externalsecurity resource naming conventions.

Note: Resource names must not conflict with existing panel or commandnames if the default PANEL resource class is used. For more information,see the description of the RCLASS keyword in the chapter "SECURITYStatement."

UIDThe value that will be associated with the resource name supplied on theRSRC= parameter. The value can be from 0 to 255.


UID Resources

Usage Notes






■ The UID Resource Table name must be identified on the CA 7 initializationfile SECURITY statement using the UID= parameter. For a discussion ofthe SECURITY statement and its associated parameters, see “SECURITYStatement” on page 26.






UID Resources


When a user signs on to CA 7, the user can optionally supply a UID resourcename in the UID RESOURCE field on the CA 7 Logon panel. If no UIDresource name is supplied, a check is made to see whether one is defined inthe user's CA 7 profile record. If present, the profile resource name is used asif it were entered on the Logon panel. The USERID and PASSWORD suppliedare first validated through external security and then a lookup is performed todetermine whether the user is defined in the CA 7 Internal Security module.







UID Resources

CA-7 Logon Panel: The following is a sample CA 7 Logon panel:


PLEASE ENTER LOGON DATA OR PRESS PF3 TO DISCONNECT



� �




- UID Resource =>


� �

Enter the END command to terminate CA-7 TSO-ISPF.


UID Resources

/UID Command







UID Resources

/REFRESH Command

The /REFRESH command is used to refresh the UID Resource Table that wasloaded during CA 7 initialization without cycling CA 7. The definitions codedwithin the specified module will completely replace the definitions currentlybeing used. However, any changes made in the actual CA ACF2 definitions(using CA ACF2 commands) may not take effect until CA 7 is recycled.




xxxxxxxxThis must be the member name of the UID Resource Table, and it mustreside in a load library accessible to CA 7.


Program Protection

Program Protection

The following topics discuss program protection for CA 7 and batch users.

CA 7 Requirements

CA 7 requires access to numerous programs for execution during productionprocessing. Due to the number of modules involved, a program prefix of SASScan be used when authorizing CA 7 program access. CA 7 also needs accessto the main driver module UCC7.

Batch Users









External Communicators with CA ACF2


The external communicators (SASSBSTR, SASSTRLR, U7SVC, CAL2X2W0,and SASSBCLP) provide a means for users outside the CA 7 address space tocommunicate with CA 7. Because the use of these programs may allow accessto production jobs, we recommend that careful consideration be given to thequestion of access to these facilities. Users of the Batch Terminal Interfacerequire access to the program SASSBSTR. Users of the Trailer step, the BatchCard Load Program, and U7SVC must be given access to SASSTRLR,SASSBCLP, and U7SVC respectively. Once the question of program access issettled, additional controls may be implemented to prevent unauthorized use ofthese facilities. This topic describes those controls.


Two types of communication with CA 7 are supported with the externalcommunicators:






The Batch Terminal Interface (SASSBSTR), the Trailer facility (SASSTRLR), theCA 7 CAICCI Interface (CAL2X2W0), and U7SVC each allow the user to sendterminal commands to CA 7. Although no online terminal is used with thismode of communication, input from these programs is treated as terminal inputby CA 7. Command security in these environments is handled as it is for allCA 7 terminals. CA ACF2 will control access to CA 7 commands ifEXTERNAL=COMMAND is specified on the SECURITY statement in the CA 7initialization file. CA ACF2 will determine a user's access to CA 7 terminalcommands based on the LOGONID supplied on the /LOGON command. Thus,when using an External Communicator, any command input must be precededby a CA 7 /LOGON command.

CA ACF2 normally requires a password at logon. But including passwords incommand input for the External Communicators would obviously represent aserious security exposure. Several checks may be made to avoid the need toinclude passwords in command input when using these facilities. If no /LOGONcommand is found in the command input, a /LOGON statement is built usingthe LOGONID associated with the current user. Under certain conditions it maynot be possible to extract the LOGONID associated with the user of theExternal Communicator. In that event, a /LOGON statement is built using adefault LOGONID of CA7DUMMY. If a /LOGON statement is found in thecommand input then the current user's authority to use the LOGONID found onthe /LOGON statement may be checked. If the LOGONID found on the/LOGON statement matches the LOGONID of the current user then it isassumed that the user has the authority to use the LOGONID. If theLOGONIDs differ then a check may be made to validate the user's READaccess to a resource whose name is the LOGONID found on the /LOGONstatement. The generalized resource type is SUB. Rules for this resourceshould be written to reflect the security needs of your installation. If a /LOGONstatement was generated or if the user's authority to use a LOGONID wassuccessfully validated then CA 7 allows the user to LOGON without apassword.

Note: The USERID of the current user is determined by using CAS9 SSFservices. For more information about SSF, see the CA Common Servicesdocumentation. Submit checking for External Communicators is controlled bythe value of BSUBCHK that is set by CAIRIM. For more information, see thechapter "Execution" in the Systems Programmer Guide.





A security EXTRACT is done to determine the LOGONID of the submitted job.This LOGONID is later used to generate a full logon statement or optionallyperform a submit check. The input stream is then read to determine whether alogon statement was supplied. If no logon statement was supplied or if a logonstatement was supplied without an OPID, one is generated for the execution.The logon statement resembles the following:




If the OPID is not the same as the EXTRACTed ID, other checks are done. Acheck is made to see whether the value of BSUBCHK for this instance is Y. Ifso, a submit check is performed. The check is done to see whether theEXTRACTed ID has the authority to submit on behalf of the OPID in the logonstatement. If the check is okay, the logon statement is passed to CA 7indicating that no password is needed with this particular logon attempt.

If the value of BSUBCHK is not Y, no submit checks are done. The logonstatement is passed as it is coded with no special indication to CA 7. If CA 7has EXTERNAL=LOGON coded in the initialization file, a logon check isperformed trying to supply a password. If the password was entered on thelogon statement, it is validated by the external security package. If no passwordwas coded, the logon fails due to a missing password.



In general, there are only two times a password is needed:





The following information is intended to show the actions that are performed bySASSBSTR and CAL2X2W0 during execution with relation to security.

A security EXTRACT is done to determine the LOGONID of the submitted job.or user environment. This LOGONID is later used to generate a full logonstatement or optionally perform a submit check. The input stream is then readto determine whether a logon statement was supplied. If no logon statementwas supplied, then one is generated for the execution. The logon statementresembles the following:







If the value of BSUBCHK for the instance is not Y, no submit checks are done.The logon statement is passed as it is coded with no special indication to CA 7.If CA 7 has EXTERNAL=LOGON coded in the initialization file, a logon checkis performed trying to supply a password. If the password was entered on thelogon statement, it is validated by the external security package. If no passwordwas coded, the logon fails due to a missing password.






The following information is intended to show the actions that are performed byU7SVC during execution with relation to security. There are two different pathsthat can be taken. It depends on whether there is an input stream with theU7SVC or if it is just a D= to post a data set.

U7SVC with D= PARM

A security EXTRACT is done to determine the LOGONID that invoked U7SVC.This LOGONID is later used to generate a full logon statement or optionallyperform a data set create check.

If the value of SVDSNCHK for the instance is not Y, the D= command ispassed through to CA 7 with no further security checking to be done byU7SVC.

If the value of SVDSNCHK is Y, a security call is made by U7SVC. This calldetermines if the EXTRACTed ID has CREATE authorization for the data setspecified on the D=. If the EXTRACTed ID does have authorization, the D=command is passed to CA 7 for processing.




A security EXTRACT is done to determine the LOGONID that invoked U7SVC.This LOGONID is later used to generate a full logon statement or optionallyperform a submit check. The input stream is then read to determine whether alogon statement was supplied. If no logon statement was supplied or if a logonstatement was supplied without an OPID, one is generated for the execution.The logon statement resembles the following:












Data Set Posting

The Batch Card Load Program (SASSBCLP) and U7SVC allow the user to postthe creation of a data set to CA 7. Because such posting may satisfyrequirements or cause job triggering, the need to secure the use of thesefacilities is critical. There are two features of these facilities that should bementioned in this connection: data set access validation and LOGONIDpropagation.

The LOGONID associated with the user of U7SVC or SASSBCLP is extractedto determine the user's authority to create the data set. Under certain conditionsit may not be possible to extract the LOGONID for the user of the ExternalCommunicator. In that event, a default LOGONID of CA7DUMMY is used.

If REQ is specified in the SUBUID hierarchy on the SECURITY statement in theCA 7 initialization file, the LOGONID associated with the data set creation maybe propagated to triggered jobs.

For example, suppose that a user whose LOGONID is XXX submits a batch jobthat uses U7SVC to post the creation of data set A.B to CA 7. Suppose alsothat the creation of this data set triggers job Z. Further suppose that REQ is inthe first position in the SUBUID hierarchy. In such a case, LOGONID XXXcould be propagated to job Z when the job is submitted.

Note: Each of the External Communicators attempts to extract the USERID ofthe current user, SASSBCLP and U7SVC may be made to verify the authorityof the user to create that data set whose creation is to be posted to CA 7. Formore information about the CAIRIM keywords that control this USERIDverification, see the chapter "Execution" in the Systems Programmer Guide.


Sample Definitions

Sample Definitions

The member ACF2SAMP in the CA 7 Sample JCL file (SAMPJCL) on theinstallation media contains sample CA ACF2 commands that can be used tosecure the CA 7 processing environment under CA ACF2. The definitions areintended as examples only and should be reviewed and modified to meet yourinstallations security requirements. Once tailored to your site's specifications,the definitions may be used as batch input to CA ACF2.

Note: For more information about executing CA ACF2 commands in batch,see the CA ACF2 Administrator Guide (for z/OS).


Chapter 6. Implementing Security withIBM RACF


Define Security to RACF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108RACF Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Define the CA 7 Started Task to RACF . . . . . . . . . . . . . . . . . . . . 113Define CA 7 ICOM to RACF . . . . . . . . . . . . . . . . . . . . . . . . . . 114CA 7 and CA 7 ICOM Data Set Access Requirements . . . . . . . . . . . 115Define the CA 7 Application Resource Profile . . . . . . . . . . . . . . . . 116Define CA 7 Command and Panel Security to RACF . . . . . . . . . . . . 118Secure the /MVS Command . . . . . . . . . . . . . . . . . . . . . . . . . . 120Control Job Submission Under RACF . . . . . . . . . . . . . . . . . . . . . 121Surrogate Usage for Job Submission Under RACF . . . . . . . . . . . . . 123Job Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124UID Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127/UID Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132/REFRESH Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Program Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Group Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135External Communicators with IBM-RACF . . . . . . . . . . . . . . . . . . . 136Sample Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

This chapter describes the steps necessary to implement the CA 7 ExternalSecurity Interface with IBM RACF. A working knowledge of the securitystructure for RACF and its associated command syntax is required. All of theexample RACF commands shown in this chapter must be executed underRACF.


Chapter 6. Implementing Security with IBM RACF 107

Define Security to RACF

Define Security to RACF

To secure the CA 7 processing environment under RACF, the following stepsmust be taken.

■ Modify the RACF Resource Descriptor Table to include the resourceclasses required by CA 7.

■ Modify the RACF Router Table to identify processing options for the newresource classes.

■ Modify the Started Procedures Table to add the CA 7 and CA 7 ICOMstarted task names.

■ Add user profiles for CA 7 and CA 7 ICOM to RACF.

■ Define the data set security access requirements for CA 7 and CA 7 ICOM.

■ Optionally, define CA 7 as an application resource to be protected byRACF.

■ Modify the CA 7 initialization file to specify the security functions to becontrolled by RACF.

■ Define CA 7 command and panel security access for users to RACF.

■ Identify USERID requirements for jobs being submitted by CA 7.


RACF Requirements

RACF Requirements

The following topics explain the requirements for security using the RACFproduct.

System Requirements

Following are the system requirements for RACF:

■ RACF must be at release level supported by IBM.

■ To use the CA 7 External Security Interface with RACF, the CA StandardSecurity Facility (CAISSF) is required. CAISSF is a subcomponent of theCAIRIM services.

Resource Class Descriptor Table - ICHRRCDE

The Resource Class Descriptor Table is used to identify the general resourceclasses to be protected by RACF. CA 7 currently requires two resource classesfor implementation of the CA 7 External Security Interface with RACF. The IBMmacro ICHERCDE is used to define the resource classes to the ResourceClass Descriptor Table.

Note: For more information about updating the Class Descriptor Table, seethe IBM manual Security Server RACF System Programmer's Guide.


RACF Requirements

ICHERCDE

ICHERCDE, the IBM supplied Class Descriptor macro, located inSYS1.MACLIB, is used to define installation required resource classes underRACF. Once updated, the source is assembled and link edited as moduleICHRRCDE and resides in SYS1.LINKLIB. This module can reside in anylinklisted library, however, ensure that a copy of this module does not exist in alibrary anywhere above the new module in the linklist libraries concatenation.

Note: For more information about the ICHRRCDE module and the ICHERCDEmacro parameters, see the IBM manual Security Server RACF SystemProgrammer's Guide.

The following entries must be added to the table for CA 7.

The resource classes required by CA 7 are PA@EL and SU@MIT. See thefollowing example:

PA@EL ICHERCDE CLASS=PA@EL, +ID=xxx, available resource number +

MAXLNTH=8, + FIRST=ALPHANUM, + OTHER=ANY, +

POSIT=xx, bit position in bitstring + OPER=NO, + RACLIST=ALLOWED, + GENLIST=ALLOWEDSU@MIT ICHERCDE CLASS=SU@MIT, +

ID=xxx, available resource number + MAXLNTH=8, + FIRST=ALPHANUM, + OTHER=ANY, +

POSIT=xx, bit position in bitstring + OPER=NO, + RACLIST=ALLOWED, + GENLIST=ALLOWED ICHERCDE

Note: The last entry must be the ICHERCDE macro with no parameters.

The resource class of CA@ENDAR is needed if the CALENDAR option isspecified in the EXTERNAL keyword of the SECURITY statement in the CA 7initialization file. Also, if the RCLASS keyword is used, the specified valueneeds to be included here as a resource class. The CAS9SAFC moduleprobably needs updating to include these classes.

For information about customizing this module, see the CA Common Servicesfor z/OS Getting Started.


RACF Requirements

RACF Router Table

The RACF Router Table provides a means to associate installation resourceclass authorization calls with RACF functions. The resource classes added tothe Class Descriptor Table must also be added to the RACF Router Table tospecify security processing requirements for the resource classes.

Note: For more information about implementing or modifying the RACF RouterTable, see the IBM manual Security Server RACF System Programmer's Guide.

You must add the following entries to the Router Table to implement the CA 7External Security Interface with RACF. Add the entries using the IBMICHRFR01 macro. This module must reside in a linklist library.

PA@EL ICHRFTRB CLASS=PA@EL,ACTION=RACF SU@MIT ICHRFTRB CLASS=SU@MIT,ACTION=RACF

PA@EL and SU@MITSpecifies the label field that identifies the resource class.

ICHRFTRBIdentifies the IBM RACF Router Table macro.

CLASS=PA@ELIdentifies a resource class of PA@EL.

CLASS=SU@MITIdentifies a resource class of SU@MIT.

ACTION=RACFSpecifies the action to be taken for this resource class.

Note: The @ is required in the resource class name.

Activate the New Resource Classes

To activate the resource classes under RACF, issue the following command:

SETROPTS CLASSACT(PA@EL,SU@MIT)


RACF Requirements

Started Procedures Table - ICHRIN03

Started tasks have system generated JOB statements and do not haveassociated USER, GROUP, or password parameters. RACF requires a user orgroup ID to specifically authorize access to resources. The Started ProceduresTable for RACF allows installations to associate a USERID with a started taskthat can then be used to specify authorization access.

See the following example:

ICHRIN�3 CSECTTITLE 'ICHRIN�3 - STARTED PROCEDURES TABLE'

EJECTDC XL2'8��3' NEW FORMAT - �3 ENTRIES

�DC CL8'CA7ONL ' PROCNAME - CA 7 PRODUCTION ID

DC CL8'CA7ONL ' USERIDDC CL8' ' GROUP - NULLDC XL1'��' NOT PRIVILEGED OR TRUSTED

DC XL7'��' RESERVED� DC CL8'CA7ICOM ' PROCNAME DC CL8'CA7ICOM ' USERID DC CL8' ' GROUP

DC XL1'��' NOT PRIVILEGED OR TRUSTED DC XL7'��' RESERVED� DC CL8'� ' PROCNAME DC CL8'= ' USERID DC CL8' ' GROUP

DC XL1'��' NOT PRIVILEGED OR TRUSTED DC XL7'��' RESERVED� END

This table must reside in the link pack area (LPA). The last entry shown is ageneric entry that RACF uses if the specific started task name is not found inthe table. The equal sign states that the started task name is used as theUSERID for any entry that does not match an entry in the table.

Note: For more information about the Started Procedures Table, see the IBMmanual Security Server RACF System Programmer's Guide.

Security for the CA 7 and CA 7 ICOM started task does not take effect untilthe USERIDs are defined to RACF.


Define the CA 7 Started Task to RACF

Define the CA 7 Started Task to RACF

The ADDUSER command is used under RACF to define a new user and toassociate that user with an existing RACF defined group.


ADDUSER CA7ONL NAME('CA 7 ONLINE') OWNER(CA7GROUP) PASSWORD(CA7ONL)

ADDUSERIdentifies the RACF command used to define a new user to RACF.

CA7ONLIdentifies the name chosen in this example for the CA 7 USERID that isassociated with the CA 7 started task.

NAME('CA 7 ONLINE')Identifies the RACF parameter used to describe the USERID.

OWNER(CA7GROUP)Identifies the predefined owning group for the CA 7 USERID profile. Thegroup or USERID used in the OWNER parameter must already be definedto RACF.

PASSWORDIdentifies the password chosen in this example for the CA 7 USERID. Thisprovides an additional level of security for the CA 7 started task ID. If nopassword is specified, the password defaults to the owning group name thatmay be available to unauthorized personnel.


Define CA 7 ICOM to RACF

Define CA 7 ICOM to RACF

The CA 7 ICOM, Independent Communications Manager, which manages SMFtracking data for CA 7 must also be defined to RACF.

The following example can be used to add the CA 7 ICOM USERID to RACF:

ADDUSER CA7ICOM NAME('CA 7 ICOM') OWNER(CA7GROUP) PASSWORD(CA7ICOM)

ADDUSERIdentifies the RACF command used to define a new user to RACF.

CA7ICOMIdentifies the name chosen for the CA 7 Independent CommunicationsManager (ICOM) started task.

NAMEIdentifies the RACF keyword used to describe the user profile beingdefined.

OWNERIdentifies an existing RACF defined USERID or group that owns this userprofile.

PASSWORDIdentifies the RACF keyword used to specify a password for the USERIDbeing defined.

CA7ICOMIdentifies the password chosen for the CA7ICOM USERID. If apassword is not defined, the owning group name becomes thepassword by default.


CA 7 and CA 7 ICOM Data Set Access Requirements

CA 7 and CA 7 ICOM Data Set Access Requirements

CA 7 requires access to all of the CA 7 permanent data sets defined duringinstallation. CA 7 must also have full access to all JCL libraries that are definedin the CA 7 initialization file.

Note: For more information about the CA 7 permanent data sets and thedefinition of JCL libraries, see the Systems Programmer Guide.


Define the CA 7 Application Resource Profile


The CA 7 External Security Interface allows you to define CA 7 as anapplication resource to RACF. The application resource name can then bespecified on the SECURITY statement in the CA 7 initialization file. During theLOGON validation process, an additional check is made to determine whetherthe user has the authority to access the CA 7 application resource. This featureis optional; however, it allows for an additional level of security protection forCA 7.

This statement has the following format:

RDEFINE APPL CA7PROD DATA('CA 7 Security Application Resource') OWNER(CA7USERS) UACC(NONE)

RDEFINEIdentifies the command used to define resources to RACF.

APPLIdentifies the resource class name for application resources under RACF.

CA7PRODIdentifies the name chosen in this example for the CA 7 security applicationresource name.

DATADescribes the application resource entry.

OWNERIdentifies an existing RACF defined group that owns the resource.

UACCIdentifies a RACF keyword used to define the universal access for thisresource. In this case, NONE.



After defining the CA 7 security application resource to RACF, users must beauthorized to access the CA 7 APPL resource. This can be accomplished byusing the RACF PERMIT command.


PERMIT CA7PROD CLASS(APPL) ID(xxxxxxx)

PERMITIdentifies the RACF command used to grant access to resources.

CA7PRODIdentifies the name chosen in the previous example for the CA 7 securityapplication resource name.

CLASS(APPL)Identifies the resource class for that this command applies. (Application)

ID(xxxxxxx)Identifies the USERID you want to grant access to the CA 7 securityapplication resource.


Define CA 7 Command and Panel Security to RACF


Security for CA 7 commands and panels can be protected under RACF bydefining each panel and command as a resource. Besides restricting access totop line commands and panels, functions found on each panel can be protectedby specifying an access level for each panel. For a list of the CA 7 commands,panels, and a cross-reference of panel functions with their associated accesslevel requirements, see the Appendix A, “Security Tables” on page 169.

The following examples illustrate the use of the RACF RDEFINE and PERMITcommands to first define the CA 7 command or panel as a resource to RACFand then "permit" access to specific commands. The resource class is PA@ELfor both CA 7 commands and panels.

RDEFINE PA@EL (L2DB1) DATA('CA 7 Job Definition Panel') OWNER(CA7USERS) UACC(NONE)

RDEFINEIdentifies the RACF command used to define general resources.

PA@ELIdentifies the resource class type for CA 7 commands and panels. If youhave specified a resource type other than PANEL (see the SECURITYstatement PCLASS keyword), substitute its value for PA@EL. Also, forresource types other than PANEL, you must modify the CA CommonServices security exit CAS9SAFC.

(L2DB1)Identifies the resource name for the CA-7 Job Definition panel.

OWNER(CA7USERS)Identifies a predefined RACF user or group profile that owns this resource.

UACC(NONE)Identifies the universal access level for this resource. In this case, NONE.



This example grants access to the resource L2DB1 defined to RACF in theprevious example.

PERMIT L2DB1 CLASS(PA@EL) ID(xxxxxxx) ACCESS(READ,UPDATE)

PERMITIdentifies the RACF command used to grant access to a resource.

L2DB1Identifies the resource name for the CA-7 Job Definition panel.

CLASS(PA@EL)Identifies the resource class type.

ID(xxxxxxx)Identifies the USERID being granted access to the resource.

ACCESS(READ,UPDATE)Identifies the access level for functions found on the Job Definition panel.The user would have full access to functions that require READ andUPDATE authority.





The /MVS command text is sent to MVS using SVC 34. The USERID that isassociated with the CA 7 address space is the USERID in control when theSVC is issued.

CA 7 does not perform any special validation to verify the terminal user'sauthority for the MVS command attempted. If the user is allowed to issue the/MVS command, the specified command text will be sent to MVS.



Control Job Submission Under RACF


Depending on your security options, submit checking can be done by CA 7 tovalidate the authorization of a USERID to submit jobs for another USERID. The“SECURITY Statement” on page 26 describes the options available to performsubmit checking.

This example defines a submit (SU@MIT) resource that can be validated byCA 7.

RDEFINE SU@MIT (USERID1) DATA('userid1 submission class') OWNER(CA7USERS)UACC(NONE)

RDEFINEIdentifies the RACF command used to define general resources.

SU@MITIdentifies the resource class type for CA 7 submission checking.

(USERID1)Identifies the USERID that can be submitted by other user IDs.

DATADescribes the submission resource class.

OWNER(CA7USERS)Identifies a predefined RACF user or group profile that owns this resource.

UACC(NONE)Identifies the universal access level for this resource. In this case, NONE.



This example grants submit authority for USERID2 to submit for USERID1.

PERMIT USERID1 CLASS(SU@MIT) ID(USERID2)


USERID1Identifies the USERID that can be submitted by the ID USERID2 in thisexample.

CLASS(SU@MIT)Identifies the resource class type.

ID(USERID2)Identifies the USERID that is given submit authority for another ID.


Surrogate Usage for Job Submission Under RACF

Surrogate Usage for Job Submission Under RACF

Beginning with RACF 1.9, a surrogate designation can be assigned toUSERIDs. This designation allows one USERID to submit jobs on behalf ofanother USERID. If CA 7 will be submitting jobs that have USERIDs in the JCLthat are different from the CA 7 USERID, a surrogate designation may beneeded. This designation would allow CA 7 to submit those jobs with aUSERID that is not the same as the one CA 7 uses.

This allows CA 7 to submit jobs with various USERIDs, but this is different fromthe "Submit Checking" that is done by CA 7. CA 7 can check for submitauthority, but it is done using the SU@MIT class not the SURROGATe class.

Note: For more information about SURROGATe classes, see the IBM manualSecurity Server RACF Security Administrator's Guide.

This example grants surrogate authority for CA 7 to submit jobs for USERID1.

PERMIT CLASS(SURROGAT) USERID1.SUBMIT ID(CA7ONL) ACCESS(READ)


CLASS(SURROGAT)Identifies the resource class type.

USERID1.SUBMITIdentifies the USERID that can be submitted by the ID CA7ONL in thisexample.

ID(CA7ONL)Identifies the USERID that is given submit authority for another ID.

ACCESS(READ)Identifies the ACCESS level to be given.


Job Submission

Job Submission



Job OwnerSpecifies a USERID in the OWNER field for a job on the job definitionpanel. (SUBUID value of OWNER)


RequesterSpecifies the USERID of the user who requests a job through the DEMAND,LOAD, or RUN commands. (SUBUID value of REQ)


CA-7Specifies the USERID assigned to CA 7 at startup. If requested the CA 7ID is propagated to submitted jobs. (SUBUID value of CA7)


At submission time, CA 7 scans the USERID hierarchy to determine whether aUSERID is available from the first hierarchy entry. If an ID is found, it isinserted into the job's JCL and the job is submitted, assuming all otherrequirements have been met. If an ID was not found, the next source entry ischecked for an available ID.

This process continues until an ID is found and inserted into the JCL. If allpotential sources have been checked and a USERID is not available, CA 7checks the status of the SUBNOID flag. The SUBNOID flag is set by theSUBNOID keyword specified on the SECURITY statement in the CA 7initialization file. If SUBNOID=YES, a job can be submitted without a USERID. IfSUBNOID=NO, jobs cannot be submitted without a valid USERID and aremoved back to the request queue with a requirement status of R-NOUID. TheR-NOUID status indicates that all USERID sources were checked and no validUSERID was found for JCL insertion.


Job Submission

RACF USERID Format

For USERID insertion, CA 7 modifies the last statement of the JCL JOBstatement to add the USERID. A comma is added to the last statement toindicate continuation and is followed by a USER= statement to supply theUSERID. The following example illustrates the JCL statement format usedduring ID insertion.

// USER=userid

Note: The USERID password is inserted, if required, by RACF. This is anautomatic function related to Job Submission.

The SUBNOID parameter is used to specify whether a job can be submittedwithout a USERID. If SUBNOID equals YES, the job is submitted without aUSERID. If SUBNOID equals NO, the job is moved back to the request queuewith a status of R-NOUID.

The R-NOUID status indicates that all candidate USERID sources in thehierarchy were scanned without finding a USERID for the job and that theSUBNOID parameter requested that jobs not be submitted without a USERID.



■ The first method is to edit the job's queue JCL and add a USERID using theJCL USER= parameter. The added USERID is then recognized by CA 7 asan existing JCL USERID and thereby satisfies the R-NOUID requirement.

■ The second method requires that the QJCL parameter be specified in theSUBUID hierarchy. Edit the job's JCL and SAVE/REPLACE the JCL withoutactually making any modifications. Because the QJCL parameter wasspecified in the SUBUID hierarchy, CA 7 recognizes the queue JCL editoras a potential USERID source and retains the USERID of the user editingthe queue JCL. A USERID would now be available and therefore satisfy theR-NOUID requirement.


You cannot manually satisfy or POST an R-NOUID requirement. If you try tosatisfy the requirement by any method other than those listed previously, therequest is ignored.


Job Submission

USERID Propagation


■ The USERID of a user requesting work through the DEMAND, LOAD orRUN commands.





UID Resources

UID Resources

Access to information on the CA 7 database is controlled through UID securityvalidation. When a user attempts to access a job on the database, regardlessof whether internal or external security is in control, the user's UID value ischecked against the UID value associated with the job. This provides job-levelsecurity for the CA 7 database. External security does not provide anequivalent JOB level protection; therefore, it is important that each CA 7 userbe assigned a UID that relates to the user's area of responsibility.


The UID value (0-255) can be obtained from the USERID entry in the CA 7internal security module, through UID resource validation during logons to CA 7or through the /UID top line command issued under a CA 7 session. If youwant to maintain USERIDs in the CA 7 internal security module, seeChapter 7, “Internal Security” for more information about defining USERIDs inthe internal security module. The following information outlines the stepsnecessary to implement UID resource validation and describes the securityprocessing involved.

UID resource security requires a UID Resource Table that CA 7 referencesduring UID resource validation. This table contains resource names andassociated UID value entries to be used during the UID validation process. Asample resource table, SASSRTBL, is provided in both source and load moduleformat and can be used to implement UID resource security. To create a sitespecific UID Resource Table with unique resource names and UID values, usethe CA7RTBL macro to generate the table.

Note: The default resource class for UID resources is PA@EL. You canchange the resource class for calls to external security using the RCLASS=parameter on the CA 7 initialization file SECURITY statement.

You can use the /PROF command to establish and maintain a default UIDresource for users logging on to CA 7. For a description of the /PROFcommand, see the Command Reference Guide.



UID Resources

CA7RTBL Macro

The CA7RTBL macro is used to generate the UID Resource Table. For moreinformation, see the following descriptions about the macro's requiredparameters. Once the new source has been created, see member UL2B109 inthe CA 7 SAMPJCL file for applying the USERMOD.

The following is an example of the CA7RTBL macro statement.


CA7RTBLIdentifies the UID Resource Table generation macro. It is used to build theUID Resource Table.

RSRCIdentifies the resource name to be generated in this entry of the table. Theresource name can be a one- to eight-character name that meets sitespecific external security resource naming conventions.

Note: Resource names must not conflict with existing panel or commandnames if the default PANEL resource class is used. see the description ofthe RCLASS keyword in the chapter "SECURITY Statement."

UIDIdentifies the value that will be associated with the resource name suppliedon the RSRC= parameter. The value can be from 0 to 255.


UID Resources

Usage Notes






■ The UID Resource Table name must be identified on the CA 7 initializationfile SECURITY statement using the UID= parameter. For a discussion ofthe SECURITY statement and its associated parameters, see “SECURITYStatement” on page 26






UID Resources


When a user signs on to CA 7, the user can optionally supply a UID resourcename in the UID RESOURCE field on the CA 7 Logon panel. If no UIDresource name is supplied, a check is made to see if one is defined in theuser's CA 7 profile record. If present, the profile resource name is used as if itwere entered on the Logon panel. The USERID and PASSWORD supplied arefirst validated through external security and then a lookup is performed todetermine whether the user is defined in the CA 7 Internal Security module.







UID Resources

CA-7 Logon Panel: The following is a sample CA-7 Logon panel:


PLEASE ENTER LOGON DATA



� �




- UID Resource =>


� �

Enter the END command to terminate CA 7 TSO-ISPF.


/UID Command

/UID Command







/REFRESH Command

/REFRESH Command

The /REFRESH command is used to refresh the UID Resource Table that wasloaded during CA 7 initialization without cycling CA 7. The definitions codedwithin the specified module will completely replace the definitions currentlybeing used. However, any changes made in the actual RACF definitions (usingRACF commands) cannot take effect until CA 7 is recycled.




xxxxxxxxSpecifies the member name of the UID Resource Table, and it mustreside in a load library accessible to CA 7.


Program Protection

Program Protection

The following topics discuss program protection for CA 7 and batch users.

CA 7 Requirements

CA 7 requires access to numerous programs for execution during productionprocessing. Due to the number of modules involved, a program prefix of SASScan be used when authorizing CA 7 program access. CA 7 also needs accessto the main driver module UCC7.

Batch Users









Group Profiles

Group Profiles

RACF allows you to define Group Profiles that are used to organize securityaccess at a group level rather than by individual users. Although CA 7 does notsupport group identification at logon, you can structure your resourceauthorizations by group and then "connect" users to the specific Group Profiles.If you use multiple "connect groups" you must activate the List-of-Groupsauthorization checking feature in RACF. For more information about Grouplevel access, see the RACF Security Administrators Guide.


External Communicators with IBM-RACF


The External Communicators (SASSBSTR, SASSTRLR, U7SVC, CAL2X2W0,and SASSBCLP) provide a means for users outside the CA 7 address space tocommunicate with CA 7. Because the use of these programs can allow accessto production jobs, we recommend that careful consideration be given to thequestion of access to these facilities. Users of the Batch Terminal Interfacerequire access to the program SASSBSTR. Users of the Trailer step, the BatchCard Load Program, and U7SVC must be given access to SASSTRLR,SASSBCLP and U7SVC respectively. Once the question of program access issettled, additional controls can be implemented to prevent unauthorized use ofthese facilities. This section describes those controls.


Two types of communication with CA 7 are supported with the ExternalCommunicators:






The Batch Terminal Interface (SASSBSTR), the Trailer facility (SASSTRLR), theCA 7 CAICCI Interface (CAL2X2W0), and U7SVC each allow the user to sendterminal commands to CA 7. Although no online terminal is used with thismode of communication, input from these programs is treated as terminal inputby CA 7. Command security in these environments is handled as it is for allCA 7 terminals. IBM-RACF controls access to CA 7 commands ifEXTERNAL=COMMAND is specified on the SECURITY statement in the CA 7initialization file. IBM-RACF determines a user's access to CA 7 terminalcommands based on the USERID supplied on the /LOGON command. Thus,when using an External Communicator, any command input must be precededby a /LOGON command.

IBM-RACF normally requires a password at logon. But including passwords incommand input for the External Communicators would obviously represent aserious security exposure. Several checks can be made to avoid the need toinclude passwords in command input when using these facilities. If no /LOGONcommand is found in the command input, a /LOGON statement is built usingthe USERID associated with the current user. Under certain conditions it maynot be possible to extract the USERID associated with the user of the ExternalCommunicator. In that event, a /LOGON statement is built using a defaultUSERID of CA7DUMMY. If a /LOGON statement is found in the command inputthen the current user's authority to use the USERID found on the /LOGONstatement can be checked. If the USERID found on the /LOGON statementmatches the USERID of the current user then it is assumed that the user hasthe authority to use the USERID. If the USERIDs differ then a check can bemade to validate the user's READ access to an entity whose name is theUSERID found on the /LOGON statement. The resource class is [email protected] definitions for this resource should be created to reflect the securityneeds of your installation. If a /LOGON statement was generated or if the user'sauthority to use a USERID was successfully validated then CA 7 allows theuser to LOGON without a password.

Note: The USERID of the current user will be determined using CAS9 SSFservices. For more information about SSF, see the CA Common Servicesdocumentation.

Submit checking for External Communicators is controlled by the value ofBSUBCHK that is set by CAIRIM. For more information, see the chapter"Execution" in the Systems Programmer Guide.





A security EXTRACT is done to determine the user ID of the submitted job.This user ID is later used to generate a full logon statement or optionallyperform a submit check. The input stream is then read to determine whether alogon statement was supplied. If no logon statement was supplied or if a logonstatement was supplied without an OPID, one is generated for the execution.The logon statement resembles the following:




If the OPID is not the same as the EXTRACTed ID, other checks are done. Acheck is made to see whether the value of BSUBCHK for the instance is Y. Ifso, a submit check is performed. The check is done to see whether theEXTRACTed ID has the authority to submit on behalf of the OPID in the logonstatement. If the check is okay, the logon statement is passed to CA 7indicating that no password is needed with this particular logon attempt.









The following information describes the actions that SASSBSTR andCAL2X2W0 perform during execution related to security.

A security EXTRACT is done to determine the user ID of the submitted job oruser environment. This user ID is later used to generate a full logon statementor optionally perform a submit check. The input stream is then read todetermine whether a logon statement was supplied. If no logon statement wassupplied, one is generated for the execution. The logon statement resemblesthe following:







If the value BSUBCHK for the instance is not Y, no submit checks are done.The logon statement is passed as it is coded with no special indication to CA 7.If CA 7 has EXTERNAL=LOGON coded in the initialization file, a logon checkis performed trying to supply a password. If the password was entered on thelogon statement, it is validated by the external security package. If no passwordwas coded, the logon fails due to a missing password.








The following information is intended to show the actions that are performed byU7SVC during execution with relation to security. There are two different pathsthat can be taken. It depends on whether there is an input stream with theU7SVC or if it is just a D= to post a data set.

U7SVC with D= PARM

A security EXTRACT is done to determine the user ID that invoked U7SVC.This user ID is later used to generate a full logon statement or optionallyperform a data set create check.

If the value of SVDSNCHK for the instance is not Y, the D= command ispassed through to CA 7 with no further security checking to be done byU7SVC.

If the value of SVDSNCHK for the instance is Y, a security call is made byU7SVC. This call determines if the EXTRACTed ID has CREATE authorizationfor the data set specified on the D=. If the EXTRACTed ID does haveauthorization, the D= command is passed to CA 7 for processing.


A security EXTRACT is done to determine the user ID that invoked U7SVC.This user ID is later used to generate a full logon statement or optionallyperform a submit check. The input stream is then read to determine whether alogon statement was supplied. If no logon statement was supplied or if a logonstatement was supplied without an OPID, one is generated for the execution.The logon statement resembles the following:












Data Set Posting

The Batch Card Load Program (SASSBCLP) and U7SVC allow the user to postthe creation of a data set to CA 7. Because such posting can satisfyrequirements or cause job triggering, the need to secure the use of thesefacilities is critical. There are two features of these facilities that should bementioned in this connection: data set access validation and USERIDpropagation.

The USERID associated with the user of U7SVC or SASSBCLP is extracted todetermine the user's authority to create the data set. Under certain conditions itmay not be possible to extract the USERID for the user of the ExternalCommunicator. In that event, a default USERID of CA7DUMMY is used.

If REQ is specified in the SUBUID hierarchy on the SECURITY statement in theCA 7 initialization file, the USERID associated with the data set creation maybe propagated to triggered jobs.

For example, suppose that a user whose USERID is XXX submits a batch jobthat uses U7SVC to post the creation of data set A.B to CA 7. Suppose alsothat the creation of this data set triggers job Z. Further suppose that REQ is inthe first position in the SUBUID hierarchy. In such a case, USERID XXX couldbe propagated to job Z when the job is submitted.

Note: Each of the External Communicators attempts to extract the USERID ofthe current user, SASSBCLP and U7SVC can be made to verify the authority ofthe user to create that data set whose creation is to be posted to CA 7. Formore information about the CAIRIM keywords that control USERID verification,see the chapter "Execution" in the Systems Programmer Guide.


Sample Definitions

Sample Definitions

The member RACFSAMP in the CA 7 Sample JCL file (SAMPJCL) on theinstallation media contains sample RACF commands that can be used tosecure the CA 7 processing environment under RACF. The definitions areintended as examples only and should be reviewed and modified to meet yourinstallations security requirements. Once tailored to your site's specifications,the definitions can be used as batch input to RACF.

Note: For more information about executing RACF commands in batch, seethe Security Server RACF Command Language Reference.


Chapter 7. Internal Security


Security Use Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 146Define Security Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147SECURITY Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154USERID Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

The user can define the security structure and level of authority for eachindividual allowed access to CA 7. You should make a careful evaluation ofsecurity requirements prior to implementation of CA 7.

The ability to control levels of authority is based on the CA 7 SECURITYmacro. You can define five distinct levels of security:

■ Terminal/Operator

■ Operator/CA 7 Application

■ CA 7 Application/Command

■ Command/Function

■ User ID/External Data Set

Each level of security or authorization provides further qualification (orrestriction) of the preceding level. This means each level of security defined bythe SECURITY macro requires that preceding levels also be defined. Forexample, to have authorization to perform a specific command within anapplication (Application/Command security), an operator must also haveauthorization to use the application providing that command. You must definethe first level of security (Terminal/Operator) before an operator is allowed tolog on to CA 7.

Establishing the user-defined security structure is accomplished through theCA 7 initialization process. The CA 7 initialization file must contain aSECURITY statement. This SECURITY statement points to a load modulecontaining the user's security definitions. The Security module identifies alloperators authorized to log on to CA 7, which terminal each operator can use,and other authorization qualifiers necessary to limit the interface with CA 7. Thedefinition of control provided can be modified whenever necessary because ofchanges in personnel, addition/deletion of terminals, and so forth. Since theinitialization file pointing to this matrix is reloaded each time CA 7 is initialized,the most current definition of the data center's security structure is always ineffect.

Chapter 7. Internal Security 145

Security Use Considerations

Security Use Considerations

Capabilities provided by CA 7 make it important to identify control personnelwithin the organization who will be allowed to interface directly with CA 7. Byestablishing a security structure, various access levels can be allowed and stillcontrolled, making CA 7 available for use by any number of authorizedpersonnel. CA 7 security can be used in the following ways:

■ The Master Terminal Operator (MTO) has the most responsibility for theactivity of CA 7. MTO functions might include monitoring production activity,providing status reports, responding to CA 7's requests for JCL overrides ormanual verifications, and using various application functions to ensuredatabase integrity.

To permit the MTO to perform these various functions, the MTO'sSECURITY macro statement would allow access to all functions within allCA 7 applications. Assigning a function level of 15 within each applicationallows this access. In addition, assigning the MTO a special user ID of 255allows access to all data regardless of ownership.

■ The workstation terminal operator generally requires less authority than theMTO. Each operator would be assigned a level of authorization to reflectthe various responsibilities of each workstation. Likewise, an individual canhave different levels of authorization depending on which terminal is beingused and which functions are being performed.

■ Database Maintenance can be established as a separate activity to becontrolled and performed by one person or a designated group ofpersonnel. The level of authority required for this activity must obviouslyallow full use of maintenance application functions, but probably would notrequire the ability to modify the queues.

■ End users and some data center managers may also have a need toaccess CA 7 in inquire-only mode. For example, RJE users could beauthorized to interrogate the queues to determine job status and also haveaccess to database entries for those jobs belonging to them as defined bytheir user ID (UID) value. Data center managers could be authorized tointerrogate CA 7 for information reflecting current production status,projected schedules, past history, and so forth.

Regardless of a person's level of responsibility as defined to CA 7, allauthorized operators (MTO through end user) must use the same procedure toestablish communication with CA 7. This procedure is the logon and isdescribed in the Command Reference Guide.


Define Security Levels


Once requirements are defined, two general areas of activity need to bereviewed and planned:

■ SECURITY macros are used to generate the load module referenced in theinitialization file. The default Security module distributed with CA 7 will notrestrict security.

■ If the need for joint ownership of classified jobs or external data sets hasbeen identified, UIDs need to be established with an optional USERIDSecurity module.

The following provides a description of each of the five levels of security:

Terminal/Operator Security

To enforce the security structure defined, CA 7 requires identification of allpersonnel (terminal operators). Each terminal operator is identified by a uniqueoperator ID, up to eight characters, which is specified in the SECURITY macro.The macro must also specify the terminal IDs of each terminal on which thisoperator is allowed to log on (/LOGON).

Operator/Application Security

An operator can be restricted to the use of only those applications that fallwithin the operator's specific area of responsibility. The SECURITY macrodefines access to applications for each operator. Application security levels areshown in the table in “Application/Command Security” on page 147.

Application/Command Security

Within each CA 7 application there is at least one command that can beperformed. Each command is assigned a required authorization value (level)from 0 to 15 in the SASSTRAN module. This program can be modified to adjustthese values. Any command can be disabled by assigning it a level greaterthan 15 in SASSTRAN. Commands assigned lower numbers are less restrictivethan commands assigned higher numbers. For example, inquiry commands canhave level 4, while Utilities can have level 10. An operator is limited tocommands of the application that have an assigned value (in SASSTRAN)equal to or less than the authorization level specified in the SECURITY macrofor the operator. An authorization level is specified for each application that anoperator can access. For each CA 7 application, its commands and assignedlevels, see the table in “Application/Command Security” on page 147.



Application ID FunctionAuthorityLevel

Function Name

AR (Automated RecoveryFacility)

00 AR.3

MLR (Management LevelReporting)

00 GRAPHD, GRAPHJ, GRAPHN, GRAPHS

PS (Personal Scheduling)

00 PS (See SASSDSCR source module for function securitylevels)

RSC (Virtual ResourceManagement)

00 RM (See SASSDSCR source module for function securitylevels)

SAN (Analyze)

05 PRRNJCL, RESANL, RQMT, RQVER, TRIG, XREF

SCM (System Commands)

00 /CLOSE, /COPY, /DISPLAY, /ECHO, /FETCH, /NXTMSG,/PAGE, /PAnn, /PFnn, /PROF

01 /OPERID, /UID

05 /AUTO, /EMAIL, /LOG, /MSG, /SDESK

10 /BRO, /DRCLASS, /PURGPG, /WTO

12 /DRMODE, /EADMIN, /START, /STOP, /SWAP

13 /RESET

14 /ASSIGN, /CHANGE, /CLOSE(T=), /DMP1, /DUMP,/LOGOFF(T=), /MVS, /OPEN, /RELINK, /REFRESH,/SHUTDOWN, /WLB, /XTASK

15 /GVAR, /JCL, /OPERIDS, /PROFS

SDM (Database Maintenance)

00 CALMOD, CONVERT, DBM, DSN, PROSE, PROSE(DD),PROSE(DSN), PROSE(JOB), PROSE(NETWORK),PROSE(JOB), PROSE(USER), JCL, JOB, JOBCONN,JOBCONN(DSN), JOBCONN(JDEP), JOBCONN(NWK),JOBCONN(RPT), JOBCONN(USR), NETWORK, QJCL,RESTORE, SCHD, SCHD(DTRG), SCHD(INWK),SCHD(JOB), SCHD(JTRG), SCHD(NTRG),SCHD(ONWK), SCHDMOD, XPJOB(See SASSDSCR source module for function securitylevels)

15 XNODE, XPSWD




Function Name

SFC (Forecast)

04 FALL, FJOB, FPOST, FPRE, FQALL, FQJOB, FQPOST,FQPRE, FQRES, FQSTN, FQTAPE, FRES, FRJOB,FRQJOB, FSTN, FSTRUC, FTAPE, FWLP

SJR (Job Restart)

10 LIST, RESTART

SLI(Inquiry and Report)

00 HELP

01 FLOWL, LACT(R), LARF, LARFQ, LCTLG, LDSN, LDTM,LJES, LJOB(R), LLOCK, LNODE, LNTWK, LOC, LPOST,LPRE, LPRRN, LPROS, LQ(P/R), LRDY(P/R),LREQ(P/R), LRES, LRLOG, LRMD, LSCHD, LSYS,LWLB

04 LGVAR, LJCK, LJCL, LLIB, LPDS

09 DUMP

SPO (Queue Posting)

05 IN, IO, LOGIN, LOGOUT, OUT, REMIND, RSVP

10 ADDRQ, ADDSCH, ARFP, CANCEL, CTLG,DEMAND(H), DIRECT, DMDNW, FLOWD, HOLD,JCLOVRD, LOAD(H), NOPRMP, NXTCYC, POST,PRMP, PRSCF, PRSQA, PRSQD, RELEASE,REQUEUE, RESCHNG, RUN(H), RUNNW, RUSH,SUBMIT, SUBSCH, SUBTM, VERIFY

15 SSCAN, START, STOP

SQM (Queue Maintenance)

00 XPOST, XPRE, XQ, XQJ, XQM, XQN, XRQ, XRST,XSPOST, XSPRE, XUPD, XWLB, (See SASSDSCRsource module for function security levels)

SRC (Schedule Resolution)

02 PRINT

04 RESOLV

UTL (Utilities)

00 DMPCAT, DMPDSCB, DMPDSN, FIND, LISTDIR, MAP,SPACE

04 TIQ

08 ARTS

10 AL, ALC, ALLOC, BLDG, CAT, CONN, DEALLOC,DCONN, DLTX, RENAME, SCRATCH, UNC

15 SCRATCHP, TIQU




Function Name

SYS (System Information)

00 SYSDMP, SYSINQ

SCO (Core Manipulation)

00 DMP, ZAP

TRA (System Debugging)

00 DM, FIX, FRE, GO, LTR, PAT, SAV, TRP, ZA(Used only by CA Technical Support representatives.)



Command/Function Panel Security

In a broad application area, such as Database Maintenance (SDM0), a singleauthorization level as defined in the SASSTRAN module is not enough tocontrol database access and update. Therefore, a security method was devisedto control access based on panel, function and terminal.

The security table is defined in SASSDSCR. It is composed of the SECURITYmacros.

��─ ──SEC SCR=nnn ──,PAN=nnnnnnnn ──┬ ┬──────────────── ────────────────────� │ │┌ ┐─�──

└ ┘──,READ= ──┴ ┴─nn─

�─ ──┬ ┬─────────────── ──┬ ┬─────────────── ──┬ ┬─────────────── ────────────� │ │┌ ┐─�── │ │┌ ┐─�── │ │┌ ┐─�──

└ ┘──,ADD= ──┴ ┴─nn─ └ ┘──,UPD= ──┴ ┴─nn─ └ ┘──,DEL= ──┴ ┴─nn─

�─ ──┬ ┬──────────────── ──┬ ┬───────────── ──┬ ┬─────────────────── ────────��│ │┌ ┐─�── └ ┘──,TERMLVL=nn │ │┌ ┐─,───└ ┘──,SUBM= ──┴ ┴─nn─ └ ┘──,TERM=( ───� ┴termn )

SCR=nnnIdentifies the panel. Required. This should not be changed.

PAN=nnnnnnnnIdentifies the panel ID. Required. This should not be changed.

READ=nnIdentifies the authorization level (from 0 to 15) that is required for read-onlyfunctions such as LIST, FETCH, and so forth. The default value is 0.

ADD=nnIdentifies the authorization level (from 0 to 15) that is required for add typefunctions such as ADD or SAVE. The default value is 0.

UPD=nnIdentifies the authorization level (from 0 to 15) that is required for updatetype functions such as UPD or REPL. The default value is 0.

DEL=nnIdentifies the authorization level (from 0 to 15) that is required for deletetype functions such as DELETE or DD. The default value is 0.

SUBM=nnIdentifies the authorization level (from 0 to 15) that is required for jobsubmission functions such as RUN or SUBMIT. The default value is 0.

The TERMLVL and TERM values are optional but can be used to restrictaccess by physical terminal.



TERMLVL=nnIdentifies the authorization level (from 0 to 15) at which the terminal list willbe checked for access qualification. This allows you to restrict certain panelfunctions such as UPD or DELETE to specific terminals, but allow functionssuch as LIST to be performed without terminal restrictions.

TERM=(term1,...,termn)Identifies one or more terminals to be validated when checking functionaccess. The maximum number of characters that can be within theparentheses is 255. If this limit is encountered, specify as many terminalnames as will fit. Then code another SEC macro immediately after this one,with the terminals listed in the TERM parameter. For this secondary SECmacro, only the TERM parameter can be coded.

The following logic is employed to control access:

■ If the function does not access the database (such as CLEAR, EDIT orFORMAT), no security checking is done.

■ If the user has an authorization level of 15 defined in the Security module,he is allowed to execute all functions.

■ In all other cases, the authorization level as defined in the Security moduleis compared against the security level required for the appropriate paneland function (READ, ADD, and so forth). If the authorization level is less,the command is rejected.

■ The TERM list is now checked for terminal restrictions. If there are none,the command is accepted. If the security level required is less than theTERMLVL value, the command is accepted. Otherwise, the TERM list ischecked. If the user's terminal is not found in this list, the command isrejected.

If EXTERNAL=COMMAND was specified on the SECURITY statement in theCA 7 initialization file, SASSDSCR should not be modified. If CA 7 nativesecurity controls command access, SASSDSCR can be modified to reflect theneeds of your installation.



UID/External Data Set Security

The UID/External Data Set security option ensures that only authorizedpersonnel have access to specific classified jobs and identified data setsexternal to CA 7. This restriction is accomplished for jobs by assigningownership in the form of a UID through the Database Maintenance applicationwhen the jobs are placed under control of CA 7. External data sets can receivesimilar protection by identifying the data set by name and the UID valid foraccess in a user-defined USERID Security module.

For a terminal operator to gain access to UID protected jobs or data sets, theoperator's SECURITY macro definition must specify a UID matching the UID ofthe job or the data set defined in the USERID Security module. Since read-onlyor write-only access may be needed for different UIDs and equivalencebetween some UIDs may be desirable, a USERID Security module can furtherdefine these equivalencies and access limitations. The module is identified onthe SECURITY statement of the initialization file with the USER operand.


SECURITY Macro

SECURITY Macro

The SECURITY macro defines the access levels for all personnel who will bedesignated as CA 7 operators as follows:

■ The terminals where the specified ID is allowed access.

■ The operator IDs (OPID) used for logon.

■ The CA 7 applications the operator will have access to and the functionlevel within each.

■ Operator restriction to only those jobs that carry a specific UID or ownershipcode.

A Security module should be assembled and link edited for the user's specificenvironment. It must not be linked as reentrant, reusable. CA 7 must be shutdown after assembling and link editing this Security module and changing theSECURITY statement in the initialization file. Then, with the startup of CA 7,this security will be in effect. A sample Security module resides on the CA 7Source library with the name SASSSECI.

��──name──SECURITY─ ──APPLID=(xxxx,nn) ──,OPID=xxxxxxxx ──,TRM=xxxxxxx ────�

�─ ──┬ ┬────────────────── ──┬ ┬─────────── ───────────────────────────────��│ │┌ ┐─�─── └ ┘──,LAST=YES└ ┘──,USRID= ──┴ ┴─nnn─

nameDefines a name, up to eight characters, specified on the first SECURITYstatement coded. The name must reflect the CSECT name for the securitymodule. Coding and continuation follow the rules of assembler macrocoding.

APLIDSpecifies a CA 7 application and the level of functional authority to whichthe designated operator will be allowed access. APLID is required and hasno defaults. Values must be one of the following:

xxxxIdentifies the CA 7 application driver (must end in 0). For eachapplication ID's first three characters, see the table in“Application/Command Security” on page 147.

nnIndicates the function authorization level with a number from 00 to 15,with 00 being the lowest level and 15 the highest.

Multiple applications can be specified by a sublist in the format:

((xxxx,nn),...,(xxxx,nn))


SECURITY Macro

OPIDSpecifies an operator's identification code that must be used when loggingon to a CA 7 terminal. Value must be alphanumeric, up to eight characters.OPID is required and has no default. More than one OPID can be specifiedin the following format:

OPID=(xxxxxxxx,...,xxxxxxxx)

Multiple OPIDs will assign the same APLID and USRID information to allauthorized operators for the terminal specified.

TRMSpecifies the names, in up to 7 characters, of the CA 7 terminals that thedesignated operators are authorized to use. Value must match the NAMEvalue given on the TERM statement in the initialization file defining theterminal. All input terminals defined by TERM statements must bereferenced in at least one SECURITY macro statement. TRM is requiredand there is no default. More than one terminal name can be specifiedusing a sublist notation of TRM=(xxxxxxx,...,xxxxxxx). A value of **ALL**will propagate the specified operator definitions to all terminals defined inthe initialization file. At least one TRM=**ALL** must be specified to use theVirtual Terminal feature.

USRID(Optional) Specifies a user (ownership) identification that will control theoperator's ability to access information in the database. Value must be anumber from 0 to 255. The default is 0. USRID=255 allows access to allinformation regardless of ownership.

LAST(Optional) If used, specifies the last SECURITY statement in the module.The value must be YES.

An assembler END statement must appear after the last SECURITY macro. It isadvisable to place a PRINT NOGEN statement before the first SECURITYmacro to suppress the macro expansion printout, which can be lengthy.


SECURITY Macro

Example

The following is an example of the Security module:

TITLE 'SECURITY MODULE EXAMPLE' PRINT NOGENSASSSECA SECURITY TRM=(TERM1,TERM2),OPID=(OP1,OP2), X APLID=((SLI�,8),(SPO�,9),(SDM�,3)), X USRID=23 SECURITY TRM=(TERM3),OPID=(OP1,OP2,OP3), X APLID=((SJR�,1�),(SDM�,12)),LAST=YES END

The following is an explanation of the Security module example:

Terminals TERM1 and TERM2 can be logged on with OPIDs of OP1 or OP2.These terminal names correspond to the TERM statements in the initializationfile with NAME=TERM1 and NAME=TERM2. The operators can perform thefollowing:

■ Enter listing commands (SLI0) requiring an authority level of 8 or less.

■ Access jobs (or data sets if the USERID external data set security is ineffect) with a UID of 23 or 0 (on the DB.1 panel).

■ Enter database maintenance commands (SDM0) requiring an authority levelof 3 or less.

■ Enter queue maintenance command (SPO0) requiring an authority level of 9or less.

Terminal TERM3 can be logged on with OPIDs of OP1, OP2, or OP3. Theoperators can perform the following:

■ Perform job restart commands (SJR0) requiring an authority level of 10 orless.

■ Perform database maintenance commands (SDM0) requiring an authoritylevel of 12 or less.


USERID Macro

USERID Macro

The USERID macro defines the correspondence, if any, between various UIDsfor access to classified jobs, and can also identify data sets external to CA 7 tobe protected on a UID level.

To implement this level of security, a USERID Security module must beassembled and link edited (not RENT). It must then be identified on theSECURITY statement, in the initialization file, to allow UID correspondence anddata set protection. No sample is provided in the CA 7 Source library since thisfeature is entirely user dependent.

External data sets not specified in the USERID Security module are notprotected by the CA 7 UID feature.

Two formats are associated with the USERID macro. One is for IDcorrespondence, and the other is for data set protection. All USERID macrosusing UID keywords must precede the first DSN entry or assembly errors willresult.

��──name──USERID─ ── ──┬ ┬─UID─ = ──┬ ┬─(nnn)─────────── ─────────────────────� └ ┘─U─── ├ ┤─(nnn,...,nnn)─── ├ ┤─(nnn-nnn)─────── └ ┘─(nnn-nnn,,,nnn)─

�─ ──┬ ┬──────────────────────────────────── ──,LAST=YES ─────────────────�� └ ┘──, ──┬ ┬─COIDS─ = ──┬ ┬─(nnn)─────────── └ ┘─C───── ├ ┤─(nnn,...,nnn)─── ├ ┤─(nnn-nnn)─────── └ ┘─(nnn-nnn,,,nnn)─


USERID Macro

For external data set protection, the format is:

┌ ┐─,──��──name──USERID─ ── ──┬ ┬─DSNAME─ =( ───� ┴xxxx ) ─────────────────────────────� ├ ┤─DSN──── └ ┘─D──────

�─ ──┬ ┬─────────────────────────────────── ──────────────────────────────� └ ┘──, ──┬ ┬─READ─ = ──┬ ┬─(ALL)─────────── └ ┘─R──── ├ ┤─(nnn)─────────── ├ ┤─(nnn,...,nnn)─── ├ ┤─(nnn-nnn)─────── ├ ┤─(nnn-nnn,,,nnn)─ └ ┘─(WRITE)─────────

�─ ──┬ ┬──────────────────────────────────── ──┬ ┬────────────────── ───────�└ ┘──, ──┬ ┬─WRITE─ = ──┬ ┬─(ALL)─────────── └ ┘──,MBROPT= ──┬ ┬─R──

└ ┘─W───── ├ ┤─(nnn)─────────── ├ ┤─W── ├ ┤─(nnn,...,nnn)─── ├ ┤─RW─ ├ ┤─(nnn-nnn)─────── └ ┘─WR─ ├ ┤─(nnn-nnn,,,nnn)─ └ ┘─(READ)──────────

�─ ──,LAST=YES ─────────────────────────────────────────────────────────��

name(Optional) Specified only on the first USERID statement in the module togenerate the CSECT name for the module. The default is UIDTABLE.

The macro name USERID should begin in column 10. One space mustappear before and after the macro name USERID. Continuation follows therules of assembler macro coding.

U|UIDSpecifies a UID, a range, a list of UIDs, or a list of ranges to have acorrespondence with COIDS. UID and U can be used interchangeably.Value can be a single ID, a range of IDs or a sublist combining the previoustwo values. IDs can be any value between, but not including, 0 and 255 inascending order.

C|COIDSSpecifies UIDs that the UID will inherit access to. (This is for job accessonly, not external data set access, unless MBROPT is used.) Can bespecified as a UID, range of UIDs, list of UIDs and/or ranges of UIDs inascending order.

D|DSN|DSNAMESpecifies a data set name or list of data set names to be protected by UIDsecurity. DSNAME, DSN and D can be used interchangeably. Value is adata set name or names up to 44 characters each, which can be enclosedin quotes. A generic name can be indicated by ending it with an asterisk (*)such as SYS*. This keyword cannot be specified on a statement containingUID. If DSNAME is used with no other keywords, access to that data set isonly allowed for a UID of 255.


USERID Macro

R|READSpecifies a UID or a list of UIDs or ranges to be allowed read access todata sets in the DSN list in ascending order. READ and R can be usedinterchangeably. This keyword has the same format as UID. Can also beREAD=WRITE to indicate that the value is the same as the WRITE list orREAD=ALL to indicate unrestricted access. This keyword cannot bespecified on a statement containing the UID keyword. If MBROPT is used,READ is ignored.

W|WRITESpecifies a UID or list or ranges in ascending order to be allowed writeaccess to data sets in the DSN list. WRITE and W can be usedinterchangeably. This keyword has the same format as UID. Can also beWRITE=READ to indicate that the value is the same as the READ list orWRITE=ALL to indicate unrestricted access. This keyword cannot bespecified on a statement containing the UID keyword. If MBROPT is used,WRITE is ignored.

MBROPT= R|W|RW|WRSpecifies member protection for JCL PDS type data sets based on accessto like-named jobs in the CA 7 database. Cannot be used on statementscontaining the UID keyword. Values can be R for read protection, W forwrite protection, RW or WR for both read and write protection. If specified,this keyword causes a read of the database for a job having the samename as the PDS member. If a job is found, its UID (and any associatedCOIDs) control PDS access. If a like-named job is not found, access isallowed (regardless of READ or WRITE values). This provides a way ofextending protection to JCL members for jobs protected with a UID.

LAST=YESRequired. This keyword must be coded only on the last macro statement ofthe module. Value must be YES.

An assembler END statement must appear after the last USERID macro. It isadvisable to place a PRINT NOGEN statement before the first USERID macroto suppress the macro expansion.


USERID Macro

Example

The following is an example of the USERID module:

TITLE 'USER-ID SECURITY MODULE' PRINT NOGENSASSUID USERID UID=5,COIDS=(7,9,11) USERID UID=(1�-2�),COIDS=(2�-25,3�) USERID DSN=SYS�,WRITE=(2��-254) USERID DSN=USER.PROCLIB,LAST=YES END


Chapter 8. Troubleshooting


Diagnostic Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Problem Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Accessing the Online Support System . . . . . . . . . . . . . . . . . . . . . 165Contact Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Product Releases and Maintenance . . . . . . . . . . . . . . . . . . . . . . 167Requesting Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Chapter 8. Troubleshooting 161

Diagnostic Procedures

Diagnostic Procedures

The following flowchart provides a summary of the procedures you shouldfollow if you have a problem with a CA product. These procedures are detailedon the following pages.


Problem Resolution

Problem Resolution

Before contacting Technical Support, attempt to resolve the problem using thefollowing steps.

Verifying the Problem

1. Examine the procedure that you used and compare it to the documentedprocedure for performing the required activity.

2. If you find no discrepancies between your procedures and the documentedprocedures, repeat the activity under conditions similar to those that existedwhen the problem first appeared. (If you no longer get unsatisfactoryresults, an inadvertent error may have caused the problem.)

3. If the same error occurs when you repeat a given activity, and you can findnothing in the documentation to suggest that your procedure is flawed,check with others at your site to determine if they have had the same orsimilar problem and how they handled it.

Collecting Diagnostic Data

The following information is helpful in diagnosing problems that might occur:

■ Short description of the problem

■ Control statements used to activate your product

■ JCL used to install or activate your product

■ Relevant system log or console listings

■ Relevant system dumps or product dumps

■ List of IBM or third-party products that might be involved

■ Manufacturer, model number, and capacity of your hardware

■ Numbers and text of IBM or CA error messages associated with theproblem

■ Names of panels where the problem occurs

■ Listings of all fixes applied to all relevant software, including:

– The dates fixes were applied– Fix numbers– Names of components to which fixes were applied


Problem Resolution

Interpreting Diagnostic Data

When you have collected the specified diagnostic data, write down youranswers to the following questions.

■ What was the sequence of events prior to the error condition?

■ What circumstances existed when the problem occurred and what action didyou take?

■ Has this situation occurred before? What was different then?

■ Did the problem occur after a particular PTF was applied or after a newrelease of the software was installed?

■ Have you recently installed a new release of the operating system?

■ Has the hardware configuration (tape drives, disk drives, and so forth)changed?

From your response to these questions and the diagnostic data, try to identifythe cause and resolve the problem.

If you determine that the problem is a result of an error in a CA product, youcan make use of the CA online support system to see if a fix (APAR or PTF) orother solution to your problem has been published. Otherwise, call TechnicalSupport.


Accessing the Online Support System

Accessing the Online Support System

SupportConnect is CA's online product support and service system available onthe Internet. Enter http://ca.com/support in your browser to connect to the site.These include the following:

■ Knowledge Base■ Solution downloads■ Technical Support issue management■ License key downloads■ Virus signature downloads■ Product downloads■ Product documentation downloads■ Newsgroup open forums■ E-News newsletters

Requirements for Using SupportConnect

For full access to all the services related to your licensed products, you mustlog in. Many areas require that you are a registered SupportConnect user.You can enroll on the site or convert your Webtrack or eSupport login andpassword to a SupportConnect account.

If you enrolled at http://ca.com/AccountConnect, you can log intoSupportConnect using your AccountConnect digital certificate rather thanentering a login name and password. However, this works only on the PCwhere the digital certificate resides, and only if you are using Microsoft InternetExplorer 5.5 or later. If you need to access SupportConnect from another PC,or if you are using Netscape Navigator, you must provide a login name andpassword.

CA-TLC: Total License Care

Many CA products use license keys or authorization codes to validate yourhardware configuration. If you need assistance obtaining a license key orauthorization code, contact the CA-TLC: Total License Care group throughSupportConnect.




For online technical assistance and a complete list of locations, primary servicehours, and telephone numbers, contact Technical Support athttp://ca.com/support.

Note: Only your local CA Support Center can provide native languageassistance. Please use English when contacting any North American center.

If you are unable to resolve the problem, please have the following informationready before contacting Technical Support:

■ All the diagnostic information described in “Collecting Diagnostic Data” onpage 163.

■ Product name, release number, operating system, and genlevel.

■ Product name and release number of any other software you suspect isinvolved.

■ Release/version level and PUTLEVEL of the operating system.

■ Your name, telephone number and extension (if any).

■ Your company name.

■ Your site ID.

■ Severity code. This is a number (from 1 to 4) that you assign to theproblem. Use the following to determine the severity of the problem:

1 "System down" or inoperative condition

2 Suspected high-impact condition associated with the product

3 Question concerning product performance or an intermittentlow-impact condition associated with the product

4 Question concerning general product utilization or implementation


Product Releases and Maintenance

Product Releases and Maintenance

Customers are requested to operate only under currently supported releases ofthe product.

Customers with current maintenance agreements also receive ongoing productmaintenance. When a new release of the system is available, a notice is sentto all current customers.


Requesting Enhancements

Requesting Enhancements

CA welcomes your suggestions for product enhancements. All suggestions areconsidered and acknowledged. Contact your Account Manager.


Appendix A. Security Tables


Panel-ID Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Command Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Function and Service Level Table . . . . . . . . . . . . . . . . . . . . . . . 183Access Level Translation Table . . . . . . . . . . . . . . . . . . . . . . . . 185

Appendix A. Security Tables 169

Panel-ID Table

Panel-ID Table

The following table lists the CA 7 panel-IDs. Each panel-ID has acorresponding resource name to be used when defining the resource rules forsecuring CA 7. An asterisk identifies any panel-ID that is new for this release.

Note: Use the resource name listed in the table for each panel when definingthe resource rules under external security. The L2 shown in the resource nameis the CA 7 product code and is required.

Panel-ID ResourceName

Description New inr11.1

APA L2AP CA-7 Automated Performance Analysis Menu (APA)

AP.1 L2AP1 CA-7 Automated Performance Analysis Prompt





AR L2AR CA-7 ARF

AR.3 L2AR3 CA-7 ARF Condition Definition Maintenance

DB L2DB Database Maintenance Menu (DBM)

DB.1 L2DB1 DBM - Job Definition

DB.10 L2DB1 DBM - XPJOB Definition *

DB.2 L2DB2 DBM - Scheduling Menu

DB.2.1 L2DB21 DBM - CPU Job Scheduling

DB.2.1-E L2DB21E DBM - CPU Job Scheduling Parameter Edit

DB.2.2 L2DB22 DBM - Input Network Scheduling

DB.2.2-E L2DB22E DBM - Input Network Scheduling Parameter Edit

DB.2.3 L2DB23 DBM - Output Network Scheduling

DB.2.3-E L2DB23E DBM - Output Network Scheduling Parameter Edit

DB.2.4 L2DB24 DBM - Job Triggering

DB.2.5 L2DB25 DBM - Input Network Triggering

DB.2.6 L2DB26 DBM - Data Set Triggering

DB.2.7 L2DB27 DBM - Modification to Resolve Schedule Dates

DB.2.8 L2DB28 DBM - Base Calendar Maintenance

DB.3 L2DB3 DBM - Job Predecessor/Successor Menu


Panel-ID Table



DB.3.1 L2DB31 DBM - Data Set Predecessors

DB.3.2 L2DB32 DBM - CPU Job Predecessors

DB.3.4 L2DB34 DBM - Input/Output Network Tasks

DB.3.6 L2DB36 DBM - User Memo-Form Predecessors

DB.3.7 L2DB37 DBM - Report-IDs Created

DB.4 L2DB4 DBM - Workload Documentation Menu

DB.4.1 L2DB41 DBM - CPU Job Documentation

DB.4.2 L2DB42 DBM - Input/Output Network Documentation

DB.4.3 L2DB43 DBM - User-Defined Item Documentation

DB.4.4 L2DB44 DBM - Data Set Documentation

DB.4.5 L2DB45 DBM - DD Statement Documentation

DB.4.6 L2DB46 DBM - Application System Documentation

DB.5 L2DB5 DBM - Input/Output Network Definition

DB.6 L2DB6 DBM - Data Set Definition

DB.7 L2DB7 DBM - JCL Library Maintenance

DB.8 -na- DBM -

QM L2QM Queue Maintenance Menu (QM)

QM.1 L2QM1 QM - CPU Jobs Status Prompt

QM.1-M L2QM1M QM - CPU Jobs Status (RQMTS)

QM.1-X L2QM1 QM - CPU Jobs Status

QM.1-XC L2QM1C QM - Job Cancel

QM.1-XE L2QM5 QM - Queued JCL

QM.1-XF L2QM4 QM - CPU Jobs in Restart Status

QM.1-XH L2QM1H QM - CPU Jobs in Hold Status

QM.1-XJ L2QM1J QM - CPU Jobs Status - Reverse JCL OverrideRequirement

QM.1-XP L2QM1P QM - CPU Jobs Status - Respond to Prompting

QM.1-XQ L2QM1Q QM - CPU Jobs Status - Requeue for a Restart

QM.1-XR L2QM1R QM - CPU Jobs Status - Release from Hold Status

QM.1-XS L2QM1S QM - CPU Jobs Status - Satisfy Submit TimeRequirement

QM.1-XU L2QM3 QM - CPU Jobs Status - Go to Attribute Update Panel


Panel-ID Table



QM.1-XV L2QM1V QM - CPU Jobs Status - Reverse Verify RequirementStatus

QM.1-XX L2QM2 QM - CPU Jobs Status - Go to Job Predecessor Panel

QM.2 L2QM2 QM - CPU Job Predecessors Prompt

QM.2-X L2QM2 QM - CPU Job Predecessors

QM.3 L2QM3 QM - CPU Job Attributes Prompt

QM.3-X L2QM3 QM - CPU Job Attributes

QM.4 L2QM4 QM - CPU Job in Restart Status Prompt

QM.4-X L2QM4 QM - CPU Job in Restart Status

QM.5 L2QM5 QM - Queued JCL

QM.6 L2QM6 QM - Input Networks Prompt

QM.6-S L2QM6 QM - Input Networks (2 Up Display)

QM.6-SC L2QM6C QM - Input Networks - Cancel (2 Up Display)

QM.6-SF L2QM6F QM - Input Networks - Force (2 Up Display)

QM.6-SH L2QM6H QM - Input Networks - Hold (2 Up Display)

QM.6-SI L2QM6I QM - Input Networks - Login (2 Up Display)

QM.6-SO L2QM6O QM - Input Networks - Logout (2 Up Display)

QM.6-SP L2QM6P QM - Input Networks - Respond to Prompting (2 UpDisplay)

QM.6-SR L2QM6R QM - Input Networks - Release from Hold (2 UpDisplay)

QM.6-X L2QM6 QM - Input Networks

QM.6-XC L2QM6C QM - Input Networks - Cancel

QM.6-XF L2QM6F QM - Input Networks - Free

QM.6-XH L2QM6H QM - Input Networks - Hold

QM.6-XI L2QM6I QM - Input Networks - Login

QM.6-XO L2QM6O QM - Input Networks - Logout

QM.6-XP L2QM6P QM - Input Networks - Respond to Prompting

QM.6-XR L2QM6R QM - Input Networks - Release from Hold

QM.7 L2QM7 QM - Output Networks Prompts

QM.7-S L2QM7 QM - Output Networks (2 Up Display)

QM.7-SC L2QM7C QM - Output Networks - Cancel (2 Up Display)


Panel-ID Table



QM.7-SF L2QM7F QM - Output Networks - Force (2 Up Display)

QM.7-SH L2QM7H QM - Output Networks - Hold (2 Up Display)

QM.7-SI L2QM7I QM - Output Networks - Login (2 Up Display)

QM.7-SO L2QM7O QM - Output Network - Logout (2 Up Display)

QM.7-SP L2QM7P QM - Output Networks - Respond to Prompting (2 UpDisplay)

QM.7-SR L2QM7R QM - Output Networks - Release from Hold (2 UpDisplay)

QM.7-X L2QM7 QM - Output Networks

QM.7-XC L2QM7C QM - Output Networks - Cancel

QM.7-XF L2QM7F QM - Output Networks - Free

QM.7-XH L2QM7H QM - Output Networks - Hold

QM.7-XI L2QM7I QM - Output Networks - Login

QM.7-XO L2QM7O QM - Output Networks - Logout

QM.7-XP L2QM7P QM - Output Networks - Respond to Prompting

QM.7-XR L2QM7R QM - Output Networks - Release from Hold

RM L2RM Virtual Resource Management Menu (RM)

RM.1 L2RM1 RM - Job Resource Management

RM.2 L2RM2 RM - Resources and Jobs Cross-Reference List

RM.3 L2RM3 RM - Active Job Resources Display

RM.4 L2RM4 RM - Pending Resources Job Display

RM.5 L2RM5 RM - Jobs Waiting on Resources

RM.6 L2RM6 RM - Corequisite Resources List

RM.7 L2RM7 RM - Resource Count Management

UT L2UT CA-7 Utilities

UT.1 L2UT1 CA-7 Utilities - Allocate Data Set

UT.1C L2UT1C CA-7 Utilities - Allocate/Catalog Data Set

UT.10 L2UT10 CA-7 Utilities - Find Data Set on DASD

UT.11 L2UT11 CA-7 Utilities - Allocate Volume

UT.12 L2UT12 CA-7 Utilities - Deallocate Volume

UT.13 L2UT13 CA-7 Utilities - Display Format 1 DSCB

UT.14 L2UT14 CA-7 Utilities - Display Directory Information


Panel-ID Table



UT.15 L2UT15 CA-7 Utilities - Display Data Set Attributes Map

UT.16 L2UT16 CA-7 Utilities - Display Available DASD Space

UT.17 L2UT17 CA-7 Utilities - Display Physical Data Records

UT.18 L2UT18 CA-7 Utilities - Display Catalog Block

UT.19 L2UT19 CA-7 Utilities - Display Catalog Entries

UT.2 L2UT2 CA-7 Utilities - Catalog Data Set

UT.3 L2UT3 CA-7 Utilities - Rename Data Set

UT.4 L2UT4 CA-7 Utilities - Scratch Data Set

UT.5 L2UT5 CA-7 Utilities - Uncatalog Data Set

UT.6 L2UT6 CA-7 Utilities - Build GDG Index

UT.7 L2UT7 CA-7 Utilities - Delete Index

UT.8 L2UT8 CA-7 Utilities - Connect a Catalog

UT.9 L2UT9 CA-7 Utilities - Disconnect a Catalog

WB.X L2WBX CA-7 Workload Balancing Maintenance

XN.1 L2DBXNOD DBM - XPJOB Node Definition *

XN.2 L2DBXPSW DBM - XPJOB Password Definition *


Command Table

Command Table

The following table lists the CA 7 commands and the corresponding resourcename to be used when defining the resource rules to external security. Theservice level is READ. The prefix of L2 on the resource names is the CA 7product code and is required. The command entries that have a resource nameof N/A (not applicable) do not require access authorization. These commandsonly affect the issuing user's current terminal environment. For moreinformation about the following commands, see the Command ReferenceGuide:

Command ResourceName

New in r11.1

/ASSIGN L2SCASSI

/AUTO L2SCAUTO

/BRO L2SCBRO

/CHANGE L2SCCHAN

/CLOSE N/A

/CLOSE(T) L2SCCLOS

/COPY N/A

/DISPLAY N/A

/DMP1 L2SCDMP1

/DUMP L2SCDUMP

/DRCLASS L2SCDRCL

/DRMODE L2SCDRMD

/EADMIN L2SCEADM

/ECHO N/A

/EMAIL L2SCEMAL

/FETCH N/A

/GVAR L2SCGVAR *

/JCL L2SCJCL

/LOG L2SCLOG

/LOGOFF N/A

/LOGOFF(T) L2SCLGOF

/LOGON N/A

/MSG L2SCMSG


Command Table


New in r11.1

/MVS L2SCMVS

/NXTMSG N/A

/OPEN N/A

/OPEN(T) L2SCOPEN

/OPERID L2SCOPER

/OPERIDS L2SCOPRS

/PA N/A

/PAGE N/A

/PF N/A

/PROF N/A

/PROFS L2SCPROF

/PURGPG N/A

/PURGPG(T) L2SCPURG

/REFRESH L2SCRFSH

/RELINK L2SCRLNK

/RESET L2SCRSET

/SDESK L2SCSDSK

/SHUTDOWN L2SCSHUT

/START L2SCSTAR

/STOP L2SCSTOP

/SWAP L2SCSWAP

/UID L2SCUID

/WLB L2WBSWLB

/WTO L2SCWTO

/XTASK L2SCXTSK *

ADDRQ L2QPADRQ

ADDSCH L2QPADSC

AL L2UT1

ALC L2UT1C

ALLOC L2UT11

ARFP L2QPARFP


Command Table


New in r11.1

ARTS L2CAARTS

BLDG L2UT6

CALMOD L2DB28

CANCEL L2QPCNCL

CAT L2UT2

CLEAR N/A

CONN L2UT8

CONVERT L2DBCONV *

CTLG L2QPCTLG

DCONN L2UT9

DEALLOC L2UT12

DEMAND L2QPDMND

DEMANDH L2QPDMND

DIRECT L2QPDREC

DLTX L2UT7

DM L2TSDM

DMDNW L2QPDMNW

DMP L2TSDMP

DMPCAT L2UT18

DMPDSCB L2UT13

DMPDSN L2UT17

DSN L2DB6

DUMP L2GIDUMP

EDIT N/A

FALL L2FCFALL

FIND L2UT10

FIX L2TSFIX

FJOB L2FCFJOB

FLOWD L2QPFLWD

FLOWL L2GIFLWL

FPOST L2FCFPOS


Command Table


New in r11.1

FPRE L2FCFPRE

FQALL L2FCFQAL

FQJOB L2FCFQJO

FQPOST L2FCFQPO

FQPRE L2FCFQPR

FQRES L2FCFQRE

FQSTN L2FCFQST

FQTAPE L2FCFQTA

FRE L2TSFRE

FRES L2FCFRES

FRJOB L2FCFRJO

FRQJOB L2FCFRQJ

FSTN L2FCFSTN

FSTRUC L2FCFSTR

FTAPE L2FCFTAP

FWLP L2FCFWLP

GO L2TSGO

GRAPHD L2AP3

GRAPHJ L2AP1

GRAPHN L2AP4

GRAPHS L2AP2

HELP N/A

HOLD L2QPHOLD

IN L2QPIN

IO L2QPIO

JCL L2DB7

JCLOVRD L2QPJCLO

JOB L2DB1

JOBCONN L2DB3

LACT L2GILACT

LACTR L2GILACR


Command Table


New in r11.1

LARF L2GILARF

LARFQ L2GILARQ

LCTLG L2GILCTL

LDSN L2GILDSN

LDTM L2GILDTM

LGVAR L2GILGVR *

LIST L2GILIST

LISTDIR L2UT14

LJCK L2GILJCK

LJCL L2GILJCL

LJES L2GILJES

LJOB L2GILJOB

LJOBR L2GILJOR

LLIB L2GILLIB

LLOCK L2GILLOC

LNODE L2GILNOD *

LNTWK L2GILNWK

LOAD L2QPLOAD

LOADH L2QPLOAD

LOC L2UT19

LOGIN L2QPLGIN

LOGOUT L2QPLGOU

LPDS L2GILPDS

LPOST L2GILPOS

LPRE L2GILPRE

LPROS L2GILPRO

LPRRN L2GILPRN

LQ L2GILQ

LQP L2GILQP

LQUE L2GILQ

LQR L2GILQR


Command Table


New in r11.1

LRDY L2GILRDY

LRDYP L2GILRDP

LRDYR L2GILRDR

LREQ L2GILREQ

LREQP L2GILREP

LREQR L2GILRER

LRES L2GILRES

LRLOG L2GILRLO

LRMD L2GILRMD

LSCHD L2GILSCH

LSYS L2GILSYS

LTR L2TSLTR

LVAR L2GILVAR

LWLB L2WBLWLB

MAP L2UT15

MENU N/A

MOVE L2TSMOVE

NETWORK L2DB5

NOPRMP L2QPNOPR

NXTCYC L2QPNXTC

OUT L2QPOUT

PAT L2TSPAT

POST L2QPPOST

PRINT L2GIPRNT

PRMP L2QPPRMP

PROSE L2DB4

PRRNJCL L2QPPRNJ

PRSCF L2QPPRCF

PRSQA L2QPPRQA

PRSQD L2QPPRQD

PS L2PS


Command Table


New in r11.1

QJCL L2QM5

RELEASE L2QPRLSE

REMIND L2QPRMIN

RENAME L2UT3

REQUEUE L2QPRQUE

RESANL L2DBRSNL

RESCHNG L2QPRSCH

RESOLV L2DBRSLV

RESTART L2QPREST

RESTORE L2DBCONV *

RQMT L2DBRQMT

RQVER L2QPRQVR

RSVP L2QPRSVP

RUN L2QPRUN

RUNH L2QPRUN

RUNNW L2QPRNNW

RUSH L2QPRUSH

SAV L2TSSAV

SCHD L2DB2

SCHDMOD L2DB27

SCRATCH L2UT4

SCRATCHP L2UT4P

SPACE L2UT16

SSCAN L2SCSCAN

START L2QPSTAR

STOP L2QPSTOP

SUBMIT L2QPSUBM

SUBSCH L2QPSUBS

SUBTM L2QPSUBT

SYSDMP L2TSSYSD

SYSINQ L2TSSYSI


Command Table

Note: Access to the commands with a resource name prefix of L2TS must berestricted. These are diagnostic commands generally only issued at the requestof Technical Support. The ability to display and modify storage with thesecommands could allow unauthorized access of sensitive data.


New in r11.1

TIQ L2CATIQ

TIQU L2CATIQU

TRA L2TSTRA

TRIG L2DBTRIG

TRP L2TSTRP

UNC L2UT5

UT* L2UT

VERIFY L2QPVERI

X L2TSX

XNODE L2DBXNOD *

XPJOB L2DB1 *

XPOST L2QM7

XPRE L2QM6

XPSWD L2DBXPSW *

XQ L2QM1

XQJ L2QM1

XQM L2QM1M

XQN L2QM1

XREF L2DBXREF

XRQ L2QM2

XRST L2QM4

XSPOST L2QM7S

XSPRE L2QM6S

XUPD L2QM3

XWLB L2WBX

ZA L2TSZA

ZAP L2TSZAP


Function and Service Level Table


The function table lists the CA 7 functions and a corresponding service levelrequired to perform that function. Each function may have additional aliases.The service level must be specified on the resource rule for a given panel orcommand to grant access to that function. Service levels are translated forexternal security calls according to “Access Level Translation Table” onpage 185.

Functions ServiceLevel

Alias

ADD ADD A,ADDT,AELETE,AIST,APD

APPEND READ AP,APP

APPENDP READ N/A

CLEAR N/A CL,CLR

DD DELETE N/A

DELETE DELETE D,DEL,DELT

DELPRRN UPDATE N/A

EDIT N/A E,EDITH

EXIT N/A N/A

FE READ FEIT,FEPL,FEVE

FETCH READ F

FETCHP READ FP

FORMAT N/A FMT,FOR,FORM

FPE READ N/A

FREE DELETE N/A

LIST READ L,LDD,LDIT,LISTA,LISTP,LISTR,LPD

PURGE DELETE N/A

RENAME UPDATE REN

REPL UPDATE R,REP

REQ UPDATE N/A

RESOLV SUBMIT RES

RET SUBMIT N/A

RUN SUBMIT N/A

RUNH SUBMIT N/A



Functions ServiceLevel

Alias

SAVE ADD S

SR UPDATE N/A

SS ADD N/A

SUBMIT SUBMIT SUB

UPD UPDATE U,UDD,UIST,UPDATE,UPDT

XPOST UPDATE N/A

XPRE UPDATE N/A

XQ UPDATE N/A

XQJ UPDATE N/A

XQM UPDATE N/A

XQN UPDATE N/A

XRQ UPDATE N/A

XRST UPDATE N/A

XSPOST UPDATE N/A

XSPRE UPDATE N/A

XUPD UPDATE N/A

XWLP UPDATE N/A


Access Level Translation Table


The following table describes the access levels for CA 7 commands and panelsand how they are translated by the CA Standard Security Facility (CAISSF).See the appropriate column for the security package that you haveimplemented at your installation for the equivalent access level to specify whendefining access authorization for CA 7 users.

CA 7 CAISSF CA Top Secret CA ACF2 RACF

Read Read Read Read Read

Update Update Update Update Update

Add Create Create Add Control

Delete Scratch Scratch Delete Control

Submit Control Control Update Control


Index

Special Characters/ commands

See alphabetical listing/MVS command security 51, 83, 120

AAccess Level Translation table 185AccountConnect 165ACF2SAMP member 106ACID definition 44activating the new resource classes, RACF 111ADDUSER command, RACF 113alphabetical listing 26application

command security levels 147resource profile 116security 147

ARF (Automated Recovery Facility)customizing recovery procedures 19defining conditions 19security 19

authority, levels of 146authorization codes, obtaining 165

Bbase calendar security 29batch

jobs and external security 15USERIDs 55, 98, 134

BTIsecuring 66, 99, 136security checking 22

CCA ACF2 security 75CA Standard Security Facility (CAISSF) 109CA Top Secret security 41CA-7 ISPF Interface Primary Option Menu

panel 63, 95, 131CA-TCC (CA Total Client Care)

See SupportConnectCA-TLC (CA Total License Care) 165

CA7RTBL macro 60, 92, 128CA7TOUNI batch program 21CAISSF 109CAL2X2W0 program 66, 99, 136calendar security 29, 87Class Descriptor Table, RACF 109client, CA 7 as 21command

securityapplication/command 147CA ACF2 80CA Top Secret 49RACF 118, 137

table, CA 7 175Command/Function Panel security 151commands

DISPLAY,ST 37REFRESH 65, 97, 133securing /MVS 51, 83, 120UID 64, 96, 132

cross-platform schedulingCA 7 as client 21CA 7 as server 23security 20SUBMIT function 21

Customer SupportSee Technical Support

Customizing recovery procedures with ARF 19

DData set

postingCA ACF2 105CA Top Secret 72RACF 142

security 15defining

CA 7started task to RACF 113to CA ACF2 76to CA Top Secret 42

resource rules 170security levels 147SUBMIT resource rules 85

Index 187

DISPLAY,ST command 37DISPLAY,ST=SEC panel 37displaying current security options 37

EeSupport

See SupportConnectexternal

data set security 153security

CA ACF2 75CA Top Secret 41RACF 107

external communicatorsCA ACF2 99CA Top Secret 66overview 16RACF 136

FFunction Access Level table 183

GGroup profiles, RACF 135

IICHERCDE macro 110ICHRIN03 Started Procedures Table 112ICHRRCDE module 109ICOM

and CA ACF2 84and CA Top Secret 46and RACF 114data set access requirements 115

identifying your security requirements 13initialization file, SECURITY statement 26installation requirements

securitylevels, defining 147macro 154use considerations 146USERID macro 157

internal security installation requirements 145Internet, CA site 165ISPF Interface Primary Option Menu panel 63, 95,

131

JJob submission

and USERID insertion 15CA ACF2 88CA Top Secret 56RACF 124

LL2, CA 7 product code 81, 170, 175levels of security 145license keys, obtaining 165logon

panel 63, 95, 131security 14

LOGON procedure 146

Mmasking resource names 80multi-CPU security environments 17MVS command security 51, 83, 120

Oonline ACIDoperator security 147operator/application security 147

PPA@EL parameter 111panel security 15Panel-ID table 170panels 39

CA-7 ISPF Interface Primary Option Menu 63,95, 131

DISPLAY,ST 37Logon 63, 95, 131

PERMIT command, RACF 117program protection


RRACF

ADDUSER command 113group profiles 135interface 107


RACF (continued)Router Table 111Started Procedures Table 112using surrogates 123

RACFSAMP member 143RDEFINE command, RACF 118REFRESH command 65, 97, 133Resource Class Descriptor Table, RACF 109resource names, masking 80Router Table, RACF 111

Ssample definitions


SASSBCLP (Batch Card Load Program)and CA ACF2 99and CA Top Secret 66and RACF 136

SASSBSTR programand CA ACF2 99and CA Top Secret 66and RACF 136

SASSDSCR module 151SASSRTBL 61, 93, 129SASSSECI (sample security module) 154SASSTRAN module 147SASSTRLR program

and CA ACF2 99and CA Top Secret 66and RACF 136

Scheduling, cross-platform 20screens

See panelssecurity 13

and ARF 19CA ACF2 75CA Top Secret 41calendar 29, 87commands 15cross-platform scheduling 20external communicators 16introduction 9job submission 15levels, defining

application/command 147Command/Function panel 151operator/application 147terminal/operator 147UID/external data set 153

security (continued)macro 26, 154module example 156multi-CPU security environments 17panels 15RACF 107structure using

external security 14internal security 18

submit data sets 17tables 169USERID

macro 157module example 160protection 16

SECURITY statement 26server, CA 7 as 23StarTCC

See SupportConnectStarted Procedures Table, RACF 112SU@MIT parameter 111submit checking 16Submit data sets 17SUBMIT function 21SUBMIT resource rules 85SupportConnect 165system requirements, RACF 109

Tterminal/operator security 147Total License Care (CA-TLC) 165Troubleshooting 161—167TSSSAMP member 73

UU7SVC facility

and CA ACF2 99and CA Top Secret 66and RACF 136

UCC7 moduleand CA ACF2 98and CA Top Secret 54and RACF 134

UIDassignment 16command 64, 96, 132external data set security 153Resource Table 61, 93, 129resources 59, 91, 127

Index 189

USERIDmacro 157protection 16

USERID propagationCA ACF2 90CA Top Secret 57RACF 126

Vvalidating CA 7 logon and UID resource 62, 94,

130

XXPJOB definitions 20


CA 7 Workload Automation - CA Technologies Global Search ... · PDF fileThis documentation and...

Documents

Transcript of CA 7 Workload Automation - CA Technologies Global Search ... · PDF fileThis documentation and...