ca top secret for z/os troubleshooting guide · $databas (adabas database) ..... 107 $dbd (ims...

CA Top Secret® for z/OS

Troubleshooting Guide r12

Third Edition

This documentation and any related computer software help programs (hereinafter referred to as the "Documentation") are for your informational purposes only and are subject to change or withdrawal by CA at any time.

This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. This Documentation is confidential and proprietary information of CA and may not be used or disclosed by you except as may be permitted in a separate confidentiality agreement between you and CA.

Notwithstanding the foregoing, if you are a licensed user of the software product(s) addressed in the Documentation, you may print a reasonable number of copies of the Documentation for internal use by you and your employees in connection with that software, provided that all CA copyright notices and legends are affixed to each reproduced copy.

The right to print copies of the Documentation is limited to the period during which the applicable license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed.

TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION "AS IS" WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO THE END USER OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE.

The use of any software product referenced in the Documentation is governed by the applicable license agreement and is not modified in any way by the terms of this notice.

The manufacturer of this Documentation is CA.

Provided with "Restricted Rights." Use, duplication or disclosure by the United States Government is subject to the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.2277014(b)(3), as applicable, or their successors.

Copyright © 2009 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

Contact CA Contact Technical Support

For your convenience, CA provides one site where you can access the information you need for your Home Office, Small Business, and Enterprise CA products. At http://ca.com/support, you can access the following:

■ Online and telephone contact information for technical assistance and customer services

■ Information about user communities and forums

■ Product and documentation downloads

■ CA Support policies and guidelines

■ Other helpful resources appropriate for your product

Provide Feedback

If you have comments or questions about CA product documentation, you can send a message to [email protected].

If you would like to provide feedback about CA product documentation, complete our short customer survey, which is also available on the CA Support website, found at http://ca.com/docs.

http://www.ca.com/support�

mailto:[email protected]�

http://www.ca.com/docs�





Documentation Changes CA has made the following documentation updates since the last release of this document:

■ TSSFAR JCL—Corrected the output to show valid parameters and removed reference to RACF compatibility mode.

Contents

Contents 5

Chapter 1: Troubleshooting Approach 13

CA Top Secret Approach to Troubleshooting ............................................................................ 13

Chapter 2: Phase 1—Problem Identification 15

Troubleshooting Phase 1 ...................................................................................................... 16

The Security Validation Algorithm .......................................................................................... 18

Chapter 3: Phase 2—Diagnostic Procedures 21

About Diagnostic Procedures................................................................................................. 21

TSSSIM ............................................................................................................................. 22

Abends .............................................................................................................................. 22

STEP 1 ......................................................................................................................... 23

STEP 2 ......................................................................................................................... 23

Customization..................................................................................................................... 24

Tips and Checkpoints ...................................................................................................... 25

Troubleshooting Procedure .............................................................................................. 27

Facility Access .................................................................................................................... 29

Access Incorrectly Allowed .............................................................................................. 30

Signon Passwords not being Checked ................................................................................ 33

CPU Restrictions not Honored .......................................................................................... 37

Facility Access Incorrectly Denied..................................................................................... 41

Logging of Events ................................................................................................................ 43

CA Top Secret Not Logging Violations ................................................................................ 43

CA Top Secret not Logging Access or Initiations.................................................................. 45

Messages ........................................................................................................................... 46

Users not Receiving CA Top Secret Messages ..................................................................... 46

Console not Receiving CA Top Secret Messages .................................................................. 48

Resource Access Problems .................................................................................................... 50

Data Set or Volume Access Incorrectly Denied ................................................................... 51

Data Set Passwords not being Checked ............................................................................. 54

Chapter 4: Phase 3—Technical Support 57

Pre-Call Preparation............................................................................................................. 57

Contents 5

Required Information ..................................................................................................... 57

Enhancing Communication with Technical Support .............................................................. 58

Contacting Technical Support ................................................................................................ 59

Problem Escalation ......................................................................................................... 60

Level One Support ......................................................................................................... 60

Level Two Support ......................................................................................................... 61

Mailing Diagnostic Information......................................................................................... 61

Chapter 5: Performance Tuning Considerations 63

Statistics Gathering ............................................................................................................. 64

CPF Statistics ................................................................................................................ 65

Security File ....................................................................................................................... 65

Secfile Location ............................................................................................................. 65

Recovery File ................................................................................................................ 66

CA Top Secret Address Space .......................................................................................... 66

Data Integrity ............................................................................................................... 66

Sharing Considerations ................................................................................................... 66

Acid Index Performance Setting ....................................................................................... 67

File Sharing and the Coupling Facility................................................................................ 67

CA Top Secret CACHE..................................................................................................... 68

CACHE and CF Size ........................................................................................................ 68

Security File Cache ......................................................................................................... 69

Tuning CPF ................................................................................................................... 71

User Authentication ............................................................................................................. 71

CICS Performance Considerations ..................................................................................... 72

CICS Signon Sub-Tasking................................................................................................ 73

Shared Profile Table ....................................................................................................... 73

Security Records Cache ........................................................................................................ 74

CICS / DB2 Considerations ................................................................................................... 74

TSSDB2 Considerations .................................................................................................. 74

Performance Related Statistics ......................................................................................... 75

Chapter 6: Using the TSSSIM Utility 77

Introduction ....................................................................................................................... 77

Authority and Scope ............................................................................................................ 78

TSSSIM Facilities................................................................................................................. 78

Using TSSSIM/TSO (Non-SPF Environment) ....................................................................... 78

Using TSSSIM/TSO (SPF Environment).............................................................................. 79

Using TSSSIM in TSO/E-Background or TSO/E-Batch ........................................................... 81

Using TSSSIM/BATCH ..................................................................................................... 82

Using TSSSIM and Advantage CA-Roscoe .......................................................................... 83

6 Troubleshooting Guide

Logging on to TSSSIM .................................................................................................... 84

TSSSIM Commands in General ......................................................................................... 85

System Environment Commands ........................................................................................... 93

LOGON/SIGNON .................................................................................................................. 93

Security Macro: ............................................................................................................. 93

Parameters ................................................................................................................... 94

LOGOFF/SIGNOFF .......................................................................................................... 95

HELP............................................................................................................................ 96

ENVIRON ...................................................................................................................... 97

END/QUIT..................................................................................................................... 97

Simulated Resource Commands ............................................................................................. 98

$ABSTRACT ................................................................................................................ 100

$ALT-ACID (Checks acid cross-authorization)................................................................... 100

$APPCLU (APPC Logical Units) ........................................................................................ 101

$APPCPORT (APPC Ports) .............................................................................................. 101

$APPCSI (APPC Side Information) .................................................................................. 101

$APPCTP (APPC Transaction Programs and Profiles) .......................................................... 102

$APPL (IMS Application) ................................................................................................ 102

$AREA (IDMS Database Areas) ...................................................................................... 102

$CAADMIN (CA Administrative Functions) ....................................................................... 103

$CACCFDSN (AllFusion CA-Librarian/CCF Data Sets) ......................................................... 103

$CACCFMEM (AllFusion CA-Librarian/CCF Members) .......................................................... 103

$CACMD (CA Command Authorization)............................................................................ 104

$CALIBMEM (AllFusion CA-Librarian Member)................................................................... 104

$CAREPORT (Unicenter CA-Dispatch reports) ................................................................... 104

$CATAPE (BrightStor CA-1 Resource) .............................................................................. 105

$CAVAPPL (CA VTAM Applications) ................................................................................. 105

$CIMS (PC Port Logical Unit(LU) Names) ......................................................................... 105

$CPCMD (CP Commands) .............................................................................................. 106

$CPU (Central Processing Unit) ...................................................................................... 106

$DASDVOL (DASD Volume Level) ................................................................................... 106

$DATABAS (ADABAS Database) ..................................................................................... 107

$DBD (IMS Database Descriptor) ................................................................................... 107

$DB2 (DB2 Access) ...................................................................................................... 107

$DB2BUFFP (DB2 Buffer Pools) ...................................................................................... 108

$DB2COLL (DB2 Collections) ......................................................................................... 108

$DB2DBASE (DB2 Databases)........................................................................................ 109

$DB2PKG (DB2 Packages) ............................................................................................. 109

$DB2PLAN (DB2 Plans) ................................................................................................. 110

$DB2STOGP (DB2 Storage Groups) ................................................................................ 110

$DB2SYS (DB2 System) ................................................................................................ 111

$DB2TABLE (DB2 Tables).............................................................................................. 111

$DB2TABSP (DB2 Table Spaces) .................................................................................... 112

Contents 7

$DCSS (Discontiguous Saved Statements) ....................................................................... 112

$DCT (CICS Destination Control Table) ........................................................................... 112

$DEVICES (Hardware Devices)....................................................................................... 113

$DIAG (VM Diagnose Codes) ......................................................................................... 113

$DIRECTRY ................................................................................................................. 113

$DLFCLASS (DLF Data Set) ........................................................................................... 114

$DLISEG (VSE DL/I Segment) ....................................................................................... 114

$DSN (z/OS Data Set) .................................................................................................. 115

$DSPACE (Dataspaces) ................................................................................................. 116

$DTADMIN (DT Administration) ...................................................................................... 116

$DTSYSTEM (DT System Data) ...................................................................................... 116

$DTTABLE (DT Table Data) ............................................................................................ 117

$DTUTIL (DT Utility) ..................................................................................................... 117

$FCT (CICS File Control Table) ....................................................................................... 117

$FIELD (Database Field) ............................................................................................... 118

$IBMFAC (IBM Facilities) ............................................................................................... 118

$IBMGRP (IBM Products) .............................................................................................. 119

$IUCV (Inter User Communication Vehicle(IUCV)) ............................................................ 119

$JCT (CICS Journal Control Tables) ................................................................................ 119

$JESINPUT (JES Source) ............................................................................................... 120

$JESJOBS (JES Job Submit and Cancel) .......................................................................... 120

$JESSPOOL (JES Spool Data Sets) .................................................................................. 121

$JOBNAME .................................................................................................................. 121

$LCF (Limited Command Facility) ................................................................................... 122

$LFSCLASS LF Class..................................................................................................... 122

$MDISK (VM Minidisks (VMMDISK) ) ............................................................................... 122

$MGMTCLAS (SMS Management Class) ........................................................................... 123

$MQADMIN MQ Administration ....................................................................................... 123

$MQCMDS MQ Commands ............................................................................................. 123

$MQCONN MQ Connections ........................................................................................... 124

$MQNLIST MQ Names ................................................................................................... 124

$MQPROC MQ Procedures ............................................................................................. 124

$MQQUEUE MQ Queues ................................................................................................ 125

$NODES VTAM Nodes ................................................................................................... 125

$OPCMD (System Operator Command) ........................................................................... 125

$OPERCMD (z/OS and JES Operator Commands) .............................................................. 126

$OTRAN (Owned Transactions(OTR)) .............................................................................. 126

$PANAPT AllFusion CA-PANAPT Functions ........................................................................ 126

$PANEL (CA Product Panels) .......................................................................................... 127

$PGM (z/OS Program Module Name) ............................................................................... 127

$PPT (CICS Program Table) ........................................................................................... 127

$PROPCNTL (Automatic Propagation Control) ................................................................... 128

$PSB (IMS Program Specification Block).......................................................................... 128


$PSFMPL (Print Services Facility Modifiable Page Labeling) ................................................. 128

$RESLIST Resource Names ........................................................................................... 129

$RECIPID CA DISPATCH RECIPIENT ................................................................................ 129

$SCHEDULE CA SCHEDULER SCHEDULE.......................................................................... 129

$SFSCMD VM SFS COMMANDS....................................................................................... 130

$STATION CA SCHEDULER STATION ............................................................................... 130

$SDSF (Spool Display and Search Facility) ....................................................................... 130

$SMESSAGE (TSO Message Transmission) ....................................................................... 131

$SPI (CICS System Functions) ....................................................................................... 131

$STORCLAS (SMS Storage Class) ................................................................................... 131

$SUBMIT (ACID Job Submission) ................................................................................... 132

$SUBSCH (IDMS Subschema) ........................................................................................ 132

$SYSCONS (System Console) ........................................................................................ 132

$TAPEVOL (Tape Volume) ............................................................................................. 133

$TERM (Network Terminal ID) ....................................................................................... 133

$TSAF (Transparent Services Access Facility) ................................................................... 134

$TSOACCT (TSO Account Codes) .................................................................................... 134

$TSOAUTH (TSO Authorities) ......................................................................................... 134

$TSOPRFG (TSO Performance Groups) ............................................................................ 135

$TSOPROC (TSO Procedures) ........................................................................................ 135

$TST (Temporary Storage Table) ................................................................................... 135

$UR1 (Owned General UR1 Resource) ............................................................................. 136

$UR2 (Owned General UR2 Resource) ............................................................................. 136

$USER (Unowned User Resource)................................................................................... 137

$USRCLASS USER CLASSES .......................................................................................... 137

$VMANAPPL (VMAN Applications) ................................................................................... 137

$VMCF (VMCF Communication Targets) ........................................................................... 138

$VMDIAL (VMDIAL access) ............................................................................................ 138

$VMMACH (VM Machines) .............................................................................................. 138

$VMNODE (VM Nodes) .................................................................................................. 139

$VMRDR (VM Readers) ................................................................................................. 139

$VTAMAPPL (VTAM Applications) .................................................................................... 139

$VXDEVICE (VAX Devices) ............................................................................................ 140

$VXFILE (VAX Files) ..................................................................................................... 140

$WRITER (JES Writer Control) ....................................................................................... 140

@cccccccc (User-Defined Resource)................................................................................ 141

Special Commands ............................................................................................................ 141

EJECT (BATCH Page Eject) ............................................................................................ 142

STATUS (Status of Environment) .................................................................................... 142

TSS (TSS Command Functions)...................................................................................... 143

Simulator Trace Information ............................................................................................... 144

Contents 9

Chapter 7: Using the TSSFAR Utility 149

About the TSSFAR Utility .................................................................................................... 149

TSSFAR JCL...................................................................................................................... 150

Control Statements ............................................................................................................ 150

KEY= ......................................................................................................................... 151

ARLBMAP .................................................................................................................... 151

ALLOC........................................................................................................................ 151

ACIDCHAN .................................................................................................................. 151

ACIDLINK ................................................................................................................... 152

HEADER ..................................................................................................................... 152

RESINDEX .................................................................................................................. 152

ACIDRES .................................................................................................................... 152

SFSTATS .................................................................................................................... 153

WHOHAS (Resource Owning ACID)................................................................................. 154

Chapter 8: PDS Member Level Protection Utilities 155

Introduction ..................................................................................................................... 155

Security Ownership Commands ........................................................................................... 156

Appendix A: Diagnostic Tools 159

Diagnostic Tools for Authorization Issues .............................................................................. 160

Appendix B: CA Top Secret Diagnostic Trace 163

Introduction ..................................................................................................................... 163

Trace Destinations............................................................................................................. 163

Trace Messages ........................................................................................................... 164

Detail 1 ...................................................................................................................... 165

Detail 2 ...................................................................................................................... 173

Detail 3 ...................................................................................................................... 177

Detail 4 ...................................................................................................................... 182

Detail 5 ...................................................................................................................... 183

Detail 6 ...................................................................................................................... 184

Example Diagnostic Traces and Meanings.............................................................................. 185

Example 1. CPU Validation During TSO Logon .................................................................. 185

Example 2. Password Violation during TSO Logon ............................................................. 186

Example 3. Reader Access Violation for Batch Job ............................................................. 186

Example 4. Authorized Access to data set ........................................................................ 187

Example 5. Failure Due to Bad Access Level with ACTION(FAIL).......................................... 187

Example 6. Job Submission (Authorized) ......................................................................... 188

Example 7. Program Violation ........................................................................................ 188


Example 8. CICS Transaction Violation ............................................................................ 188

Example 9. CICS Resource Violation ............................................................................... 189

Appendix C: Message Display/Suppression Algorithm 191

Introduction ..................................................................................................................... 191

Message Display/Suppression Checks................................................................................... 192

Appendix D: Tracing SAF Requests 193

About SAF SECTRACE ........................................................................................................ 194

Using the SAF SECTRACE Command ..................................................................................... 195

Setting and Modifying SAF SECTRACE Operands .................................................................... 197

TYPE Group Operands................................................................................................... 199

OMVS Group Operands ................................................................................................. 201

TRACING Group Operands............................................................................................. 202

ENVIRONS Group Operands........................................................................................... 203

STATUS Group Operands .............................................................................................. 204

EVENTS Group Operand ................................................................................................ 205

ROUTE TO Group Operands ........................................................................................... 206

Other Operands ........................................................................................................... 208

Stopping (and Restarting) the SECTRACE for OMVS................................................................ 209

Enabling SAF SECTRACE Traps ............................................................................................ 209

Disabling SAF SECTRACE Traps ........................................................................................... 209

Deleting SECTRACE Traps................................................................................................... 209

Displaying SAF SECTRACE Operands .................................................................................... 210

Setting SAF SECTRACE at SAF Initialization........................................................................... 210

Example 1 Installation Defaults..................................................................................... 211

Example 2 Prompted Implementation ............................................................................ 212

Tracing UNIX System Services (OMVS)................................................................................. 213

Stopping the SECTRACE for OMVS.................................................................................. 213

Contents 11

Chapter 1: Troubleshooting Approach This section contains the following topics:

CA Top Secret Approach to Troubleshooting (see page 13)

CA Top Secret Approach to Troubleshooting CA Top Secret contains features and utilities which allow a three-phase procedure:

Phase 1

Verify and categorize the problem. Try to answer the following questions: "Is this problem really a problem, what type of problem is it, and where do I go for help?"

This phase provides:

■ A simple procedure for categorizing problems. The supported general categories are:

– Abends

– Customization

– Facility Authorization

– Logging of Events

– Message Production/Suppression

– Resource Authorization

■ Directions and references to other CA Top Secret guides and utilities which allow you to diagnose and resolve the problem.

Phase 2

Perform diagnostic or checkout procedure(s) to determine the cause of the problem. Refer to the appropriate diagnostic procedure or checklist that is provided for each general category.

Each procedure is designed to allow you to determine the cause and resolution of the problem yourself, or to assemble as much information as you can about the problem.

Phase 3

(Optional) Organize diagnostic information, and contact Technical Support for assistance with diagnosis and resolution of the problem. This phase provides a checklist of items and information which will greatly facilitate any discussions with the CA Top Secret support analyst.

Chapter 1: Troubleshooting Approach 13

Chapter 2: Phase 1—Problem Identification

This section contains the following topics:

Troubleshooting Phase 1 (see page 16) The Security Validation Algorithm (see page 18)


Troubleshooting Phase 1

Troubleshooting Phase 1 Step 1 Determine nature of the problem.

Has anything changed recently?

YES

If the ACID has changed lately, run the TSSAUDIT changes() report. If there were any recent software upgrades, investigate the changes.

NO

GO TO STEP 2.

Step 2 Attempt to recreate the problem on the system, or use TSSSIM to simulate the problem.

Did the problem reoccur?

YES

GO TO STEP 3.

NO

This indicates a user error which might involve user training or some other administrative action. Take the appropriate action.

GO TO STEP 5.

Step 3 Did the system display a TSS message, DRC code, or other abend code?

YES

See the Messages and Codes Guide to determine the cause of the problem. Take the corrective action which corresponds to the message or code.

GO TO STEP 5.

NO

GO TO STEP 4.

Step 4 Categorize the problem, if possible, and go to the appropriate Phase 2 procedure.

The following list contains general categories only. If you cannot locate an exact category in the list, try to apply the basic troubleshooting principles of a related category before contacting the CA Top Secret Support Center. If the problem does not correspond to one of the categories listed next, or appears to be caused by CA Top Secret internals, go directly to the Phase 3 documentation in this guide.


Troubleshooting Phase 1

Abends Abends

Customization Customization

Facility Access Access Incorrectly Allowed Signon Passwords Not Being Checked CPU Restriction Not Honored Access Incorrectly Denied

Logging CA Top Secret Not Logging Violations CA Top Secret Not Logging Access or Initiations

Messages Users Not Receiving CA Top Secret Messages Console Not Receiving CA Top Secret Messages

Resource Access Data Set or Volume Access Incorrectly Denied Data Set Passwords Not Being Checked

Does the problem pertain to or is it related to a listed category?

YES

Go to STEP 5.

NO

Go to Phase 3.

Step 5 Review the CA Top Secret security validation algorithm

Review the CA Top Secret security validation algorithm to ensure that the problem is not due to a misunderstanding of how CA Top Secret works. For information, see the User Guide.


The Security Validation Algorithm

The Security Validation Algorithm The CA Top Secret algorithm takes the following factors into consideration when processing a request to access a resource.

■ Ownership vs. Authorization

Ownership overrides authorization. If CA Top Secret finds two TSS entries, one giving ownership of a resource to an ACID and the other giving authorization, ownership will prevail, allowing the ACID total access.

■ Order of Search

CA Top Secret searches the security records in the following order:

– ACID's security record

– Profile(s) attached to the ACID

– The ALL Record

■ LCF Lists

LCF lists are used to restrict the use of a facility's commands on a user-by-facility basis. There are two types of LCF lists: inclusive and exclusive. Within a particular facility, the inclusive or exclusive restriction (not a combination of both) should be used. If both types are used within a single facility, inclusive is checked first, then exclusive. For a further discussion of LCF lists, see the User Guide.

■ Best Match Criteria

When more than one relevant PERMIT is encountered in a security validation search, CA Top Secret employs the "best match" criteria. "Best match" refers to the closeness of the matchup between the resource identifier in the PERMIT and the resource identifier for which access is being requested. Generic prefixing and masking are often the culprits responsible for (un)authorized access discrepancies.

■ AUTH Control Option

The AUTH control option governs whether CA Top Secret will merge the results of the security record search.

■ Volume vs. Data Set Authorization

When determining access to a particular DASD data set, CA Top Secret must evaluate both volume and data set access authorizations. Volume level checking can optionally be bypassed. However, in situations where both volume and data set level checking is being done, CA Top Secret performs volume-level checking first. Thus, a request to access a data set can be granted or failed strictly on the basis of the user's volume access authorization.


The Security Validation Algorithm

■ MODE Control Option

The mode setting specifies the level of security at which security validation is performed. MODE options range from DORMANT to FAIL. CA Top Secret uses this setting to determine its response to security validation requests. See the User Guide for further information on the modes and how they affect security calls.

Based on the CA Top Secret security validation algorithm, does a problem still exist?

YES

Go to Phase 2.

NO

Review the CA Top Secret documentation and examine your existing security definitions. Remember that CA Top Secret offers customer assistance in the form of education classes, on-site security consulting, and professional services.


Chapter 3: Phase 2—Diagnostic Procedures


About Diagnostic Procedures (see page 21) TSSSIM (see page 22) Abends (see page 22) Customization (see page 24) Facility Access (see page 29) Logging of Events (see page 43) Messages (see page 46) Resource Access Problems (see page 50)

About Diagnostic Procedures Phase 2 of the troubleshooting procedure describes the steps that should be taken to diagnose the root of your problem. The procedures in Phase 2 are broken down by categories. (Prior to reaching this phase you should have placed your problem into a specific category.) To locate the proper procedure, find the exact category heading or the heading that most closely resembles the type of problem you are experiencing. The general categories are:

Problem Procedure

Abends Abends

Customization Customization

Facility Access Access Incorrectly Allowed

Signon Passwords Not Being Checked

CPU Restriction Not Honored

Access Incorrectly Denied

Logging CA Top Secret Not Logging Violations

CA Top Secret Not Logging Access or Initiations

Messages Users Not Receiving CA Top Secret Messages

Console Not Receiving CA Top Secret Messages

Resource Access Data Set of Volume Access Incorrectly Denied

Data Set Passwords Not Being Checked


TSSSIM

TSSSIM TSSSIM (explained in detail in the chapter “Using the TSSSIM Utility”) is a valuable tool when trying to find the underlying problems in (un)authorized access discrepancies. If you are unsure of how CA Top Secret reacts to certain authorization definitions, use TSSSIM to test those authorizations in a simulated security environment. TSSSIM uses the CA Top Secret security validation algorithm and immediately displays whether access is granted or denied. If denied, TSSSIM also displays the reason for denial in the form of a DRC and CA Top Secret messages.

Abends Most CA Top Secret abend messages and dump titles contain and document the abend code, program name, and program offset associated with the error. When an CA Top Secret dump exists in a SYS1.DUMPxx data set, the z/OS operator command “D D,E” can be used to gather further details about the error. Similarly, when an CA Top Secret dump is being viewed via IPCS, the “ST FAILDATA IPCS command can now be used to obtain an excellent summary of the error. Whenever possible try to provide “ST FAILDATA” (or “D D,E”) output to CA when reporting an abend of CA Top Secret since this information will allow faster and more accurate problem isolation and resolution.

Sample output from the “ST FAILDATA” command of IPCS follows:

TSS9681A CA-TSS SECURITY FILE SERVICES ABEND S0C4 IN TSSSFSC+38D4


Abends

STEP 1

If the CA Top Secret address space abends during processing, gather the following information:

■ Provide an actual system dump COPY from the dump data set onto a 6250 BPI magnetic tape or cartridge. Use IEBGENER to produce a standard label tape; sample JCL, is shown below. Support will require an unformatted dump. The unformatted SVC dump can be FTP'd to Support. //DUMP JOB // EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //SYSIN DD DUMMY //SYSUT1 DD DISP=SHR,DSN=SYS1.DUMPxx //SYSUT2 DD DISP=(,KEEP),UNIT=TAPE,DSN=xxx

■ Provide all copies of the system log data from 15 minutes before and 5 minutes after the abend occurred. Hardcopy is preferred. You can also email to [email protected]. Include the issue number in the subject field.

■ If the abend was produced by a batch job, provide a copy of the JCL for that batch job and the JES joblog.

■ If TSS message TSS9999E indicated the abend, record the text of the message, including all register and offset information which follow the message.

■ Copy all other CA Top Secret messages that appear with the job or session in the order in which they occur.

■ See the Phase 3 procedure for a checklist of general information required by technical support, and for instructions on how to contact technical support.

STEP 2

Proceed to Phase 3 Contact CA Top Secret Technical Support.


Customization

Customization Customization problems can stem from any one of the three supported CA Top Secret customization techniques. Namely,

■ The z/OS Security Interface,

■ The Installation Exit, or

■ The Application Interface.

Problems usually occur within the parameter lists that are passed to CA Top Secret by the customized code. There are a number of tools that can be used for diagnostics:

■ Information Feedback Areas containing DRCs

■ CA Top Secret Messages, and IBM Messages

■ Traces containing DRCs (see the appendix, “CA Top Secret Diagnostic Trace“)

■ Dumps (forced or from DIAGTRAP)


Customization

Tips and Checkpoints

Customization code can get tricky at times. This section outlines those little things that can easily be overlooked when developing the customization code and can lead to problems. (The old forgetting a semicolon!) Locate the customization facility you are using and check that the listed items have been incorporated into your customization code.

■ Parameter lists

– Is the correct format being used?

– Have you supplied a length?

■ RACDEF and RACLIST have NOT been used for customization.

■ The INSTLN operand of the security macro is being used to obtain information feedback.

■ The ACEE= parameter is present for multi-user address space on all requests to security (RAC macros or RACROUTE), except in task per user environments (TCBSENV).

■ RACROUTE

– Used by current releases of z/OS (state-of-the-art).

– Preferred to the usage of RACINIT, RACHECK, and FRACHECK.

– Your call is one that is supported by CA Top Secret- that is, REQUEST=AUTH, REQUEST=FASTAUTH

– REQUEST=VERIFY, REQUEST=EXTRACT

– A valid Class Name is being used. See the User Guide for valid Class Names.

– If using the Dynamic Extract/Update Facility, you are not trying to extend or reduce the size of the INSTDATA (Installation Data) field.

– If using RACROUTE REQUEST=VERIFY to build a facility, review the facility entries to make sure they were entered correctly.

– RACROUTE REQUEST=VERIFY, ENVIR=DELETE - ensure ACEE parameter points to the address if the address of the ACEE is returned with RACROUTE REQUEST=VERIFY, ENVIR=CREATE.

– Program issuing RACROUTE REQUEST=VERIFY (top RB) matches a valid facility.

– If the facility does not have the NOAUTHINIT attribute, ensure that the program is issuing RACROUTE REQUEST=VERIFY APF authorized in system Key 0 or Supervisor state.

Note: NOAUTHINIT is only valid for STC.

If using RACROUTE REQUEST=VERIFY use the installation feedback area for returned DRCs.


Customization

Installation Exit ■ The Installation Exit is executed in Key 0, Supervisor State, when live;

therefore, it must be coded and tested with great care.

■ The activation matrix contains a nonzero entry for the desired function.

■ The customized code is in the appropriate section of the TSSINSTX module.

■ The EXIT control option is ON. F TSS,STATUS will list the status of EXIT.

■ Under TSO, the installation exit code can be tested in Key 8 by:

– Loading TSSINSTX

– Building your own parameter list as expected by the exit. Parameter lists are described in the TSSINSTX code found in the Optional Materials file on the CA Top Secret distribution tape.

– Passing control to TSSINSTX

– Examining the parameter list, feedback areas, and return codes

To test your installation exit code you can set up debug code which will execute the exit only for a particular ACID, jobname, and so on. The logic is as follows:

■ Locate the correct branch point in the Installation Exit.

■ Check for the ACID, jobname, and so on. You can use one of the following techniques:

■ To locate the jobname or TSO session name, use the following code: L R2,PSATOLD-PSA(0) TCB L R2,TCBTIO-TCB(R2) TIOT

CLC TIOCNJOB-TIOT1(8,R2)=CL8”jobname or TSO session” *

BE OURJOB it's our job so perform the exit code *

BNE NOTJOB it's not our job, exit so we don't interfere with other users

* . . . IHAPSA PSA expansion KJTCB TCB expansion IEFTIOT1 TIOT expansion

Since the acidname is passed into a particular field in the installation exit, another way to locate the ACID is to examine the field.

■ If you are running under ESA or XA, do not forget to refresh LLA after linking a new exit: F LLA,REFRESH


Customization

Application Interface ■ All the necessary Request Record fields are supplied.

■ Samples of the Application Interface can be found in the Optional Materials file on the CA Top Secret distribution tape and in the User Guide.

Troubleshooting Procedure

The general procedure that can be used to troubleshoot customization problems follows.

STEP 1

Write down all message numbers and text displayed by CA Top Secret. See the Messages and Codes Guide to determine the meaning of the CA Top Secret messages and the appropriate action that should be taken to correct the problem.

Did the messages expose the problem?

YES

Go to STEP 4.

NO

Go to STEP 2.


Customization

STEP 2

Turn on the CA Top Secret TRACE:

F TSS,SECTRACE(ACT,WTL) TSS ADDTO(acid) TRACE

If the acid is signed on, either issue TSS REFRESH(acid) JOBNAME(*) or have the acid signoff and back on again.

To turn off the TRACE:

TSS MODIFY(SECTRACE(OFF)) TSS REMOVE(acid) TRACE

Retry request and examine the TRACE information. The TRACE will show the information that is being passed to CA Top Secret along with DRCs and other valuable diagnostic information. The appendix “CA Top Secret Diagnostic Trace“ explains how to read the CA Top Secret TRACE.

Did the TRACE expose the problem?

YES

Go to STEP 4.

NO

Go to STEP 3.

STEP 3

Obtain a dump. Force a dump through your code using: DC F'00' or use the CA Top Secret DIAGTRAP control option. Examine the parameter list that is being sent to CA Top Secret.

Did the DUMP expose the problem?

YES

Go to STEP 4.

NO

Go to STEP 5.


Facility Access

STEP 4

Implement the solution to the problem and retest the customization code.

Was the problem resolved?

YES

Stop.

NO

Go to STEP 5.

STEP 5

Gather all pertinent information. Go to Phase 3 contacting Technical Support.

Facility Access This section details the procedures for investigating the following conditions:

■ Access Incorrectly Allowed

■ Signon Passwords Not Being Checked

■ CPU Restrictions Not Honored

■ Access Incorrectly Denied.

These procedures assume that the reader is familiar with the TSS LIST and TSS MODIFY commands and with the FACILITY, LOG, and MODE control options.

Remember that TSSSIM can be a valuable aid to determine the cause of access discrepancies.


Facility Access

Access Incorrectly Allowed

STEP 1

Determine if the user or profile has been explicitly granted access to the facility. TSS LIST(acid) DATA(BASIC,PROFILE) TSS LIST(ALL) DATA(BASIC)

Does the facility in question appear within the user or profile ACID's Security Record?

YES

TSS REMOVE the facility from the Security Record or remove the user from the profile.

Go to STEP 8.

NO

Go to STEP 2.

STEP 2

Determine the security mode for the facility (or site) and for the user or profile ACID.

Facility

TSS MODIFY(FACILITY(fac))

ACID(s)

TSS LIST(acid) DATA(XAUTH,PROFILE) TSS LIST(ALL) DATA(XAUTH)

Is the user or profile ACID or the facility in DORMANT or WARN MODE?

YES

DORMANT MODE can allow access without security checking. WARN MODE can also allow access, but CA Top Secret should be sending messages to the user's terminal. Consider using the TSS PERMIT command to move the user to a more restrictive security mode (IMPL or FAIL), or set WARNPW for the FACILITY control option. This will prohibit a user from accessing a facility unless he is explicitly authorized.

Go to STEP 3 if WARN MODE;

Go to STEP 6 if DORMANT.

NO

Go to STEP 4.


Facility Access

STEP 3

List the logging options to determine if warning messages are being issued to the user. Ask the user to enter TSS WHOAMI at his terminal.

Is MSG displayed in the LOG field of the WHOAMI response?

YES

Take administrative action. GO TO STEP 8.

NO

The MSG option is not specified, therefore no messages are being sent to the user. Review LOG control options.

Go to STEP 8.

STEP 4

Determine if the user possesses the NORESCHK attribute:

TSS LIST(acid) DATA(BASIC,PROFILE)

Does the user possess the NORESCHK attribute?

YES

TSS REMOVE the NORESCHK attribute from the ACID.

NO

Go to STEP 5.

STEP 5

Determine if user is being allowed to bypass security by locating BYPASS message TSS9530I, on the STATUS response:

TSS MODIFY(STATUS)

Does the user's ACID, jobname or started task name appear in this list?

YES

You must reset BYPASS, TSS BYPASS(RESET). Go to STEP 8.

NO

Go to STEP 6.


Facility Access

STEP 6

Determine if the DRC control option is set to NOVIOL for the returned DRC code:

TSS MODIFY(DRC(drc#))

Is the DRC set to NOVIOL?

YES

See the Control Options Guide to reset the DRC NOVIOL attribute.

NO

Go to STEP 7.

STEP 7

Activate the diagnostic trace for the user. See TSS ADDTO(acid)TRACE in the Command Functions Guide for instructions.

Did trace records not appear for facilities other than TSO, BATCH, or STC?

YES

The site might not have a working interface with CA Top Secret. Ask the site systems programmer to check/install the correct interface. See the appropriate facility implementation guide for installation guidelines.

Go to STEP 8.

NO

See the appendix “CA Top Secret Diagnostic Trace“ for instructions on how to interpret trace information.

Go to STEP 8 when the examination of the trace is completed.

STEP 8

Implement the solution to the problem if this has not been done. If no solution has been determined, GO TO STEP 10.


Facility Access

STEP 9

Attempt to sign on to the facility in question using the ACID in question.

Was access denied?

YES

Stop.

NO

GO TO STEP 10.

STEP 10

Gather all information obtained during previous steps, or gather any procedures, JCL, or STC procedures that are believed to be involved with the problem.

Go to Phase 3 for instructions on how to contact Technical Support.

Signon Passwords not being Checked

STEP 1

Determine user's or profile's security mode:

TSS LIST(acid) DATA(XAUTH,PROFILE)

Is ACID in DORMANT or WARN MODE?

YES

DORMANT MODE might allow access without security checking. WARN MODE might also allow access, but CA Top Secret should be sending messages to the user's terminal. Consider using the TSS PERMIT command to move the user to a more restrictive security mode (IMPL or FAIL). This will prohibit a user from accessing a facility unless he is explicitly authorized. Or assign the WARNPW attribute to the facility: TSS MODIFY((fac=WARNPW)). This will force defined users and jobs to enter their correct passwords while in WARN MODE.

If user is in WARN, GO TO STEP 3.

If in DORMANT, GO TO STEP 7.

NO

GO TO STEP 2.


Facility Access

STEP 2

Determine the facility's mode and attributes.


Is facility in WARN MODE with the NOWARNPW attribute?

YES

WARN MODE, in combination with NOWARNPW, will allow a user to bypass password security checking. Consider using the TSS PERMIT command to move the user to a more restrictive security mode, IMPL or FAIL. This will prohibit a user from accessing a facility unless he is explicitly authorized. Or assign the WARNPW attribute to the facility and TSS MODIFY(FACILITY(fac= WARNPW)). This will force defined users and jobs to enter their correct passwords while in WARN MODE.

GO TO STEP 7.

NO

GO TO STEP 3.

STEP 3

Is facility in DORMANT MODE?

YES

DORMANT MODE might allow access without security checking. Consider using the TSS PERMIT command to move the user to a more restrictive security mode (IMPL or FAIL). This will prohibit a user from accessing a facility unless he is explicitly authorized.

GO TO STEP 7.

NO

GO TO STEP 5.


Facility Access

STEP 4

List the user's logging options to determine if warning messages are being logged. Ask the user to enter TSS WHOAMI at his terminal.


YES

Take administrative action. GO TO STEP 7.

NO

LOG options are not specified, therefore no messages are being sent to the user. Review LOG control options.

GO TO STEP 7.

STEP 5

Determine if user is being allowed to bypass security by locating the BYPASS message TSS9530I, on the STATUS response:

TSS MODIFY(STATUS)

Does the user's ACID, jobname or started task name appear in this list?

YES

TSS REMOVE the applicable bypass attribute from the user's ACID, jobname or started task name.

GO TO STEP 7.

NO

GO TO STEP 6.


Facility Access

STEP 6

Activate the diagnostic trace for the user. See TSS ADDTO(acid) TRACE in the Command Functions Guide for instructions.


YES

The site might not have a working interface with CA Top Secret. Ask the site systems programmer to check/install the correct interface. See the appropriate facility implementation guide for installation guidelines.

GO TO STEP 7.

NO


GO TO STEP 7 when the examination of the trace is completed.

STEP 7

Implement the solution to the problem if this has not been done. If no solution has been determined, GO TO STEP 9.

STEP 8

Attempt to sign on to the facility in question using the ACID and an invalid password.

Was access denied?

YES

Stop.

NO

GO TO STEP 9.

STEP 9




Facility Access

CPU Restrictions not Honored

STEP 1

Determine if the CPU restriction exists for the user(s) and CPU in question.

TSS LIST(acid) DATA(BASIC,XAUTH,PROFILE) TSS LIST(ALL) DATA(XA)

Note: Examine rules for time of day, day of week, and program restrictions, along with any ACTIONS which might be in the PERMITs for the CPU.

Do permissions exist which allow the user to access the CPU?

YES

TSS REVOKE the permissions, or TSS PERMIT the user access to the CPU with ACTION(FAIL,DENY).

GO TO STEP 9.

NO

GO TO STEP 2.

STEP 2

Ensure that the CPU is owned.

TSS WHOOWNS CPU(cpu)

Is the CPU owned?

YES

GO TO STEP 3.

NO

See TSS ADD - CPU in the Command Functions Guide.

If resource is not owned, CA Top Secret cannot restrict access.

GO TO STEP 9.

Note: If the DEFPROT attribute is attached to a particular resource class, then the resource class is protected by default, even if it is not owned.


Facility Access

STEP 3

Determine the security mode for the facility (or site) and for the user or profile ACID(s).

Facility


ACID(s)


Is the ACID(s) or the facility in DORMANT or WARN MODE?

YES

DORMANT MODE might allow access without security checking. WARN MODE might also allow access, but CA Top Secret should be sending messages to the user's terminal. Consider using the TSS PERMIT command to move the user to a more restrictive security mode (IMPL or FAIL). This will prohibit a user from accessing a facility unless he is explicitly authorized.

GO TO STEP 4 if WARN MODE;

STEP 9 if DORMANT.

NO

GO TO STEP 4.

STEP 4

List the user's logging options to determine if warning messages are being logged. Ask the user to enter TSS WHOAMI at his terminal.


YES

GO TO STEP 5.

NO

LOG options are not specified, therefore no messages are being sent to the user. Review LOG control options.

GO TO STEP 9.


Facility Access

STEP 5

Determine if the ACID possesses the NORESCHK attribute:


Does ACID possess the NORESCHK attribute?

YES

TSS REMOVE(acid) NORESCHK

GO TO STEP 9.

NO

GO TO STEP 6.

STEP 6

Determine if the DRC control option is set to NOVIOL for the returned DRC:

TSS MODIFY (DRC(drc#))

Is the DRC set to NOVIOL?

YES

See the Command Functions Guide to reset the DRC.

GO TO STEP 9.

NO

GO TO STEP 7.

STEP 7

Determine if user is being allowed to bypass security by locating the BYPASS message on the STATUS response:

TSS MODIFY(STATUS)

Does the user's ACID appear in this list?

YES

TSS REMOVE the applicable bypass attribute from the user's ACID.

GO TO STEP 9.

NO

GO TO STEP 8.


Facility Access

STEP 8



YES

The subsystem might not have a working interface with CA Top Secret. Ask the site systems programmer to check/install the correct interface. See the appropriate facility implementation guide for installation guidelines.

GO TO STEP 9.

NO


GO TO STEP 9 when the examination of the trace is completed.

STEP 9

Implement the solution to the problem if this has not been done.

GO TO STEP 10.

Note: If no solution has been determined, GO TO STEP 11.

STEP 10


Was access denied?

YES

Stop.

NO

GO TO STEP 11.

STEP 11




Facility Access

Facility Access Incorrectly Denied

STEP 1

Is there a Detailed Violation Reason code (DRC) displayed with the violation?

YES

See “Detailed Reason Codes” in CA Top Secret Messages and Codes to determine if the correct authorizations have been made to ensure access.

NO

GO TO STEP 4.

STEP 2

Was the problem resolved during Step 1?

YES

GO TO STEP 5.

NO

GO TO STEP 3.

STEP 3

Determine the facilities the user is allowed to access through ADD or PERMIT authorizations.

TSS LIST(acid) DATA(BASIC,PROFILE) TSS LIST(ALL) DATA(BASIC)

Do authorizations exist which permit the user to access the facility?

YES

GO TO STEP 4.

NO

TSS ADD the facility to the user's ACID.

GO TO STEP 5.


Facility Access

STEP 4


Did NOTRACE appear for facilities other than TSO, BATCH, or STC?

YES

Facility might not have a working interface with CA Top Secret. Ask the site systems programmer to check/install the correct interface. See the appropriate facility implementation guide for installation guidelines.

GO TO STEP 5.

NO

See the appendix “CA Top Secret Diagnostic Trace“ for instructions on how to diagnose the trace information.

GO TO STEP 5.

STEP 5

Implement the solution to the problem if this has not already been done.

GO TO STEP 6.

STEP 6


Was access allowed?

YES

Stop.

NO

GO TO STEP 7.

STEP 7

Gather all information obtained during previous steps, or gather any procedures, JCL, or STC procedures that are believed to be involved with the problem. Go to Phase 3 for instructions on how to contact Technical Support.


Logging of Events

Logging of Events Whether security events are properly logged is a function of the LOG option which can be issued globally or by facility.

Although the following procedure provides basic checks which should be made to ensure that the LOG options are set correctly, the actual settings for the LOG option will vary from site to site, and from facility to facility. See the chapter “Determine Violation Logging and Reporting” in the Planning Guide and the LOG control option in the Control Options Guide to ensure the proper implementation and use of the LOG control option.

These procedures assume that the reader can use TSSUTIL, TSSTRACK, and TSSAUDIT to obtain logging reports. See the Report and Tracking Guide if unfamiliar with any of these utilities.

CA Top Secret Not Logging Violations

STEP 1

Enter:

TSS MODIFY(STATUS)

Is the site or facility in DORMANT MODE?

YES

CA Top Secret does not perform logging in DORMANT MODE. Upgrade mode of user or facility if logging is desired.

GO TO STEP 4.

NO

GO TO STEP 2.


Logging of Events

STEP 2

Examine the DRC control option setting.

TSS MODIFY(DRC(drc#))

Is DRC set to NOVIOL?

YES

Reset the DRC NOVIOL setting. Enter: TSS MODIFY(DRC(drc#,VIOL))

GO TO STEP 4.

NO

GO TO STEP 3.

STEP 3

Determine if SMF suboption of LOG control option is specified, and examine the CA Top Secret started task procedure to determine if the //AUDIT... statement is included in the procedure. Also, ensure that the Audit/Tracking File exists.

Are SMF and/or //AUDIT specified?

YES

GO TO STEP 5.

NO

Enter: TSS MODIFY(LOG(SMF...))

See the Installation Guide for instructions on how to add the //AUDIT statement to the CA Top Secret started task procedure, and how to create the Audit/Tracking File.

GO TO STEP 4.

STEP 4

Simulate a violation to the facility in question using the ACID in question.

Was the violation logged?

YES

STOP.

NO

GO TO STEP 5.


Logging of Events

STEP 5


CA Top Secret not Logging Access or Initiations

STEP 1

Enter:

TSS MODIFY(STATUS) and TSS MODIFY(FACILITY(fac)) and TSS LIST(acid) DATA(XAUTH,PROFILE) TSS LIST(ALL) DATA(XAUTH)


YES

CA Top Secret does not perform logging in DORMANT MODE. Upgrade the mode of the user or facility if logging is required.

GO TO STEP 3.

NO

GO TO STEP 2.

STEP 2

Are ACCESS or INIT specified as suboptions of the LOG control option?

YES

GO TO STEP 4.

NO

See the LOG or FACILITY control options in the Control Options Guide to enter ACCESS or INIT suboptions.

GO TO STEP 3.


Messages

STEP 3

Simulate the access and initiation attempt using the ACID in question.

Was the access or initiation logged?

YES

STOP.

NO

GO TO STEP 4.

STEP 4


Messages The behavior of CA Top Secret Messages is controlled by the MSG suboption of the FACILITY or LOG control option.

Users not Receiving CA Top Secret Messages

STEP 1

Enter:

TSS MODIFY(STATUS) or

TSS LIST(acid) DATA(XAUTH,PROFILE) or

TSS LIST(ALL) DATA(XAUTH)


Is the site, facility, or user in DORMANT MODE?

YES

CA Top Secret does not perform logging in DORMANT MODE. Consider upgrading the mode of the user or facility if logging is desired.

GO TO STEP 4.

NO

GO TO STEP 2.


Messages

STEP 2

Determine if the MSG suboption of the LOG control option is specified by having the user enter TSS WHOAMI, or enter:


Is MSG specified?

YES

GO TO STEP 3.

NO

See to LOG or FACILITY in the Control Options Guide and enter the MSG suboption.

GO TO STEP 4.

STEP 3

TSS might suppress messages due to entries made through the MSG control option. See the Control Options Guide for instructions on how to check the characteristics of messages through the MSG control option.

Are messages being suppressed unnecessarily?

YES

Make the appropriate entries for the MSG control option.

GO TO STEP 4.

NO

GO TO STEP 5.

STEP 4

Perform access and initiation attempts using the ACID in question.

Were messages received?

YES

STOP.

NO

GO TO STEP 5.


Messages

STEP 5


Console not Receiving CA Top Secret Messages

STEP 1

Enter:

TSS MODIFY(STATUS)



YES

CA Top Secret does not perform logging in DORMANT MODE. Upgrade the security mode if logging is required.

GO TO STEP 4.

NO

GO TO STEP 2.

STEP 2

Determine if the SEC9 suboption of the LOG control option is specified.

Is SEC9 specified?

YES

GO TO STEP 3.

NO

See to LOG or FACILITY in the Control Options Guide and enter the SEC9 suboption.

GO TO STEP 5.


Messages

STEP 3

CA Top Secret might suppress certain messages due to entries made through the MSG control option (such as NOSEC9). See the Control Options Guide for instructions on how to check the characteristics of messages through the MSG control option.

Are messages being suppressed unnecessarily?

YES

Make the appropriate entries for the MSG control option.

GO TO STEP 4.

NO

GO TO STEP 5.

STEP 4

Perform access and initiation attempts using the ACID in question.

Were messages received?

YES

STOP.

NO

GO TO STEP 5.

STEP 5



Resource Access Problems

Resource Access Problems This procedure provides instructions on how to diagnose access authorization problems for:

■ Data Sets

■ Volumes

■ Other ownable resources

CA Top Secret uses an access algorithm to determine whether to grant a user the access that they requested to the resource. This algorithm is detailed in the User Guide.

A thorough understanding of the algorithm, and the control options and commands which affect the algorithm, are prerequisites to the effective use of the following procedures and guidelines.

Use of the TSS LIST command function, and the TSSSIM utility are also prerequisite skills. If you are unfamiliar with any of the aforementioned items, see the appropriate guide for details. See Diagnostic Tools in the appendix, “Diagnostic Tools,” for references.



Data Set or Volume Access Incorrectly Denied

STEP 1

Determine the user's and the facility's mode.

To determine the user's mode, enter:


To determine the facility's mode, enter:


Is user in a more restrictive mode than the facility?

Example: Facility is in WARN MODE, but user is in FAIL.

YES

Permit the user to a less restrictive mode or, PERMIT the user explicit access to the resource.

GO TO STEP 7.

NO

GO TO STEP 2.

STEP 2

Determine if default data set protection is in effect for IMPLement or WARN MODEs.

Enter:

TSS LIST(RDT) RESCLASS(DATASET)

Is the DEFPROT attribute attached to the data set?

YES

PERMIT the user explicit access to the resource.

GO TO STEP 7.

NO

GO TO STEP 3.



STEP 3

Access TSSSIM to simulate a data set access attempt by entering TSSSIM parameters as shown following:

For Enter

ACID User's ACID

FACILITY Facility user had access to when the problem occurred

MODE The facility's mode

TRACE Yes

ACCESS The access that the user requested when access was denied

Note: See the chapter “Using the TSSSIM Utility“ in this guide.

STEP 4

Press Enter.

Was the requested access granted or denied?

DENIED

GO TO STEP 5.

GRANTED

This indicates a probable user error, or system error. Take administrative action.



STEP 5

TSS LIST the user's profiles and user Security Record.

TSS LIST(acid) DATA(ALL,PROFILE) TSS LIST(ALL) DATA(ALL)

Note: Be sure to examine ownership and XAUTH fields, and the security records of any connected profiles. Also, be aware that data set access problems might be caused by volume access rules. CREATE access for data sets might, for example, be overridden by a volume authorization which only allows UPDATE access to data sets on the volume.

Does the display show authorizations at the requested access level and to the resource in question?

YES

GO TO STEP 6.

NO

PERMIT the user access to the resource through the user record, ALL Record, or through connection to a profile which has the appropriate access.

GO TO STEP 7.

STEP 6

Check the settings of the AUTH control option:

TSS MODIFY(STATUS)

Has AUTH been changed after the Security File was originally established?

YES

Attempt to reconstruct Security File to match the required access definitions.

GO TO STEP 7.

NO

GO TO PHASE 3 for instructions on how to contact Technical Support.



STEP 7

See Step 3 for instructions on how to use TSSSIM to perform a simulated data set access attempt.

Was access denied?

GRANTED

Stop.

DENIED

Obtain all information gathered during the previous steps. GO TO PHASE 3 for instructions on how to contact Technical Support.

Data Set Passwords not being Checked

STEP 1

Determine if the data set has the ACTION(PASSWORD) attribute.

TSS WHOHAS DSNAME(data set name or prefix)

Is the ACTION(PASSWORD) attached?

YES

GO TO STEP 2.

NO

To password protect the data set you must PERMIT the data set attaching the ACTION(PASSWORD) attribute. If the attribute is not attached, password protection is overridden by CA Top Secret. See the Command Functions Guide.

GO TO STEP 7.



STEP 2

Determine if the ACID has the NODSNCHK attribute.


Does the ACID have the NODSNCHK attribute?

YES

Remove the NODSNCHK authority. TSS REMOVE(acid) NODSNCHK

GO TO STEP 7.

NO

GO TO STEP 3.

STEP 3

Determine if the user has ACTION(NODSNCHK) authority to the volume.

TSS LIST(acid) DATA(XAUTH,PROFILE)

TSS LIST(ALL) DATA(XAUTH)

Is the volume authorized with ACTION(NODSNCHK)?

YES

CA Top Secret will not perform data set level checking. TSS REVOKE(acid) VOLUME(volser or prefix)

ACTION(NODSNCHK)

GO TO STEP 7.

NO

GO TO STEP 4.

STEP 4

Turn on the TSS TRACE for the ACID in question:

TSS ADDTO(acid) TRACE

If the acid is signed on, issue:

TSS REFRESH(acid)

GO TO STEP 5.



STEP 5

Activate the TRACE from the console:

TSS MODIFY(SECTRACE(ACT,WTL))

GO TO STEP 6.

To turn off the TRACE:

TSS MODIFY(SECTRACE(OFF))

TSS REMOVE(acid) TRACE

STEP 6

Ask the user to access the data set in question. Examine the trace information that is generated.

Is the 04 DRC being returned?

YES

The data set is authorized with ACTION(PASSWORD).

GO TO STEP 8.

NO

An overriding authorization was found in the user acid, connected profiles, or ALL Record. Determine the source of the overriding authorization and REVOKE it from the ACID.

GO TO STEP 7.

STEP 7

Implement the correction described in the previous step. Ask the user to attempt access to the data set.

Was the ACID prompted for the data set password?

YES

The problem is resolved.

NO

GO TO STEP 8.

STEP 8

Gather all previously collected information. Proceed to Phase 3.


Chapter 4: Phase 3—Technical Support This section contains the following topics:

Pre-Call Preparation (see page 57) Contacting Technical Support (see page 59)

Pre-Call Preparation Before contacting Technical Support, attempt to use the Phase 2 diagnostic procedure. If you cannot solve your problem by using the applicable Phase 2 diagnostic procedure, you must prepare the necessary information prior to placing your call. What follows is a list of the information that the CA Top Secret Technical Support technician might want to discuss with you.

Required Information

Prior to calling CA Top Secret Technical Support, obtain the following:

■ All information obtained from the Phase 2 diagnostic process, including violation codes, message numbers, TRACE results, operator console log from the time of the error, TSS LIST results, TSSSIM results, and everything else you know about the problem.

■ CA Top Secret's current maintenance level as obtained through the VERSION control option (see the Control Options Guide for details).

■ Maintenance levels of the software environment, specifically the z/OS JES, DFP release and PUT levels, and the IGC0CLFT FMID for all catalog problems (SVC-1A) are required. This site-dependent information is crucial.

■ Any information regarding special exits or customization strategies.

■ Any information about when the specific problem started and what changes occurred in your system.


Pre-Call Preparation

Enhancing Communication with Technical Support

The information listed above lets you be as specific as possible about the problem. Symptoms such as "it doesn't work", or "getting some message", or "some weird abend", only lead to delays in solving the problem. Have all required information available. If a dump is produced, have a system programmer present to give dump details. Dumps sent to Technical Support must be unformatted. The dump can be sent on tape or FTPed. If FTPing the diagnostic information, contact Technical Support for instructions. See the section in this chapter, Mailing Diagnostic Information, for more details.


Contacting Technical Support

Contacting Technical Support Contact Technical Support for a complete list of CA locations and phone numbers. If you need technical assistance with your product, there are several ways to obtain it:

■ During normal business hours, call the support number for the product with which you are having a problem, and you are connected with a support representative. If a technician is not available, your call is logged and a technician will return your call as soon as possible.

If you are calling with a severity one problem and do not get a technician immediately, the receptionist will ask you if you would like to stay on hold until a technician is available.

Note: Only your local Support Center can provide native language assistance. Use English when contacting any North American center.

■ SupportConnect offers dial-up and online services to provide you with total service and support. You can use SupportConnect to determine if a fix (APAR or PTF) or other solution to your problem has been published. You can also access the latest documentation on SupportConnect.ca.com. To enroll in this service, contact your CA Client Service Representative.

There are two kinds of technical support available: primary and emergency. Primary service is provided for all CA products during normal business hours. Emergency service is available after primary service hours for severity one problems only.

When contacting Technical Support, have the following information available:

■ Your site ID (a six-digit ID which uniquely identifies your site). This number can be found on the labels of most mailings received from CA, or might be obtained from your account manager.

■ The product name, release number, operating system and genlevel.

■ Your name, telephone number, and extension (if any).

■ Your company name.

■ The severity code.

This is a number from one to four that you assign to the problem. Use the following guidelines when determining the severity of the problem:

– A "system down" or inoperative condition

– A suspected high-impact condition associated with the product

– A question concerning product performance or an intermittent low-impact condition associated with a product

– A question concerning general product utilization or implementation



■ Any documentation that might help in resolving the problem, including dumps, compiler listings, and so on.

■ Your CA Personal Identification Number (PIN) which is used to retrieve your contact information. If you do not have a PIN, one can be created when you contact Technical Support.

Note: Requests for services such as orders for documentation, maintenance tapes, requests for products, information about education, on-site assistance, or requests for new features or design changes to CA Top Secret might be directed to your Regional Account Representative.

Problem Escalation

If you wish to change the severity code of a reported problem, contact the support center working on your problem and request the change.

If you feel that your problem is not being adequately addressed by CA, you can escalate your concerns by contacting the following:

■ Level one or level two support manager

■ Product owner

■ Senior Vice President of Research and Development

■ Corporate Help Desk in Islandia

Level One Support

The level one support team handles problems as follows:

■ If the problem appears to be caused by CA Top Secret internals, the technician determines if corrective fixes have been distributed. If the fixes have been distributed, the technician asks the customer to apply the fixes. If no fix exists, the problem is escalated to the Level Two Support Team for further examination.

■ If the problem appears to be caused by customer error, then the technician attempts to help the customer diagnose and resolve the error. The technician asks many of the same questions that were asked by the Phase 2 procedures. If no resolution can be reached, then the problem is escalated to the Level Two Support Team for further examination.

■ Before escalating a problem to Level Two Support, the Level One technician ensures that the customer has prepared information as documented in this guide.

■ If a client calls asking for the status of a case, any technician can offer assistance provided the client has a contact number. The customer should specify that he or she merely wants the status of a particular case.



Level Two Support

The level two support team is responsible to locate the internal errors and provide a fix. These fixes are later incorporated into the standard maintenance tapes. If the level two technician is unable to locate the internal error, or if the error requires major modifications, the request is referred to management for review by development.

Mailing Diagnostic Information

Diagnostic information, such as dump tapes, trace records, and system logs, can be mailed. Consult http://SupportConnect.ca.com for the correct address.

Note: Your CA Top Secret case number and representative must be clearly marked on the package.

SVC dumps must be sent in the form of SYSDUMPS on the 6250-bpi magnetic tape or cartridge. SVC dumps must not be edited in any way, and do not use the AMDPRDMP utility program to format dumps. Do not send SYSDUMPS when a SVC dump is available; under no circumstances should an ABEND-AID dump be sent.

Mark the following information on the tape's external label:

■ Tape label information.

■ Contact number associated with diagnostic materials.

■ Data set name(s).

■ DCB attributes (including RECFM, LRECL, and BLKSIZE).

■ Release of operating system on which material was produced (for example, z/OS/ESA 4.1), as well as the maintenance level of the operating system (for example, 9806).

■ Return address if the tape needs to be returned to your data center.

Materials that are not in the proper form delay problem resolution.


Chapter 5: Performance Tuning Considerations


Statistics Gathering (see page 64) Security File (see page 65) User Authentication (see page 71) Security Records Cache (see page 74) CICS / DB2 Considerations (see page 74)


Statistics Gathering

Statistics Gathering You can set up CA Top Secret to gather statistics for the:

■ Sysplex coupling facility

■ Cache facility

■ Command processor

■ Command processor workload balance

■ Command Propagation Facility (CPF)

■ Input/Output

■ SAF RACROUTE calls

■ Seccache facility

The collected statistics are written to SMF at defined time intervals. Use the TSSRPTSG report to display the saved statistics. Alternatively, a pre-allocated dataset can be specified to allow for browsing the statistics without running the report.

To collect statistics

1. Enter the command:

TSS MODIFY STATSLOG(DSNAME)

DSNAME

Specifies the name of a pre-allocated dataset statistics are written to. The dataset must with the format of RECFM=FB, LRECL=100, DSORG=PS.

Default: SMF


TSS MODIFY STATREC(statrec)

STATREC

Specifies the statistics to be collected. Valid entries are CACHE, CPF, RACROUTE, SYSPLEX, COMMAND, WORKLOAD, IOSTATS, SECCACHE, and ALL.

Default: ALL


TSS MODIFY STATGINT(nn)

NN

Specifies the time interval (in minutes) where statistics are gathered and SMF records are created.


Security File

Default: 15 minutes


TSS MODIFY STATG(ON)

Statistics gathering is activated.

Upon de-activation, a final statistics update occurs. To deactivate statistics gathering, enter the command:

TSS MODIFY STATG(OFF)

CPF Statistics

CPF related event statistics are collected for the number of:

■ Inbound command requests for a particular node

■ Inbound password requests for a particular node

■ Outbound command requests for a particular node

■ Outbound password requests for a particular node

■ Returned outbound requests for a particular node

To display CPF related event statistics, enter:

TSS MODIFY(STATS)

Note: CPF Statistics are displayed only if CPF is active and the control option STATG(ON) is specified.

Security File Several performance considerations related to the Security File are discussed in this section.

Secfile Location

Isolate the security file on a device with nothing else on the disk. This device should be high performance DASD. It is recommended that no other data reside on this device. Fill the remaining DASD space on the volume with a dummy dataset. This prevents someone with access to the volume utilizing the free space. Protect this data from access. If isolating the security file is not an option, make sure that any other data placed on the device is not utilized during prime time business hours.


Security File

Recovery File

The recovery file should not be put on the same volume as the system catalogs or any other system files. A reserve on volume could cause a “system hang” situation resulting from a deadly embrace. This is also true for the audit file.

Avoid putting the RECOVERY file on the same spindle as the SECFILE. If you lose the single device, you will lose both of these files.

CA Top Secret Address Space

The CA Top Secret address space acts as a file server for other address spaces to access the security file. This includes address spaces beyond the z/OS operating system such as LINUX. The CA Top Secret database is accessible, both inbound and outbound, from any LDAP compliant directory.

Communication between address spaces uses CSA and ECSA. The amount of memory utilized is dependent on how you configure CA Top Secret.

Data Integrity

Data integrity must be maintained in a multi-CPU environment. The security file and ATF serialize using the same logic. This logic involves the use of a LOCK record that is stored in the SECFILE. The LOCK record assures that the updating system has complete control of the SECFILE. CA Top Secret does not use a MVS hardware reserve. The Lock record is stored in HDR1 (Header Record One) of the Security File.

Sharing Considerations

Best performance from the security file is to set SHRFILE(NO) in the CA Top Secret parm file.

Important! Only set SHRFILE(NO) when the security file and audit tracking file are not being shared among systems. SHRFILE(NO) causes CA Top Secret to obtain the LOCK record from HDR1 and place it in memory until CA Top Secret is quiesced. With the lock record in memory, CA Top Secret will not need to obtain the lock record before accessing the security file. This could reduce I/O to the security file by as much as 66 percent.


Security File

Acid Index Performance Setting

The CA Top Secret acid index is a directory of the users defined on the security file. It identifies the location of the security record on the SECFILE for each ACID defined to the database. When CA Top Secret initializes, the ACID INDEX is read into memory. Any time an acid record is updated using an administration command, the acid index is refreshed.

The AINDXPER, activated via the SHRFILE control option, provides a file I/O performance improvement when the security file is shared between multiple systems and security administration is being done.

For instance, if three systems are sharing a security file and the administrator changes or creates a new ACID, it causes the index on that system to be updated both in core and on the file and to set flags that the file has changed. When the other systems attempt to access this file, if AINDXPER is not set, it will have to read the entire index. For small files, such as 5000 ACIDs, the reduction in I/0 is insignificant. For larger systems, it can mean CA Top Secret reads one or two tracks rather than several cylinders.

File Sharing and the Coupling Facility

The coupling facility is part of the SYSPLEX technology. CA Top Secret exploits this technology allowing you to store all or a portion of the security file in an XES structure. Performance is improved because the coupling facility is faster than DASD access.

CA Top Secret OPTIONS(61), allows maintaining the security file lock record in coupling facility. Instead of having to go out to the SECFILE to read the lock record, CA Top Secret uses the faster access speed available with the coupling facility.


Security File

CA Top Secret CACHE

The CA Top Secret CACHE provides an area of memory for CA Top Secret to place frequently used items from the security file. The CACHE reduces I/O against the security file and increases system performance. The CACHE option provides a performance benefit for both sharing and not sharing.

The CACHE control option can be modified on the fly or through a permanent update in CA Top Secret PARMS. This includes setting the cache size, turning the cache off, clearing the cache, and listing out the cache statistics.

■ Cache – Control option

■ Nnnn – cache size

■ Off – turn off caching

■ Clear – Force clearing of cache

■ Status – List cache statistics

CACHE and CF Size

To determine the approximate size for the CACHE and CF XES structure use the TSSFAR UTILITY. When TSSFAR is run with the SFSTATS parameter, the recommended sizes for both the CACHE and XES is listed in the output of the job.

You may need to adjust the size depending on your findings. For instance, if message TSS1301I CACHE HAS BEEN CLEARED occurs too often, increase the cache size. To determine if the CACHE has cleared, issue a TSS MODIFY CACHE(STATUS). The output line TSS1307I CLEARED (nnnnn) increments once each time the cache is cleared. This value is cleared when you recycle CA Top Secret.

The coupling facility XES structure gets cleared when the structure becomes 95% full. A message is sent to the console when the structure hits 75% full. Then, the message is resent every additional 5%. For example: Message: TSS9746I C.F. XES is now 075% full .


Security File

Security File Cache

SECCACHE provides a cache for CA Top Secret security records that reflect the status of a user following a RACROUTE VERIFY request. The cache is managed in a common data space that can be accessed from all address spaces.

Use SECCACHE to:

■ Reduce the CPU cycles required to process RACROUTE VERIFY requests in both the user and security manager address spaces. In many cases, multiple RACROUTE VERIFY requests are performed to complete a single user logon. After the first RACROUTE VERIFY request is cached, subsequent requests by the same user in the same or different address space do not queue the security manager address space.

■ Reduce file I/O in an environment where the security file is shared between multiple systems.

You can use SECCACHE to generate a comprehensive status display. Use the status display run-time information to tune SECCACHE by balancing the commitment of virtual storage with optimal system performance.

To recover unused space, SECCACHE record entries can be set to automatically expire at regular intervals or they can be force purged by command. The longer a record remains in SECCACHE, the more future requests it can handle. The percentage of requests satisfied by SECCACHE indicates how well the SECCACHE is performing.

Once activated, the SECCACHE data space remains intact during a temporary shutdown and restart of the security manager address space. This preserves the security records already cached.

Use the status display to monitor both your data and index area usage. Set a threshold full warning level during initialization that automatically attempts to recover space by clearing expired entries. The warning level applies to both the data and index areas independently. If the automated recovery process cannot recover sufficient space a warning message is sent to the operator console and remains there until sufficient space is recovered, the SECCACHE is deactivated, or the security address space is terminated. Records can be added to SECCACHE until the areas become 100% full.

The SECCACHE control option can be modified online or through permanent update in the eTrust CA-Top Secret PARMS. This includes setting the SECCACHE initialization options, turning SECCACHE off, clearing records from SECCACHE, and listing SECCACHE statistics.


Security File

Security File Cache Size

SECCACHE requires a commitment of virtual storage in the form of a common data space. The maximum size of the SECCACHE is 2 gigabytes. Start with less and use the status display to tune the size. To estimate the optimum size for SECCACHE use the formula:

SECCACHE Size = 1.01 * ( ACID# ( AVGRECSZ + 16 ) )

ACID#

The number of user ACIDs that "log on".

AVGRECSZ

The average record size from the SECCACHE(STATUS) display.

Example: calculating SECCACHE size

In this example, the number of ACIDs is 25,000 and the average record size is 4200:

1.01 ( 25,000 ( 4200 + 16 ) ) = 102 megabyte

SECCACHE in a Shared Security File Environment

In a shared security file environment, it is important that policy changes made on one system are reflected within any in-core processing tables on all remote systems as soon as possible. This is accomplished internally when a security file I/O is performed on the remote system, for example when a user logs on.

The SECCACHE control option eliminates much of the security file I/O associated with a user log on event. To improve the synchronization an internal processing event performs any in-core table refresh, if required, at the end of two TIMER cycles. This keeps the tables up to date even though the security file has not been accessed. You can manually synchronize the in-core tables with the MODIFY SYNCH control option. This allows you to immediately see the effects of remote changes to selected SDT records with the TSS LIST command.


User Authentication

Tuning CPF

Command Propagation Facility (CPF) provides synchronization of Security Files across the enterprise. This lets you take advantage of the performance benefit you get when not sharing the Security File.

As discussed earlier, running with the SHRFILE control option set to NO eliminates lock file contention.

Additional things to remember:

■ Digital Certificate related commands are not CPF.

■ CPF is designed to synchronize normal everyday processing. It is not meant for massive command updates. Massive updates should be run in batch mode using TARGET (LOCAL).

User Authentication The most important function of security is system entry validation. This includes validation of an ID and PASSWORD followed by retrieval of authorizations the user can access.


User Authentication

CICS Performance Considerations

The facility control option LOCKTIME assigns the amount of time in minutes after which a terminal connected to a specific facility will lock if CA Top Secret does not detect activity.

When running with LOCKTIME active and LTLOGOFF set to NO, the USER remains active in the CICS region taking up CICS resources.

■ LOCKTIME with LTLOGOFF set to YES, user will cause the user to be signed off.

■ PCLOCK parm on the facility controls the handling of the locktime prompting.

■ PCLOCK= YES the prompting is Pseudo conversational

■ PCLOCK=NO the prompting is conversational

The recommended setting for PCLOCK is:

TOR - PCLock = YES AOR/FOR = PCLock = NO - eliminates exit point

Set your TOR to PCLOCK = YES. This ensures that the TOR locktime is Pseudo conversational. Since the AOR and FOR types are not terminals, we recommend PCLOCK = NO. This eliminates the exit point needed to manage lock time.

Conversational CICS TCA slot is tied up until password is entered Pseudo conversational does not tie up CICS resources waiting for a reply. Replace with an CA Top Secret task freeing up the CICS TCA slot.


User Authentication

CICS Signon Sub-Tasking

CICS signons are sub tasked. Five signon subtasks are allocated by default. CA Top Secret allocates five subtasks when the CICS facility is initialized.

To determine the maximum number of signon subtasks controlled by CA Top Secret facility parms setting use:

MAXSIGN (10, retry) - facility defaults

Extra subtasks (6 through 10) are allocated as needed automatically until the MAXSIGN is hit. Specifying RETRY means that Signon/Signoff requests that exceed threshold are requeued.

Notes:

■ Do not set MAXSIGN to KILL since this can cause unwanted system dumps.

■ On average, each signon subtask takes up to 40K of High Private below the line for MVS control block.

Shared Profile Table

The shared profile table allows CA Top Secret profile sharing in multi-user address space environments such as CICS and IMS. CA Top Secret validates authorization checks without leaving the region’s address space. PROFILE sharing is only available at the facility level. To activate or deactivate this option, specify the facility control option SHRPRF or NOSHRPRF.

The number specified in the PRFT Facility Option is in PAGES. Each page holds 256 profiles that are stored in above the line storage storage.

Limit profile administration to off-peak hours for profiles you expect to be shared. Excessive administration for profiles in the table during peak use of the facility can result in having multiple copies of the same profiles stored in the table. The following message is posted when profile table is full:

TSS0960E SHARE PROFILE TABLE FULL – jobname

For example, a region supporting 250 users, each sharing three common profiles, where each user also has one unique profile, must have a shared profile table with no less than 253 entries: PRFT=1.

The default is PRFT=3. It supports profile sharing of up to 768 unique, active profiles within the region. If this value is changed using the TSS MODIFY command, the region must be recycled for the change to take effect.


Security Records Cache

Security Records Cache The caching of security records in an data space improves system performance by re-using the security records on subsequent user log ons.

To activate the security record cache, enter:

TSS MODIFY SECCACHE(nnnn)

nnnn

Specifies the number of megabytes of available memory allocated as a data space for security record caching.

Maximum: 2 gigabytes

To deactivate the security record cache, enter:

TSS MODIFY SECCACHE(OFF)

To insure that the security record cache is available from the time that CA Top Secret is initialized, add the setting to the control options parameter file.

CICS / DB2 Considerations The userid used when CICS accesses DB2 is determined by the setting of AUTHTYPE parm in the RCT or CSD:

■ AUTHTYPE = USERID, DB2 is passed from CICS userid only and must issue the SAF call to sign on the user.

■ AUTHTYPE = GROUP, DB2 is passed on to both the userid and a pointer to the ACEE which DB2 can use without issuing a signon.

The DB2 subsystem has two CICS exit points for authorization routines:

■ DSN3@SGN is for sign-on processing

■ DSN3@ATH is for connection processing

Depending on what AUTHTYPE is set, will determine whether a signon will be done.

TSSDB2 Considerations

eTrust® CA-Top Secret® Security Option for DB2 is a separate product that works with CA Top Secret Security for z/OS. DB2 permissions are externalized and administrated like any other CA Top Secret permission. CA Top Secret profiles eliminate the need for secondary AUTHIDs.


CICS / DB2 Considerations

Performance Related Statistics

To expedite a resolution for performance related issues, the CA Top Secret support team requests you automatically issue the TSS MODIFY(STATS) command on an hourly basis.

The output of the command lists the current statistics (at the time the command was issued):

INIT Job initiations validated. XREQ Cross memory requests processed. SMF SMF security records logged. CHNG Number of changes made to the security file. AUD Number of Audited events recorded in the ATS. READ Number of Secfile reads. WRIT Number of Security file writes

#REQ Number of Requests pending execution HWM High water mark is the highest amount reached for waits on the queue. LOCK Number of times lock was requested LWT Number of times we couldn’t get the lock Divide LWT by LOCK = Percentage of time waiting for the lock.

In addition, CA Top Secret Technical Support will want to see RMF Reports against the device the security file is on. If you are not already doing so, benchmark several transactions for response time and volume trends. Usually, performance problems creep up because of some added workload or system configuration change. Having a significant history of benchmark data available will do two things:

■ Predict and avoid performance problems before they occur.

■ Expedite resolving performance issue


Chapter 6: Using the TSSSIM Utility This section contains the following topics:

Introduction (see page 77) Authority and Scope (see page 78) TSSSIM Facilities (see page 78) System Environment Commands (see page 93) LOGON/SIGNON (see page 93) Simulated Resource Commands (see page 98) Special Commands (see page 141) Simulator Trace Information (see page 144)

Introduction The Security Simulation Utility (TSSSIM) gives the security administrators the ability to test permissions on the Security File without affecting the "real" production environment. When the administrator invokes the security simulator and performs a simulated LOGON/SIGNON for a specified user, he can test the Security File permissions (even simulating FAIL mode processing while the system may still be in DORMANT mode).

Testing of the security permissions consists of invoking a simulation resource command (or one of the simulator's TSO/SPF panels) for the desired resource. TSSSIM will report whether the currently active simulated ACID has access to the resource under the conditions specified by the administrator. Resource qualifying conditions that may be simulated include SVC-in-control, access level, and privileged program.

In addition, the simulator can also be used as a diagnostic tool when the administrator needs to "debug" errors in the Security File permissions. Often, when a user has several profiles attached to his ACID, it may become difficult to isolate which permission has allowed or denied access to a particular resource. By interpreting trace information generated by the security algorithm, TSSSIM can isolate the exact permission or ownership as well as indicate which record (user, profile, or all) contained the permission.

TSSSIM can be executed under the following facilities: TSO (both SPF and non-SPF environments), BATCH, and Advantage™ CA-Roscoe®. TSSSIM under TSO in a non-SPF environment is discussed in the sections immediately following the sections on the administrator's authority and scope. The other facilities can be found under TSSSIM Facilities in this chapter.

Error messages and abend codes for TSSSIM can be found in the Messages and Codes Guide.


Authority and Scope

Authority and Scope TSSSIM is only available for use by administrators having the following authority:

TSS ADMIN(acidname) MISC1(TSSSIM)

A simulated signon can be initiated for any ACID in the Security File, including those not within the administrator's scope. However, the resource checks that the administrator may issue depend on the following:

■ If the ACID lies within the administrator's scope, he may issue resource checks against any resource in the Security File.

■ If the ACID does not lie within the administrator's scope, he may issue resource checks against only those resources that lie within his scope.

TSSSIM Facilities The TSSSIM utility can be executed under the TSO (both SPF and non-SPF environments), BATCH, and Advantage CA-Roscoe environments. The following sections describe how TSSSIM operates in the above-mentioned facilities. TSO in a non-SPF environment is described in Using TSSSIM/TSO (Non-SPF Environment).

Using TSSSIM/TSO (Non-SPF Environment)

Under TSO in a non-SPF environment, TSSSIM is exclusively command-driven. Once the administrator logs on he can invoke a command for the desired resource check, information about the simulator, or user-modifiable tables within CA Top Secret. In addition, the administrator can also invoke the TSS administration command from directly within the simulator.

In order to receive all messages from TSSSIM at the TSO session terminal, the user must assure that the TSO session PROFILE WTPMSG is set prior to initiating TSSSIM. If PROFILE NOWTPMSG is set, some messages may be routed to the operator console, where the user may not be aware they have been posted.

The appropriate commands to perform the above-mentioned functions are discussed in the subsequent headings.


TSSSIM Facilities

Using TSSSIM/TSO (SPF Environment)

To use TSSSIM under TSO in a SPF environment, the administrator must access the panels by entering the number for the TSSSIM option on the SPF main menu.

TSSSIM will return a message telling the administrator that a successful simulated session has been established. If there are any restrictions, the simulator will return a message indicating that an ACID is suspended, a facility is currently deactivated, and so on. Press the END PF key to clear the message and return to the Logon panel.

When using the Logon panel (see Security Simulator Logon Panel), the simulated ACID and facility fields are the only fields that must be specified; all others are optional.

Note: HELP can be entered on any of the OPTION or COMMAND lines of the SPF panels. To return to the original panel from which HELP was issued, press the END PF key.

Each resource class has its own panel. The special commands (EJECT, STATUS and TSS) are recognized only when they are entered on the command line from one of the panels.

Note: The special commands will not work on command lines within a panel that was issued by another command.

These commands generate output to an ISPF table. This is particularly useful for commands (such as TSS LIST) that generate lengthy output, since the output resides in a normal ISPF table. Pressing the END PF key destroys the output and returns control to the previously displayed panel.

Note: The following notes apply when using TSSSIM panels:

■ The following commands are not honored when using TSSSIM in a SPF environment: LOGON, LOGOFF, QUIT, END, and ENVIRON.

■ To change the environment of a signed on simulated ACID, the administrator must return to the logon panel and specify the ACID name and FACILITY.

■ The FACILITY field on all panels after the logon panel must be clear before pressing Enter otherwise a TSS8361E message is issued indicating keyword FACILITY is invalid.

If an administrator chose number 7 on the Resource Selection panel (see Security Simulator Resource Selection), he would receive a display for data set checking with the default parameters supplied.


TSSSIM Facilities

Summary information regarding whether the data set access was allowed or denied would appear in the TSS Response block on the panel (see Data Set Resource Selection).

If an administrator chose number 31 on the Resource Selection panel, he would receive a display for checking a resource that was already defined to the RDT Record. Summary information including whether the resource was allowed or denied access would appear in the TSS Response block on the panel.

TSO Online Tutorial

As an added feature, there is an online tutorial for TSSSIM. If an administrator wishes to use it, he simply enters number 16 on the CA Top Secret Selection Menu and presses the Enter key.

On the OPTION line of the Logon panel (see Security Simulator Logon Panel), he can enter HELP. When the Enter key is depressed, he will receive a menu with all the topics and their respective numbers that are contained in the tutorial. At this point, he can enter an appropriate number from the menu display, or enter HELP again. If he enters HELP, a display will provide all of the PF keys and abbreviated forms he can use to "navigate" within the tutorial.

Note: Each resource is documented on a separate panel.


TSSSIM Facilities

Using TSSSIM in TSO/E-Background or TSO/E-Batch

The outputs of TSSSIM produced in TSO/E-Native and TSO/E-ISPF modes under TSO/E-Foreground are exactly same.

To get the same output from TSSSIM running in TSO/E-Background use the following JCL:

//stepname EXEC PGM=IKJEFT01

//SYSIN DD DUMMY

//SYSTSPRT DD SYSOUT=A //SIM$$OUT DD SYSOUT=A //SYSTSIN DD * TSSSIM

//SIM$$IN DD * (TSSSIM commands) //

Use the following JCL to invoke the simulator in a TSO/E-Batch environment to perform resource checking for a dataset 'SYS1.LINKLIB' with or without the ACCESS parameter:

//stepname EXEC PGM=IKJEFT01

//SYSIN DD DUMMY

//SYSTSPRT DD SYSOUT=A //SIM$$OUT DD SYSOUT=A //SYSTSIN DD * TSSSIM

//SIM$$IN DD * LOGON ACID(USER01) FAC(TSO) TRACE $DSN('SYS1.LINKLIB') $DSN('SYS1.LINKLIB') ACC(UPADTE) $DSN('SYS1.LINKLIB') ACC(UPDATE) PRIVPGM(IEBCOPY) END //


TSSSIM Facilities

Using TSSSIM/BATCH

Since the security administrator is meant to test security permissions resident on the Security File, the administrator may choose to design a series of tests that should be run after major changes are made to the Security File. Rather than enter lengthy commands repeatedly each time the test is run, the administrator can save the commands, and subsequently submit batch tests when required.

The format of the commands should follow the general simulator command format as described in the previous discussions and examples. All commands are supported in the batch environment, although the simulator trace information is somewhat condensed, but very straightforward. In addition, the EJECT command is a batch-only command, and causes a page eject before the next command is executed by the simulator.

The necessary JCL to execute the simulator in a batch environment is described below:

//SIMULATE EXEC PGM=TSSSIM //SIM$$LOG DD SYSOUT=A //SIM$$IN DD *

.

.

. (TSSSIM commands)

/* //

The following sample JCL illustrates how the simulator can be invoked in a batch environment to perform resource checking on a data set 'SYS1.PROCLIB' with UPDATE access. The data set can only be accessed through a privileged program called IEBUPDTE. Also, a DASD volume SYSRES is checked with CREATE access. The administrator will sign on with the simulated ACID USER01 in a TSO facility. The TRACE function is also activated.

//SIMULATE EXEC PGM=TSSSIM

//SIM$$LOG DD SYSOUT=A //SIM$$IN DD * LOGON ACID(USER01) FACILITY(TSO) TRACE $DSN('SYS1.PROCLIB') ACC(UPDATE) PRIVPGM(IEBUPDTE) $DASDVOL(SYSRES) ACC(CREATE) END /*


TSSSIM Facilities

Using TSSSIM and Advantage CA-Roscoe

The security simulator can be accessed by authorized administrators while signed on to Advantage CA-Roscoe by invoking the Advantage CA-Roscoe monitor command SIM. TSSSIM under Advantage CA-Roscoe is exclusively a command-driven utility. Usually both input and output are directed at the terminal; however, alternate input sources and output destinations are supported as follows:

SIM

Input read from the terminal, output directed to the terminal

SIM-I

Input read from the AWS, output directed to the terminal


TSSSIM Facilities

Logging on to TSSSIM

In TSO (non-SPF environment), the simulator is invoked by entering TSSSIM once READY is displayed. After invoking TSSSIM, a simulation session begins by entering the LOGON or SIGNON command. The administrator must specify at least the user ACID whose Security File permissions he wishes to check, and the facility. For example:

LOGON ACID(acid) FACILITY(TSO)

The following optional parameters can be used with the LOGON/SIGNON command:

MODE

Specify DORM, WARN, IMPL, or FAIL; the default is FAIL. This parameter indicates the security mode in which the simulated session will operate.

CPU

Specify DORM, WARN, IMPL, or FAIL; the default is FAIL. This parameter indicates the security mode in which the simulated session will operate.

Specify any four-character SMF CPU ID The default is the CPU to which the administrator is currently signed on.

TERMINAL

Specify any valid VTAM or TCAM network terminal ID. The default is the terminal to which the administrator is currently signed on.

SVC

Specify the valid SVC name that must be among the list of SVC names allowed by TSSSIM; the default is OPEN. This SVC is automatically passed as the SVC in control for all resource checks unless explicitly overridden on individual resource-check commands.

The list of SVC names that are allowed by TSSSIM can be found in this chapter in the section, Simulated Resource Commands.

PRIVPGM

Specify any valid z/OS program name. This program is automatically passed to all simulated resource commands to simulate proper PRIVPGM restrictions unless explicitly overridden on individual simulated resource commands. PRIVPGM can only used on general resource classes. It is not valid for prefixed resources such as dataset.

TRACE

Controls the simulation trace facility and can be specified as TRACE or NOTRACE; the default is NOTRACE. When activated, each resource check will pinpoint the exact reason for resource access or denial.

QUALIFIER


TSSSIM Facilities

Specify any high-level qualifier to be issued as part of the data set name. This qualifier will automatically be passed as part of the data set name for all resource checks issued unless specifically overridden on individual resource commands.

The name specified on the LOGON/SIGNON command (or panel) can be overridden on certain resource commands, such as $DSN. This is useful when checking security permissions that use program pathing.

TSSSIM Commands in General

TSSSIM is basically a command-driven facility. Once TSSSIM is invoked, simply enter the appropriate commands and any qualifying parameters, if applicable. TSSSIM will simulate a logon for a specific user, perform resource checking, as well as act as a diagnostic tool.

TSSSIM commands can be divided into three discrete types: system environment, resource, and special.

For your convenience, all commands are listed according to type and are accompanied by a brief description. The commands then appear individually with more detailed information.

System Environment Command

LOGON/SIGNON

Initiates a simulated ACID session.

LOGOFF/SIGNOFF

Terminates a current simulated session.

HELP

Generates a help listing.

ENVIRON

Changes the simulated ACID environment.

END/QUIT

Exits the Security Simulator.


TSSSIM Facilities

Simulated Resource Command

All simulated resource commands are prefixed by a dollar sign ($) with the exception of user-defined resources, which are prefixed by an at sign (@).

$ABSTRACT

Checks Abstracts

$ALT-ACID

Checks acid cross-authorization

$APPCLU

Checks logical units

$APPCPORT

Checks the VTAM logical unit name

$APPCSI

Checks access authorization to APPC side information files.

$APPCTP

Checks use of transaction programs and profile.

$APPL

Checks IMS Application Group Names

$AREA

Checks IDMS Areas

$CAADMIN

Checks CA Administrative functions

$CACCFDSN

Checks AllFusion™ CA-Librarian® data sets

$CACCFMEM

Checks AllFusion CA-Librarian CCF members

$CACMD

Checks CA Commands

$CALIBMEM

Checks AllFusion CA-Librarian members

$CAPCLU

TSS/PC Logical Unit

$CAREPORT

Checks Unicenter™ CA-Dispatch® reports


TSSSIM Facilities

$CATAPE

Checks BrightStor™ CA-1® Resources

$CAVAPPL

Checks CA VTAM applications

$CIMS

Checks security for IMS commands

$CPCMD

Checks VM CP commands

$CPU

Checks CPU resources

$DASDVOL

Checks DASD volume accesses

$DATABAS

Checks ABABAS databases

$DBD

Checks IMS Database Descriptors

$DB2

Checks DB2 databases

$DB2BUFFP

Checks DB2 buffer pools

$DB2COLL

Checks DB2 collections

$DB2DBASE

Checks DB2 databases.

$DB2PKG

Checks DB2 packages.

$DB2PLAN

Checks DB2 plans.

$DB2STOGP

Checks DB2 storage groups.

$DB2SYS

Checks DB2 system privileges and authorities.


TSSSIM Facilities

$DB2TABLE

Checks DB2 tables.

$DB2TABSP

Checks DB2 table spaces

.$DCSS

Checks VM Discontiguous Saved Statements (DCSS).

$DCT

Checks CICS Destinations.

$DEVICES

Checks z/OS Allocation of UR, graphic, or teleprocessing devices.

$DIAG

Checks VM Diagnose instructions.

$DIRECTORY

VM SFS Directory

$DLFCLASS

Checks DLF data sets.

$DLISEG

VSE DL/I Segment

$DSN

Checks z/OS data sets.

$DSPACE

VM Dataspace

$DTADMIN

DT Administration

$DTSYSTEM

DT System Data

$DTTABLE

DT Table Data

$DTUTIL

DT Utility

$FCT

Checks CICS Files.


TSSSIM Facilities

$FIELD

Checks user-defined resources.

$IBMFAC

Checks IBM facility resources.

$IBMGROUP

Checks for IBM Group resources.

$IUCV

Checks IUCV Communications targets

$JCT

Checks CICS Journal Control Tables.

$JESINPUT

Checks JES job sources.

$JESJOB

Checks JES job names.

$JESSPOOL

Checks JES Spool Data Sets (SYSIN and SYSOUT).

$JOBNAME

Checks z/OS JES2/JES3 job names.

$LCF

Checks LCF commands and transactions.

$LFSCLASS

LF Class

$MDISK

Checks VM minidisks (for the VMMDISK resource class).

$MGMTCLAS

Checks SMS management classes.

$MQADMIN

MQ Administration

$MQCMDS

MQ Commands

$MQCONN

MQ Connections


TSSSIM Facilities

$MQNLIST

MQ Names

$MQPROC

MQ Procedures

$MQQUEUE

MQ Queues

$NODES

VTAM Nodes

$OPCMD

Checks system operator commands.

$OPERCMD

Checks JES, z/OS, operator commands.

$OTRAN

Checks OTRAN (ownable transactions).

$PANAPT

AllFusion™ CA-PANAPT® Functions

$PANEL

Checks panel authorizations for CA products.

$PGM

Checks z/OS programs.

$PPT

Checks CICS programs.

$PROPCNTL

Checks automatic propagation on batch jobs.

$PSB

Checks IMS PSBs.

$PSFMPL

Checks PSF security functions.

$RECIPID

Checks CA-Dispatch recipient IDs.

$RESLIST

Resource Names


TSSSIM Facilities

$SCHEDULE

Checks CA-Scheduler schedules.

$SDSF

Checks the SDSF interface.

$SFSCMD

VM SFS Commands

$SMESSAGE

Checks TSO message sending.

$SPI

Checks CICS system functions.

$STATION

Checks CA-Scheduler stations.

$STORCLAS

Checks SMS storage classes.

$SUBMIT

Checks ACIDs job submissions.

$SUBSCH

Checks IDMS subschemas.

$SYSCONS

Checks System consoles.

$TAPEVOL

Checks tape volumes.

$TERM

Checks network terminal IDs.

$TOTAL

Checks ENVIRON/1 totals.

$TSAF

Checks VM TSAF connections.

$TSOACCT

Checks TSO account codes.

$TSOAUTH

Checks TSO user attributes.


TSSSIM Facilities

$TSOPRFG

Checks TSO performance groups.

$TSOPROC

Checks PROCs used for TSO logon.

$TST

Checks temporary CICS storage names.

$UR1

Checks for general UR1 resource names.

$UR2

Checks for general UR2 resource names.

$USER

Checks for user non-ownable resources.

$USRCLASS

Checks SDSF USRCLASSES.

$VMANAPPL

Checks Unicenter® CA-VMAN® applications.

$VMCF

Checks VMCF communication targets.

$VMDIAL

Checks virtual machines with DIAL access security.

$VMMACH

Checks virtual machine logons.

$VMNODE

Checks VM nodes.

$VMRDR

Checks virtual machine readers.

$VTAMAPPL

Checks ACB open authority from non-APF programs.

$VXDEVICE

Checks VAX devices.

$VXFILE

Checks VAX files.


System Environment Commands

$WRITER

Checks processing of output to specific devices.

@cccccccc

Checks user-defined resources added to the RDT Record

Special Commands

EJECT

Generates a page eject for a batch listing.

STATUS

Displays current simulation status.

TSS

Invokes the TSS command for administrators.

System Environment Commands The system environment commands allow administrators to log on and off of TSSSIM, issue help requests for any command, and exit the simulator. Each command is discussed on the following pages and includes this information: function, the security macro invoked, any parameters that may be used to qualify the command, an example, and any additional comments.

LOGON/SIGNON Initiates a simulated ACID session.

In TSO (a non-SPF environment), the simulator is invoked by entering the command TSSSIM from the READY prompt. A simulation session should then begin with the LOGON subcommand:

LOGON ACID(acid) FACILITY(facility-name)

Security Macro:

RACROUTE REQUEST=VERIFY


LOGON/SIGNON

Parameters

ACID, CPU, FACILITY, MODE, PRIVPGM, SVC, TERMINAL, TRACE

The operands ACID and FACILITY are required:

ACID(acid)

Select the acid whose session you will simulate with TSSSIM. A password is not used with a TSSSIM signon.

FACILITY(facility-name)

Select the facility you are simulating for your TSSSIM session. Note that if you are planning to test maskable resources with TSSSIM, this facility-name must have the RES suboption; otherwise, the simulation may not accurately reflect the permissions for maskable resources.

After invoking the Security Simulation Facility by entering TSSSIM, an administrator logs on with the simulated ACID in a TSO facility. He enters the following:

LOGON ACID(acid) FACILITY(TSO)

or

SIGNON ACID(acid) FACILITY(TSO)

TSSSIM will return a message telling the administrator that a successful simulated session has been established. If there are any restrictions, the simulator will return a message indicating that an ACID is suspended, a facility is currently deactivated, and so on.

The command SIGNON is an alias for the command LOGON in TSSSIM. The effect of these two commands is identical regardless of the facility invoked.


LOGON/SIGNON

LOGOFF/SIGNOFF

Terminates a current simulated session.

Parameters: None.

Example: When ready to end a simulated session, the administrator enters one of the following commands:

LOGOFF

Or

SIGNOFF

The SIGNOFF or LOGOFF command has the same effect and can be used interchangeably. The administrator must be logged on to execute the LOGOFF/SIGNOFF command.


LOGON/SIGNON

HELP

Without any accompanying TSSSIM command or asterisk, it will generate a listing of all commands and a brief description of each.

When accompanied by a command, it will give a brief description of the command as well as its command class, attributes, and qualifying parameters.

Parameters: Any valid TSSSIM command names.

Example: When an administrator wishes to acquire a listing of all TSSSIM commands, she enters:

HELP

If an administrator wants to know more about the $DSN command, she enters:

HELP $DSN

She then receives the following information concerning $DSN:

COMMAND NAME = $DSN DESCRIPTION = RES CHECK - OS DATASETS COMMAND CLASS= DATASET (C4) ATTRIBUTES = LOGON-REQUIRED,NEWRB PARAMETERS = ACCESS,NEWDSN PARAMETERS = PRIVPGM,SVC,TRACE,VOLUME,XACCESS

The NEWRB indicates that if PRIVPGM is specified, TSSSIM will generate another RB to simulate the one in the CA Top Secret PRIVPGM.

COMMAND CLASS indicates the security class in which this resource resides.

If an administrator enters:

HELP *

she will receive the same information as illustrated above, but for every command.


LOGON/SIGNON

ENVIRON

Changes the simulated ACID environment.

Parameters: CPU, MODE, OWN, PRIVPGM, SVC, TERMINAL, TRACE

Example: An administrator originally logged on with a simulated ACID in FAIL mode.

He now wishes to change the environment of the simulated ACID to WARN mode and put a trace on all resource checks. He enters the following:

ENVIRON MODE(WARN) TRACE

END/QUIT

Exits the Security Simulator Facility.

Parameters: None.

Example: When an administrator wishes to exit the simulator, he enters:

END

Or

QUIT

You may enter either of these commands at any time during a simulated session.

If you enter QUIT or END before entering the LOGOFF or SIGNOFF command, it will terminate the session as well as exit the simulator.


Simulated Resource Commands

Simulated Resource Commands The simulated resource commands allow the administrator to choose the type (or class) of resource he wishes to check. Resource checks for the specific resource are passed to CA Top Secret on behalf of the simulated ACID. Summary information regarding whether the resource access was allowed or denied is displayed and includes the following:

■ Return codes and reason codes from the respective security routine.

■ Violation messages (which would be received by the user if the user was in IMPL or FAIL mode).

■ A status message indicating if access would have been actually allowed or denied, based on the simulated mode.

Basically, all of the specific commands provide a similar function in that they pass a resource-check command to the simulator which, in turn, issues a security request to CA Top Secret. The only real difference between the individual commands is the different parameters that are allowed. For example, certain resources allow access-level checks, while a few do not.

Note: Only one resource check can be performed for each command. Generic prefixing is not honored.

Each command is discussed in detail, and includes the following information: function, the security module invoked, any parameters that may be used to qualify the command, an example, and any additional comments.

Note: To perform a resource check for a facility different from the one you are signed on to, log off and then log on to the new facility using the LOGON command (explained earlier in this chapter).

The following is a brief description of the resource qualifying parameters. The discussion of individual resource commands will indicate which parameters are valid.

ACCESS

Specifies the name of the access level for the resource check.

OWN

Valid for resources that use the RACROUTE REQUEST=FASTAUTH security module; the default is NOOWN. If OWN is specified, it indicates that CA Top Secret should assume the resource is owned, and not check its Global Resource Table to see if the resource entity (or prefix) is defined.

Whether OWN is specified or not, if the resource is not owned, the access is denied.



PRIVPGM

Specifies the program in control when the resource check is to be issued. PRIVPGM can only used on general resource classes. It is not valid for prefixed resources such as dataset.

SVC

Specifies the SVC in control when the resource check is to be issued. The following list of SVC names are allowed by TSSSIM:

■ ALLOCATE

■ CATALOG

■ CREATE

■ FEOV

■ OPEN

■ RENAME

■ SCRATCH

The default is OPEN.

TRACE

If TRACE is specified, it indicates that the trace feature is to be enabled so that the exact permission causing the resource access or denial can be located. The default is NOTRACE.

XACCESS

Specifies a two-byte hexadecimal code equating to specific access level(s). If specified, this overrides the default access value used with the specified SVC name. This is especially convenient if you need to check a combination of access levels. For example, in an SPF environment, you can not enter more than one access level with the ACCESS keyword. For more detailed information, see the examples for the $DBD and $TST commands in this section.



$ABSTRACT

Issues a security check for abstract resources.

Security Macro: RACROUTE REQUEST=FASTAUTH

Parameters: PRIVPGM, OWN, TRACE

Example: An administrator wishes to issue a security check to see if the current simulated ACID can access account numbers beginning with the prefixes RCS and CS. He enters:

$ABSTRACT(RCS,TCS)

$ABSTRACT is also used in issuing a security check for TMS security bypass control XTD98000. This resource class is also used, with additional site-written code, to extend security to other "system" type resources, for example, when defining job execution classes to CA Top Secret.

$ALT-ACID (Checks acid cross-authorization)

Issues a security check to verify an ACID can run jobs under an alternate ACID.

Security Macro: RACROUTE REQUEST=FASTAUTH.

Parameters: TRACE, OWN ACCESS, XACCESS.

Example: An administrator wishes to issue a security check to see if an ACID is cross-authorized to submit work under an alternate ACID.

To permit USERA to submit a batch job with a USER= or USERB, enter:

TSS PERMIT(USERA) ACID(USERB)

To revoke USERA's ability to code USER=USERB on a job statement, enter:

TSS REVOKE(USERA) ACID(USERB)



$APPCLU (APPC Logical Units)

Issues a security check to identify which logical units (LUs) can establish a link for the purpose of processing APPC transactions and conversations.

Security Macro: RACROUTE REQUEST=LIST

Parameters: TRACE, OWN, ACCESS, XACCESS

Example: An administrator wishes to issue a security check to see which logical units are allowed to process APPC transactions.

$APPCLU(LU1,LU2)

$APPCPORT (APPC Ports)

Issues a security check to identify the VTAM logical unit name of the logical unit from which an APPC conversation request must originate. The APPL resource class is used to indicate which logical unit a conversation request can be made.

Security Macro: RACROUTE REQUEST=AUTH

Parameters: OWN, TRACE, ACCESS, XACCES

Example: An administrator wishes to issue a security check of the current simulated ACID for a port name of LU01. He enters:

$APPCPORT(LU01)

$APPCSI (APPC Side Information)

Issues a security check to identify who can administer the APPC side information files.



Example: An administrator wishes to maintain all side information files assigned to the RESEARCH database token. He enters:

$APPCSI(RESEARCH.SYS1)



$APPCTP (APPC Transaction Programs and Profiles)

Issues a security check on the use of the APPC transaction programs and the transaction profiles.



Example: An administrator is responsible for maintaining TPB (which has a database token of PAYROLL and is accessible to all users for LU02). He enters:

$APPCTP(PAYROLL.SYS1.TPB)

$APPL (IMS Application)

Issues a security check for an IMS Application Group Name (AGN).


Parameters: OWN, TRACE

Example: An administrator needs to perform a security check on an IMS Application named TEMPAY and activate the TRACE facility to locate the exact permission.

$APPL(TEMPAY) TRACE

$AREA (IDMS Database Areas)

Issues a security check for an IDMS database Area.


Parameters: ACCESS, OWN, TRACE, PRIVPGM, XACCESS

Example: An administrator wants a security check on an IDMS Data Base Area (AFRPER3) with an access of UPDATE. He also specifies the OWN parameter so that CA Top Secret will assume the resource is owned. He enters:

$AREA(AFRPER3) ACCESS(UPDATE) OWN

Resource name lengths of up to 44 characters are supported with the $AREA command.



$CAADMIN (CA Administrative Functions)

Issues a security check for CA administrative functions



Example: An administrator wishes to issue a security check to determine who is authorized to perform the BrighStor™ CA-ASM2® $CI administrative function. He enters:

$CAADMIN($CI)

$CACCFDSN (AllFusion CA-Librarian/CCF Data Sets)

Issues a security check for AllFusion CA-Librarian/CCF data sets.


Parameters: OWN, TRACE, ACCESS, XACCESS

Example: An administrator wants a security check for the "LIB.TEST.DATA" data set. He enters:

$CACCFDSN(LIB.TEST.DATA)

$CACCFMEM (AllFusion CA-Librarian/CCF Members)

Issues a security check for AllFusion CA-Librarian/CCF members.



Example: An administrator wants a security check of the CCFMEM02 module. He enters:

$CACCFMEM(CCFMEM02)



$CACMD (CA Command Authorization)

Issues a security check for CA command authorization.



Example: An administrator wants a security check of the BrightStor CA-1 LOEXTEND command. He enters:

$CACMD(LOEXTEND)

$CALIBMEM (AllFusion CA-Librarian Member)

Issues a security check for AllFusion CA-Librarian members.



Example: An administrator wants a security check for the LIBMEM01 member. He enters:

$CALIBMEM (ALLFUSION CA-Librarian Member)

$CAREPORT (Unicenter CA-Dispatch reports)

Issues a security check for Unicenter CA-Dispatch reports.



Example: An administrator wants a security check to determine who can run the PYRLLUPD report under Unicenter CA-Dispatch. He enters:

$CAREPORT(PYRLLUPD)



$CATAPE (BrightStor CA-1 Resource)

Issues a security check for BrightStor CA-1 members.



Example: An administrator wants a security check for the BrightStor CA-1 BLPNORES resource. He enters:

$CATAPE(BLPNORES)

$CAVAPPL (CA VTAM Applications)

Issues a security check for CA products using VTAM ACBs.



Example: An administrator wants a security check to determine who has access to the ACB123 VTAM ACB. He enters:

$CAVAPPL(ACB123)

$CIMS (PC Port Logical Unit(LU) Names)

Issues a security check for IMS 4.1 commands.



Example: An administrator wishes to issue a security check to determine if a user can issue the IMS/START command. He enters:

$CIMS(STA)



$CPCMD (CP Commands)

Issues a security check for a CP command (CPCMD) resource.



Example: An administrator wishes to issue a security check on the CP command (CPCMD) QUERY. The administrator enters:

$CPCMD(QUERY)

CPCMD is used in a VM environment only.

$CPU (Central Processing Unit)

Issues a security check for a CPU resource.


Parameters: OWN, TRACE, PRIVPGM, LIBR

Example: An administrator wants a security check on a CPU (SYSA) with an access of UPDATE. He also specifies the TRACE parameter to locate the permission for the access. He enters:

$CPU(SYSA) TRACE

$DASDVOL (DASD Volume Level)

Issues a security check for a DASD volume. This is a volume-only check. No data set level check is performed.


Parameters: ACCESS, PRIVPGM, TRACE, XACCESS, LIBR

Example: An administrator wishes to issue a security check on a DASD volume. She enters:

$DASDVOL(24T921) ACCESS(UPDATE)



$DATABAS (ADABAS Database)

Issues a security check for an ADABAS database.


Parameters: OWN, ACCESS, PRIVPGM, TRACE, XACCESS, LIBR

Example: An administrator wishes to issue a security check on an ADABAS database with UPDATE access. He enters:

$DATABAS(EMPDATA) ACCESS(UPDATE)

$DBD (IMS Database Descriptor)

Issues a security check for an IMS Database Descriptor name.


Parameters: ACCESS, OWN, PRIVPGM, TRACE, XACCESS, LIBR

Example: An administrator wants a security check on an IMS DBD (TSTPDA) and issues an XACCESS of 88 which simulates access levels of UPDATE and DELETE. He enters:

$DBD(TSTPDA) XACCESS(88)

Alternately, he could have specified:

$DBD(TSTPDA) ACCESS(UPDATE,DELETE)

$DB2 (DB2 Access)

Issues a security check for a DB2 database.



Example: An administrator wants a security check on a DB2 subsystem PRD1 from CICS. He enters:

$DB2(DSNR.PRD1.SAS)

The $DB2 command supports resource name lengths of up to 44 characters.



$DB2BUFFP (DB2 Buffer Pools)

Issues a security check for DB2 buffer pools.


Parameters: ACCESS, OWN, PRIVPGM, TRACE, XACCESS

Example: An administrator wants a security check on buffer pool BP1. He enters:

$DB2BUFFP(BP1)

Note: TSSSIM does not take into account hierarchical checking for the DB2 resources.

$DB2COLL (DB2 Collections)

Issues a security check for DB2 collections.



Example: An administrator wants a security check on the collection PAY04 with PACKADM access. He enters:

$DB2COLL(PAY04) ACCESS(PACKADM)




$DB2DBASE (DB2 Databases)

Issues a security check for DB2 databases.



Example: An administrator wishes to issue a security check on the database ACCTING with DROP access. He enters:

$DB2DBASE(ACCTING) ACCESS(DROP)

DB2DBASE has been designed for use with the CA Top Secret for DB2 interface.


$DB2PKG (DB2 Packages)

Issues a security check for DB2 packages.



Example: An administrator wishes to issue a security check on the package PAY04.PQUERY with COPY access. He enters:

$DB2PKG(PAY04.PQUERY) ACCESS(COPY)

DB2PKG has been designed for use with the CA Top Secret for DB2 interface.




$DB2PLAN (DB2 Plans)

Issues a security check for DB2 plans.



Example: An administrator wants a security check on a DB2 plan named SR19052P with EXECUTE access. He enters:

$DB2PLAN(SR19052P) ACCESS(EXECUTE)


$DB2STOGP (DB2 Storage Groups)

Issues a security check for DB2 storage groups.


Parameters: OWN, PRIVPGM, TRACE, XACCESS, LIBR

Example: An administrator wants a security check on the TESTDASD storage group. He enters:

$DB2STOGP(TESTDASD)




$DB2SYS (DB2 System)

Issues a security check for DB2 System privileges and authorities.


Parameters: OWN, PRIVPGM, TRACE

Example: An administrator wants a security check on the SYSADM privilege, and activates the TRACE parameter so that he can locate the exact permission. He enters:

$DB2SYS(SYSADM) TRACE


$DB2TABLE (DB2 Tables)

Issues a security check for DB2 tables or columns.



Example: An administrator wants a security check on the table or column USER.MIKE.PAYR with UPDATE access. He enters:

$DB2TABLE(USER.MIKE.PAYR) ACCESS(UPDATE)




$DB2TABSP (DB2 Table Spaces)

Issues a security check for DB2 table spaces.



Example: An administrator wants a security check on the table space known as TSPACE1, residing on the ACCTING database, with USE access. He enters:

$DB2TABSP(ACCTING.TSPACE1) ACCESS(USE)


$DCSS (Discontiguous Saved Statements)

Issues a security check for DCSS (Discontiguous Saved Statements).



Example: An administrator wants a security check on the program product SAS and to activate the TRACE facility in order to locate the exact permission. He enters:

$DCSS(SAS) TRACE

$DCT (CICS Destination Control Table)

Issues a security check for a CICS Destination Control Table name, limited to a maximum length of eight characters.



Example: An administrator wishes to issue a security check on a DCT PRT6. He can only access this DCT via the privileged program ACDCT5. He enters:

$DCT(PRT6) PRIVPGM(ACDCT5)



$DEVICES (Hardware Devices)

Issues a security check for z/OS allocation of UR, graphic and teleprocessing devices.


Parameters: ACCESS, OWN, TRACE, XACCESS

Example: An administrator wishes to issue a security check for TP 2703. If the sysid is XAD1 and the address is E80, he enters:

$DEVICE(XAD1.TP.2703.E80)

$DIAG (VM Diagnose Codes)

Issues a security check for VM Diagnose codes.



Example: An administrator wishes to issue a security check on diagnose code number 84 (Directory Update in Place). He enters:

$DIAG(84)

The $DIAG command appears on the TSSSIM Security Resource Selection panel as DIAGNOSE.

$DIRECTRY

Issues a security check for a SFS DIRECTORY (DIRECTRY) resource.


Parameters: OWN, ACCESS, XACCESS

Example: An administrator wishes to issue a security check on the SFS DIRECTORY (DIRECTRY) “MANIR01.”. The administrator enters:

$DIRECTRY(MANIR01.).

DIRECTRY is used in a VM environment using Shared File Systems (SFS) only.



$DLFCLASS (DLF Data Set)

Issues a security check for DLF data sets.


Parameters: OWN, TRACE, PRIVPGM, XACCESS, ACCESS, LIBR

Example: An administrator wishes to issue a security check on the "VSAM01.CYCLE1" DLF data set. He enters:

$DLFCLASS(VSAM01.CYCLE1)

$DLISEG (VSE DL/I Segment)

Issues a security check for VSE DL/I database segment (DLISEG) name, limited to a maximum length of eight characters.



Example: An administrator wants a security check on a DLISEG named PENSION with ALL access. The administrator enters:

$DLISEG(PENSION) ACCESS(ALL)

DLISEG is used in a VSE environment only.



$DSN (z/OS Data Set)

Issues a security check for an z/OS data set name. Data set names should be enclosed in single quotes. If the data set is not enclosed in single quotes, the userid is prefixed to the data set which may not provide the desired simulation.


Parameters: ACCESS, PRIVPGM, SVC, TRACE, XACCESS, NEWDSN, VOLUME, LIBR, FACILITY

Example: An administrator wishes to issue a security check on a data set named ACCTPAY.MASTER with UPDATE access. The administrator enters:

$DSN('ACCTPAY.MASTER') VOLUME(ACCTP1) ACCESS(UPDATE)

Note: A $DSN simulation without a VOLUME operand can give unpredictable results.

If SVC is set to RENAME, the NEWDSN parameter can be used to simulate a DADSM RENAME function. For example:

$DSN('ACCTPAY.MASTER') NEWDSN('UPAY.MASTER') VOLUME(ACCTP1) SVC(RENAME)

Such a rename will involve checks for both data sets. For the 'ACCTPAY.MASTER' data set, the following ACCESS level is needed:

ACCESS(READ,SCRATCH)

For the 'UPAY.MASTER' data set, the following ACCESS level is needed:

ACCESS(WRITE,CREATE)

For other $DSN accesses, the ACCESS level is specified without reference to a specific SVC.



$DSPACE (Dataspaces)

Issues a security check for a VM dataspace (DSPACE) resource.



Example: An administrator wishes to issue a security check on the VM dataspaces (DSPACE) created by user DELSC01. The administrator enters:

$DSPACE(DELSC01)

DSPACE is used in a VM environment only.

$DTADMIN (DT Administration)

Issues a security check for the DTADMIN resource.



Example: An administrator wishes to issue a security check on ADMIN1 of the DTADMIN resource. The administrator enters:

$DTADMIN(ADMIN1)

DTADMIN is used in the z/OS operating system.

$DTSYSTEM (DT System Data)

Issues a security check for the DTSYSTEM resource.



Example: An administrator wishes to issue a security check on SYSTEM1 of the DTSYSTEM resource. The administrator enters:

$DTSYSTEM(SYSTEM1)

DTSYSTEM is used in the z/OS operating system.



$DTTABLE (DT Table Data)

Issues a security check for the DTTABLE resource



Example: An administrator wishes to issue a security check on TABLE1 of DTABLE. The administrator enters:

$DTABLE(TABLE)

DTTABLE is used in the z/OS operating system.

$DTUTIL (DT Utility)

Issues a security check for the DTUTIL resource



Example: An administrator wishes to issue a security check on UTILITY1 of the DTUTIL resource. The administrator enters:

$DTUTIL(UTILITY1)

DTUTIL is used in the z/OS operating system.

$FCT (CICS File Control Table)

Issues a security check for a CICS File Control Table (FCT) name, limited to a maximum length of eight characters.



Example: An administrator wants a security check on an FCT named PENSION with ALL access. She enters:

$FCT(PENSION) ACCESS(ALL)



$FIELD (Database Field)

Issues a security check for general user-defined resource names. This resource class supports entities with a maximum of 44 characters.



Example: An administrator needs to issue a security check on a data base field SALARY. This particular database field can only be accessed through a privileged program called PRTFLD. He also wishes to activate the trace facility for this resource. He enters:

$FIELD(SALARY) PRIVPGM(PRTFLD) TRACE

CA Top Secret allows the definition of user-defined resources and the validation of access to these resources by user programs or transactions. This resource is intended for those sites that wish to further customize security checks within their environment.

$IBMFAC (IBM Facilities)

Issues a security check to determine who has ownership or control over catalog, IDCAMS, SMS, DFDSS and other IBM facilities.



Example: An administrator wishes to issue a security check on the IBM facility IDC.DIAG. He enters:

$IBMFAC(IDC.DIAG)



$IBMGRP (IBM Products)

Issues a security check to determine who has access to or ownership of identifiers which are examined by DB2, DF/HSM and other IBM products.



Example: An administrator wants a security check on the DB2 resource PAYROLL. He also activates the TRACE facility to locate the exact permission. He enters:

$IBMGRP(PAYROLL) TRACE

$IUCV (Inter User Communication Vehicle(IUCV))

Issues a security check for IUCV communication targets.



Example: An administrator wants a security check on an IUCV connect to virtual machine APP17 and he also specifies the OWN parameter so that CA Top Secret will assume the resource is owned. He enters:

$IUCV(APP17) OWN

For VM: IUCV communication targets control the ability of users to issue IUCV connection to the virtual machine designated by the resource name.

$JCT (CICS Journal Control Tables)

Issues a security check for a CICS Journal Control Table (JCT) name, limited to a maximum length of eight characters.



Example: An administrator wishes to issue a security check on a JCT named JRN03 with WRITE access. He enters:

$JCT(JRN03) ACCESS(WRITE)



$JESINPUT (JES Source)

Issues a security check for JES job entry sources checked during job initiation.



Example: An administrator wants to issue a security check to determine if a user can execute jobs which originate from JES node SRCNODE. He enters:

$JESINPUT(SRCNODE)

Only JES2 SP 3.1.3 and JES3 SP 3.1.3 releases and above offer support for JESINPUT resources.

$JESJOBS (JES Job Submit and Cancel)

Issues a security check to determine which job names users can use when submitting or canceling jobs. JESJOBS can also control which users can submit jobs.



Example: An administrator wants to issue a security check to determine if a specific user can submit a job using MYJOB as a jobname. He enters:

$JESJOBS(SUBMIT.MYNODE.MYJOB.MYACID)

Only JES2 SP 3.1.3 and JES3 SP 3.1.3 releases and above offer support for JESJOBS resources.



$JESSPOOL (JES Spool Data Sets)

Issues a security check to determine who has access to or ownership of JES Spool data sets (SYSIN and SYSOUT)



Example: An administrator wants a security check to see if a user may update the JESNEWS (JES2) data set. He enters:

$JESPOOL(MYNODE.JES2.$JESNEWS.STC00000.D01.JESNEWS)

Only JES2 SP 3.1.3 and JES3 SP 3.1.3 releases and above offer support for all JESPOOL resources.

$JOBNAME

Issues a security check for the JBNAME resource.


Parameters: TRACE, OWN

Example: An administrator wishes to issue a security check on PROD of the JOBNAME resource. The administrator enters:

$JOBNAME(PROD)

JOBNAME is used in the z/OS operating system.



$LCF (Limited Command Facility)

Issues a security check for commands or transactions that are protected through the Limited Command Facility.


Parameters: TRACE

Example: An administrator wishes to issue a security check on an LCF, and wants to put a trace on the transaction DDYA. She enters:

$LCF(DDYA) TRACE

The $LCF command appears on the TSSSIM Security Resource Selection panel as CMD/TRAN.

$LFSCLASS LF Class

Issues a security check for the LFSCLASS resource.



Example: An administrator wishes to issue a security check on the COMMANDS of the LFSCLASS resource. The administrator enters:

$LFSCLAS(COMMANDS)

LFSCLASS is used in the z/OS operating system.

$MDISK (VM Minidisks (VMMDISK) )

Issues a security check for VM minidisks.



Example: An administrator wants a security check on the SCAMID.191 mini disk. He enters:

$MDISK(SCAMID.191)

The $MDISK command appears on the TSSSIM Security Resource Selection panel as VMDISK.



$MGMTCLAS (SMS Management Class)

Issues a security check for SMS management classes defined by the storage administrator.



Example: An administrator wants a security check on the management class named PRODMGMT. He enters:

$MGMTCLAS(PRODMGMT)

$MQADMIN MQ Administration

Issues a security check for the MQADMIN resource



Example: An administrator wishes to issue a security check on CSQ1. of the MQADMIN resource. The administrator enters:

$MQADMIN(CSQ1.)

$MQADMIN is used in the z/OS operating system.

$MQCMDS MQ Commands

Issues a security check for the MQCMDS resource.



Example: An administrator wishes to issue a security check on CSQ1. of the $MQCMDS resource. The administrator enters:

$MQCMDS(CSQ1.)

$MQCMDS is used in the z/OS operating system.



$MQCONN MQ Connections

Issues a security check for the MQCONN resource.



Example: An administrator wishes to issue a security check on CSQ1. of the $MQCONN resource. The administrator enters:

$MQCONN(CSQ1)

$MQCONN is used in the z/OS operating system.

$MQNLIST MQ Names

Issues a security check for the MQNLIST resource.



Example: An administrator wishes to issue a security check on CSQ1. of the MQNLIST resource. The administrator enters:

$MQNLIST(CSQ1,)

$MQNLIST is used in the z/OS operating system.

$MQPROC MQ Procedures

Issues a security check for the MQPROC resource.



Example: An administrator wishes to issue a security check on CSQ1. of the MQPROC resource. The administrator enters:

$MQPROC(CSQ1.)

$MQPROC is used in the z/OS operating system.



$MQQUEUE MQ Queues

Issues a security check for the MQQUEUE resource.



Example: An administrator wishes to issue a security check on CSQ1. of the MQQUEUE resource. The administrator enters:

$MQQUEUE(CSQ1.)

$MQQUEUE is used in the z/OS operating system.

$NODES VTAM Nodes

Issues a security check for the NODES resource.



Example: An administrator wishes to issue a security check on node. The administrator enters:

$NODES(<node(s)>)

NODES is used in the z/OS and VM operating systems.

$OPCMD (System Operator Command)

Issues a security check for a system operator command that was issued by programs using SVC 34; for example, SDSF, TSO OPER, or installation-written programs.



Example: An administrator wishes to issue a security check on an operator command (DISPLAY). He enters:

$OPCMD(DISPLAY)



$OPERCMD (z/OS and JES Operator Commands)

Issues a security check on JES and z/OS operator commands



Example: An administrator wishes to issue a security check to determine if a user can issue the z/OS "D A,L" console command. He enters:

$OPERCMD(MVS.DISPLAY.ACTIVE)

The OPERCMDS resource class is only used for OS/390 SP 3.1.3, JES2 SP 3.1.3 or JES3 SP 3.1.3 release or higher.

$OTRAN (Owned Transactions(OTR))

Issues a security check for an owned transaction name (OTRAN). IMS and IDMS names can have a maximum of eight characters; CICS names a maximum of four characters.


Parameters: OWN, TRACE, XACCESS, ACCESS

Example: An administrator wishes to issue a security check on an owned transaction (OTRAN) named PAYR. He enters:

$OTRAN(PAYR)

$PANAPT AllFusion CA-PANAPT Functions

Issues a security check for the AllFusion™ PANAPT® resource.



Example: An administrator wishes to issue a security check on the COMMANDS of the PANAPT resource. The administrator enters:

$PANAPT(COMMANDS)

PANAPT is used in the z/OS operating system.



$PANEL (CA Product Panels)

Issues a security check for user access to CA product panels.



Example: An administrator wants a security check to determine if a user can access panel KOTSTPNL. He enters:

$PANEL(KOTSTPNL)

Resource names for this class are defined in the corresponding CA product documentation.

$PGM (z/OS Program Module Name)

Issues a security check for z/OS and program module names. The names can have a maximum of eight characters.


Parameters: OWN, PRIVPGM, TRACE, LIBR

Example: An administrator wishes to issue a security check on an OS program named AMASPZAP. He then enters:

$PGM(AMASPZAP)

The $PGM command appears on the TSSSIM Security Resource Selection panel as PROGRAM.

$PPT (CICS Program Table)

Issues a security check for CICS Program Table name (PPT). The names can have a maximum of eight characters.


Parameters: OWN, PRIVPGM, TRACE, LIBR, ACCESS, XACCESS

Example: An administrator wishes to issue a security check on a PPT named SRSIP. This resource can only be accessed through a privileged program CPROPX. He enters:

$PPT(SRSIP) PRIVPGM(CPROPX)



$PROPCNTL (Automatic Propagation Control)

Issues a security check for those ACIDs not subject to automatic propagation on batch jobs.



Example: An administrator wants a security check on the IMS ACID to ensure that it cannot be automatically propagated. In the event that it can, he also wants to activate the TRACE facility to locate the exact permission. He enters:

$PROPCNTL(IMS) TRACE

$PSB (IMS Program Specification Block)

Issues a security check for IMS Program Specification Block (PSB) names. The names may contain a maximum of eight characters.


Parameters: OWN, PRIVPGM, TRACE, ACCESS, XACCESS, LIBR

Example: An administrator wishes to issue a security check on an IMS PSB named LRLPP. He also wishes to put a trace on the resource to locate the permission for the access. He enters:

$PSB(LRLPP) TRACE

$PSFMPL (Print Services Facility Modifiable Page Labeling)

Issues a security check for output processed by PSF to allow for user suppression of output labeling.


Parameters: ACCESS, OWN, TRACE

Example: An administrator wants a security check to see if a user can suppress PSF identification labels in printed output. He enters:

$PSFMPL(PSF.DPAGELBL)



$RESLIST Resource Names

Issues a security check for the RESLIST resource.



Example: An administrator wishes to issue a security check on RESLIST1 of the RESLIST resource. The administrator enters:

$RESLIST(RESLIST1)

RESLIST is used in the z/OS operating system.

$RECIPID CA DISPATCH RECIPIENT

Issues a security check for the RECIPID resource.



Example: An administrator wishes to issue a security check on the id ABCDEFGH of the resource RESIPID. The administrator enters:

$RECIPID(ABCDEFGH)

RECIPID is used in the z/OS operating system.

$SCHEDULE CA SCHEDULER SCHEDULE

Issues a security check for the SCHEDULE resource.



Example: An administrator wishes to issue a security check on PROD of the resource SCHEDULE. The administrator enters:

$SCHEDULE(PROD)

SCHEDULE is used in the z/OS operating system.



$SFSCMD VM SFS COMMANDS

Issues a security check for a VM SFS Command (SFSCMD) resource.



Example: An administrator wishes to issue a security check on the SFS command (SFSCMD) AUDIT. The administrator enters:

$SFSCMD(AUDIT)

SFSCMD is used in a VM environment using Shared File Systems (SFS) only

$STATION CA SCHEDULER STATION

Issues a security check for the STATION resource.



Example: An administrator wishes to issue a security check on ABCDEFGH of the STATION resource. The administrator enters:

$STATION(ABCDEFGH)

STATION is used in the z/OS operating system.

$SDSF (Spool Display and Search Facility)

Issues a security check for SDSF 1.3 commands, functions, and other resources.

Security Macro: RACROUTE REQUEST = AUTH

Parameters: ACESS, OWN, TRACE

Example: An administrator issues a security check to see if a user can issue z/OS and JES2 commands through SDSF. He enters:

$SDSF(ISFOPER.SYSTEM)



$SMESSAGE (TSO Message Transmission)

Issues a security check to determine if a TSO user is allowed to transmit messages to other TSO users via the TSO SEND command.



Example: An administrator wishes to issue a security check to determine if TGTUSER is allowed to transmit messages. He enters:

$SMESSAGE(TGTUSER)

$SPI (CICS System Functions)

Issues a security check for the following:

■ CEMT INQUIRE, SET and PERFORM

■ EXEC CICS INQUIRE, and CICS

■ EXEC CICS ENABLE, DISABLE and EXTRACT

■ EXEC CICS SPOOLOPEN



Example: An administrator wants a security check on the SPI CONNECTION resource with SET access. He enters:

$SPI(CONNECTION) ACCESS(SET)

$STORCLAS (SMS Storage Class)

Issues a security check for an SMS storage class as defined by the storage administrator.



Example: An administrator issues a security check on the PRODSTOR storage class and he also includes the OWN parameter so that CA Top Secret will assume that the resource is owned. He enters:

$STORCLASS(PRODSTOR) OWN



$SUBMIT (ACID Job Submission)

Issues a security check to determine if the simulated ACID is allowed to submit a job that will run with the specified ACID name.


Parameters: PRIVPGM, TRACE, LIBR

Example: An administrator wants a security check to determine if the simulated ACID is allowed to submit a job with the specified ACID of PAYPROD. He enters:

$SUBMIT(PAYPROD)

$SUBSCH (IDMS Subschema)

Issues a security check for IDMS subschema names. These names may consist of up to eight characters.



Example: An administrator wants a security check on an IDMS subschema called PARTA. He also wants CA Top Secret to assume that the resource is owned. He enters:

$SUBSCH(PARTA) OWN

The $SUBSCH command appears on the TSSSIM Security Resource Selection panel as SUBSCHEM.

$SYSCONS (System Console)

Issues a security check for System Consoles. This is equivalent to the IBM CONSOLE resource class.



Example: An administrator wants a security check on the 03 console. He enters:

$SYSCON(03)



$TAPEVOL (Tape Volume)

Issues a security check for tape volumes. This is a volume-only check. No data set-level check is performed.


Parameters: ACCESS, TRACE, XACCESS, PRIVPGM, LIBR

Example: An administrator wishes to issue a security check on a tape volume, 30T112, with access levels of READ and WRITE. She enters:

$TAPEVOL(30T112) ACCESS(READ,WRITE)

The $TAPEVOL command appears on the TSSSIM Security Resource Selection panel as VOLUME.

$TERM (Network Terminal ID)

Issues a security check for terminal ID names. The names should correspond to actual logical unit IDs as follows:

VTAM

Eight-character VTAM terminal name

TCAM

Eight-character TCAM terminal name

BTAM

Four-character CICS terminal name

Security Macor RACROUTE REQUEST=FASTAUTH


Example: An administrator wishes to issue a security check on a terminal known to VTAM by the name T0001012. He enters:

$TERM(T0001012)

The $TERM command appears on the TSSSIM Security Resource Selection panel as TERMINAL.



$TSAF (Transparent Services Access Facility)

Issues a security check for TSAF resources.



Example: An administrator wants a security check for the FTPSERV TSAF resource. He also wishes to specify OWN so that CA Top Secret will assume that the resource is owned. He enters:

$TSAF(FTPSERV) OWN

$TSOACCT (TSO Account Codes)

Issues a security check for those account codes to be used during TSO logon.


Parameters: OWN, TRACE, PRIVPGM

Example: An administrator wants a security check on an account code named 044221. He enters:

$TSOACCT(044221)

$TSOAUTH (TSO Authorities)

Issues a security check for TSO user attributes.


Parameters: OWN, TRACE, PRIVPGM

Example: An administrator issues a security check on a TSO MOUNT authority. He also activates the TRACE facility so that he can find the exact permission that allows access to the resource. He enters:

$TSOAUTH(MOUNT) TRACE



$TSOPRFG (TSO Performance Groups)

Issues a security check for TSO performance groups.



Example: An administrator wants a security check on a performance group named 001. He enters:

$TSOPRFG(001)

$TSOPROC (TSO Procedures)

Issues a security check for PROCs used for TSO logon.



Example: An administrator wants a security check on a logon PROC of SMPEPROC. He enters:

$TSOPROC(SMPEPROC)

$TST (Temporary Storage Table)

Issues a security check for CICS Temporary Storage Table (TST) names. The names are limited to a maximum length of eight characters.



Example: An administrator wants a security check for a TST named FOLDER. He also wants to use the one-byte hexadecimal code (61) in place of specifying READ, WRITE and PURGE accesses. He enters:

$TST(FOLDER) XACCESS(61)

Alternately, he could have specified:

$TST(FOLDER) ACCESS(READ,WRITE,PURGE)



$UR1 (Owned General UR1 Resource)

Issues a security check for general UR1 resource names. These names can have a maximum of 44 characters; however, ownership of these resources is based on a maximum prefix length of eight characters.



Example: An administrator wishes to issue a security check for a general resource class 1 with the name ARCH. This resource is accessed through a privileged program ACUPDATE with an access level of READ. He enters:

$UR1(ARCH) PRIVPGM(ACUPDATE) ACCESS(READ)

$UR2 (Owned General UR2 Resource)

Issues a security check for general UR2 resource names. These names can have a maximum of 44 characters; however, ownership of these resources is based on a maximum prefix length of eight characters.



Example: An administrator wishes to issue a security check for a general resource class 2 with the name BARG. This particular resource can only be accessed through a privileged program called GABX5. The OWN parameter is specified so that CA Top Secret will assume the resource is owned. She enters:

$UR2(BARG) PRIVPGM(GABX5) OWN



$USER (Unowned User Resource)

Issues a security check for a non-ownable USER resource of the given one-character class code (A-Z, 0-9). Each name is limited to a maximum of eight characters.


Parameters: TRACE, PRIVPGM, LIBR

Example: An administrator wants a security check for a non-ownable USERA resource named OIL. The TRACE parameter is specified so that the exact permission causing the access is located. She enters:

$USER(A,OIL) TRACE

$USRCLASS USER CLASSES

Issues a security check for the USRCLASS resource.


Parameters: TRACE, OWN, ACCESS, XACCESS, PRIVPGM

Example: An administrator wishes to issue a security check on the BACKUP of the USRCLASS resource. The administrator enters:

$USRCLASS(BACKUP)

USRCLASS is used in the z/OS and VM operating systems.

$VMANAPPL (VMAN Applications)

Issues a security check for VMAN application names.



Example: An administrator issues a security check on a VMAN application. He also specifies the OWN parameter so that CA Top Secret will assume that the resource is owned. He enters:

$VMANAPPL(TESTTSO) OWN



$VMCF (VMCF Communication Targets)

Issues a security check for VMCF communication targets.



Example: An administrator wants a security check on a VMCF communication target. He enters:

$VMCF(SVCMACH)

For VM: The communication targets control the ability of users to issue a VMCF send to the virtual machine designated by the resource name.

$VMDIAL (VMDIAL access)

Issues a security check for virtual machines with DIAL access security.



Example: An administrator wants a security check on virtual machine OPER17. He enters:

$VMDIAL(OPER17)

For VM.

$VMMACH (VM Machines)

Issues a security check to verify who can allow a virtual machine to be autologged or logged on using an alternate ACID.


Parameters: ACCESS, OWN, TRACE, XACCESS, PRIVPGM

EXAMPLE: An administrator wants a security check on virtual machine BATCH1. He enters:

$VMMACH(BATCH1)

For VM.



$VMNODE (VM Nodes)

Issues a security check for VM nodes (RSCS Network Node prefixes).



Example: An administrator wants a security check on the VMNODE MIAMI. He enters:

$VMNODE(MIAMI)

For VM only.

$VMRDR (VM Readers)

Issues a security check for VM readers.



Example: An administrator wants a security check on a CMSBATCH machine. He enters:

$VMRDR(CMSBATCH)

For VM.

$VTAMAPPL (VTAM Applications)

Issues a security check for authorization to access VTAM ACB's under a non-APF authorized program.



Example: An administrator wants a security check for access to the VTAM application SA32SESN. He enters:

VTAMAPPL(SA32SESN)



$VXDEVICE (VAX Devices)

Determines the relationship of volumes to nodes that can access them for the ACID or NDT Record. A volume name must be a device name and a volume must be owned by a department or division.



Example: An administrator wants a security check on the ZEUS$DUA0 device. He enters:

$VXDEVICE(ZEUS$DUA0)

$VXFILE (VAX Files)

Issues a security check to determine who may transfer ownership of VMS Files.

Note: A VMS file can be a data file or directory file. Data files are equivalent to z/OS data sets and directory files are equivalent to z/OS catalogs.



Example: An administrator wants a security check on the PEGASUS$DUA0.HORSE VAX file. He enters:

$VXFILE (PEGASUS$DUA0.HORSE)

$WRITER (JES Writer Control)

Issues a security check to monitor routing and processing of job output to local devices, RJE stations or NJE nodes.



Example: An administrator issues a security check to see if a user is authorized to route output to another JES node. He enters:

$WRITER(JES3.NJE.SITE2)


Special Commands

@cccccccc (User-Defined Resource)

Issues a security check for a resource added to the RDT record by the installation. The at sign (@) is followed immediately by the one- to eight-character resource class name.


Parameters: PRIVPGM, OWN, TRACE, ACCESS, XACCESS, SVC

Example: An administrator wants a security check for a JOBNAME called TDD022 with UPDATE access. This resource class has already been defined to the RDT record. He enters:

@JOBNAME(TDD022) ACCESS(UPDATE)

The tested resource class name (that is, the value of "cccccccc"in @cccccccc) must have been defined previously to CA Top Secret by means of the ADDTO(RDT) command function. Access levels are relevant only if they were specified when the resource class was defined.

The user-defined resource field appears on the TSSSIM Security Resource Selection panel as DYNAMIC.

Special Commands The special simulator commands (EJECT, STATUS, TSS) perform no resource checks. They are primarily designed to provide the administrator with information about the simulator within CA Top Secret. Each command is discussed in detail, and includes the following information: function, any parameters that may be used to qualify the command, an example, and any additional comments.

The EJECT command is used for batch-only processing of TSSSIM, and causes a page eject before the next command is processed. The STATUS command provides the current status of the simulation environment. The TSS command is "passed through" the simulator to the CA Top Secret administration processor and supports all of the TSS administration command functions.


Special Commands

EJECT (BATCH Page Eject)

A batch-only command that causes a page eject before the next command is executed by the simulator.

Parameters: None.

Example: An administrator issues the $DSN and $TERM commands. Before he enters any other commands, he issues EJECT in order to effect a page break.

Note: These commands are entered as control statements in the JCL when executing TSSSIM in batch. For more detailed information, see Using TSSSIM/Batch.

STATUS (Status of Environment)

Provides the administrator with the current status of the simulation environment, and includes the following:

Simulation ACID, data set qualifier, simulation mode Simulation facility, terminal, CPU Default SVC name, SVC number, and associated access Default privileged program PRIVPGM Default TRACE setting

Parameters: None.

Example: An administrator wishes to view the current status of the logged on simulated ACID. He enters:

STATUS

A screen is then displayed with the following information:

TSS8410I SIMULATED ACID = USER01 QUALIFIER = USER01 MODE = FAIL TSS8410I SIMULATED FAC = TSO TERMINAL = T100010 CPU = XA81 TSS8410I DEFAULT SVC = TSO NUMBER = 13 (HEX) ACCESS = 40 TSS8410I DEFAULT PRIVPGM = <NONE> TSS8410I SECURITY TRACE = NO


Special Commands

TSS (TSS Command Functions)

This command is not really executed by the simulator. Instead it is simply passed on to the CA Top Secret administration processor module. All of the administration command functions are supported. This gives the administrator the capability of performing any security administration function without the need to leave, and then subsequently re-enter the simulator.

Parameters: TSS command functions and parameters.

Example: An administrator wishes to view some pertinent information on one of his profiles. He enters:

TSS LIST(SYSPROF1) DATA(ALL)


Simulator Trace Information

Simulator Trace Information When activated, the trace may consist of several messages. Each message is described, below.

TSS8390I RESOURCE = (c) xxxxxxxx

c

Resource class code in hexadecimal.

xxxxxxxx

Resource entity name.

This trace message is displayed to assure the administrator that CA Top Secret checked the proper resource entity name.

TSS8391I TSS SVC=ss RC=rr DRC=dd VDRC=vv XSW=xx ALG=aa

ss

security SVC called for the resource check (00=FRACHECK, 82=RACHECK, 83=RACINIT, 85=RACDEF).

rr

CA Top Secret's security return code.

dd

CA Top Secret's detailed reason code for the resource.

vv

CA Top Secret's detailed reason code for volumes.

xx

Algorithm results (00=auth, 04=not found, 08=unauthorized).

aa

Algorithm selection (00=override, 80=merge, 40=allmerge).

TSS8392I REQUESTED ACCESS = nnnnnnnn,nnnnnnnn,... TSS8392I ALLOWED ACCESS = nnnnnnnn,nnnnnnnn,... TSS8392I VOLUME ACCESS = nnnnnnnn,nnnnnnnn,...

nnnnnnnn

Access level name for the resource class.

There may be several TSS8392I messages in the trace. The "requested" access assures the check was for what the administrator asked. The "allowed" and "volume" accesses indicate the security accesses that CA Top Secret allowed the resource and the volume, respectively.



TSS8393I OVERRIDES = xxxxxxxx,xxxxxxxx,...

xxxxxxxx

One of the security overrides:

DSNAME

Data set security bypass

LCF

Limited command facility bypass

RESOURCE

General resource security bypass

SUB

Job submission security bypass

VOLUME

Volume security bypass

USR-BYP

Complete security bypass for user

EMG-BYP

System is in emergency bypass mode

TSS8394I RES ORIGIN = rrrrrrrr - llllllll

rrrrrrrr

One of the following:

OWNED

Resource found to be owned by this ACID

PERMITTED

Resource found permitted to this ACID

Note: This permission may be one of denial. Check return codes for allowance or denial.

llllllll

One of the following:

*USER*

Contained in user's record

PROFILE=(profile-name)

Contained in this profile



*ALL*

Contained in the ALL Record

TSS8395I RES RULE # = nnn

nnn

Permission number (relative to 0) controlling the simulated access within the user security record, the named profile record, or the ALL record as designated by message TSS8394I.

Note: This message is only present for resources where no extend mask was involved in the authorization. This message is unavailable for resource classes that do not support masking characters.

TSS8397I ------SECURITY PERMISSION------ TSS8397I RESOURCE = xxxxxxxx TSS8397I ACCESS = xxxxxxxx,xxxxxxxx,... TSS8397I FACILITY = xxxxxxxx,xxxxxxxx,... TSS8397I PRIVPGM = xxxxxxxx,xxxxxxxx,...

.

.

. TSS8397I --------------------------------

The above represents the security permission that allowed or denied access to the resource. The format is identical to that of a TSS LIST function, so it is easy to compare against a listing of a Security Record.

TSS8398I VOLUME FEEDBACK: f1 f2 f3 f4

f1,f2,f3,f4

Represent bit-mapped tape volume information. The information presented in these flags goes beyond the scope of user problem diagnosis; however, this information may be requested by Technical Support.

TSS8389I RESOURCE CLASS TRANSLATED (xxxx) : (yyyy)

XXXX

The original resource class code in hexadecimal

YYYY

The translated resource class code in hexadecimal

This trace message is displayed to inform the administrator that a translation of the original resource class has occurred.


cc


TSS8399I SUBRTN FLAGS: f1 f2 f3 f4 f5

f1,f2,f3,f4,f5

Represent bit-mapped security subroutine information. The information presented in these flags goes beyond the scope of user problem diagnosis. It may be requested by Technical Support.

TSS8400I PARENT SVC = pp CALLING SVC = cc

The SVC hexadecimal number of the module that called a security routine.

pp

The SVC hexadecimal number of the security caller.

TSS8401I CURRENT/PARENT/BOTTOM PRIVPGM(S) = cccccccc pppppppp bbbbbbb b

cccccccc

Current PRIVPGM program name used for the security check

pppppppp

Name of the calling program from the parent z/OS tcb

bbbbbbbb

Name of the program called from the current z/OS tcb (bottom/last PRB)

An example of trace information follows using the data set name QASCA.LIB.TEXT as the resource class.

TSS8390I RESOURCE = (C4) QASCA.LIB.TEXT TSS8391I TSS SVC = 82 RC = 00 DRC = 00 VDRC = 00 XSW = 04 ALG = 00 TSS8392I REQUESTED ACCESS = READ TSS8392I ALLOWED ACCESS = NONE TSS8392I VOLUME ACCESS = NONE TSS8393I OVERRIDES = DSN SUB VOL TSS8398I VOL FEEDBACK: 00 00 00 00 TSS8399I SUBRTN FLAGS: 80 00 04 00 01 TSS8400I PARENT SVC = 85 CALLING SVC = 13

TSS8401I CURRENT/PARENT/BOTTOM PRIVPGM(S) = ISPTASK TSSSIM00 ISPTASK

Note: These fields contain values initialized by the security algorithm. In this case, access was granted due to the NODSNCHK attribute.


Chapter 7: Using the TSSFAR Utility This section contains the following topics:

About the TSSFAR Utility (see page 149) TSSFAR JCL (see page 150) Control Statements (see page 150)

About the TSSFAR Utility The CA Top Secret File Analysis Routine (TSSFAR) allows security administrators to review the permissions and assignments that are recorded in the Security File. The type of security information displayed by TSSFAR depends upon the control statements selected. Each control statement is discussed in detail following a discussion of the JCL necessary to execute TSSFAR.

TSSFAR can be used to perform the following tasks:

■ Provide a cross-reference of ALRB block keys with the ARLBs in the block and verify the count against what is in the header block map.

■ Review mismatched ARLB chains.

■ Review connections between ACIDs and PROFILEs.

■ Review connections between owned and owning ACIDs.

■ Review resource ownership between ACIDs and resources.

Important! The file upon which TSSFAR executes is continuously accessed for the duration of the job. Therefore, running TSSFAR against the Security File could cause significant degradation to system performance. Because of this, we recommend that TSSFAR always run against a Backup File.

Only run TSSFAR at the direction of the CA Top Secret support staff.


TSSFAR JCL

TSSFAR JCL The following sample JCL can be used to run TSSFAR.

//TSSFAR JOB USER=msca,CLASS=A //FAR EXEC PGM=TSSFAR //SECFILE DD DSN=top.secret.backup.file,DISP=SHR // //SYSPRINT DD SYSOUT=* //INPUT DD * KEY=ENCRYPTION KEY HEADER ARLBMAP ALLOC ACIDCHAN ACIDLINK RESINDEX ACIDRES SFSTATS WHOHAS (resource owning ACID) /*

Control Statements The selection criteria used in generating TSSFAR reports are listed below. They are described on the following pages.

Mandatory control statements are:

■ KEY

Option control statements are:

■ ARLBMAP

■ ALLOC

■ ACIDCHAN

■ ACIDLINK

■ HEADER

■ RESINDEX

■ ACIDRES

■ SFSTATS

■ WHOHAS (resource owning ACID)


Control Statements

KEY=

Displays customer encryption key in 16-byte hexadecimal or 8 EBCDIC characters. The KEY control statement is mandatory.

KEY=hhhhhhhhhhhhhhhh|'cccccc'

ARLBMAP

Prints the ARLB allocation map from the header record.

ALLOC

Prints a cross-reference of all mismatches between ARLB block keys and the actual ARLBs in the block. ALLOC also verifies the number of ARLB s against what is in the header block map.

Exceptions exist if an ARLB is chained and the first byte was used to add an x'00' to end an XE. This makes the key appear to be wrong because the key is allocated but the ARLB is empty. These cases can be resolved using the ACIDCHAN function.

ACIDCHAN

ACIDCHAN runs the ALLOC function and then uses the ACID index and chase ARLB chains to build a second allocated ACID map. While chasing the chains, TSSFAR will confirm the actual number of chained ARLBs against what the ACID had listed in its FACTREC. ACIDCHAN then lists any ARLBs that are chained but empty. If these match the ARLB numbers reported as key errors in the ALLOC function, the allocation maps are correct.

All FACTREC header ARLB counts match actual chains -

This message shows that the value found as the number of ARLBs in the FACTREC header matches the number of ARLBs chained together for all ACIDs.

Note: There is a discrepancy of 12 in the total number of ACIDs reported in your system by TSSFAR compared to a TSS LIST command. This is due to TSSFAR having eight User ACIDs that are reserved and four Department ACIDs that are dynamically built.


Control Statements

ACIDLINK

ACIDLINK reviews all ACIDs for connections to other ACIDs. If a connection exists, ACIDLINK verifies whether it should exist. If an ACID shows a profile attached, ACIDLINK verifies that the profile reflects the same information.

HEADER

Prints the first 256 bytes of the header record.

RESINDEX

RESINDEX verifies that all resource ownership indexes match the owning ACID.

ACIDRES

ACIDRES verifies that all resources claimed to be owned by an ACID have a correct matching owning ACID in the resource index.


Control Statements

SFSTATS

Searches the security file and prints statistics for the following:

■ Acid index entries allocated

■ Acid index entries defined

■ Next available acid number

■ Last available acid number

■ Acid blocks allocated

■ Acid blocks used

■ Volume entries allocated

% Used % Deleted

■ PIE blocks allocated

% Used % Deleted

■ RES blocks allocated

% Used % Deleted

■ SDT blocks allocated

% Used

■ Recommended TSS cache size

■ Recommended XES structure size

■ Active Acid count Average size xxxxxxx bytes

SCAs

LSCAs

ZONEs

ZCAs

DIVs

VCAs

DEPTs

DCAs

USERs

PROFs

GROUPs


Control Statements

WHOHAS (Resource Owning ACID)

WHOHAS (resource owning ACID) lists PERMITS to all resources owned by the specified ACID.

Only one WHOHAS control statement per run is permitted.


Chapter 8: PDS Member Level Protection Utilities


Introduction (see page 155) Security Ownership Commands (see page 156)

Introduction Three utility programs are provided to assist the resolution of problems with PDS member level protection. These programs are not normally executed and their use should be under the direction of CA Technical Support personnel. To prevent their misuse, these programs should be secured using "CAPDSSEC" resources within the IBMFAC resource class.


Security Ownership Commands

Security Ownership Commands The following example commands define security ownership over these resources and permit their use by "user1" alone:

TSS ADDTO(anydept) IBMFAC(CAPDSSEC)

TSS PERMIT(user1) IBMFAC(CAPDSSEC.STATUS) TSS PERMIT(user1) IBMFAC(CAPDSSEC.TRACE) TSS PERMIT(user1) IBMFAC(CAPDSSEC.TERM)

CAS4STAT will display overall status of the PDS member level protection component, location of key modules, and other statistics. This program can only be executed using an ACID which has access to the CAPDSSEC.STATUS resource within the IBMFAC resource class. Sample execution JCL follows.

//PDS EXEC PGM=CAS4STAT,REGION=512K

CAS4TRCE will enable PDS member level protection tracing. Trace messages are issued to the system console. This program can only be executed using an ACID which has access to the CAPDSSEC.TRACE resource within the IBMFAC resource class. The output messages from this trace are documented in CA Top Secret Messages and Codes, CAS Messages section. Sample execution JCL follows.

//PDS EXEC PGM=CAS4TRCE,REGION=512K,PARM='opt'

Where opt can be:

ON

Enables general tracing.

SEC

Enables tracing of security processing.

CCW

Enables general tracing and also traces CCW I/O activity against a protected data set. This setting can potentially generate a lot of output and, depending on how many data sets are protected, impact system performance.

MEM

Enables general tracing and also generates tracing showing Using the TSSFAR UtilityUsing the TSSFAR UtilityPDS member information including disk address translation. This setting can potentially generate a lot of output.

ALL

Enables all tracing.


Security Ownership Commands

OFF

Disables all tracing.

CAS4TERM may be run to remove PDS member level protection intercepts from the system. In all normal situations, TSS MODIFY PDSPROT(ON/OFF) commands should be used to enable or disable PDS member level protection. This program can only be executed using an ACID which has access to the CAPDSSEC.TERM resource within the IBMFAC resource class. Sample execution JCL follows.

//PDS EXEC PGM=CAS4TERM,REGION=512K

To re-enable PDS member level protection, issue the following command:

TSS MODIFY PDSPROT(ON)


Appendix A: Diagnostic Tools This section contains the following topics:

Diagnostic Tools for Authorization Issues (see page 160)


Diagnostic Tools for Authorization Issues

Diagnostic Tools for Authorization Issues The following is list of diagnostic tools, descriptions, and where you can find further information:

TSS LIST

Lists ACID information including that contained in attached profiles. Lists global (ALL) authorizations related to the accessed resource.

TSSSIM utility

Simulates resource access requests made by users. Pinpoints the rule that allows or denies access. Most access problems or behaviors can be effectively diagnosed by TSSSIM.

SAF SECTRACE command

Captures, formats, and displays the RACROUTE parameter list passed by requests for z/OS and OpenEdition SAF services.

See SAF SECTRACE discussion in the appendix, “Tracing SAF Requests“.

TSS WHOHAS

Lists the ACIDs which have access to the resource specified in the command.

TSSUTIL program

Used to obtain event reports.

TSS WHOAMI

Describes a logged-on user's security environment and important controls such as bypass attributes, log and message display options, and user's mode. Useful for “on-the-spot” debugging.

TSSOERPT program

Used to obtain a report on OpenEdition security events.

MODE

The mode of the actual event, not always the user's or facility's mode. You must know the actual mode, be it facility, user, or event level. The only sure way of knowing the mode of a security event is through a trace.

Authorization Algorithm

Basic understanding of the algorithm is mandatory for definition of proper authorizations.

AUTH control option

Incorrect setting or changing of AUTH dramatically affects whether CA Top Secret will grant access to a resource.

LOG control option


Diagnostic Tools for Authorization Issues

LOG and FACILITY(LOG=) control CA Top Secret violation recording and message display.

Message Algorithm

Explains when and why messages are displayed or suppressed. The appendix, “Message Display/Suppression Algorithm,” describes the algorithm.

MSG control Option

Controls message characteristics, such as when they are to be suppressed.

TRACE

The diagnostic trace can be employed to provide event-related details that cannot be uncovered by other tools. The appendix, “CA Top Secret Diagnostic Trace,” explains how to interpret trace information.

STATUS control option

Status of various control options and understanding of how they relate to or affect CA Top Secret's behavior.

FACILITY control option

Attributes and status of facility controls.

DRC control option

Controls or displays violation attributes, especially if your site has changed the effect of some violations.

TSSAUDIT utility

Generates attribute cross-reference and audits z/OS bypasses.

DIAGTRAP control option

Diagnostic dump production.

Generates internal control block dump.

TSSCHART program

Diagrams your Security File organization and structure.

TSSCFILE program

Formats the Security File records to be used for generating customized reports.

PDS member level

Provides utility programs to assist the resolution of protection utilities problems with PDS member level protection.


Appendix B: CA Top Secret Diagnostic Trace


Introduction (see page 163) Trace Destinations (see page 163) Example Diagnostic Traces and Meanings (see page 185)

Introduction The trace is used to diagnose access problems. It is activated via any one of several control options specified through the O/S MODIFY TSS command or the TSS MODIFY in combination with the TSS ADDTO commands:

Trace Level Activation

SYSTEM-WIDE SECTRACE(ON) SECTRACE(WTO) SECTRACE(WTL)

FACILITY-WIDE FACILITY(TSO=TRACE)

GROUP OF USERS TSS ADDTO(profile) TRACE

SPECIFIC USER TSS ADDTO(user) TRACE

Trace Destinations TSO traces go to both the user's screen and the system log. IMS, CICS, and other online traces go to SYSLOG.

Note: For CICS, you can also write diagnostic trace records into the CICS main trace table; see the Implementation: CICS Guide for details.

For batch, traces go to SYSLOG if SECTRACE(ACT,WTL) is specified, or to the security console if SECTRACE(ACT,WTO) is specified.

The trace provides abundant information: three or four lines worth per event. Therefore keep tracing down to a minimum and be specific about who or what is being traced.


Trace Destinations

Trace Messages

A sample trace message is shown below. A table that explains what each term in the message indicates appears in the following sections.

Trace messages begin with:

TSS-?

The ? indicates the type of trace record, as shown below. A trace for a single event comprises four or five trace messages with the headers shown below.

TSS-x-trace data ........

TSS-1 trace data ........


TSS-3 optional trace data if LIBRARY was specified in rule for event


TSS-5 optional trace data if the event is a RACROUTE EXTRACT


Trace Destinations

Detail 1

TSS-x-rcdr*acid init fcmmrr G/swr1r2dhvh,pfdovoaa L/l1l2ee F/f1f2f3f4, c1c2c3,aabb,iijjkk

x

Event Code:

■ A=Abend

■ C=RACROUTE REQUEST=AUTH

■ D=RACDEF access

■ E=termination

■ F=RACROUTE REQUEST=FASTAUTH

■ I=initiation/signon

■ L=RACLIST

■ O=RACROUTE REQUEST=AUDIT

■ P=Control option

■ T=TSS command/program

■ V=password verify (from JES)

■ X=RACXTRT

■ Y=VERIFYX call from JES

rc

Security Interface Return Code (hex):

■ 00-access allowed

■ 04-resource not owned / ACID not defined / ACTION(PASSWORD) on data set PERMIT

■ 08-access denied / signon password incorrect

■ 0C-password expired

■ 10-new password invalid

■ 14-signon failed

■ 18-initiation failed by site security exit

■ 1C-initiation access failed (see DRC for explanation)

■ 20-force TSO UADS password security

■ 28-OID card required

■ 2C-OID card not valid

■ 30-terminal access rejected

■ 34-application access denied


Trace Destinations

■ 50-surrogate check failed

■ 54-JESJOBs not authorized

dr

Detail Violation Reason Code (hex):

Specific violation code that denied access or operation.

*If present, indicates that the return code 'rc' was actually passed to the caller. If blank, then a real return code of 00 was returned. A real return of 00 indicates that the user is not in FAIL MODE.

acid

The name of the ACID associated with this event.

init

A batch jobname, STC procname, or online userid with this event.

f

Facility Code-From the Facility Matrix entry for this facility. Identifies the facility:

■ T=TSO

■ C=CICSPROD

■ B=BATCH

■ I=IMSPROD

■ S=STC

■ K=CICSTEST

■ N=NCCF

■ R=ROSCOE

See FACILITY(ID) in the Control Options Guide.

c

Resource Class or Event:

Identifies the type of resource being accessed, or the operation being attempted. For example: PROGRAM, CPU, TERMINAL, DATASET, ABSTRACT, VOLUME.

mm

User or Facility Mode (bit mask):

■ 0=DORMANT

■ 40=WARN

■ 20=FAIL


Trace Destinations

■ 30=IMPL,

■ 01=CA-Top Secret HAS EXPIRED

rr

RACF SVC Flags (bit mapped):

RACINIT:

■ 00ENVIR=CREATE

■ 04STAT=NO

■ 08PASSCHK=NO

■ 40ENVIR=CHANGE

■ 80ENVIR=DELETE

■ C0ENVIR=VERIFY

RACHECK:

■ 00RACFIND not specified

01ENTITY=(,CSA)

■ 02LOG=NONE

■ 0831-bit parameters

■ 10VSAM dataset

■ 80RACFIND=NO

■ C0RACFIND=YES

RACDEF:

■ 00RACFIND not specified

■ 20CHKAUTH=YES

■ 80RACFIND=NO

■ C0RACFIND=YES

G/

Algorithm Data

sw

Algorithm Switch:

■ 00access allowed

■ 04authorization not found

■ 08access denied

■ 0Cvolume access is create; force DSN checking

■ 10volume access is (none)


Trace Destinations

r1

RELATIVE RULE that allowed or denied data set (first rule is 01, second rule is 02, and so on.)

r2

RELATIVE RULE that allowed or denied volume access

dh

ALGORITHM HIGH LENGTH for data sets or resources

vh

ALGORITHM HIGH LENGTH for volume access

pf

RELATIVE SECURITY RECORD that allowed or denied access:

■ 00 = USER record

■ FF = ALL record

■ 01-FE = PROFILE 1-254

do

DATA SET AUTHORIZATION ORIGIN: (see vo below)

vo

VOLUME AUTHORIZATION ORIGIN:

■ 10 = owned (via TSS ADDTO)

■ 20 = authorized (via TSS PERMIT)

■ 80 = tape owned

aa

ACTION from rule that authorized or allowed access (bit mask):

■ 02PASSWORD or NODSN or DENY

■ 08NOTIFY

■ 10EXIT

■ 20AUDIT

■ 80FAIL

L/

LOGGING INDICATORS

l1

■ 01do not write to SMF

■ 02force message to user

■ 04send specific message by id


Trace Destinations

■ 08do not perform I/O

■ 10audited event

■ 20real return code passed

■ 40forced log-out

■ 80violation

l2

FLAGS (bit mask):

■ 01delay after message

■ 02audit update/alteration

■ 04audit access if successful

■ 08audit access or LOG=NOFAIL

■ 10initiating control ACID

■ 20reserved

■ 40do not update feedback area

■ 80LOG=NONE

ee

EVENT CODE:

■ 01job initiation

■ 02resource check

■ 32TSS command

■ 33program change

■ 34change control option

■ 39DUF update

■ 40operator accountability check

F/

FLAG INDICATOR

f1

■ 01 = change propagation

■ 02 = rename

■ 04 = RACROUTE REQUEST=FASTAUTH logging

■ 08 = JES early verify

■ 10 = trace this call

■ 20 = always caller


Trace Destinations

■ 40 = tape data set request

■ 80 = VSAM data set access

f2

■ 01 = ACTION(EXIT)

■ 02 = no initiation resource checks

■ 04 = FETCH protection required

■ 08 = VTHRESH exceeded

■ 10 = this is a "non" violation

■ 20 = mask search performed

■ 40 = resource is audited

■ 80 = ACTION(PASSWORD)

f3

■ 01 = environment data obtained

■ 02 = z/OS system

■ 04 = feedback area validated

■ 08 = do not perform logging

■ 10 = audit this event

■ 20 = simulator trace

■ 40 = TSSSIM simulation

■ 80 = AMODE(31) storage used

f4

■ 01 = PLIST is not RACF-compatible

■ 02 = this is TCBSENV

■ 04 = third party RACHECK

■ 08 = RACHECK invoked by FRACHECK

■ 10 = at least ONE TSO message issued

■ 20 = priv/exempt caller

■ 40 = initiator in control

■ 80 = JES2 or JES3 in control

c1

■ 01 = password change required

■ 02 = exit continues without checks

■ 04 = no password checking


Trace Destinations

■ 08 = user mode used

■ 10 = STCACT

■ 20 = VMRDR submission

■ 40 = password violation

■ 80 = security bypass /job

c2

■ 01 = abend switch

■ 02 = address space termination

■ 04 = CHKAUTH=YES

■ 08 = ACEE= supplied with SVC

■ 10 = non 3270 device

■ 20 = GAR retry

■ 40 = undefined ACID

■ 80 = OID card prompt

c3

UNDEFINED ACID RETRY SWITCH:

■ n01 = default ACID

■ n02 = exit called

aa

PROCESS/ABEND STATE (bit mapped):

■ 01 = TSSERASE

■ 02 = TSSKGAR

■ 04 = logging interface

■ 20 = installation exit

■ 40 = invalid feedback area

■ 80 = invalid parameter

bb

MODULE/ABEND STATE (bit mapped)

■ 01 = TSSKROUT

■ 02 = TSSKEXTR

■ 04 = TSSKCHG

■ 08 = TSSKIXI

■ 10 = TSS utility or command


Trace Destinations

■ 20 = TSSKSEC

■ 40 = TSSFRACK

■ 80 = TSSKID

ii

INSTALLATION EXIT FLAG (bit mapped):

■ 01 = RESERVED

■ 02 = RESERVED

■ 04 = RESERVED

■ 08 = User in BYPASS mode

■ 10 = RESERVED

■ 20 = Exit requested ACID to be suspended

■ 40 = Exit requested auditing

■ 80 = Exit requested MODE change

jj

Return Code From Installation Exit

kk

Function Code For Entry To Installation Exit


Trace Destinations

Detail 2 TSS-1 ravada v1v23v400 T/t1t2t3t4t5 volser resourcenamenewdsname

ra

Requested Access Level (see da below)

va

Allowed Access Level For Volume (see da below also)

■ 8000 = BLP

da

■ Allowed Access Level For Data Set:

■ 0100 = NOCREATE (volume level access only)

■ 0400 = CONTROL

■ 0800 = SCRATCH

■ 1000 = CREATE

■ 1C00 = ALTER (ALL) (control, scratch, create)

■ 2000 = WRITE

■ 4000 = READ

■ 6000 = UPDATE

■ 8000 = FETCH

■ FFFF = ALL

v1

Tape Volume Information:

If tape VOLUME protection is active

■ 01 = volume not authorized

■ 08 = scratch requested

■ 10 = volume not owned

■ 20 = volume is owned

■ 40 = volume defined as SCRATCH

■ 80 = not defined to CA-Top Secret

v2

Tape Volume Switch


Trace Destinations

v3

Tape Volume Disposition (bit mapped):

■ 40 = DISP=OLD

■ 80 = DISP=MOD

■ C0 = DISP=NEW

v4

Tape Volume Disposition (bit mapped):

■ 00 = RESERVED

■ 01 = UNCATALOGED

■ 02 = CATALOGED

■ 04 = DELETE

■ 08 = KEEP

■ 10 = PASS

00

Reserved

T/

Trace Information

t1

■ 01 = password required for this ACID

■ 02 = default ACID assigned (INIT) or restricted CA-Top Secret data set accessed

■ 04 = userid extracted from NJE header

■ 08 = DRC(FAIL) alteration

■ 10 = password not validated or vol scan

■ 20 = exit invoked

■ 40 = CVOL (CHECK) or random password generation

■ 80 = resource audit

t2

■ 01 = DINFO occurred

■ 02 = unused

■ 04 = TAPE dsname derived or DASDVOL scratch dsname derived

■ 08 = unused

■ 40 = RESERVED

■ 80 = MUAS c/b switch occurred (INIT) or VINFO obtained


Trace Destinations

t3

■ 01 = data set prefix found

■ 02 = unused

■ 04 = NOxxxCHK access allowed

■ 08 = data set rule found

■ 10 = library scan found library

■ 20 = library scan occurred (CHECK) or forced password change

■ 40 = TMP CALL active

■ 80 = unused

t4

■ 01 = extra restrictions in rule

■ 02 = VSAM access level change

■ 04 = tasklib present

■ 08 = TMP active

■ 10 = no library

■ 20 = fetch-only rule found

■ 40 = extended mask found

■ 80 = floating mask found

t5

■ 01 = KSEC/KID entered

■ 02 = automatic logon occurred

■ 04 = SECREC built

■ 08 = dummy SECREC built

■ 10 = ACEE built

■ 10 = RECVR allowed access (if call is not a RACINIT)

■ 20 = 31-bit XA GETMAIN

■ 40 = ACEE freed

■ 80 = SECREC freed

volser

Volume Serial


Trace Destinations

resourcename

Data Set or Resource Name

newdsname

NEW Data Set Name


Trace Destinations

Detail 3

TSS-2 s1s2cp R/ssffaa terminal S/i1i2i3,a1a2a300 A/afasai P/pgminfo, p1,c1c2,p2,p3 F/fafbfcfd

s1

SVC in control

s2

SVC above SVC in control

cp

CVOL/VSAM flag

R/

RACVT Data

ss

STATUS (bit mapped):

■ 02 = AUTOCMDS issued

■ 10 = reserved

■ 20 = emergency bypass active

■ 40 = reserved

■ 80 = TSS address space is DOWN

ff

FLAGS (bit mapped):

■ 01 = DEBUG(ON)

■ 02 = reserved

■ 04 = RESERVED

■ 08 = MSUSPEND(YES)

■ 10 = AUTOERASE(YES)

■ 20 = RESERVED

■ 40 = ADSP(ALL) in effect

■ 80 = recovery active

aa

ALGORITHM (default AUTH(OVERRIDE,ALLOVER)):

■ 40 = ALL RECORD MERGE

■ 80 = PROFILE MERGE


Trace Destinations

terminal

Online Terminal or Batch Reader Name

S/

SECREC Indicators and Attributes

i1

■ 01 = master SECREC

■ 02 = multi-user address space

■ 04 = reserved

■ 08 = reserved

■ 10 = exclusive LCF present

■ 20 = inclusive LCF present

■ 40 = executing under TMP

■ 80 = bypass active

i2

■ 01 = defined user

■ 02 = TSS address space

■ 04 = in-core DUF update occurred

■ 08 = unused

■ 10 = unused

■ 20 = password verified by JES

■ 40 = reserved

■ 80 = default SECREC

i3

■ 01 = unused

■ 02 = unused

■ 04 = TSO password supplied

■ 08 = error in SECREC

■ 10 = locked due to excessive violations

■ 20 = TSO retry pending

■ 40 = terminal locked

■ 80 = initialization complete


00

Trace Destinations

a1

■ 01 = NOSUBCHK

■ 02 = TRACE

■ 04 = OIDCARD required

■ 08 = AUDIT

■ 10 = NOPWCHG

■ 20 = NOADSP

■ 40 = TSOMPW attribute

■ 80 = multiple passwords/fac

a2

■ 01 = unused

■ 02 = NOLCFCHK

■ 04 = NODSNCHK

■ 08 = NOVOLCHK

■ 10 = NORESCHK

■ 20 = SUSPEND attribute

■ 40 = record in error

■ 80 = library(s) permitted

a3

■ 01 = unused

■ 02 = unused

■ 04 = DUFUPD

■ 08 = DUFXTR

■ 10 = reserved

■ 20 = CONSOLE

■ 40 = reserved

■ 80 = MRO attribute

Reserved

A/

ACEE Indicators CA-Top Secret


Trace Destinations

af

■ 01 = ACID defined to CA-Top Secret

■ 40 = ADSP active for user

as

■ 01 = DLI initiation complete

■ 02 = TONE initiation complete

■ 04 = VAM/SPF initiation complete

■ 08 = IDMS/DC initiation complete

■ 10 = multi-user address space

■ 20 = MRO environment

■ 40 = IMS initiation complete

■ 80 = CICS initiation complete

ai

■ 20 = TSB password updated

■ 80 = ACEE completed

P/

Programs in control

pgminfo

Name of program currently in control

p1

Program from current TCB, TOP PRB

c1

CDE ATTR1

c2

CDE ATTR2:

■ n02 = SYSLIB

■ n01 = APF (from LINK or ATTACH)

p2

Program from current TCB, BOTTOM PRB (from LINK SVC)

p3

Program from higher TCB, TOP PRB (mother program)

F/

Facility (Matrix Entry) Attributes


Trace Destinations

fa01 = XDEF

■ 02 = MULTIUSER

■ 04 = NOABEND

■ 10 = ASUBM

■ 20 = NSHRPRF

■ 40 = INACTIVE

■ 80 = facility in use

fb01 = NOINITAUTH

■ 02 = RNDPW

■ 04 = NOINSTDATA

■ 08 = unused

■ 10 = PSEUDO

■ 20 = SIGNS

■ 40 = STMSG

■ 80 = LUMSG

fc01 = transactions being used

■ 02 = TSOC

■ 04 = WARNPW

■ 08 = unused

■ 10 = NORES

■ 20 = AUDIT

■ 80 = TSOPWP

fd01 = VM SIO checking in effect

■ 02 = IMS extended support

■ 04 = new password reverification

■ 08 = honor password in dormant mode

■ 40 = TRACE

■ 80 = ALWAYSCALL


Trace Destinations

Detail 4

TSS-3 pgm bkbzbt librarydata setname

BLDL information only when data set rule specifies library.

pgm

BLDL program name

bk

BLDL concatenation number of task library

bt

BLDL type

bz

BLDL module origin:

■ 01 = linklist

■ 02 = tasklib

■ 03+ = higher TCB

■ 03+ = higher TCB tasklib


Trace Destinations

Detail 5

TSS-4 aiai2a3a4 aaaaaaaa ssssssss REQ/reqstor SUB/subsys OC/xxxxxxxx

Audit Indicator Information

a1

First Audit Indicator

■ 01=action of audit

■ 02=user is audited

Can be result of:

– facility has AUDIT attribute FACILITY(xxx=AUDIT)

– check facility flags

– in trace CA-Top Secret-2 message

– user bypassing security

– installation exit requesting audit of user

■ 04=TEMPDSN(NO)

■ 08=CA-Top Secret file access

■ 10=Bypass DSN check (NODSNCHK)

■ 20=DSN/VOL exit RC=8

■ 40=ACEEOPER set

■ 80=security bypass set

a2

Second Audit Indicator

■ 01=RESERVED

■ 2=DRC(AUDIT)

■ 04=audit of update

■ 08=audit if successful

■ 10=signon terminal/CPU audited

■ 20=resource audit

■ 40=DSN audit

■ 80=volume audit

a3

Third Audit Indicator

■ 01=Reserved

■ 02=RESERVED


Trace Destinations

■ 04=RESERVED

■ 08=environmental error

■ 10=user authentication

■ 20=user accountability

■ 40=lock request

■ 80=no authority for function

a4

Fourth Audit Indicator

■ RESERVED

aaaaaaaa

Address of ACEE

ssssssss

Address of SECREC

reqstor

The REQSTOR= parameter from the RACROUTE macro

subsys

The SUBSYS= parameter from the RACROUTE macro

OC

The original resource class if a translation was performed

Detail 6

TSS-5 fieldname/pf fieldname/pf fieldname/pf fieldname/pf fieldname/pf fieldname/pf

Fieldname

Name of field to be extracted

pf

Relative security record from which the field was extracted:

■ 00 = User record

■ 01-FE = Profile 1-254

■ FF = Default value supplied

■ NF = Field not found


Example Diagnostic Traces and Meanings


Example 1. CPU Validation During TSO Logon

TSS-F-0000 NLSMPK NLSMPK T U4000 G/0000000000,00000000 L/00A002 F/04000F20,000800,0001,000000 TSS-1 000000 0000000000 T/0000000000 CPU.XA81 TSS-2 830000 R/108A00 S/000100,02002000 T0001013 A/010080 P/IKJEFLC, B512, ,IDJEFLA F/80C20600

TSS-F indicates RACROUTE REQEST=FASTAUTH validation.

Return code 00 and no violation (00).

ACID and jobname both NLSMPK.

T indicates TSO.

U indicates Abstract.

4000 shows Warn MODE.

Logging indicates Log=None (normal for CPU check by CA-Top Secret).

Resource is CPU.XA81.

SVC in control is 83 (Racinit).

User (ACID) is defined. ACID has TRACE and CONSOLE attributes.

Terminal is T0001013. Program in control is TSO scheduler (IKJEFLC), running.

Facility using LastUsed and Status, RndPw, WarnPw options.



Example 2. Password Violation during TSO Logon

TSS-I-0809*NLSMPK NLSMPK T 4000 G/0000000000,00000000 L/F01001 F/00000330,400000,0081,000040 TSS-1 000000 0000000000 T/1100000015 TSS-2 008000 R/108A00 S/000100,02002000 T0001013 A/010080 P/IKJEFLC B512, ,IDJEFLA F/80C20600

TSS-I shows initiation call. Real return code passed to TSO (*).

Return code violation code is 09.

Logging indicates violation, forced logging, real return and event being audited.

Flags indicate password violation.

Trace (11) shows password required but not validated.

Example 3. Reader Access Violation for Batch Job

TSS-I-1C88 NLSMPK BJOB2 B TERMINAL 4000 G/0000000000,00000000 L/801001, F/00000330,000000,0081,000040 TSS-1 000000 0000000000 T/0100000015 R5.R1 TSS-2 008000 R/108A00 S/000100,02002000 T0001013 A/010080 P/IEFIIC , B512,IEFIB600,IEESB605 F/80C00400

Another initiation call. Return code passed to initiator is 00, but would be 1C if this had been a real failure instead of a warning.

Violation is 88 (136).

B indicates Batch facility.

TERMINAL indicates batch job performing reader violations.

Trace (01) shows required password has been validated.

Source of origin is remote 5.

Program in control is the initiator.



Example 4. Authorized Access to data set

TSS-C-0000 NLSMPK LINKMVS B DATASET 4081 G/0009080906,00202000 L/100002 F/00000320,000000,0021,000040 TSS-1 60FF10 0000000000 T/0000090001 SRVC01 SYS2.TSS.TEST.LOAD TSS-2 160000 R/108A00 S/000180,02002000 INTRDR A/0100A0 P/IEWL , 0B22, ,IEFIIC F/80C00400

Job LINKMVS has accessed SYS2.TSS.TEST.LOAD for update access (60).

ACID NLSMPK has All access (FF).

Algorithm data shows access allowed (00).

Ninth data set permission in user record.

Data set rule had a permission of length nine (actually, SYS2.TSS.), volume rule had six characters (SRVC01).

Open-J was in control (16).

Example 5. Failure Due to Bad Access Level with ACTION(FAIL)

TSS-D-0866*NLSMPK NLSMPK T DATASET 20A0 G/08070A1106,00202080 L/B00002 F/00000330,000000,0021,000040 TSS-1 486010 0000000000 T/0000010801 STRG02 NLSMPK.SYSLOG.DATA TSS-2 1E0000 R/108A00 S/440180,02002000 T0001013 A/0100A0 P/RENAME 3512, ,IKJEFT09 F/80C20600

A real return code of 08 (*) was passed to the rename (1E) SVC.

66 indicates wrong access level attempt. T DATASET shows TSO and data set resource.

A0 indicates RACFIND=NO (no RACF bit).

Algorithm shows access illegal (08), seventh data set rule, tenth volume rule.

Action is FAIL (80), which changes running mode to FAIL (20) for this event.

TSO command is RENAME, running directly under the TMP (IKJEFT09).



Example 6. Job Submission (Authorized)

TSS-C-0000 NLSMPK NLSMPK T ALT-ACID 4081 G/0000000000,00000000 L/100002 F/00000330,000800,0021,000040 TSS-1 400000 0000000000 T/0000000001 NLSMPK TSSRACL TSS-2 000000 R/108A00 S/440180,02002000 T0001013 A/0100A0 P/IKJEFF04, 3122, ,IDJEFF76 F/80C20600

TB indicates job submission (B) from TSO (T).

ACID for job TSSRACL is NLSMPK.

Submit command (IKJEFF04) was used.

Example 7. Program Violation

TSS-F-0888 IMSRG2 IMSB S PROGRAM 4000 G/0000000000,00000000 L/802002 F/04000720,000800,0001,000040 TSS-1 000000 0000000000 T/0000000400 DFSFDLD0 TSS-2 2A0000 R/108A00 S/000180,02000000 A/0100A0 P/DFSXDSP0,0B22,

,DFSMVRC0 F/80C00000

Here a program (DFSXDSP0) which is running as started task IMSB is attempting to access program DFSFDLD0.

0888 indicates resource not accessible.

S PROGRAM shows STC with program check.

4000 shows WARN MODE, therefore the security driver receives a real return code (0) and continues normally.

Example 8. CICS Transaction Violation

TSS-F-0888*DANTEST CICS50 K LCF 2000 G/0000000000,00000000 L/A02002 F/04000720,000800,0001,000040 TSS-1 000000 0000000000 T/0000000400 CSMT TSS-2 000000 R/108A00 S/200180,0A008800 T0001008 A/01B0A0 P/DFHSIP,0B23 ,

,IEESB605 F/16C21500

TSS-F is a FRACHECK-processed CICSTEST,LCF (K LCF) event.

0888* indicates that a real return code was passed back to CICS because the ACID is in FAIL MODE (20).



Example 9. CICS Resource Violation

TSS-F-0888*DANTEST CICS50 K PPT 2000 G/0000000000,00000000 L/A02002 F/04000720,000800,0001,000040 TSS-1 000000 0000000000 T/0000000400 DFHEMTP TSS-2 000000 R/108A00 S/200180,0A008800 T0001008 A/01B0A0 P/DFHEMTP, 3 0B23, ,IEESB605 F/16C21500

A real violation again (*) for PPT (Q) resource DFHEMTP.


Appendix C: Message Display/Suppression Algorithm


Introduction (see page 191) Message Display/Suppression Checks (see page 192)

Introduction The checks that are made to determine whether the user or security console should receive a message are documented in the flowchart on the following page.

Appendix C: Message Display/Suppression Algorithm 191

SUPPRESS

ISSUE MESSAGE

NONO

TYPE

LOG(MSG) LOG(SEC9)

Message Display/Suppression Checks

Message Display/Suppression Checks

YES FORCED

NO

YES FAIL MODE

NO

YES INITIATING

NO

YES DORMANT SUPPRESS MODE

NO

USER MESSAGE

YES

YES SUPPRESS

ANY SUPPRESSIONS

NO

YES SUPPRESS

EXIT SUPPRESSIONS

NO

Some messages are always forced out no matter the mode (such as password violations).

A process in FAIL MODE always gets the message.

Initiating Control ACID always gets the message

No need to harass users in DORMANT MODE

SEC9

LOG suboption of current facility checked for suppression YES

MSG control option can be used to suppress messages under certain conditions

Invoke site security exit with message function and honor desire to suppress


Appendix D: Tracing SAF Requests This section contains the following topics:

About SAF SECTRACE (see page 193) Using the SAF SECTRACE Command (see page 194) Setting and Modifying SAF SECTRACE Operands (see page 197) Stopping (and Restarting) the SECTRACE for OMVS (see page 209) Enabling SAF SECTRACE Traps (see page 209) Disabling SAF SECTRACE Traps (see page 209) Deleting SECTRACE Traps (see page 209) Displaying SAF SECTRACE Operands (see page 210) Setting SAF SECTRACE at SAF Initialization (see page 210) Tracing UNIX System Services (OMVS) (see page 213)


About SAF SECTRACE

About SAF SECTRACE The SAF SECTRACE command enables you to trace any security request made to the System Authorization Facility (SAF). SAF is a z/OS component that permits resource managers of the operating system to request security services. The primary function of SAF is to route security information between the application and the security product that resides with the z/OS software. Any program using SAF automatically interfaces with CA Top Secret because it translates SAF security requests into CA Top Secret requests.

You do not need to use SAF SECTRACE for CA Top Secret to intercept SAF requests; SAF SECTRACE is provided for diagnostic purposes only. You can use SAF SECTRACE to supply information to technical support for a problem or to determine what SAF calls are made by a vendor's product.

SAF SECTRACE enables you to capture, format, and display the RACROUTE parameter list passed by requests for SAF services. It also lets you display additional environmental information, such as job name, user ID, and the program issuing the SAF call. Although you can use SAF SECTRACE to trap all requests made to SAF, you might want to limit the requests that you see. You can limit these requests by identifying who is to be traced, which security events are to be trapped, and where the output is to be routed. The function and keywords of the SAF SECTRACE command closely parallel those of the SLIP command in z/OS.

The batch utility program, TSSRPTST, processes and displays the output that is written to SMF by the SAF SECTRACE command. See the chapter “TSSRPTST Utility” in the Report and Tracking Guide for instructions on how to use this utility.

Because SAF SECTRACE can supply sensitive information about jobs executing in your system, you might also want to limit the use of the SAF SECTRACE command. By using CA Top Secret, you can restrict access via the OPERCMDS resource class.


Using the SAF SECTRACE Command

Using the SAF SECTRACE Command The basic format of the SAF SECTRACE command is shown below.

SECTRACE \{ SET|T operand \} id=trapid|ALL \{ MODIFY|F operand \} \{ ENABLE \} \{ DISABLE \} \{ DELETE \} \{ D|DISPLAY \}

Here are descriptions of these keywords.

SET|T operand

Defines a SAF SECTRACE trap. The following section describes additional operands you can use to define the affected users, actions to take, environmental information, and so on. By default, the SET keyword defines the trap as enabled.

MODIFY|F operand

Changes one or more operands of a named SAF SECTRACE trap. A SAF SECTRACE SET command must have previously defined the trap. The following section describes additional operands you can use to define the affected users, actions to take, environmental information, and so on.

ENABLE

Activates the named SAF SECTRACE trap. A SAF SECTRACE SET command must have previously defined the trap.

DISABLE

Deactivates the named SAF SECTRACE trap. The trap definition is retained and can be reactivated by a subsequent SAF SECTRACE ENABLE command.

DELETE

Removes the named SAF SECTRACE trap definition.

D|DISPLAY

Displays the status and operands of the named SAF SECTRACE trap.

ID=trapid|ALL

Names the SAF SECTRACE trap. Define multiple trace requests by specifying a unique ID for each. This keyword is required with all SAF SECTRACE commands except the SAF SECTRACE SET command. If you do not supply an ID value with the SET command, the SAF SECTRACE command assigns a value. The format of the default trace ID is TRACE (nnn),where (nnn), is the next available sequential number. ALL specifies that all IDs are to be traced.


Using the SAF SECTRACE Command

Note: You must enter the ID on the MODIFY command before any other operand.

The protection table of the SECTRACE command is shown below:

Command OPERCMDS resource name access

SECTRACE SET TRCE.SECTRACE.SET UPDATE

SECTRACE DELETE TRCE.SECTRACE.DELETE UPDATE

SECTRACE MODIFY TRCE.SECTRACE.MODIFIED UPDATE

SECTRACE DISPLAY TRCE.SECTRACE.DISPLAY READ

SECTRACE ENABLE TRCE.SECTRACE.ENABLE UPDATE

SECTRACE DISABLE TRCE.SECTRACE.DISABLE UPDATE

The ST command starts the SECTRACE address space and this address space remains up (but not active) until the next IPL. The only time the address space does anything is when the SAF SECTRACE is active. No attempt should be made to cancel the SECTRACE address space as unpredictable result might occur.

You can enter the SECTRACE command at an operator's console, at a terminal that acts as a console, or through SYS1.PARMLIB. When the first SAF SECTRACE command is entered, CA Top Secret automatically starts the SAF SECTRACE address space.

When you enter commands at a console, you can enter multiple keywords and operands by pressing ENTER after each line. SAF SECTRACE prompts you at the operator's console issuing the command for more operands until you type:

END or CANCEL.

Here is an example of the WTOR message asking for continuance of the SAF SECTRACE operands:

nn CAS21100 CONTINUE SECTRACE SPECIFICATION, CANCEL, OR END

R nn,JOBNAME=jobname,END


Setting and Modifying SAF SECTRACE Operands

Setting and Modifying SAF SECTRACE Operands The SAF SECTRACE SET and MODIFY operands are divided into the following groups:

TYPE

Identifies the security event to be processed.

OMVS

Identifies callable services.

TRACING

Defines the user or job that is being trapped. These operands filter the security events based on the user making the SAF request.

ENVIRONS

Defines the environment of the request that is being trapped. These operands filter the security events based on the event's return and reason codes, the request block of the security event, and the program.

STATUS

Activates and deactivates a trap. These operands also determine the action that occurs when an event matches as well as when the SAF SECTRACE trap is applied (before or after security processing).

EVENTS

Specifies when the SAF SECTRACE trap is automatically deactivated.

ROUTE TO

Defines the destination and formatting options of the trace output.

Other Operands

Specify whether the specifications for the current SAF SECTRACE trap are complete or whether the specifications should be canceled for this ID.

The syntax for the SAF SECTRACE command is as follows:

SECTRACE\{ SET \} operands

\{ MODIFY\}



The following table describes the SET and MODIFY operands:

Operand Description

ID=trapid|ALL Trap identification

[ TYPE=SAF|SAFP|OMVS] TYPE group

[FUNC=ALL|MAKE|INIT|SET|GET| CHECK|CHANGE|MISC]

OMVS group

[ ASID=nn] [ JOBname=mask] [ USERid=mask]

TRACING group

[ RB=mask] [ ProGraM=mask] [ RETcode=nn] [ RSNcode=nn]

ENVIRONS group

[ ENABLE|DISABLE ] [ ACTION=IGNORE|TRACE] [,TRACE= [ PRE|BEFORE ]] [ [ POST|AFTER ]] [ [ ALL ]]

STATUS group

[ ,MATCHLIM=1000|0|nn] EVENTS group

[CONSid=nn] [TSoUser=id] [LINELEN=nn] [,DEST=[ CONSOLE ]] [ [ JOBLOG ]] [ [ SMF ]] [ [ SYSLOG ]] [ [ TSOUSER ]] [ [ ALL ]] [ [ DATASET ]] [,ForMaT[ DUMP ]] [ [ LABEL ]] [ [ NOPACK ]] [ [ PACK ]] [ IMSGid|NOMSGid] [ WAIT|NOWAIT]

ROUTE TO group

[END ] [CANCEL ]

Other operands

You must identify the trap through the ID operand when you issue the SAF SECTRACE MODIFY command. You can, however, invoke the SAF SECTRACE SET command without the ID operand. SAF SECTRACE assigns the value TRACE(nnn), where (nnn) is the next available sequential number.



TYPE Group Operands

The TYPE group contains one operand (TYPE) that identifies the type of security event to be processed. It enables you to specify RACROUTE parameters. These parameters act as additional filters on specific SAF requests. Here are the TYPE operand options.

TYPE=SAF|SAFP|OMVS

Permits you to specify the type of security event traced.

SAF

Specifies that the security event to be traced is from the z/OS SAF facility. Any SAF event that matches the specified environment qualifies for tracing. SAF is the default.

SAFP

Specifies that the security event to be traced is from the z/OS SAF facility. However, this option enables you to enter additional SAF information you can use to further filter out SAF events. When you enter TYPE=SAFP you are prompted by SAF SECTRACE for the RACROUTE parameters. The parameters you can specify are documented in the IBM z/OS/ESA SPL: Application Development Macro Reference Guide. Only single values for parameters are accepted. Also, the maximum length that you can specify for the parameter keyword, operator, and value is 64 characters. To specify parameters unique to a specific RACROUTE request, first enter REQUEST= to specify the type of RACROUTE request. SECTRACE continues to prompt you until you enter END or CANCEL. Here is an example of how SAF SECTRACE prompts you:

sectrace set,id=test,type=safp nn CAS21200 SPECIFY RACROUTE PARAMETERS, CANCEL OR END r nn,request=verify,subsys=mymusass,reqstor=mypgm-nn CAS212210 CONTINUE SAF RACROUTE SPECIFICATIONS, CANCEL, OR END r nn,envir=create,acee=>,loc<>below,end nn CAS21100 CONTINUE SECTRACE SPECIFICATIONS, CANCEL, OR END r nn,end CAS21110 SECTRACE SET ON 91.026 13:01:52 id=TEST

You must adhere to RACROUTE macro coding conventions when you specify RACROUTE parameters for SAF SECTRACE filtering. However, you can specify special operators to indicate the presence of a particular value (for example, ENVIR=CREATE) or the presence of a pointer address (for example, ACEE=>). You can use the following operators depending on your type of keyboard:

=

Equal to

^=

Not equal to



<>

Not equal to

!=

Not equal to

=>

Pointer address specified

^=>

No pointer address specified

!=>

No pointer address specified.

Pointer operators are valid only if the parameter is specified as a pointer to a data area or a data structure (for example, an ACEE). When you specify a pointer operator, you cannot specify a value for the parameter. A point operator indicates the presence or absence of a pointer. For example, you cannot specify ACEE=>address, but you can specify ACEE=> or ACTINFO^=>. You can mask character data types of parameters using standard CA Top Secret masking characters (asterisks or dashes). You can mask other types of data only if the mask is complete. A complete mask indicates that the trap will match all values. For example, you can enter USERID=- to indicate that this parameter matches all values of USERID.

USERID^=

Indicates that the USERID option is not coded on the RACROUTE request.

OMVS

Specifies that the security event to be traced is from the z/OS OMVS/Unix Systems Services facility. Any SAF event that matches the specified function qualifies for tracing.



OMVS Group Operands

The OMVS group defines callable services using the following command:

FUNC=ALL|MAKE|INIT|SET|GET|CHECK|CHANGE|MISC

The following lists the callable services for FUNCTION (FUNC):

MAKE

make_fsp, make_root_fsp, make_ISP

INIT

initUSP, deleteSUP, fork_exit, init_ACEE

SET

set_file_creation_mask, setuid, set_effective_uid, setgid, set_effective_gid, R_exec_set, clear_setid, R_admin

GET

getUMAP, getGMAP, get_supplemental_groups, get_users_groups, get_effective_uid_gid_supplemental_groups, R_dceinfo, R_dcekey, R_dceruid

CHECK

check_access, check_privilege, check_process_owner, check_file_owner, check_owner_2_files, R_dceauth

CHANGE

change_owner_group, change_file_mode, change_audits_options

MISC

audit, query_file_options, query_security_options

Note: FUNC defaults to ALL if not specified.

You cannot specify more than one function, however, multiple SECTRACES can be set. Other parameters can be specified on the command, but they are ignored. The OMVS SECTRACE output is written to the console only. DEST does not redirect the output.



TRACING Group Operands

The TRACING group specifies which address spaces, jobs, or users must be in control for an event to match the SAF SECTRACE specifications. By specifying USERID= - or JOBNAME= -, you can trap events regardless of the address space they occur in. However, you can create more specific traps to filter out individual users or started tasks by ASID or job name. These traps enable you to use SAF SECTRACE in a production environment with little impact. When you specify one or more operands from this group, a match occurs only when all of the operands are matched (that is, the operands are ANDed together). Here are the TRACING group operands.

ASID=nn

Specifies the address space number.

JOBname=mask

Indicates the job name or job name mask of the target address space as determined by the ACUCB (address space level ACEE). You can use this operand to target batch, TSO, started task, and MOUNT address spaces, even if they are not secured by CA Top Secret.

Note: Use an asterisk (*) as a masking character to display all possible combinations of a specific jobname. For example, specify ABC* to display all jobnames beginning with ABC.

USERid=mask

Specifies the logonid or logonid mask of the target address space as determined by the ACUCB (address space level ACEE).

Note: Use an asterisk (*) as a masking character to display all possible combinations of a specific userid. For example, specify ABC* to display all userids beginning with ABC.



ENVIRONS Group Operands

The ENVIRONS group operands act as filters on the environment when a security event occurs. If one or more fields from this group are specified, all fields must match for SAF SECTRACE to trap the event. Here are the criteria that you can specify for the ENVIRONS group.

RB=mask

Specifies the request block (RB) name that the security event must occur in. When an event occurs directly under a PRB, the name of the program specified in that block is used to match what you specify in this field. If an event occurs under a supervisor call request block (SVRB), the RB name is assigned SVCnnn, where nnn is the decimal SVC number. If this RB is the only RB on the active RB chain under an SVRB, the interrupt code (SVC number) cannot be determined. Therefore, another RB name is assigned. If the program manager indicator is set, the assigned RB name is *PMSVRB*. If this indicator is not set, the RB name is *SYSTEM*. If the security event occurs under the control of a service request block (SRB), the assigned RB name is *SRB*.

ProGraM=mask

Specifies the program name of the newest PRB on the active RB chain. If no PRB exists on the active RB chain when a monitored event occurs, the name used for the RB field is also used for PROGRAM.

RETcode=nn

Specifies the return code to be matched against the return code from the security event. If a return code of 0 (the default) is specified, all return codes from security events match. If a nonzero return code is specified and the return codes match (for TRACE=AFTER requests only), the specified SAF SECTRACE action takes place.

RSNcode=nn

Indicates the reason code to be matched against the reason code from the security event. If a reason code of 0 (the default) is specified, all reason codes from security event match. If a nonzero reason code is specified and the reason codes match (for TRACE=AFTER requests only), the specified SAF SECTRACE action takes place.



STATUS Group Operands

The STATUS group operands define the status of the SAF SECTRACE trap. They also tell SECTRACE which action to take if an event is trapped and when to apply the trap. If an event matches the criteria for more than one defined SAF SECTRACE trap, SAF SECTRACE generates trace output in the order that the SAF SECTRACE traps were entered until a trap specifying ACTION=IGNORE is encountered. Here are the STATUS group operands.

ENABLE|DISABLE

Specifies the initial status of the SECTRACE trap.

ENABLE

Indicates that the SECTRACE trap identified by the ID operand is enabled. All events that match the SECTRACE trap are trapped. This is the default.

DISABLE

Indicates that the SECTRACE trap identified by the ID operand is disabled.

ACTION=IGNORE|TRACE

Specifies the action to perform when a SECTRACE trap is matched.

IGNORE

Indicates that the SECTRACE trap is ignored and the search for other defined SECTRACE traps that might match the event is halted.

TRACE

Specifies that the trace output is sent to all specified destinations. See the DEST operand for the destinations that you can specify.

TRACE=PRE|BEFORE|POST|AFTER|ALL

Specifies when the trap is applied if all criteria are matched: before security validation or processing occurs or after it occurs.

PRE|BEFORE

Specifies that the event is trapped before security validation or processing occurs.

POST|AFTER

Specifies that the event is trapped after security validation or processing occurs.

ALL

Indicates that the event is trapped before and after all security validation or processing occurs.



EVENTS Group Operand

The EVENTS group operand specifies the maximum number of events to be traced before the trap is automatically disabled.

MATCHLIM=1000|0|nn

Specifies the maximum number of trace events to occur before SAF SECTRACE is automatically disabled.

To reduce overhead, terminate SAFTRACE after a finite number of events. The maximum number of events you can specify is 9999 . For an unlimited trace, set the match limit to zero.

When a disabled SAFTRACE is modified to ENABLE, the event counter for the trap is reset to zero and the MATCHLIM remains unchanged (unless specifically modified by the command).



ROUTE TO Group Operands

The ROUTE TO group describes how the trace output is formatted and routed to a console, SYSLOG, JOBLOG, TSO user, or to SMF for batch reporting. This screen shows sample output that might be sent to a console, SYSLOG, JOBLOG, or TSO user:

CAS21301 TRACEID: TRACE001 JOBNAME: CONSOLE ASID: 0007 USERID: N/A CAS21302 PROGRAM: *PMSVRB* RB CURR: *PMSVRB* APF: YES SFR/RFR: 4/0:0 CAS21501 RACROUTE REQUEST=FASTAUTH,REQSTOR=(=>)'PROGMCHK', CAS21501 SUBSYS=(=>)'CONTENTS',MSGSP=0, CAS21501 WORKA=(STRUCTURE SAFWORKA,=>,00AF932C),ATTR=READ CAS21501 CLASS=(=>)'PROGRAM ',ENTITY=((<>)'IEECB800'), CAS21501 RELEASE=1.8,WKAREA=(STRUCTURE,=>,00AF952C)

DEST=CONSOLE|JOBLOG|SMF|SYSLOG|TSOUSER|ALL|DATASET

Specifies where the trace output is delivered when ACTION=TRACE is specified. You can specify these options:

■ CONSOLE-Indicates that trace output is sent to the console identified by the CONSID operand. SAF SECTRACE may discard trace output when control is received with LOCKs held or in SRB mode. When control is received again, a message is issued stating how many trace events were lost.

■ JOBLOG-Specifies that trace output is sent to the JOBLOG (ROUTCDE=11). SAF SECTRACE may discard trace output when control is received with LOCKs held or in SRB mode. When control is received again, a message is issued stating how many trace events were lost.

■ SMF-Indicates that trace output is journaled to the System Management Facility (SMF). SMF is the only trace output destination where output is guaranteed. Information is retrieved and formatted with TSSRPTST.

■ SYSLOG-Specifies that trace output is sent to the system log file (WTL). SAF SECTRACE may discard trace output when control is received with LOCKs held or in SRB mode. When control is received again, a message is issued stating how many trace events were lost.

■ TSOUSER-Specifies that trace output is sent to the time-sharing (TSO) user identified by the TSOUSER operand. See the WAIT|NOWAIT operand for additional information. SAF SECTRACE may discard trace output when control is received with LOCKs held or in SRB mode. When control is received again, a message is issued stating how many trace events were lost.

■ ALL-Indicates that all of the above destinations will receive trace output.



■ DATASET-Specifies that trace output is sent to a data set. The data set can be a sequential data set or a member of a partitioned data set(PDS). SECTRACE might discard trace output when control is received with locks held in SRB mode. DATASET is not included in DEST=ALL. A separate SECTRACE is required to specify DATASET as a destination.

Note: DEST=DATASET also requires the DSName= operand to specify the data set that is to receive the trace output. If a member of a partitioned data set is to be used, the MEMBER= operand is required in addition to the DSName= operand.

CONSid=nn

Identifies the console that receives the trace output when DEST=CONSOLE is specified. This operand avoids problems caused by flooding crucial consoles in a production environment and preserves the existing SAF SECTRACE function. This console may also receive messages regarding the failure to deliver trace messages to any of the other destinations. The default for CONSID is the console that initially set the SAF SECTRACE trap.

DSName=dsn

Identifies the DASD data set that receives the trace output. The data set must be allocated and available before the SECTRACE is enabled.

This must be a fully-qualified data set name. Do not include the member name in the DSName= operand. Use the MEMBER= operand to specify the member name.

Specifying this operand automatically sets DEST=DATASET provided that the DEST= operand does not follow this operand when entering the SECTRACE command.

You can use the INITSECD member included in the sample JCL library to allocate the data set.

TSoUser=id

Identifies the ID of the time-sharing (TSO) user who receives the trace output when DEST=TSOUSER is specified. Refer also to the WAIT|NOWAIT operand.

LINELEN=nn

Specifies the length of the variable output line for the display of the RACROUTE macro parameters.

ForMaT=DUMP|LABEL|NOPACK|PACK

Specifies the format option of the trace output. Format options are valid only for output destinations of CONSOLE, JOBLOG, SYSLOG, and TSOUSER. You can specify one of the following:



Other Operands

■ DUMP-Specifies that the external data structures identified in the RACROUTE macro definition are to be displayed following the RACROUTE macro parameters. These external data structures are shown in both hexadecimal and EBCDIC formats.

Note: DUMP is only valid when used with the PACK operand.

■ LABEL-Indicates that the RACROUTE parameter format extension tags are displayed. This field is for internal use and diagnostic purposes only.

Note: LABEL is only valid when used with the PACK operand.

■ NOPACK-Specifies that the output of the RACROUTE macro is not to be packed. Only one parameter per line is displayed.

■ PACK- Indicates that the output of the RACROUTE macro is to be packed with multiple parameters per line up to the line length specified by the LINELEN operand of the SAF SECTRACE command.

MEMBER=member

Identifies the member of a partitioned data set that receives the trace output.

MSGid|NOMSGid

Indicates whether the message ID of the trace output is displayed on the output. This option is valid only for CONSOLE, JOBLOG, SYSLOG, and TSOUSER destinations. The default is MSGID.

WAIT|NOWAIT

Specifies whether the task control block (TCB) being traced is to wait if trace output destined for a TSO user cannot be displayed until TPUT buffers are available for the TSOUSER destination. The default is NOWAIT. When NOWAIT is specified, trace messages may be lost. When TPUT buffers are available, a message tells the TSO user of the loss of trace messages. Use the WAIT option with extreme caution because you may halt system-level processing by waiting for the availability of TPUT buffers. To view messages and free buffers for use, the TSO user must press the Enter key.

You must choose one of the following operands to complete your SAF SECTRACE specifications.

END

Indicates that the SAF SECTRACE specifications for this trap are finished.

CANCEL

Specifies that the SAF SECTRACE specifications for this trap are ignored.


Stopping (and Restarting) the SECTRACE for OMVS

Stopping (and Restarting) the SECTRACE for OMVS To disable the SECTRACE for OMVS, issue the following command, where tracennn is the identifier assigned to the SECTRACE:

ST DISABLE,ID=tracennn,END

You can restart a disabled trace by entering an enable command. To start a disabled trace, issue the following command, where tracennn is the identifier assigned to the SECTRACE:

ST ENABLE,ID=tracenn,END

To stop the SECTRACE for OMVS, issue the following command, where tracennn is the identifier assigned to the SECTRACE:

ST DEL,ID=tracennn,END

Enabling SAF SECTRACE Traps To activate a SAF SECTRACE trap that has been previously defined by the SAF SECTRACE SET command, enter the following:

SECTRACE ENABLE id=trapid|ALL

Disabling SAF SECTRACE Traps To deactivate a SAF SECTRACE trap, enter the following. The trap definition is retained and can be reactivated using a subsequent SAF SECTRACE ENABLE command.

SECTRACE DISABLE id=trapid|ALL

Deleting SECTRACE Traps To delete a SECTRACE trap that has been previously defined, enter the following:

SECTRACE DELETE id=trapid|ALL


Displaying SAF SECTRACE Operands

Displaying SAF SECTRACE Operands With the SAF SECTRACE DISPLAY command, you can display the operands of a specified trap and the number of events that matched the specified trap. Here is the format of the DISPLAY command:

SECTRACE D|DISPLAY id=trapid|ALL

The following is an example of output from the SECTRACE DISPLAY command:

st d,id=trace001 CAS21160 SECTRACE DISPLAY ID: TRACE001 DATE: 91.026 TIME: 13:45:59 TRACE001 TRACING JOBNAME=CONSOLE,USERID=-

ENVIRONS RETCODE=8,RSNCODE=32,PROGRAM=-,RB=- ROUTE TO DEST=CONSOLE,CONSID=1,FORMAT=DUMP STATUS ACTION=TRACE,ENABLED,TRACE=(BEFORE-SAF,AFTER-SAF) EVENTS MATCHLIM=10 RACROUTE REQUEST=FASTAUTH,REQSTOR='PROG- ',

SUBSYS='CONTENTS',CLASS='PROGRAM '

See the section, Setting and Modifying SAF SECTRACE Operands, for descriptions of each of these operands.

Setting SAF SECTRACE at SAF Initialization SAF SECTRACE may be set during the SAF initialization process when problems are encountered by creating the member, CAISEC00, in SYS1.PARMLIB. This member may contain one of the one-line entries below:

PROMPT or TRACE(zz,{NOSTART|START})

The first entry indicates that the message CAS2070I is generated at the system console. The operator should then respond to the message as designated in Messages and Codes Guide.

The second entry indicates that ST SAF SECTRACE commands are read from member CAITRCzz; the operand, NOSTART or START, is used to indicate if SAF initialization should suppress or start the commands in the member. For details, See the Messages and Codes Guide, message CAS2070I.


Setting SAF SECTRACE at SAF Initialization

Example 1 Installation Defaults

The Installation Guide provides the following default member CAISEC00 and CAITRC00.

CAISEC00: TRACE(00,NOSTART)

This member associates SAF initialization with ST command member CAITRC00, but does not start the commands in that member. The commands provided in CAITRC00 are:

CAITRC00: ST SET,ID=SAFINIT,DEST=SMF,END

Note: The SAF SECTRACE at SAF initialization should be directed to SMF, because it is probable that JES SYSTEM LOFG is not available at the time the trace begins.


Setting SAF SECTRACE at SAF Initialization

Example 2 Prompted Implementation

When directed by support to do so, you may implement a prompted SAF SECTRACE for OMVS with members:

CAISEC00: PROMPT

This member automatically generates the message, CAS2070I, prompting the console operator to choose at IPL whether to initiate a SAF SECTRACE specification or to default.

■ If the operator responds

R 01,6

the default command goes into effect

TRACE(00,NOSTART)

so that the member, CAITRC00 (if it exists), is referenced but not processed by SAF SECTRACE.


R 01,TRACE(55,START)

the TRCE command is entered directly from the console. The member CAITRC55 is referenced for its ST command, and the trace is started immediately.


R 01,SEC=01

the member CAISEC01 is invoked:

CAISEC01 TRACE(99,START)

This member points you to the member CAITRC99:

ST SET,TYPE=OMVS,ID=OMVS,DEST=SMF,END


Tracing UNIX System Services (OMVS)

Tracing UNIX System Services (OMVS) Setting a SECTRACE for Unix Systems Services will direct the trace to the SMF file. There is no choice (as there is with TYPE=SAF or TYPE=SAFP) of:

■ ID

■ DEST

■ FORMAT

■ ACTION

■ TRACE

■ ENABLE|DISBALE

The troubleshooting administrator will need to make a note of this ID, since this is needed later to disable the SECTRACE. The allowable syntax for setting an OMVS trace is given by:

SECTRACE SET,FUNC=function,END

For a list of valid functions, see OMVS Group Operands. The ID for the TRACE request is provided on the MVS console using the non-rollable message

CAS2110I SECTRACE SET ON mm.ddd hh:mm:ss ID=TRACE001

The SECTRACE remains active until it is disabled. In general, setting or enabling a SECTRACE should be performed only under the direction of CA Top Secret Support, as this can add considerable overhead to USS/OMVS operations.

Stopping the SECTRACE for OMVS

To stop the SECTRACE for OMVS, issue the following command, where xxxx is the identifier assigned to the SECTRACE:

ST DEL,ID=XXXX,END


ca top secret for z/os troubleshooting guide · $databas (adabas database) ..... 107 $dbd (ims...

Documents