Docstoc

IMS V6 Security Guide

Document Sample
IMS V6 Security Guide Powered By Docstoc
					                                                                       IBML
IMS V6 Security Guide
Scott Chen, Alonia Coleman, Mike Gonzales, Chris Taylor, Mehran Mozaffari




                     International Technical Support Organization

                            http://www.redbooks.ibm.com




                                                                            SG24-5363-00
IBML
                                                      SG24-5363-00
       International Technical Support Organization

       IMS V6 Security Guide

       July 1999
     Take Note!

 Before using this information and the product it supports, be sure to read the general information in
 Appendix D, “Special Notices” on page 257.




First Edition (July 1999)

This edition applies to Version 6, Release Number 1 of IMS/ESA, Program Number 5655-158 for use with the
MVS/ESA or OS/390 operating system.

Comments may be addressed to:
IBM Corporation, International Technical Support Organization
Dept. QXXE Building 80-E2
650 Harry Road
San Jose, California 95120-6099

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any
way it believes appropriate without incurring any obligation to you.

© Copyright International Business Machines Corporation 1999. All rights reserved.
Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is
subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents

                         Figures   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   vii

                         Tables    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   ix

                         Preface  . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . .    xi
                         The Team That Wrote This Redbook              . . . . . . . . . . . . . . . . . . . . . . . . .    xi
                         Comments Welcome         . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . .   xii

                         Chapter 1. Introduction to IMS Security . . . . . . . . . . . . . . . . . . . . . . .              1
                         1.1 Objectives of the Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .           1
                         1.2 Brief History of IMS Security . . . . . . . . . . . . . . . . . . . . . . . . . . .            2
                            1.2.1 Security in the Basic Telecommunications Access Method (BTAM) Era                         2
                            1.2.2 Security in the Virtual Telecommunications Access Method (VTAM)
                             Era . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      2
                            1.2.3 External Security Management Products              . . . . . . . . . . . . . . . . .      3
                         1.3 Overview of SMU and RACF            . . . . . . . . . . . . . . . . . . . . . . . . . . .      4
                            1.3.1 SMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .         4
                            1.3.2 Resource Access Control Facility (RACF) . . . . . . . . . . . . . . . . .                 5
                         1.4 Quick Review      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      7
                            1.4.1 Installations Had Unique Security Needs . . . . . . . . . . . . . . . . .                 7
                            1.4.2 Installations Did Not Require Security . . . . . . . . . . . . . . . . . . .              7
                         1.5 Overview of the Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . .             8

                         Chapter 2. Implementing IMS Security         . . . . . . . . . . . . . . . . . . . . .      . .   11
                         2.1 IMS Resources That Can Be Protected and Types of Protection . . . .                     . .   11
                            2.1.1 Protecting IMS Terminals      . . . . . . . . . . . . . . . . . . . . . . . .      . .   11
                            2.1.2 Protecting IMS Commands         . . . . . . . . . . . . . . . . . . . . . . .      . .   13
                            2.1.3 Protecting IMS Transactions       . . . . . . . . . . . . . . . . . . . . . .      . .   16
                            2.1.4 Protecting IMS Databases . . . . . . . . . . . . . . . . . . . . . . . .           . .   17
                            2.1.5 Protecting IMS Dependent Region(s) and the IMS Online System                       . .   19
                            2.1.6 Protecting IMS Program Specification Blocks           . . . . . . . . . . . .      . .   20
                            2.1.7 Protecting IMS Control Program and Region Application Programs                       .   21
                            2.1.8 Protecting IMS System Data Sets         . . . . . . . . . . . . . . . . . . .      . .   21
                            2.1.9 Securing IMS Resources Accessed from Other Systems . . . . . .                     . .   22
                         2.2 Specifying IMS Security Choices at SYSDEF . . . . . . . . . . . . . . . .               . .   23
                            2.2.1 SYSDEF Macros Keyword and Parameter Settings and Meanings                          . .   25
                            2.2.2 SECURITY Macro      . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      . .   25
                         2.3 Overriding Security Specifications Made during SYSDEF . . . . . . . .                   . .   43
                            2.3.1 Supplying IMS Startup Parameters That Change Security . . . . .                    . .   43
                            2.3.2 Overriding Security Choices on /NRE and/or /ERE Commands . .                       . .   46
                         2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       . .   50

                         Chapter 3. Securing IMS Terminals       . . . . . . . . . . . . . . . .       . . . . . . . . .   55
                         3.1 Autosignoff and Autologoff for IMS Terminals . . . . . . . .              . . . . . . . . .   55
                         3.2 Additional Security for Static and/or ETO Terminals . . . .               . . . . . . . . .   56
                         3.3 Securing IMS Terminals . . . . . . . . . . . . . . . . . . . . .          . . . . . . . . .   57
                            3.3.1 Terminal-User Security for Static and ETO Terminals                  . . . . . . . . .   57
                            3.3.2 Sign-On Verification Security for Static Terminals . . .             . . . . . . . . .   60
                            3.3.3 Sign-On Verification Security for ETO Terminals . . . .              . . . . . . . . .   64
                            3.3.4 Output Message Security for Static and ETO Terminals                   . . . . . . . .   68
                            3.3.5 Bypass Security Checking Routine . . . . . . . . . . . .             . . . . . . . . .   68


© Copyright IBM Corp. 1999                                                                                                 iii
                         3.4 Password Security for /IAM, /LOCK, and /UNLOCK                    . . . . . . . . . . . . .     70
                         3.5 LTERM-Based Security      . . . . . . . . . . . . . . . .       . . . . . . . . . . . . . .     70
                         3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . .       . . . . . . . . . . . . . .     70

                         Chapter 4. Securing IMS Commands               . . . . . . . . . . . . . . . . . . . .   . . . .    77
                         4.1 Command Protection Facilities . . . . . . . . . . . . . . . . . . . . . .            . . . .    77
                            4.1.1 Using Default Terminal Security to Secure IMS Commands . .                      . . . .    77
                            4.1.2 Using SMU to Secure IMS Commands                  . . . . . . . . . . . . . .   . . . .    79
                            4.1.3 Using the KEYWD Macro to Limit the Scope of IMS Commands                          . . .    81
                            4.1.4 Using RACF to Secure IMS Commands . . . . . . . . . . . . . .                   . . . .    82
                            4.1.5 Using DFSCCMD0 to Secure IMS Commands                     . . . . . . . . . .   . . . .    84
                         4.2 Terminal Entered Commands              . . . . . . . . . . . . . . . . . . . . . .   . . . .    85
                            4.2.1 Commands Entered from Static Terminals . . . . . . . . . . . .                  . . . .    85
                            4.2.2 Commands Entered from ETO Terminals . . . . . . . . . . . . .                   . . . .    86
                         4.3 Securing Commands Issued by Automated Operator Programs . .                          . . . .    87
                            4.3.1 AO Programs That Issue the DL/I CMD Call . . . . . . . . . . .                  . . . .    88
                            4.3.2 AO Programs That Issue the DL/I ICMD Call . . . . . . . . . . .                 . . . .    89
                         4.4 Commands Entered from MCS or E-MCS Consoles                      . . . . . . . . .   . . . .    90
                         4.5 APPC (LU 6.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .        . . . .    92
                         4.6 OTMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       . . . .    93
                         4.7 CICS     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   . . . .    94
                            4.7.1 CICS-DBCTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .          . . . .    94
                            4.7.2 CICS—ISC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .        . . . .    95

                         Chapter 5. Securing IMS Transactions           . . . . . . . . . . . . . . . . . .    . . . . .    97
                         5.1 Securing IMS Transactions . . . . . . . . . . . . . . . . . . . . . . .           . . . . .    97
                            5.1.1 SMU Transaction Authorization . . . . . . . . . . . . . . . . . .            . . . .    . 98
                            5.1.2 RACF Transaction Authorization          . . . . . . . . . . . . . . . . .    . . . .    . 98
                         5.2 IMS Initialization   . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    . . . .    . 99
                            5.2.1 Set Security Options in Effect . . . . . . . . . . . . . . . . . . .         . . . .    . 99
                            5.2.2 Transaction Authorization in Effect . . . . . . . . . . . . . . . .          . . . .     101
                         5.3 Processing SIGNON and SIGNOFF Requests                 . . . . . . . . . . . .    . . . .     105
                         5.4 RACF Security Checking for IMS Transactions              . . . . . . . . . . .    . . . .     105
                         5.5 DL/I CMD and ICMD Call Transaction Authorization . . . . . . . .                  . . . .     112
                            5.5.1 Using DFSCCMD0 with AO Applications . . . . . . . . . . . . .                . . . .     113
                            5.5.2 Type 1 AO Transaction Authorization           . . . . . . . . . . . . . .    . . . .     113
                            5.5.3 Type 2 AO Transaction Authorization           . . . . . . . . . . . . . .    . . . .     117
                            5.5.4 Security Errors Related to ICMD/CMD Calls             . . . . . . . . . .    . . . .     119
                         5.6 DL/I CHNG Call Transaction Authorization . . . . . . . . . . . . . .              . . . .     120
                            5.6.1 CHNG Call Issued from OTMA Transaction . . . . . . . . . . .                 . . . .     122
                         5.7 Deferred Conversational Program-to-Program Message Switches                          . . .    123
                         5.8 DL/I APSB Call Transaction Authorization . . . . . . . . . . . . . .              . . . .     124
                            5.8.1 APSB Security Errors . . . . . . . . . . . . . . . . . . . . . . . .         . . . .     124
                         5.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       . . . .     124

                         Chapter 6. IMS Databases and IMS Data Sets .                . . . . . . . . . . . . . . . . .      127
                         6.1 SMU . . . . . . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . .      127
                         6.2 PSBGEN      . . . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . .      128
                            6.2.1 Segment Sensitivity . . . . . . . . . . . .        . . . . . . . . . . . . . . . . .      128
                            6.2.2 Field Level Sensitivity      . . . . . . . . . .   . . . . . . . . . . . . . . . . .      129
                            6.2.3 Key Sensitivity . . . . . . . . . . . . . . .      . . . . . . . . . . . . . . . . .      129
                            6.2.4 PSB Generation Example           . . . . . . . .   . . . . . . . . . . . . . . . . .      130
                         6.3 RACF . . . . . . . . . . . . . . . . . . . . . . .      . . . . . . . . . . . . . . . . .      130
                            6.3.1 Database Records, Segments and Fields                . . . . . . . . . . . . . . . .      131
                            6.3.2 DL/I AUTH Call Protection . . . . . . . .          . . . . . . . . . . . . . . . . .      133


iv   IMS V6 Security Guide
   6.3.3 Securing IMS Data Sets           . . . . . . . . . . . . . . . . . . . . . . . . . .     135
   6.3.4 Summary . . . . . . . .        . . . . . . . . . . . . . . . . . . . . . . . . . . .     137

Chapter 7. Securing Access to the IMS System                . . . . . . . . . . . . . . . . .     139
7.1 Protecting System Data Sets . . . . . . . .           . . . . . . . . . . . . . . . . . .     139
7.2 Protecting the IMS Control Region       . . . .       . . . . . . . . . . . . . . . . . .     140
7.3 Restricting Access to Dependent Regions               . . . . . . . . . . . . . . . . . .     140
7.4 Summary . . . . . . . . . . . . . . . . . . . .       . . . . . . . . . . . . . . . . . .     145

Chapter 8. IMS Resources Accessed from Other Environments                        . . . . . . .    147
8.1 Advanced Program-to-Program Communications (APPC) .                        . . . . . . . .    147
   8.1.1 APPC Restrictions . . . . . . . . . . . . . . . . . . . . . .         . . . . . . . .    151
8.2 Multiple Systems Coupling (MSC) Networks . . . . . . . . .                 . . . . . . . .    151
   8.2.1 Transaction Authorization for the DL/I CHNG Call . . .                . . . . . . . .    152
8.3 Open Transaction Manager Access (OTMA) Clients . . . .                     . . . . . . . .    154
   8.3.2 ITOC Security       . . . . . . . . . . . . . . . . . . . . . . . .   . . . . . . . .    156
   8.3.3 OTMA Security Restrictions . . . . . . . . . . . . . . . .            . . . . . . . .    158
8.4 Message Queuing Series (MQSeries) . . . . . . . . . . . . .                . . . . . . . .    158
8.5 CICS     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   . . . . . . . .    161
   8.5.1 Implementing AGN Security . . . . . . . . . . . . . . . .             . . . . . . . .    162
   8.5.2 Implementing Automated Operator Program Security                      . . . . . . . .    166
8.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .        . . . . . . . .    170

Chapter 9. IMS Security in a Shared Queues Environment              . . . .        . . . . . .    171
9.1 Front-End Security . . . . . . . . . . . . . . . . . . . . . . . . . .         . . . . . .    172
   9.1.1 Front-End Command Authorization . . . . . . . . . . . . . .               . . . . . .    172
   9.1.2 Front-End Transaction Authorization . . . . . . . . . . . . .             . . . . . .    174
   9.1.3 Back-End Security . . . . . . . . . . . . . . . . . . . . . . . .         . . . . . .    176
9.2 Authorizing Connections to Common Queue Structures (CQS)                       . . . . . .    178
9.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .        . . . . . .    179

Chapter 10. IMS Security Exits . . . . . . . . . . . .           . . . . . . . . . . . . . . .    181
10.1 Command Authorization Exit (DFSCCMD0) . .                   . . . . . . . . . . . . . . .    182
10.2 Transaction Authorization Exit (DFSCTRN0)               .   . . . . . . . . . . . . . . .    183
   10.2.1 Overview       . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . .    183
   10.2.2 Shared Queues Environment              . . . . . . .   . . . . . . . . . . . . . . .    183
   10.2.3 Online Application Program Authorization                 . . . . . . . . . . . . . .    184
10.3 Security Reverification Exit Routine(DFSCTSE0)                . . . . . . . . . . . . . .    184
10.4 Sign-On User Exit (DFSSGNX0) . . . . . . . . .              . . . . . . . . . . . . . . .    185
10.5 Resource Access Exit Routine (DFSISIS0)               . .   . . . . . . . . . . . . . . .    186
10.6 Sign-On/Off Security Exit (DFSCSGN0)              . . . .   . . . . . . . . . . . . . . .    186
10.7 Build Security Environment Exit (DFSBSEX0) .                . . . . . . . . . . . . . . .    187
10.8 Initialization Exit (DFSINTX0)        . . . . . . . . . .   . . . . . . . . . . . . . . .    187
   10.8.1 Password Verification . . . . . . . . . . . .          . . . . . . . . . . . . . . .    188
   10.8.2 Steps for Enabling Password Verification               . . . . . . . . . . . . . . .    188

Chapter 11. IMS Version 6 Security Enhancements . . . . . . . . . . . . .                  . .    191
11.1 APSB SAF Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . .           . .    191
   11.1.1 Enabling and Disabling APSB SAF Security . . . . . . . . . . . .                 . .    192
   11.1.2 Security Considerations for CPI-C-Driven Application Programs                      .    193
11.2 Support for the RACF Data Space Option . . . . . . . . . . . . . . . .                . .    194
   11.2.1 RACF Data Space and IMS Online Change . . . . . . . . . . . .                    . .    195
   11.2.2 Considerations for Using the RACF Data Space         . . . . . . . . .           . .    195
11.3 BMPUSID Keyword Added to DFSDCxxx           . . . . . . . . . . . . . . . .           . .    196
   11.3.1 IMS V6 BMPUSID Specification     . . . . . . . . . . . . . . . . . . .           . .    197


                                                                                       Contents    v
                            11.3.2 Considerations for BMPUSID         . . . . . . . . . . . . . . . . . . .      . . .   198
                         11.4 Sysplex Security Enhancements         . . . . . . . . . . . . . . . . . . . .      . . .   199
                            11.4.1 Securing MCS/E-MCS Entered IMS Commands                  . . . . . . . .      . . .   199
                            11.4.2 Authorizing Connections to Common Queue Structures (CQS)                        . .   200
                         11.5 Multiple RACF Task Control Blocks (TCBs) . . . . . . . . . . . . . .               . . .   201
                         11.6 Enhanced REVERIFY Support . . . . . . . . . . . . . . . . . . . . . .              . . .   201
                         11.7 Enhanced AUTOSIGNOFF/AUTOLOGOFF for ETO Devices . . . . .                          . . .   202
                            11.7.1 ASOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      . . .   202
                            11.7.2 ALOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      . . .   203
                         11.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .        . . .   203

                         Appendix A. IMS Security Exits Examples    . . .            . . . . . . . . . . . . . . . . .   205
                         A.1 Build Security Environment Exit (DFSBSEX0)                . . . . . . . . . . . . . . . .   205
                         A.2 Command Authorization Exit (DFSCCMD0)                   . . . . . . . . . . . . . . . . .   211
                         A.3 Security Reverification Exit (DFSCTSE0) . .             . . . . . . . . . . . . . . . . .   237

                         Appendix B. Security Maintenance Utility (DFSISMP0)                 . . . . . . . . . . . . .   241
                         B.1 Input and Output Flow . . . . . . . . . . . . . . . .         . . . . . . . . . . . . . .   242
                         B.2 Restrictions . . . . . . . . . . . . . . . . . . . . . .      . . . . . . . . . . . . . .   242
                         B.3 Security Options      . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . .   242
                            B.3.1 LTERM Security . . . . . . . . . . . . . . . . .         . . . . . . . . . . . . . .   242
                            B.3.2 Password Security        . . . . . . . . . . . . . . .   . . . . . . . . . . . . . .   242
                            B.3.3 Transaction Command Security             . . . . . . .   . . . . . . . . . . . . . .   243
                            B.3.4 IMS Resource Access Security . . . . . . . .             . . . . . . . . . . . . . .   243
                            B.3.5 Sign-on Verification Security        . . . . . . . . .   . . . . . . . . . . . . . .   244
                         B.4 Resource Access Control Facility (RACF)             . . . .   . . . . . . . . . . . . . .   244
                         B.5 Command Authorization Exit Routine . . . . . . .              . . . . . . . . . . . . . .   244
                         B.6 IMS Application Resource Access Security . . .                . . . . . . . . . . . . . .   245
                         B.7 SECURITY Procedure          . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . .   245
                         B.8 Utility Control Statements        . . . . . . . . . . . . .   . . . . . . . . . . . . . .   246
                         B.9 Statement Syntax        . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . .   248
                         B.10 Output     . . . . . . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . .   253
                         B.11 Security Status Reports . . . . . . . . . . . . . .          . . . . . . . . . . . . . .   254

                         Appendix C. IMS/ESA DBRC Security Tool (5697-D87)                   . . . . . . . . . . . . .   255

                         Appendix D. Special Notices           . . . . . . . . . . . . . . . . . . . . . . . . . . . .   257

                         Appendix E. Related Publications     . . . . . . . . . . . . . . . .        . . . . . . . . .   259
                         E.1 International Technical Support Organization Publications                 . . . . . . . .   259
                         E.2 Redbooks on CD-ROMs . . . . . . . . . . . . . . . . . . . .             . . . . . . . . .   259
                         E.3 Other Publications . . . . . . . . . . . . . . . . . . . . . . .        . . . . . . . . .   259

                         How to Get ITSO Redbooks   .          . . . . . . . . . . . . . . . . . . . . . . . . . . . .   261
                         IBM Redbook Fax Order Form            . . . . . . . . . . . . . . . . . . . . . . . . . . . .   262

                         Glossary    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   263

                         List of Abbreviations       . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   267

                         Index   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   269

                         ITSO Redbook Evaluation         . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   271




vi   IMS V6 Security Guide
Figures

                             1.   RACF Commands to Create Security Profiles and Authorize Users .                        . .     58
                             2.   /MODIFY and SETROPTS Commands That Refresh In-Storage Profiles                             .   58
                             3.   Activating a RACF Class, Defining Security Profiles, and Authorizing
                                  Users    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   . .   59
                          4.      SMU Input Statements for Sign-On Verification (Examples) . . . . . .                   . .   61
                          5.      SMU Input Statements (Examples)              . . . . . . . . . . . . . . . . . . . .   .   . 62
                          6.      Sign-on Verification for ETO Terminals . . . . . . . . . . . . . . . . . .             .   . 65
                          7.      DFS3649A Sign-on Message/Screen . . . . . . . . . . . . . . . . . . . .                .   . 67
                          8.      Sample Code to Bypass Security Checking in DFSSGNX0 . . . . . . .                      .   . 69
                          9.      SMU Command Protection Examples . . . . . . . . . . . . . . . . . . .                  .   . 81
                         10.      RACF Command Protection Example Using DIMS                     . . . . . . . . . . .   .   . 83
                         11.      RACF Command Protection Example Using CIMS                     . . . . . . . . . . .   .   . 83
                         12.      IMS Command Authorization Processing Flow                  . . . . . . . . . . . . .   .   . 87
                         13.      IMS Initialization     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   .    102
                         14.      Establishing IMS Transaction Authorization Security . . . . . . . . . .                .    103
                         15.      Transaction Authorization for Signed-On User (Part 1 of 4) . . . . . .                 .    108
                         16.      Transaction Authorization for Signed-On User (Part 2 of 4) . . . . . .                 .    109
                         17.      Transaction Authorization for Signed-On User (Part 3 of 4) . . . . . .                 .    110
                         18.      Transaction Authorization for Signed-On User (Part 4 of 4) . . . . . .                 .    111
                         19.      Sample Database Structure . . . . . . . . . . . . . . . . . . . . . . . . .            .    130
                         20.      Sample Access Error to VSAM Database . . . . . . . . . . . . . . . . .                 .    136
                         21.      IMS Data Sets Protection         . . . . . . . . . . . . . . . . . . . . . . . . . .   .    139
                         22.      AGN Security Definitions         . . . . . . . . . . . . . . . . . . . . . . . . . .   .    142
                         23.      AGN Security Definitions         . . . . . . . . . . . . . . . . . . . . . . . . . .   .    143
                         24.      AGN Security Definitions         . . . . . . . . . . . . . . . . . . . . . . . . . .   .    144
                         25.      TP_Profile (Standard/Modified-Standard Transaction Program)                    . . .   .    149
                         26.      TP_Profile (CPI-C Program) . . . . . . . . . . . . . . . . . . . . . . . . .           .    149
                         27.      TP_Profile (CPI-C Program) . . . . . . . . . . . . . . . . . . . . . . . . .           .    150
                         28.      Create RACF TIMS Security Profiles for APPC Transactions                   . . . . .   .    150
                         29.      Transaction Routing Example I . . . . . . . . . . . . . . . . . . . . . . .            .    152
                         30.      Transaction Routing Example II           . . . . . . . . . . . . . . . . . . . . . .   .    153
                         31.      Transaction Routing Example III          . . . . . . . . . . . . . . . . . . . . . .   .    153
                         32.      Sample JCL to Generate DRA             . . . . . . . . . . . . . . . . . . . . . . .   .    167
                         33.      RACF Command Protection Example Using CIMS and DIMS . . . . .                          .    169
                         34.      IMS Front-End and Back-End Systems               . . . . . . . . . . . . . . . . . .   .    171
                         35.      Authorization Processing in SMQ Environment                . . . . . . . . . . . . .   .    173
                         36.      RACF Definitions for APSB SAF Security . . . . . . . . . . . . . . . . .               .    193
                         37.      IMS Security Check Processing Flow             . . . . . . . . . . . . . . . . . . .   .    196
                         38.      IMS E-MCS/MCS Support in a Sysplex Environment . . . . . . . . . .                     .    199
                         39.      Protected Commands           . . . . . . . . . . . . . . . . . . . . . . . . . . . .   .    241
                         40.      Security Maintenance Utility Data Set Requirements . . . . . . . . . .                 .    243




© Copyright IBM Corp. 1999                                                                                                       vii
viii   IMS V6 Security Guide
Tables

                          1.   Summary of IMS Resources and Security Protection . . . . . . . . . .               . .   22
                          2.   IMSGEN and COMM Equal Parameter Settings Table                 . . . . . . . . .   . .   25
                          3.   Summary of SECURITY Macro Security-Related Parameters . . . . .                    .   . 27
                          4.   DL/I ICMD Security Violation DFS286I Message USERID User ID Value                      . 32
                          5.   RACF Class Names of R C L A S S = A B C for IMS System           . . . . . . . .   .   . 34
                          6.   RACF Class Names of R C L A S S = X Y Z for IMS System . . . . . . . . .           .   . 34
                          7.   SECLVL Keyword of SECURITY Macro Summary . . . . . . . . . . . .                   .   . 39
                          8.   TRANCMD Keyword of SECURITY Macro Summary                    . . . . . . . . . .   .   . 40
                          9.   TYPE Keyword of SECURITY Macro Summary . . . . . . . . . . . . . .                 .   . 42
                         10.   /NRE and /ERE Security Keywords and Meanings               . . . . . . . . . . .   .   . 46
                         11.   Security Options on the /NRESTART or /ERE COLDSYS Command                      .   .   . 48
                         12.   /SECURE Keywords and Their Meanings . . . . . . . . . . . . . . . . .              .   . 49
                         13.   Reasons for Rejected Sign-On Attempts          . . . . . . . . . . . . . . . . .   .   . 73
                         14.   Terminal Security Defaults for IMS Commands . . . . . . . . . . . . .              .   . 77
                         15.   Command Authorization Using SMU            . . . . . . . . . . . . . . . . . . .   .   . 80
                         16.   Command Authorization Exit Routine Attributes . . . . . . . . . . . . .            .   . 84
                         17.   AO ICMD Call Command Security . . . . . . . . . . . . . . . . . . . . .            .   . 89
                         18.   MCS and E-MCS Command Security for DB/DC . . . . . . . . . . . . .                 .   . 90
                         19.   MCS and E-MCS Command Security for DBCTL . . . . . . . . . . . . .                 .   . 90
                         20.   Keywords Used to Alter Security on IMS Restart . . . . . . . . . . . .             .    101
                         21.   Return Codes of RACF Security Checking           . . . . . . . . . . . . . . . .   .    106
                         22.   DL/I ICMD USERID VALUE . . . . . . . . . . . . . . . . . . . . . . . . . .         .    118
                         23.   Fields of I/O PCB Used for Authorization Checking . . . . . . . . . . .            .    120
                         24.   RACF Protection of IMS Resources from DL/I AUTH Calls . . . . . . .                .    133
                         25.   RACF Protection of Database Resources . . . . . . . . . . . . . . . . .            .    133
                         26.   AGN Function of Type=xxx Keyword of SECURITY Macro                   . . . . . .   .    141
                         27.   Parameters Used to Secure a Dependent Region . . . . . . . . . . . .               .    141
                         28.   Overriding the SECURITY Macro AGN Specification              . . . . . . . . . .   .    142
                         29.   How the Second User ID is Determined for the IMS Adapter . . . . .                 .    160
                         30.   Checks Made at Different RACF Access Levels for the IMS Adapter                    .    161
                         31.   Security Exit Routines   . . . . . . . . . . . . . . . . . . . . . . . . . . . .   .    181
                         32.   BMPUSID=PSBNAME|USERID . . . . . . . . . . . . . . . . . . . . . . .               .    198
                         33.   IMS Security Exits Source Library . . . . . . . . . . . . . . . . . . . . .        .    205
                         34.   Security Maintenance Utility Input Statements . . . . . . . . . . . . . .          .    247




© Copyright IBM Corp. 1999                                                                                              ix
x   IMS V6 Security Guide
Preface

                         The Information Management System (IMS) is a program product that is a key
                         asset in many customer installations. IMS (also referred to as IMS/VS, and
                         IMS/ESA) may be used as a Transaction Manager, a Database Manager, or both.
                         This book describes all of the IMS resources that may be protected, and the
                         security facilities used to protect them.

                         IMS resources (such as transactions, data, and application programs) are
                         valuable assets that often require protection from accidental or intentional
                         access by unauthorized users. IMS itself has provided security facilities , such
                         as the security maintenance utility (SMU) and security exits, to protect IMS
                         resources for many years. IMS also supports securing IMS resources through
                         the use of security products, such as the resource access control facility (RACF).

                         Today′s open computer systems allow IMS applications and data to be accessed
                         from new sources such as the world wide web. As companies permit their
                         applications and data to be opened up to their customers, securing IMS
                         resources has become even more critical. Therefore, it is important for an
                         installation′s security personnel to have a good understanding of how to restrict
                         access to IMS resources from traditional sources as well as from other sources
                         such as TCP/IP networks, the World Wide Web, and distributed client/server
                         systems using advanced program-to-program communications (APPC).

                         The purpose of this book is to provide an installation′s security personnel with
                         the capability to secure IMS resources.



The Team That Wrote This Redbook
                         This redbook was written by a team of specialists from around the world working
                         at the International Technical Support Organization San Jose Center.

                         Scott Chen is a member of the International Technical Support Organization, San
                         Jose Center. Scott has been installing, configurating, debugging, tuning,
                         consulting, application designing and programming and studying MVS and
                         OS/390 internal, database and transaction management systems and digital
                         library software for over 25 years, although he was trained to be an
                         astrophysicist.

                         Alonia (Lonnie) Coleman is an IMS Consultant in the Dallas Systems Center.
                         Lonnie has 21 years of experience in large systems software. Her areas of
                         expertise include IMS security using RACF and SMU, and customizing IMS
                         sample security exits.

                         Mike Gonzales is an IMS Level 2 Advisory Software Engineer at the Santa Teresa
                         Laboratory with 10 years of experience in analyzing and defining IMS security.
                         His areas of IMS expertise include APPC, OTMA, and the various forms of data
                         communications.

                         Chris Taylor is a Security Analyst in Australia. He has eight years of experience
                         in the RACF field. He has worked at IBM for 13 years. His areas of expertise
                         include mainframe security.




© Copyright IBM Corp. 1999                                                                                  xi
                          Mehran Mozaffari is a senior IT specialist in United States. He has 26 years of
                          experience in IMS and MVS field. He holds a master degree in city planning
                          from Pahlavi University. His areas of expertise include IMS. He has written
                          extensively on IMS performance.

                          Thanks to the following people for their invaluable contributions to this project:

                          Mary Anne Morgan
                          Jack Wiedlin
                          IBM Santa Teresa Laboratory, IMS Development

                          Robert Hain
                          IBM Global Services Australia

                          Bob Gendry
                          Richard Horton
                          Rich Lewis
                          Bill Stillwell
                          Suzie Wendler
                          IMS Advanced Technology Support
                          Dallas Systems Center
                          IBM US



Comments Welcome
                          Your comments are important to us!

                          We want our redbooks to be as helpful as possible. Please send us your
                          comments about this or other redbooks in one of the following ways:
                              •   Fax the evaluation form found in “ITSO Redbook Evaluation” on page 271 to
                                  the fax number shown on the form.
                              •   Use the online evaluation form found at http://www.redbooks.ibm.com/
                              •   Send your comments in an Internet note to redbook@us.ibm.com




xii   IMS V6 Security Guide
Chapter 1. Introduction to IMS Security

                         This chapter covers the following topics:
                             •   Objectives of the book
                             •   Brief history of IMS security
                             •   Overview of SMU and RACF
                             •   Overview of the contents of each chapter in the book

                         IMS provides a wide variety of security options. Different security facilities may
                         be used to protect the same IMS resource type. For example, an IMS command
                         may be secured by IMS itself or by an external security product. Since IMS
                         installations have many security options, an understanding of the security
                         options is needed in order to implement the options that best suit the
                         installation′s requirements.

                         The reader should have a thorough understanding of IMS security options and
                         understand how to implement the installation′s security requirements after
                         reading this book.



1.1 Objectives of the Book
                         The objectives of this book are to provide the reader with an understanding of:
                             •   IMS resources that can be protected and the security facilities used to
                                 protect them
                             •   How to specify the installation′s security choices on the appropriate IMS
                                 system definition (SYSDEF) macros
                             •   The ways SYSDEF security choices may be overridden (or changed):
                                 −   At IMS initialization, or
                                 −   Through the use of commands entered by the Master Terminal Operator
                                     (MTO) or from the MVS master console
                             •   How to secure access to IMS resources when the following IMS features are
                                 used; or when external subsystems are used with IMS subsystems:
                                 −   Open Transaction Manager Access (OTMA)
                                 −   Advanced Program-to-Program Communications (APPC)
                                 −   Multiple Systems Coupling (MSC)
                                 −   Inter-Systems Communications (ISC)
                                 −   IMS TCP/IP OTMA Connector (ITOC),
                                 −   IMS systems participating in a shared queues environment
                                 −   Transmission Control Protocol/Internet Protocol (TCP/IP)
                                 −   Customer Information Control System (CICS)
                                 −   DATABASE2 (DB2)
                             •   New MVS System Access Facility (SAF) and RACF security facilities available
                                 with IMS Version 6




© Copyright IBM Corp. 1999                                                                                   1
                            IMS offers a variety of ways to protect IMS resources. To gain an understanding
                            of IMS resources that can be protected and the facilities that protect them, it is
                            important to understand how security for IMS resources has evolved since the
                            availability of IMS over 30 years ago.



1.2 Brief History of IMS Security
                            When IMS was developed, external security products that used the System
                            Authorization Facility interface, such as resource access control facility (RACF),
                            had not been developed or were not in use by most installations. It was
                            common during this period to have each subsystem implement its own security.
                            IMS implemented security for IMS resources, CICS implemented security for
                            CICS resources, MVS implemented security for MVS resources, and so on.
                            Therefore, the IMS product offered some basic levels of protection for IMS
                            resources. These internal IMS security facilities (for example, security
                            maintenance utility or SMU) are still available for protecting many IMS resource
                            types and are used by some IMS installations today.


1.2.1 Security in the Basic Telecommunications Access Method (BTAM) Era
                            Years ago IMS terminal users accessed IMS through networks controlled by
                            BTAM.

                            The method of providing IMS security was through the use of IMS security
                            modules. The installation used the following process to implement security for
                            IMS resources:
                             1. The installation identified the type of security desired during SYSDEF by
                                specifying security parameters on an IMS macro, the IMSGEN macro.
                             2. An IMS system generation (SYSGEN) was performed.
                             3. Then an IMS SMU generation (SMU GEN) was performed to create security
                                tables (or matrixes) with the resource protection information that had been
                                coded on the IMSGEN macro.
                             4. The security tables/matrixes were used during IMS execution to enforce the
                                installation′s security choices that had been made during SYSDEF.

                            The IMSGEN macro contains keywords and parameters that were used to
                            implement security in an era when BTAM was the prevalent telecommunications
                            manager. The security keywords and parameters on the IMSGEN macro may
                            still be coded today, but are ignored if SYSDEF macros contain either a COMM
                            or SECURITY macro.


1.2.2 Security in the Virtual Telecommunications Access Method (VTAM) Era
                            As installations began to migrate to a more sophisticated telecommunications
                            manager, namely VTAM, they also wanted to access IMS resources from
                            terminal networks controlled by VTAM, and have security provided for IMS
                            resources accessed from those terminals. IMS introduced the COMM macro,
                            which provided support for VTAM. The COMM macro also provided security
                            parameters that were compatible with the IMSGEN macro security options.
                            However, as the IMS publications stated, if both the IMSGEN and COMM macros
                            were present in the system definitions macros, the specifications and/or defaults
                            of the COMM macro security parameters overrode any security specifications on
                            the IMSGEN macro. Thus, IMS maintained compatibility on security
                            specifications between both macros and SMU was used to secure access to the


2   IMS V6 Security Guide
               IMS resources. Another way of stating what has been described above is
               provided in the list below:
                •   The same security options can be specified on both the IMSGEN and COMM
                    macros.
                •   If both macros are present in the SYSDEF macros, the specifications and/or
                    defaults of the COMM macro are used.
                •   IMS internal security facilities (using the SMU GEN security process
                    described previously for BTAM) are used to enforce security.

               Some customer installations had large numbers of terminals that accessed
               different subsystems. For example, some terminals accessed IMS subsystems
               while others accessed CICS subsystems. It became burdensome to administer
               security within multiple subsystems. Customers required a single facility that
               supported securing resources for multiple subsystems.


1.2.3 External Security Management Products
               With the development and introduction of security products more and more
               installations have implemented security for IMS resources using security
               products.

               1.2.3.1 Overview
               Two advantages of using a security product for securing access to resources
               are:
                •   One product may be used to implement the security requirements for
                    multiple subsystems, such as IMS, CICS, and other subsystems.
                •   All of the security information may be kept and maintained in one place,
                    such as the RACF database. One centralized database repository containing
                    all the installations′ security specifications eliminated, or significantly
                    minimized, the previous requirements to have:
                    −   Security information distributed among several subsystems, and
                    −   The security enforcement functions implemented in multiple products

               RACF offered a wide range of security choices to the installation. For example,
               RACF contained new security features, such as user identification (user ID)
               verification based security which is not available through IMS internally provided
               security.

               IMS provided a new SYSDEF macro that allowed the installation to code all of
               the security specifications (available during this era) on one macro, the
               SECURITY macro. This macro was used to specify security options for IMS
               internally provided SMU security, RACF security, and/or an installation-provided
               security exit routine.

               1.2.3.2 The Security Macro
               The SECURITY macro was implemented in IMS mainly for the purpose of
               specifying the installations′ security choices to an external security product such
               as RACF. Again, IMS also provided keywords and parameters on the SECURITY
               macro that allowed security specifications for SMU-provided security and
               installation-provided security exits. That is, the same security options that could
               be specified on the COMM and IMSGEN macros could now be specified on the




                                                              Chapter 1. Introduction to IMS Security   3
                            SECURITY macro. This maintained the compatibility between security
                            specifications on the SECURITY, COMM, and IMSGEN macros.

                            Similar to our previous discussion, if the SECURITY macro is present in the IMS
                            SYSDEF macros, the specifications and/or defaults of the SECURITY macro will
                            take precedence over security specifications on the COMM and IMSGEN macros.

                            Some of the SECURITY macro keywords and parameters apply to:
                             •   RACF
                             •   IMS SMU
                             •   Installation-provided security exit routines, and
                             •   Combinations of the above (such as SMU and an installation-provided
                                 security exit routine, or RACF and an installation-provided security exit
                                 routine).
                            Additional details on the meaning of each keyword/parameter on the SECURITY
                            macro will be provided in Chapter 2, “Implementing IMS Security” on page 11.



1.3 Overview of SMU and RACF
                            Access to IMS resources can be secured by either IMS or by an external security
                            product.


1.3.1 SMU
                            IMS internal security modules may be used to implement access to IMS
                            transactions, commands, and other IMS resources. The facility that is used to
                            define the IMS resources that will be secured is called the security maintenance
                            utility (SMU). SMU does not actually enforce the security choices made by the
                            installation. Although IMS security modules actually implement the security
                            specifications defined using SMU, IMS internally provided security is commonly
                            referred to as ′SMU security′.

                            IMS internal security is a type of security that can:
                             •   Be used to restrict the entry of secured commands and transactions to
                                 specific LTERMs.
                             •   Be used to assign a password to a command and/or transaction and require
                                 that the valid password be supplied with command and/or transaction entry.
                             •   Require a password be supplied on the /LOCK and/or /UNLOCK commands
                                 to lock/unlock a database, program, physical terminal and/or logical
                                 terminal.
                             •   Require that sign-on be performed from some or all terminals.
                             •   Secure a program specification block (PSB) by restricting where (the
                                 dependent region) the PSB can be scheduled, and preventing dependent
                                 regions that are not authorized to schedule the PSB from scheduling it.
                             •   Determine whether IMS commands can be issued from automated operator
                                 (AO) programs and which AO transactions can enter IMS commands.

                            IMS internal security, or SMU security, may be used only for IMS resources that
                            have been statically defined. The installation identifies the resources that are
                            secured (such as transactions and commands) and the type of protection (such



4   IMS V6 Security Guide
                as password protection and/or LTERMs where the command and/or transaction
                may be entered) by providing input statements to SMU. The SMU generation
                process results in the security specifications being written to tables
                (IMS.MATRIXx) that are loaded and used by IMS to enforce the security
                specifications.


1.3.2 Resource Access Control Facility (RACF)
                RACF is an IBM program product that is used to secure resources for IMS and
                other subsystems. RACF protects resources by granting access only to
                authorized users of the protected resources. To accomplish this, RACF gives you
                the ability to:
                 •   Identify and authenticate users
                 •   Authorize users to access the protected resources
                 •   Log and report various attempts of unauthorized access to protected
                     resources
                 •   Control the means of access to resources
                 •   Allow applications to use the RACF macros
                RACF retains information about the users, resources, and access authorities in
                security profiles on the RACF database and refers to the profiles when deciding
                which users should be permitted access to protected system resources.

                Some RACF terms will be used throughout this book. The reader should have a
                basic understanding of the RACF terms and concepts, and detailed knowledge of
                the following:
                 •   RACF database - A collection of interrelated or independent data items
                     stored together without unnecessary redundancy, to serve RACF.
                     The RACF database contains profiles (security profiles) and access lists.
                 •   Profile - Data that describes the significant characteristics of a user, a group
                     of users, or one or more computer resources.
                     These security profiles are for users, transactions, commands, PSBs, data
                     sets, databases, terminals, and other resources.
                     Most RACF profiles are created using the RACF DEFINE (RDEFINE)
                     command.
                 •   Access Lists - A list within a profile of all authorized users and their access
                     authorities. In RACF, the access authorities (or UACC) are NONE, EXECUTE,
                     READ, UPDATE, CONTROL, and ALTER.
                     User IDs and/or groups are added to the access lists associated with the
                     security profiles. User IDs/groups are placed on the access list using the
                     PERMIT command.
                 •   Resource Class - A collection (or classification) of RACF-defined entities
                     (such as security profiles for users, groups, and resources) with similar
                     characteristics.
                     Some RACF classes are used exclusively by IMS, such as the transaction
                     classes TIMS and GIMS. Other RACF classes may be shared by several
                     subsystems.
                     Note that two classes were cited above as transaction classes. The first
                     class, TIMS, is used to create a security profile and an access list for a


                                                                 Chapter 1. Introduction to IMS Security   5
                                 single transaction. The second transaction class, GIMS, is called a grouping
                                 class. A resource grouping class is a RACF class in which resource group
                                 profiles can be defined, and the grouping class is related to another class.
                                 For example, the GIMS resources grouping class is related to the TIMS
                                 resource class. The resource grouping class contains profiles for one or
                                 more resources with unlike names. For example, one security profile for all
                                 PAYROLL transactions (PAY1, PAY2 and PAY3) can be created in the GIMS
                                 class, rather than create three security profiles (one for each transaction) in
                                 the TIMS class.
                             •   Universal Access Authority (UACC) - The default access authority that
                                 applies to a resource if the user or group is not specifically permitted access
                                 to the resource. The universal access authority can be any of the following
                                 access authorities:
                                 −   ALTER - Specifies that the user or group have full control over the
                                     resource.
                                 −   CONTROL - Is used only for VSAM data sets and specifies that the user
                                     or group have access authority that is equivalent to the VSAM control
                                     password.
                                 −   UPDATE - Specifies that the user or group be authorized to access the
                                     resource for the purpose of reading or writing.
                                 −   READ - Specifies that the user or group be authorized to access the
                                     resource for the purpose of reading only.
                                 −   EXECUTE - Specifies that the user or group can run programs but not
                                     read or copy them.
                                 −   NONE - Specifies that the user or group not be permitted to access the
                                     resource.
                             •   Accessor environment element (ACEE) - A description of the current user,
                                 including user ID, current connect group, user attributes, and group
                                 authorities. An ACEE is constructed during user identification and
                                 verification.
                                 A user signs on to IMS by issuing a sign-on command and providing a user
                                 ID and password, as shown in the example below:
                                 /SIGN ON user ID password
                                 A security environment, or ACEE, is created for the user at sign-on. When a
                                 user requests an IMS resource (such as a transaction), RACF compares the
                                 user′s privilege to the resource′s (transaction) security access specifications
                                 and makes a recommendation to grant or deny access to the resource
                                 (transaction).
                                 Note: Throughout this book reference is made to ″creating a security
                                 environment″. In this book, creating a security environment can be thought
                                 of as creating an ACEE.

                            The RACF terms and concepts used in the book should become clear as you
                            read each chapter and see the examples that have been provided.




6   IMS V6 Security Guide
1.4 Quick Review
                 Some of the material that has been covered so far is summarized below:
                   •   IMS has facilities to secure many IMS resources. These facilities are
                       commonly referred to as SMU (or IMS internal) security. Years ago, prior to
                       the availability of security products, the IMSGEN and COMM macros were
                       used to specify the installation′s security choices for transactions,
                       commands, and other resources.
                   •   RACF (or other vendor security products) may also be used to secure access
                       to IMS resources. The SECURITY macro is used to request RACF security
                       for IMS resources.
                   •   IMS has maintained compatibility between the SECURITY, COMM, and
                       IMSGEN macro security parameter/keywords. Thus, the installations security
                       options are specified on the SECURITY macro. This means the SECURITY
                       macro is used to specify:
                       −   Whether RACF is used to protect IMS resources
                       −   Whether SMU is used to protect IMS resources
                       −   Whether an installation-provided security exit routine is used to protect
                           IMS resources, or
                       −   Whether a combination of the above security facilities are used to secure
                           IMS resources

                 Note that the term installation-provided security exit routine has been used a few
                 times. An exit allows an installation to meet security requirements that could
                 not be met by IMS internal security facilities, SMU or by security products such
                 as RACF.


1.4.1 Installations Had Unique Security Needs
                 Even with such robust security products as RACF, some installations require a
                 deeper level of security for some IMS resources. An example of this type of
                 protection is to allow a user to have access to his or her own personnel and
                 payroll information, but denying that user access to the personnel and payroll
                 information of employees other than himself/herself. Therefore, the user is
                 allowed access to the personnel/payroll transactions and data, but the data the
                 employee is allowed to see should pertain only to himself/herself. To meet
                 these types of installation requirements, IMS provided several security exits.
                 Installations could customize exit routines to meet their specific security needs.

                 IMS has also provided support for customer application-based security
                 programs. A Data Language/I (DL/I) call, the AUTH (short for authorization) call,
                 may be used for securing access to IMS databases at a more granular level.
                 The AUTH call is covered in Chapter 6, “IMS Databases and IMS Data Sets” on
                 page 127.


1.4.2 Installations Did Not Require Security
                 Some customer installations did not wish to take advantage of any of the
                 security features of IMS or RACF for securing IMS resources. For these
                 installations IMS provides a basic level of security called default terminal
                 security. 4.1.1, “Using Default Terminal Security to Secure IMS Commands” on
                 page 77 /escribes the level of security automatically provided internally by IMS
                 when the installation either:


                                                                  Chapter 1. Introduction to IMS Security   7
                             •   Specifically codes all the security parameters to indicate that no security
                                 checking is requested, or
                             •   Allows the SECURITY macro to use all of the defaults which results in no
                                 security requested
                            Therefore, if the installation did not elect to (or did not know how to) specify IMS
                            security options, IMS provides this minimum level of default terminal security.

                            The authors of this book hope that by reviewing the history of IMS security, the
                            reader has gained some insight into the tremendous number of security options
                            available in IMS (via IMS-SMU, RACF or other security products, IMS security
                            exits, and DL/I AUTH call support for application-based security programs).

                            This book contains chapters that describe each IMS resource type that can be
                            protected and the security facilities used to protect that resource type.



1.5 Overview of the Contents
                            The contents of the remaining chapters in the book are described below:
                             •   Installations installing IMS for the first time need to know how to specify their
                                 security options for IMS resources. As security requirements change in an
                                 installation, security options that had been selected during SYSDEF may also
                                 need to be changed.
                                 Chapter 2, “Implementing IMS Security” on page 11 covers:
                                 −   The IMS macro keyword and parameter specifications used to implement
                                     security for IMS resources.
                                 −   How to change (or override) security options that have been set during
                                     the SYSGEN process.
                             •   The next five chapters cover implementing security for traditional IMS
                                 resources. Examples of these traditional resources are terminals,
                                 commands, transactions, databases and the IMS system control program.
                                 −   Chapter 3, “Securing IMS Terminals” on page 55 covers:
                                      - How to secure physical terminals, both static and Extended Terminal
                                        Option (ETO) devices; and
                                      - Securing logical terminals (LTERMs).
                                 −   Chapter 4, “Securing IMS Commands” on page 77 covers:
                                      - How to provide or deny users the capability to execute certain IMS
                                        commands.
                                 −   Chapter 5, “Securing IMS Transactions” on page 97 covers:
                                      - How IMS initialization and sign-on processes affect transaction
                                        authorization.
                                      - How to secure IMS transactions using SMU and RACF.
                                      - Application program functions that cause IMS to invoke security
                                        checking, such as CMD, ICMD, and CHNG calls.
                                 −   Chapter 6, “IMS Databases and IMS Data Sets” on page 127 covers:
                                      - How to protect data from accidental or intentional access; which can
                                        also result in preserving the integrity of the data.



8   IMS V6 Security Guide
         .
     −   Chapter 7, “Securing Access to the IMS System” on page 139 covers
         securing IMS system resources (such as the IMS control program,
         program specifications blocks (PSBs), dependent regions, and IMS
         system data sets).
 •   The next two chapters of this book describe how to implement security for
     IMS environments where specific IMS features are used or where IMS is
     used with external subsystems.
     −   Chapter 8, “IMS Resources Accessed from Other Environments” on
         page 147 covers:
             - Security considerations for implementing resource security when IMS
               resources are accessed from the following environments, namely
               APPC, MSC, OTMA and ITOC and from CICS DBCTL environments.
     −   Chapter 9, “IMS Security in a Shared Queues Environment” on page 171
         covers:
             - How security works in the shared queues environment and provides
               considerations for implementing security in a shared queues
               environment.
 •   As previously mentioned, in some cases, the security provided by IMS
     and/or security products such as RACF may not meet the installation′ s
     requirements. Therefore, IMS provides sample security exit routines that the
     installations can customize/code to meet their specific security needs.
     Chapter 10, “IMS Security Exits” on page 181 provides a description of the
     sample IMS security exits and their functions.
 •   The final chapter, Chapter 11, “IMS Version 6 Security Enhancements” on
     page 191, describes new security facilities and features available with
     IMS/ESA Version 6. The new features that are covered in this chapter are:
     −   Enhanced allocate program specification block (APSB) security.
     −   Use of the RACF dataspace with IMS.
     −   Sysplex security enhancements for:
             - Multiple Console Support/Extended Multiple Console Support
               (MCS/EMCS), and
             - Shared queues structures RACF FACILITY class support
     −   RACF Password REVERIFY Support.
     −   Multiple IMS task control blocks (TCBs) to service RACF calls.
     −   The DFSDCxxx (IMS procedure library member) BMPUSID parameter
         specification for batch message processing (BMP) program user ID
         assignment.

We also extract related exit programs and other information from various
sources as appendixes for reference. Now it is time to take a look at the specific
IMS resources that may be secured and which security facility(s) can be used to
secure each resource type.




                                                Chapter 1. Introduction to IMS Security   9
10   IMS V6 Security Guide
Chapter 2. Implementing IMS Security

                         This chapter covers the following topics:
                             •   Resource types that can be protected.
                             •   Security option (or type of protection) that is used for implementing security
                                 for each resource type.
                             •   Specifying IMS security choices at SYSDEF.
                                 In other words, this topic covers the SYSDEF macro keywords and
                                 parameters setting (used to specify IMS resource security) and their
                                 meanings.
                             •   How to override security specifications made on IMS macros during SYSDEF.

                         Three important concepts in understanding IMS security are:
                             •   Knowing the IMS resource types that can be protected and the type of
                                 protection provided for each resource type.
                             •   Understanding which security facilities or mechanisms may be used to
                                 protect a specific resource type; and
                             •   Understanding the type of security provided by each keyword or parameter
                                 used to define installation security requirements.

                         Some of the materials in this chapter will be repeated in other chapters. It is
                         covered in this chapter in order to provide greater clarity. Now, let us take a
                         look at the IMS resources types that can be protected and the type of protection
                         available for each resource.



2.1 IMS Resources That Can Be Protected and Types of Protection
                         IMS provides ample flexibility in allowing the installation to secure almost any
                         type of resource. Before deciding which resources to secure, make sure you
                         understand the type of protection that is provided with the specific resource type.
                         Table 1 on page 22 categorizes IMS resources that can be secured by resource
                         type and shows the type of protection available for each resource type. Please
                         refer to the table as you read this section, and keep in mind that a separate
                         chapter on most of these resource types is included in the book.


2.1.1 Protecting IMS Terminals
                         Securing a physical terminal can be thought of as protecting the terminal from
                         unauthorized use. Two types of terminals may be secured in the IMS
                         environment: 1) physical terminals, and 2) logical terminals or LTERMS. The
                         physical terminals may be static terminals (those which have been defined to
                         IMS using the TYPE and TERMINAL macros); or Extended Terminal Option (ETO)
                         terminals that are dynamically defined to IMS at logon.




© Copyright IBM Corp. 1999                                                                                    11
                         2.1.1.1 Protecting Static Terminals
                         Three security options (or types of protection) are available for securing static
                         terminals:
                             •   Sign-on verification. Static terminals are not required to perform sign-on.
                                 Sign-on means that the IMS SIGN ON command (/SIGN ON userid ) be
                                 entered from the terminal. If sign-on is used as a security mechanism for
                                 static terminals, either RACF or SMU may be used to require all users to
                                 perform sign-on. A user exit routine must also be used in the SMU
                                 environment when user ID verification is desired. RACF can be used to
                                 enforce sign-on and to provide user ID verification when sign-on is done; and
                                 RACF does not require a user exit in order to perform user ID verification.
                             •   Terminal user security. If this method is chosen to secure static terminals,
                                 RACF is called to enforce terminal security using the TERMINAL class.
                             •   Use of the IMS commands. For example, use of the /LOCK command to
                                 secure physical terminals; and /UNLOCK to allow the terminal to send and
                                 receive messages.

                         If the latter approach is used to secure the terminal, passwords should be
                         assigned to the /LOCK, /UNLOCK, and /IAM commands to restrict the use of
                         these commands to authorized users; and to restrict the use of the /LOCKed
                         terminals to users providing the correct password(s) on these commands.

                         2.1.1.2 Protecting ETO Terminals
                         Two security options (types of protection) are available for ETO terminals. Since
                         SMU does not support ETO devices, the security for these terminals must be
                         provided by RACF (and optionally a SIGNON security exit routine).
                             •   Sign-on verification. The default for ETO terminals is to perform sign-on.
                                 When end users sign on using their RACF user IDs, output for the user is
                                 queued by user ID. When sign-on is performed using a non-RACF user ID,
                                 such as node name, output security is not performed for ETO devices. In this
                                 case, the output is queued to the LTERM associated with the ETO terminal
                                 just as it is with static terminals. For ETO devices, RACF must be used to
                                 make sure that the SIGN ON command (/SIGN ON userid ) is entered from the
                                 terminal (or that a sign-on screen is used to perform the sign-on function) in
                                 order to perform user ID verification.
                                 Note: SMU does not support terminal security (restricting entry of
                                 commands/transactions to specific LTERMs) nor password security
                                 (assigning passwords to commands/transactions) for commands and
                                 transactions entered from ETO terminals.
                                 There may be instances where the installation wants to bypass sign-on, such
                                 as for printers or for a terminal in an open area where sign-on is not
                                 desired. In these cases DFSSGNX0 can be coded to bypass sign on.
                             •   Terminal user security. Terminal user security also works with ETO
                                 terminals. If this method is chosen to secure ETO terminals, RACF is used to
                                 enforce terminal security using the TERMINAL class.




12   IMS V6 Security Guide
               2.1.1.3 Protecting Commands and Transactions Using LTERMS
               The final type of terminal security is LTERM-based security. The LTERM is a
               logical input or destination point in the IMS system that is associated with a
               static terminal or ETO user.

               LTERM-based security must be provided by SMU. This security option allows the
               installation to define a set of commands and/or transactions that are authorized
               for use by specific LTERMs. For example, the /NRE (IMS command to perform a
               normal restart of the system) can be restricted to being issued from the LTERM
               assigned to the IMS master terminal. Unauthorized LTERMs cannot enter
               transactions and/or commands that have been secured.

               2.1.1.4 Locking an LTERM
               An LTERM may be locked using the /LOCK command. Issuing the /LOCK LTERM
               command specifies the logical terminal for which the sending and receiving of
               messages is to be stopped. /LOCK LTERM applies only to logical terminals
               associated with the entering physical terminal.


2.1.2 Protecting IMS Commands
               IMS commands request the system to perform specific functions, such as
               displaying information about IMS resources or altering the status of system
               resources. IMS commands may be entered from several sources:
                •   A user terminal, including APPC and OTMA users
                •   The IMS master terminal/system console
                •   Multiple Console Support/Extended Multiple Console Support (MCS/EMCS)
                    MVS consoles
                •   Automated operator programs that issue the DL/I CMD call or the DL/I ICMD
                    call
                •   Time-Controlled Operations (TCO)

               The types of protection offered for commands are:
                •   Default terminal security
                •   LTERM-based command security for static terminals
                •   Password protection for commands issued from static terminals
                •   SMU DL/I CMD call security
                •   RACF DL/I ICMD call security
                •   RACF user ID-based command security
                •   Extended command security using DFSCCMD0
                •   SMU or RACF security for TCO issued commands

               2.1.2.1 Default Terminal Security
               This type of security is automatically implemented by IMS for a large subset of
               IMS commands when the SECURITY macro has been coded (or defaulted) to
               settings that result in an IMS environment where no resource has been
               protected. This will be covered in more detail in Chapter 4, “Securing IMS
               Commands” on page 77.




                                                             Chapter 2. Implementing IMS Security   13
                         2.1.2.2 LTERM-Based Command Security
                         Entry of some or all IMS commands may be restricted to specific LTERMs. This
                         type of command security may be used for terminals that have been statically
                         defined to IMS. SMU is used to define the commands that are protected and the
                         LTERMs from which the commands may be entered. IMS enforces the security.
                         When this type of command protection is used, the installation decides from
                         which LTERMs specific IMS commands may be entered. Using this type of
                         security, the TERMINAL utility control statement is provided as input to the SMU
                         security generation process. The statements provided tell IMS the commands
                         that are restricted to entry from specific LTERM(s). The following example
                         specifies that the IMS CHANGE (/CHA) command may be entered only from
                         LTERM LT36SST.
                             )( TERMINAL     LT36SST
                                COMMAND      CHANGE

                         While the CHANGE command may be entered only from this LTERM, the LTERM
                         is not restricted in any other way. Therefore, other unprotected commands (such
                         as /LOCK) could be entered from LTERM LT36SST.

                         2.1.2.3 Password Protection for Commands
                         Command password security is implemented using SMU. This type of security
                         may be used for commands entered from static terminals. Using this type of
                         security the COMMAND utility control statement is provided as input to the SMU
                         security generation process. The statements provided tell IMS the commands
                         that are restricted to use by users that provide the correct password upon
                         entering the command. The password is entered within parentheses
                         immediately following the command verb. The following example specifies that
                         the IMS CHANGE (/CHA) command may be entered only by users specifying the
                         password S1332SST when issuing the command:
                             )( COMMAND      CHANGE
                                PASSWORD     S1332SST

                         As the examples in the IMS/ESA Administration Guide: System , SC26-8730 show,
                         these security options may be coded to be even more restrictive. For example,
                         LTERM command security and password command security may be combined.
                         The following example restricts the entry of the CHANGE command to LTERM
                         LT36SST and the password S1332SST must be supplied with the command when
                         it is entered:
                             )( COMMAND      CHANGE
                                PASSWORD     S1332SST
                                TERMINAL     LT36SST

                         One note should be made here. When SMU security facilities have been used to
                         assign passwords to commands, the only default IMS MFS format that contains a
                         field for inputting the password is the format for the master terminal (MTO). To
                         enter password-protected commands from non-MTO terminals the installation
                         has two options:
                             1. The terminal user can ″clear″ the screen and enter the command and
                                password.
                             2. The installation can modify the default MFS formats and include a field for
                                the password.




14   IMS V6 Security Guide
2.1.2.4 DL/I CMD Call Security
Automated operator (AO) programs that issue IMS commands using the DL/I
CMD call may be secured by IMS. A parameter on the SECURITY macro
(TRANCMD=NO/YES/FORCE) tells IMS whether any AO program is permitted to
issue IMS commands. If some AO programs are allowed to issue commands,
the transactions for the programs are specified to SMU using CTRANS and/or
TCOMMAND input statements:
)( CTRANS        AOTRAN
   TCOMMAND      START
   TCOMMAND      STOP
   TCOMMAND      DISPLAY

)( TCOMMAND      START
   CTRANS        AOTRAN
   CTRANS        OPRTRAN
   CTRANS        DBATRAN

2.1.2.5 DL/I ICMD Call Security
AO programs that issue the DL/I ICMD call may also be secured by RACF. The
SECURITY macro does not contain a parameter that tells IMS whether ICMD
calls may be issued from AO application programs. IMS is informed whether AO
programs may issue ICMD calls based on the specification of the A O I S =
parameter in the IMS startup parameters. IMS startup parameters are in an
IMS.PROCLIB member (the default name of the member is DFSPBxxx, where xxx
is one of the IMS, DBC, or DCC).

2.1.2.6 User ID-Based Command Security
RACF enforces command security by checking the CIMS/DIMS RACF classes for
command profiles. If a security profile for a command exists in one of the
classes (CIMS or DIMS) the command has been secured and protected. RACF
checks to see if the userid (or group name) has been authorized to issue the
command.

2.1.2.7 Extended Command Security
If a greater level of command authorization is required than SMU or RACF can
provide (such as verifying authorization to use keywords on specific commands),
the Command Authorization Exit (DFSCCMD0) routine may be used to achieve
this. We will use the following IMS command as an example: /STO DB ALL
(stop all databases). RACF could be used to verify the user′s authorization to
issue the /STOp command; and the exit could determine whether the user could
issue the DATABASE keyword on the /STOp command.

If RACF or SMU is used to perform command authorization, DFSCCMD0 is called
after RACF/SMU.

2.1.2.8 Time-Controlled Operations (TCO)
IMS defines two logical terminals for TCO: DFSTCF and DFSTCFI. These terminal
definitions allow TCO input to appear as though it came from a terminal. You do
not need to specify either LTERM name in your IMS Stage 1 input. If you do, IMS
issues a G979 message telling you that your Stage 1 includes duplicate LTERM
names.

IMS commands issued by TCO may be secured using SMU or RACF.




                                            Chapter 2. Implementing IMS Security   15
                         You can use SMU to control which IMS commands the TCO LTERMs can issue.
                         List the secured commands for LTERM DFSTCFI in the SMU input. DFSTCFI is
                         the TCO input LTERM, so all TCO issued commands need to be associated with
                         DFSTCFI.

                         When RACF is used to secure IMS commands and a secured command is issued
                         by TCO, the /SIGN command must be issued in the TCO script. The /SIGN
                         command needs to be issued prior to issuing other IMS commands; and TCO
                         sign-on must include a vaild RACF user ID and password for TCO. For example,
                         /SIGN ON TCOusid password needs to be the first command issued.

                         Since the TCO script can contain a user ID/password when RACF is used for
                         command authorization, it is important to restrict access to the IMS libraries that
                         contain this type of sensitive information. The IMS libraries can be secured in
                         the RACF DATASET class.

                         As you may have noted, the security facility used to determined whether the
                         command will be processed depends on the origin of the command. For
                         example, the command may have been entered from a static or ETO terminal; or
                         from a program that issued either the DL/I CMD or ICMD call. Furthermore,
                         DFSCCMD0 may also be customized by the installation to provide a more
                         granular level of security. This exit can be used in conjunction with SMU or
                         RACF; or it may be used alone without SMU or RACF to provide command
                         security. DFSCCMD0 will be covered in more detail in Chapter 10, “IMS Security
                         Exits” on page 181.


2.1.3 Protecting IMS Transactions
                         There are six methods that may be used to secure IMS transactions. The sixth
                         method involves implementing transaction security using the user-customized
                         Transaction Authorization Exit Routine (DFSCTRN0), which is covered in more
                         detail in Chapter 10, “IMS Security Exits” on page 181. DFSCTRN0 may be used
                         with SMU or RACF to provide installation-specific transaction authorization. The
                         types of protection for transactions are:
                             •   Restricting transaction entry to specific LTERM(s). As with IMS
                                 LTERM-based command security, SMU is used to determine which LTERMs
                                 may be used for entering transactions codes. As previously mentioned,
                                 password and LTERM-based security may be combined. Since SMU is used
                                 to provide this type of security the physical terminal (that is associated with
                                 the LTERM) must be statically defined to IMS. The example below shows the
                                 SMU input control statements used to implement LTERM-based transaction
                                 authorization. In the example, transaction ACTY has been given a password
                                 of GO and the transaction may be entered only from the terminal to which
                                 LTERM A8751111 is assigned:
                                  )( TRANSACT      ACTY
                                     PASSWORD      GO
                                     TERMINAL      A8751111
                             •   Assigning a password to the transaction. Transaction authorization that is
                                 based on securing the transaction with a password is implemented using
                                 SMU. Thus the terminals from which the password-protected transactions
                                 are entered are required to be static terminals. Using this type of security
                                 the TRANSACT utility control statement is provided as input to the SMU
                                 security generation process. The statements provided tell IMS the
                                 transactions that are restricted to use by users that provide the correct
                                 password upon entering the transaction. The following example specifies

16   IMS V6 Security Guide
                     that the IMS ACCTCHG transaction may be entered only by users specifying
                     the password CHARGE when entering the transaction:
                      )( TRANSACT     ACCTCHG
                         PASSWORD     CHARGE
                     Also remember that in addition to supplying a password with the transaction,
                     the installation may also choose to limit the entry of the transaction to
                     specific LTERM(s), as follows:
                      )( TRANSACT     ACCTCHG
                         PASSWORD     CHARGE
                         TERMINAL     A8751111
                         TERMINAL     C8751112
                 •   Transaction authorization using SMU and DFSCTRN0. If the LTERM-based
                     and/or password security facilities provided by SMU do not meet the
                     installation′s security requirements, the installation has the option of
                     customizing the Transaction Authorization Exit routine to provide additional
                     security checking beyond the capabilities of SMU.
                 •   Transaction authorization using RACF. RACF enforces transaction security
                     by checking the TIMS/GIMS RACF classes for transaction security profiles. If
                     a security profile for a transaction exists in one of the classes (TIMS or
                     GIMS) the transaction has been secured and protected. RACF checks to see
                     if the user ID (or group name) has been authorized to execute the
                     transaction. The following example shows the RACF statements used to
                     create (RDEFINE) a RACF security profile for the inquiry (INQY) transaction in
                     the TIMS class and authorize (PERMIT) user IDs connected to the customer
                     service (CUSTSERV) group to execute the INQY transaction:
                       RDEFINE TIMS INQY UACC(NONE)
                       PERMIT INQY CLASS(TIMS) ACCESS(READ) ID(CUSTSERV)
                     RACF (like SMU) provides a password protection scheme for transactions.
                     This RACF feature is known as REVERIFY. The REVERIFY function will be
                     covered in Chapter 5, “Securing IMS Transactions” on page 97.
                 •   Transaction authorization using RACF and DFSCTRN0. If RACF-provided
                     transaction authorization security is insufficient to meet the installation
                     requirements, the DFSCTRN0 routine may be customized to meet the
                     requirements. RACF is called first to determine if the user ID/group name is
                     permitted to execute the transaction. Upon successful authorization by RACF,
                     DFSCTRN0 is called to perform installation specified transaction
                     authorization security checking.
                 •   Transaction authorization using DFSCTRN0. DFSCTRN may be customized to
                     meet the installation′s transaction security requirements. It may be used as
                     the only transaction authorization security facility, or it may be used in
                     conjunction with either SMU or RACF. The (DFSCTRN0) routine may be
                     customized to meet the requirements.


2.1.4 Protecting IMS Databases
                IMS databases may be secured in several ways, as follows:
                 •   Passwords for /LOCK and /UNLOCK IMS commands
                     If SMU security is used to protect databases, the databases are prevented
                     from being used by locking them using the following command:
                      /LOCK DATABASE PAYDATA (password)



                                                               Chapter 2. Implementing IMS Security   17
                                 Note that a database password is optional. In addition to locking the
                                 database, the /LOCK command itself could be password protected (assigned
                                 a password) thereby restricting use of the command. Similarly, the
                                 /UNLOCK DATABASE PAYDATA (password) would be used to unlock the
                                 database. As with the /LOCK command, the /UNLOCK command can be
                                 password protected so that the use of the command is restricted to
                                 authorized users.
                             •   Database access security
                                 IMS databases may be protected in the RACF PIMS and/or QIMS classes.
                                 Using this type of protection, a database security profile would be created in
                                 the RACF PIMS/QIMS class and authorized users would be RACF permitted
                                 to the database. OSAM, VSAM, fast path data entry databases (DEDBs), and
                                 DB2 tables can be protected for the appropriate DB/DC and DBCTL
                                 environments.
                                 You can use RACF to protect IMS system libraries, system data sets, IMS
                                 databases and DB2 tables. IMS invokes RACF to determine whether the
                                 user ID associated with the system address space (control region, DLISAS,
                                 or batch) attempting to open the resource has the necessary access
                                 authorization. Actually, when RACF authorizes access, it associates a user
                                 ID with the started procedure name (IMS or DLISAS procedure) through a
                                 started task table. If you start IMS with JCL, the RACF user ID can be on the
                                 job card along with its password.
                                 If the user ID does not have the authorization, access is denied. The basic
                                 rule is, ″Whoever has the DD card must have the authority.″
                                 If the IMS procedure is associated with a RACF user ID (with sufficient
                                 authority), the IMS control region can open a RACF-protected data set. If an
                                 association does not exist, the IMS control region is not allowed to open a
                                 RACF-protected data set that does not allow universal access for the
                                 requested authority level.
                                 If the DLISAS procedure is associated with a RACF user ID, it overrides the
                                 RACF user ID for the IMS procedure. If an association does not exist, the
                                 RACF user ID associated with the IMS procedure is used for RACF access
                                 checking.
                             •   VSAM full-function databases
                                 In an online environment, if a RACF user ID is associated with the DLISAS
                                 started procedure, that ID is used for access checking. If a RACF user ID is
                                 not associated with the DLISAS started procedure, the control region RACF
                                 user ID is utilized. (In the batch environment, the user ID of the batch job is
                                 employed.) Access authority of ″CONTROL″ is required. The database must
                                 be defined as ICFCATALOG. Use of the older ″VSAM″ catalog type is
                                 restricted.
                             •   OSAM full-function databases
                                 In an online environment, the RACF user ID of DLISAS is used; in the batch
                                 environment, the user ID of the batch job is used.
                             •   Fast Path DEDBs
                                 In an online environment, the control region RACF user ID is used. (No
                                 batch environment exists.)
                             •   Additional protection




18   IMS V6 Security Guide
                     You can also implement database security with the PIMS, SIMS, and FIMS
                     classes in RACF.
                     These RACF classes are designed for use with application program security.
                     The application program uses the DL/I AUTH call to call RACF for database
                     authorization security checking. The application program is not forced to
                     comply with the RACF return code. The application program makes the final
                     decision on whether access to the database record, segment, or field will be
                     allowed.
                 •   Database security using the PIMS/QIMS RACF classes
                     Creating database security profiles in the PIMS/QIMS RACF classes alone
                     will not provide database security using RACF. The application program
                     must issue the AUTH call and specify PIMS/QIMS RACF classes when
                     requesting database authorization checking.
                     Conversely, securing the data sets that make up a database is more direct.
                     That is, data sets may be secured in the DATASET class and the AUTH call
                     does not have to be used.
                 •   Segment and field access security
                     RACF also has SIMS/UIMS RACF classes for protecting segments within a
                     database, FIMS/HIMS RACF classes for protecting fields within a segment,
                     and OIMS/WIMS RACF classes for protecting user-defined fields in a
                     database. As with the database class (PIMS); security profiles for the
                     SEGMENT, FIELD, or OTHER information would be created in the appropriate
                     RACF class and authorized users permitted to the resource.
                     Note that two classes each are shown for database, segment, field and other.
                     This is because each of these classes has a regular class name and an
                     associated grouping class name. The SIMS/UIMS, FIMS/HIMS, and
                     OIMS/WIMS RACF classes are used with an installation′ s
                     application-provided security program that uses the DL/I AUTH call to RACF
                     to obtain resource authorization information. It should also be noted here
                     that segments and fields may also be protected during the PSB generation
                     (PSBGEN) process. See Chapter 6, “IMS Databases and IMS Data Sets” on
                     page 127 for details of the AUTH call and PSBGEN security options.


2.1.5 Protecting IMS Dependent Region(s) and the IMS Online System
                IMS dependent regions can be protected with Application Group Name (AGN)
                security. AGN security involves three steps:
                 1. Deciding which IMS resources will be included in the AGN group and naming
                    the group with the AGN input control card to SMU.
                 2. Creating a security profile in the RACF AIMS Class. The name of the RACF
                    security profile corresponds to the AGN group name used to define the AGN
                    in SMU. User ID and/or groups are authorized (using the RACF PERMIT) to
                    the RACF AGN security profile in the AIMS class. Or, if RACF is not used to
                    authorize user IDs the Resource Access Security Exit routine (DFSISIS0) may
                    be customized by the installation to authorize user IDs to the AGN group.
                 3. Determining which IMS dependent region(s) will be allowed to schedule the
                    PSB included in the AGN group. The procedure that is used to start the
                    dependent region contains an AGN= parameter in the procedure′s job
                    control language (JCL). The procedure must specify the correct AGN name
                    in order to schedule the PSB.



                                                              Chapter 2. Implementing IMS Security   19
                         AGN security provides the following protection:
                             •   Protects the PSB by allowing the PSB only to be scheduled by dependent
                                 regions that have been authorized to schedule it.
                             •   Protects dependent regions by allowing dependent regions only to schedule
                                 work the region is supposed to schedule.
                         Let us review and look at an example. AGNs are defined to SMU using input
                         control statements. The statements name the IMS resources that are included in
                         the AGN. Once the AGN has been defined to SMU, the installation can use
                         either RACF or the Resource Access Security Exit (DFSISIS0) to determine
                         whether a specific user ID is authorized to the AGN. If RACF is used to
                         determine whether the user is authorized to use the AGN, the RACF AGN
                         security profile is created in the AIMS RACF class; and the RACF profile name is
                         identical to the AGN name defined to SMU.

                         An example of the SMU input control statements for defining an AGN (named
                         TEST002) has been provided below. The AGN TEST002 tells IMS which IMS
                         resources are included and secured in the AGN group TEST002; namely
                         PAYROLL and PAYTRAN. While the AGN group TEST002 has not been defined to
                         include LTERMs, be aware that LTERMs can also be part of the AGN group.
                         RACF or DFSISIS0 is used to determine which user IDs are permitted to use (or
                         execute) resources included in this AGN. In the example below, RACF (rather
                         than DFSISIS0) has been chosen to determine user authorization:
                         SMU input statements:

                             )( AGN        TEST002
                                AGPSB      PAYROLL
                                AGTRAN     PAYTRAN

                         The RACF statements below are used to create (RDEFINE) a RACF security
                         profile for TEST002 (an AGN) in the AIMS class and authorize (PERMIT) user IDs
                         in the group PAYGROUP and PAYBMP (batch message program that performs
                         payroll functions) to the AGN.
                         RDEFINE AIMS TEST002 UACC(NONE)
                         PERMIT TEST002 CLASS(AIMS) ACCESS(READ) ID(PAYBMP PAYGROUP)

                         The final step would be to code the AGN=TEST002 in the JCL contained in the
                         procedure used to start the dependent region(s).


2.1.6 Protecting IMS Program Specification Blocks
                         PSBs exist for both online application programs and for batch message
                         processing (BMP) programs. PSBs may be protected in several ways.
                             •   PSB access security. As you noticed in the AGN example, one method of
                                 securing a PSB is by making the PSB part of an AGN group using SMU
                                 security facilities. Then RACF or DFSISIS0 can be used to check the user′ s
                                 authorization to use the PSB.
                             •   Securing PSB used by CPI-C-driven transactions. For common programming
                                 interface for communications (CPI-C) driven transactions, security profiles for
                                 PSBs may be created in the AIMS class (along with the AGN security
                                 profiles). This allows RACF to verify that the CPIC end user′s user ID is
                                 authorized to schedule the PSB. The advantages for the CPIC user are that
                                 SMU AGN security is bypassed, and user IDs (rather than PSB) are checked




20   IMS V6 Security Guide
                     for authorization to schedule the PSB. This security support requires IMS V6
                     and later releases.


2.1.7 Protecting IMS Control Program and Region Application Programs
                RACF may be used to secure access to the IMS online system. Think of this as
                securing the IMS control program, the IMS control region, and the VTAM
                application name for IMS. The IMS VTAM APPLID may be secured in the RACF
                APPL class by creating a security profile in the class and authorizing (issuing a
                RACF PERMIT command using ) the VTAM user ID.


2.1.8 Protecting IMS System Data Sets
                The old way of protecting IMS system data sets (such as IMS.ACBLIBx,
                IMS.MATRIXx, IMS.MODBLKS, and others) was to secure them using MVS
                operating system password protection. Although some IMS publications still
                refer to this method of protecting IMS system data sets, it is not the current
                method used by many customer installations.

                The current method used to protect IMS system data sets is to create data set
                profiles in the RACF DATASET class, then authorize the user ID (of the IMS
                region that owns the DD statement) to the data set. To determine which IMS
                region user IDs should be authorized to open specific IMS system data sets, a
                general rule to follow is: the user ID of the IMS region that has the DD card
                must have the authority. For example, the IMS control region accesses
                IMS.MATRIX data sets; therefore, the user ID associated with the control region
                is placed on the RACF access list (or is RACF permitted) with sufficient authority
                to use the data set. Likewise, since DBRC uses IMS.RECON data sets, its user
                ID would be permitted with sufficient access authority to the RECON data sets.

                The following sample shows how to create a RACF security profile for an IMS
                system data set and authorize (PE=permit) the user ID of the region to the data
                set:
                 ADDSD ′ IMS.MATRIXA′ GENERIC
                 PE ′ IMS.MATRIXA′ GENERIC ID(IMSUSID) ACCESS(UPDATE)

                There are a couple of ways to assign the IMS control region, DLISAS, DBRC,
                batch regions, and MPRs RACF user IDs:
                 •   Each subsystem can be assigned a user ID in the started task table
                     (ICHRIN03); or each subsystem may be assigned a user ID simply by
                     creating a security profile for the subsystem in the RACF STARTED class.
                 •   If the regions are started using JCL (regions started as batch jobs), the RACF
                     user ID and password can be assigned using JCL on the job card. The
                     USER= and PASSWORD= parameters on the job card are used to specify
                     the user ID and password. If the JCL to start the regions contain user IDs
                     and passwords, this may be a security exposure in itself. Therefore,
                     consider protecting the data set(s) that contain the JCL used to start the
                     regions.




                                                               Chapter 2. Implementing IMS Security   21
2.1.9 Securing IMS Resources Accessed from Other Systems
                         IMS applications and data can be accessed a number of ways, for example:
                             •   From LU6.2 (APPC) users
                             •   From MSC networks
                             •   From OTMA clients and/or ITOC clients
                             •   From CICS DBCTL users

                         The methods and facilities used to protect the IMS resources is dependent on
                         the way IMS resources are accessed. Thus, security options are different for
                         accessing IMS through APPC than for accessing IMS through CICS/DBCTL.
                         Chapter 8, “IMS Resources Accessed from Other Environments” on page 147
                         describes the security options available when APPC, MSC, OTMA, and
                         CICS/DBCTL are used.

                             Table 1 (Page 1 of 2). Summary of IMS Resources and Security Protection
                             Resource Type                    Security Option/Type of Protection
                             Static Terminals                 Sign-on Verification
                                                              Terminal User Security
                                                              Passwords for /IAM, /LOCK, /UNLOCK
                             ETO Terminals                    Sign-on Verification
                                                              User ID Verification
                                                              Terminal User Security
                             Logical Terminals (LTERMs)       Passwords for /IAM, /LOCK, /UNLOCK
                                                              LTERMs May Be Included in AGNs
                                                              Command/Transaction Entry Limited to LTERM(s)
                             IMS Commands                     Default Terminal (Command) Security
                                                              Command Entry Restricted to LTERM(s)
                                                              Assign Password to Command
                                                              AO Program DL/I CMD Call Security
                                                              AO Program DL/I ICMD Call Security
                                                              RACF User ID-Based Command Security
                                                              DFSCCMD0 Installation-provided Command Security
                             Transactions                     Transaction Entry Restricted to LTERM(s)
                                                              Assign Password to Transaction
                                                              Transaction May Be Included in AGN
                                                              RACF User ID-Based Transaction Security
                                                              DFSCTRN0 Installation-provided Transaction Security
                             Databases                        Passwords for /LOCK, /UNLOCK
                                                              Database Security via DL/I AUTH Call/RACF PIMS
                                                              Segment Sensitivity (PSB Generation)
                                                              Segment Security via DL/I AUTH Call/RACF SIMS
                                                              Field Sensitivity (PSB Generation)
                                                              Field Security via DL/I AUTH Call/RACF FIMS
                                                              Other Security via DL/I AUTH Call/RACF OIMS
                                                              DB Data Sets Secured by RACF DATASET Class
                             IMS Ctrl Pgm/Region              RACF APPL Class
                             IMS Online System                RACF Command/Transaction Authorization Processing
                                                              SMU Command/Transaction Security
                                                              AGN Security
                             PSBs                             AGN Security Using SMU and RACF
                                                              AGN Security Using SMU and AGNEXIT (DFSISIS0)
                                                              Allocate PSB (APSB) SAF Security for CPI-C Appls




22   IMS V6 Security Guide
                 Table 1 (Page 2 of 2). Summary of IMS Resources and Security Protection
                 Resource Type                        Security Option/Type of Protection
                 Online Appl Pgm Libraries            Passwords for /IAM, /LOCK, /UNLOCK
                                                      RACF Security Using DATASET Class
                 Dependent Regions                    AGNs (SMU and RACF)
                                                      AGNs (SMU and DFSISIS0)
                 System Data Sets                     Security Using RACF DATASET Class
                                                      Operating System Password Protection
                 Connections                          APPC Allocate Verification Security
                                                      APPC IMS-Mngd Outbound Conversations
                                                      Multiple Systems Coupling Security
                                                      OTMA Security
                                                      MQSeries Security
                                                      External Subsystems Security (CICS, DB2)
                 Note: It should be noted that IMS SMU-provided security is only for statically
                 defined resources, that is, the resource is defined to IMS in the system definition via
                 a macro. SMU does not support ETO devices.


               As you can see, IMS resources can be secured through various means. Now let
               us look at how the type and level of security are defined to IMS.



2.2 Specifying IMS Security Choices at SYSDEF
               The bulk of this topic addresses understanding the IMS SYSDEF macros used to
               implement security. That is, understanding the keyword and parameter settings
               and their meanings.

               In an IMS system, two types of security exist. The installation can address one
               or both types:
                •   Securing the kind of resource to which a user has access. For example, a
                    user might be allowed access to the Part database but not to the Customer
                    database.
                •   Securing what the user can do to the resource after that user has access to
                    it. For example, a user might be allowed to read a file but not to update it.

               The IMSGEN, COMM, and SECURITY macros security parameters define to IMS
               the type of protection (or security checking) to be performed. For example, an
               installation may require only sign-on and transaction authorization security
               checking.

               The security options selected on the IMSGEN, COMM and SECURITY macros are
               enforced by IMS through the use of the SMU tables and matrixes containing the
               security information (that is, password tables/matrixes), RACF, and/or one or
               more of the security exits. Refer to Appendix B, “Security Maintenance Utility
               (DFSISMP0)” on page 241 on how to use and control statement coding of SMU
               program.

               The focus in this section of the book is on security specifications on the
               SECURITY macro for several reasons:
                •   Most installations tend to use RACF because IMS SMU-provided security has
                    some limitations; and RACF specifications are coded on the SECURITY
                    macro


                                                                  Chapter 2. Implementing IMS Security     23
                                 −   With IMS SMU-provided security, you cannot determine what the
                                     authorized user can do to the resource after that user has access to it.
                                     This is one of the reasons why IMS provides installations with sample
                                     security exits (DFSxxxxx) that they can customize to meet their specific
                                     security requirements.
                                 −   IMS SMU security does not provide support for ETO, APPC, OTMA, and
                                     SYSPLEX.
                                 −   IMS SMU security requires a unique set of matrix data sets for each IMS
                                     such that IMS.MATRIX data sets cannot be shared across multiple IMS
                                     systems. The exceptions to this are:
                                      - If each IMS system is generated identically (with the same
                                        databases, same number/types of terminals, same transactions, and
                                        other resources); the matrix data sets may be shared.
                                      - Each IMS system sharing matrix data sets has been generated with a
                                        unique nucleus suffix.
                                 −   IMS SMU has a limited number (usually 65K) of resources of each type
                                     that can be defined.
                             •   Both SMU and RACF options/specifications may be coded on the SECURITY
                                 macro
                             •   The SECURITY macro has keyword and parameter settings equal (in effect)
                                 to keyword/parameter settings on the COMM and IMSGEN macros

                         In spite of some of the limitations of IMS SMU-provided security, as you may
                         have noted in 2.1, “IMS Resources That Can Be Protected and Types of
                         Protection” on page 11 that SMU must be used to protect some IMS resource
                         types, such as application group names (AGN) or the DL/I CMD call.

                         Unlike IMS SMU security, RACF-provided security provides the installation with:
                             •   A dedicated security program product
                             •   Sharable security profile data sets
                             •   Protection for most MVS resources
                             •   Security for IMS entry ports
                             •   Significantly improved security profile capacity

                         With all these advantages of RACF-provided security, IMS enhanced the security
                         options available to installations by:
                             1. Consolidating all IMS security specifications on to the SECURITY macro
                             2. Maintaining compatibility with COMM and IMSGEN security specifications by
                                allowing the same IMS SMU-related security specifications on the SECURITY
                                macro
                             3. Adding RACF-provided security specifications, and installation-customized
                                security exits to provide an even greater level of security if needed

                         The reader should keep in mind that the installation can also utilize the
                         additional security capabilities provided in IMS security exits that have been
                         customized/modified to meet the installation′s security requirements. Some of
                         the IMS-provided security exits can operate in an IMS SMU security
                         environment; and all of the IMS-provided security exits can operate in a RACF



24   IMS V6 Security Guide
               security environment. IMS-provided security exits will be described in a later
               section.


2.2.1 SYSDEF Macros Keyword and Parameter Settings and Meanings
               The following topics (on the three IMS macros used to indicate an installation′ s
               security specifications) compare the meanings/results of each of the three
               macros security parameter specifications. As you familiarize yourself with the
               security keywords and parameters settings, keep in mind that security options
               can be changed/overridden using the DFSPBxxx IMS.PROCLIB member or by the
               IMS MTO. The MTO can control the following security at cold start when either
               /NRE CHKPT 0 or /ERE COLDSYS command is used to cold start IMS:
                •   Sign-on verification (require/do not require /SIGN ON command)
                •   Transaction authorization (Turn on/off transaction authorization security
                    checking)
                •   Terminal security (command/transaction entry restricted to specific LTERMs
                    turned on/off)
                •   Transaction command security (allow/disallow IMS commands to be issued
                    from automated operator programs)
                •   Password security (turn on/off password security for password-protected
                    resources such as commands/transactions)
                •   Command authorization (turn on/off command authorization security
                    checking for IMS commands entered from a terminal)

               When IMS is warm started the security settings/specifications are recovered
               from the checkpoint log record used to restart IMS.


2.2.2 SECURITY Macro
               The compatibility of the SECURITY macro with the COMM and IMSGEN macros
               has been mentioned several times. Table 2 compares the parameters of the
               three security macros, and lists the remainder of the security parameters that
               may be specified only on the SECURITY macro. The intent of Table 2 is to show
               that the security keywords on the IMSGEN, COMM, and SECURITY macros have
               equivalent and compatible meanings. That is, PSWDSEC=NO
               keyword/parameter specification (on the IMSGEN macro) is compatible with the
               OPTIONS=NOPSWD specification (on the COMM macro); and both are
               compatible with the PASSWD=NO specification (on the SECURITY macro) and
               likewise for the other keywords shown.

                Table 2 (Page 1 of 2). IMSGEN and COMM Equal Parameter Settings Table
                IMSGEN MACRO             COMM MACRO              SECURITY MACRO
                PSWDSEC=NO               OPTIONS=NOPSWD          PASSWD=NO
                PSWDSEC=YES              OPTIONS=PASSWD          PASSWD=YES
                PSWDSEC=FORCE            OPTIONS=FORPSW          PASSWD=FORCE
                TERMSEC=NO               OPTIONS=NOTERMNL        TERMNL=NO
                TERMSEC=YES              OPTIONS=TERMINAL        TERMNL=YES
                TERMSEC=FORCE            OPTIONS=FORCTERM        TERMNL=FORCE
                SECCNT=0                 SECCNT=0                SECCNT=0
                SECCNT=1                 SECCNT=1                SECCNT=1



                                                              Chapter 2. Implementing IMS Security   25
                             Table 2 (Page 2 of 2). IMSGEN and COMM Equal Parameter Settings Table
                             IMSGEN MACRO             COMM MACRO               SECURITY MACRO
                             SECCNT=2                 SECCNT=2                 SECCNT=2
                             SECCNT=3                 SECCNT=3                 SECCNT=3
                                                      PASSWD=
                                                      (pswrd1,pswrd2,pswrd3)
                                                                               RCLASS=IMS/class-id
                                                                               SECLVL=NOTRAN,NOSIGN
                                                                               SECLVL=TRANAUTH,SIGNON
                                                                               SECLVL=FORCTRAN,FORCSIGN
                                                                               TRANCMD=NO
                                                                               TRANCMD=YES
                                                                               TRANCMD=FORCE
                                                                               TYPE=<A> See below.
                             Note:   TYPE= can be one of the following:
                             NOAGN   NORACTRM NOTRANEX NOSIGNEX NORACFCM
                             RACFAGN RACFTERM TRANEXIT SIGNEXIT RACFCOM
                             AGNEXIT


                         Now that you have seen the keywords and parameter settings for the SECURITY
                         macro, let us examine the meaning of each specification. Table 3 on page 27
                         shows the meaning of each parameter setting:




26   IMS V6 Security Guide
Table 3 (Page 1 of 5). Summary of SECURITY Macro Security-Related Parameters
Keywords and        Meaning(s) and Results
Parameters
PASSWD=NO            1. Password security checking will not be performed.
                     2. IMS.MATRIXA or IMS.MATRIXB password tables will not
                        be loaded into control region storage at startup.
                     3. The MTO can specify PASSWORD (turn on password
                        security checking) on the /NRE CHKPT 0 or /ERE COLDSYS
                        commands, thus overriding the PASSWD=NO system
                        definition specification.
PASSWD=YES           1. Password security checking will be performed.
                     2. IMS.MATRIXA or IMS.MATRIXB password tables will be
                        loaded into control region storage at startup.
                     3. The MTO can specify NOPASSWORD (turn off password
                        security checking) on the /NRE CHKPT0 or /ERE COLDSYS
                        commands, thus overriding the PSWDSEC=YES system
                        definition specification.
PASSWD=FORCE         1. Password security checking will be performed.
                     2. IMS.MATRIXA or IMS.MATRIXB password tables must be
                        loaded into control region storage at startup. User
                        ABENDU0171 will occur if the load fails.
                     3. The MTO cannot specify PASSWORD or NOPASSWORD on
                        the /NRE CHKPT 0 or /ERE COLDSYS commands, and
                        cannot override PASSWD=FORCE system definition
                        specification.
TERMNL=NO            1. Terminal security checking will not be performed.
                     2. IMS.MATRIXA or IMS.MATRIXB tables will not be loaded
                        into control region storage at startup.
                     3. The MTO can specify the TERMINAL keyword on the /NRE
                        CHKPT 0 or /ERE COLDSYS commands to override
                        TERMNL=NO system definition specification.
TERMNL=YES           1. Terminal security checking will be performed.
                     2. IMS.MATRIXA or IMS.MATRIXB tables will be loaded into
                        control region storage at startup.
                     3. The MTO can specify the NOTERMINAL keyword on the
                        /NRE CHKPT 0 or /ERE COLDSYS commands to override
                        TERMNL=YES system definition specification.
TERMNL=FORCE         1. Terminal security checking will be performed.
                     2. IMS.MATRIXA or IMS.MATRIXB tables must be loaded into
                        control region storage at startup. User ABENDU0171 will
                        occur if the load fails.
                     3. The MTO cannot specify TERMINAL or NOTERMINAL
                        keywords on the /NRE CHKPT 0 or /ERE COLDSYS
                        commands to override TERMNL=FORCE specification
                        when IMS is restarted.




                                             Chapter 2. Implementing IMS Security   27
                             Table 3 (Page 2 of 5). Summary of SECURITY Macro Security-Related Parameters
                             Keywords and        Meaning(s) and Results
                             Parameters
                             SECCNT=0             1. Terminal and password security violation notification
                                                     messages are not sent to the master terminal.
                                                  2. The terminal user that caused the security violation
                                                     receives a security violation message. The message
                                                     received by the terminal user depends on:
                                                       a. The type of session manager (VTAM/BTAM)
                                                       b. The type of terminal (static/ETO)
                                                       c. Whether the user performed sign-on, and
                                                       d. Whether the violation was a terminal security violation
                                                          or a password security violation
                                                     Among the messages that terminal users can receive are:
                                                       a. DFS2467 - and Reason Code
                                                       b. DFS3649 - and Reason Code
                                                       c. DFS3662W - and Reason Code
                                                     If an AO program caused the security violation, a CD
                                                     status code is returned to the application program after
                                                     each violation. (Note that the CD status is received for AO
                                                     programs that have a security violation when issuing the
                                                     ICMD DL/I call. Programs that issue the AUTH, ISRT,
                                                     and/or CHNG calls receive an A4 status code on a security
                                                     violation.)




28   IMS V6 Security Guide
Table 3 (Page 3 of 5). Summary of SECURITY Macro Security-Related Parameters
Keywords and        Meaning(s) and Results
Parameters
SECCNT=1             1. Each terminal security violation and each password
                        security violation results in a security violation notification
                        message (DFS286) being sent to the master terminal. The
                        text in the DFS286 notification message depends on where
                        the resource access violation action was input:
                         a. BTAM terminal
                         b. VTAM terminal
                         c. Automated Operator Program issuing IMS cmd(s). The
                            DFS286 message sent to the master terminal contains
                            a user ID for the program that caused the security
                            violation. The user ID in the message depends on the
                            region type where the program was executing, and
                            whether a GU call was made. (See Table 2 on
                            page 25).
                        The master terminal operator decides what action to take,
                        depending on the installation′s security procedures.
                     2. The terminal user that caused the security violation also
                        receives a security violation message. The message
                        received by the terminal user depends on:
                         a.   The type of session manager (VTAM/BTAM)
                         b.   The type of terminal (static/ETO)
                         c.   Whether the user performed sign-on, and
                         d.   Whether the violation was a terminal security violation
                              or a password security violation
                        Among the messages that terminal users can receive are:
                         a. DFS2467 - and Reason Code
                         b. DFS3649 - and Reason Code
                         c. DFS3662W - and Reason Code
                        If an AO program caused the security violation, a CD
                        status code is returned to the application program after
                        each violation. (Note that the CD status is received for AO
                        programs that have a security violation when issuing the
                        ICMD DL/I call. Programs that issue the AUTH, ISRT,
                        and/or CHNG calls receive an A4 status code on a security
                        violation.)




                                               Chapter 2. Implementing IMS Security       29
                             Table 3 (Page 4 of 5). Summary of SECURITY Macro Security-Related Parameters
                             Keywords and        Meaning(s) and Results
                             Parameters
                             SECCNT=2             1. A notification message (DFS286) is sent to the master
                                                     terminal, after two terminal and/or password security
                                                     violations on a static terminal, and after one terminal
                                                     and/or password security violation on an ETO terminal.
                                                     The text in the DFS286 notification message depends on
                                                     whether the resource access violation action was inputted
                                                     from a:
                                                      a. BTAM terminal
                                                      b. VTAM terminal
                                                      c. Automated Operator Program issuing IMS cmd(s)
                                                     The master terminal operator decides what action to take.
                                                  2. The terminal user that caused the security violation also
                                                     receives a security violation message after each violation.
                                                     The message received by the terminal user depends on:
                                                      a.   The type of session manager (VTAM/BTAM)
                                                      b.   The type of terminal (static/ETO)
                                                      c.   Whether the user performed sign-on, and
                                                      d.   Whether the violation was a terminal security violation
                                                           or a password security violation
                                                     Among the messages that terminal users can receive are:
                                                      a. DFS2467 - and Reason Code
                                                      b. DFS3649 - and Reason Code
                                                      c. DFS3662W - and Reason Code
                                                     If a AO program caused the security violation, a CD status
                                                     code is returned to the application program after each
                                                     violation. (Note that the CD status is received for AO
                                                     programs that have a security violation when issuing the
                                                     ICMD DL/I call. Programs that issue the AUTH, ISRT,
                                                     and/or CHNG calls receive an A4 status code on a security
                                                     violation.)




30   IMS V6 Security Guide
 Table 3 (Page 5 of 5). Summary of SECURITY Macro Security-Related Parameters
 Keywords and          Meaning(s) and Results
 Parameters
 SECCNT=3               1. After three terminal and/or password security violations on
                           a static terminal, and after one terminal security violation
                           on an ETO terminal, a notification message (DFS286) is
                           sent to the master terminal. The text in the DFS286
                           notification message depends on whether the resource
                           access violation action was inputted from a:
                             a. BTAM terminal
                             b. VTAM terminal
                             c. Automated Operator Program issuing IMS cmd(s)
                           The master terminal operator decides what action to take.
                        2. The terminal user that caused the security violation
                           receives a security violation message after each violation.
                           The message received by the terminal user depends on:
                             a. The type of session manager (VTAM/BTAM)
                             b. The type of terminal (static/ETO)
                             c. Whether the user performed sign-on, and
                             d. Whether the violation was a terminal security violation
                                or a password security violation
                           Among the messages that terminal users can receive are:
                             a. DFS2467 - and Reason Code
                             b. DFS3649 - and Reason Code
                             c. DFS3662W - and Reason Code
                           If an AO program caused the security violation, a CD
                           status code is returned to the application program after
                           each violation. (Note that the CD status is received for AO
                           programs that have a security violation when issuing the
                           ICMD DL/I call. Programs that issue the AUTH, ISRT,
                           and/or CHNG calls receive an A4 status code on a security
                           violation.)


2.2.2.1 The SECCNT Keyword
When the SECCNT keyword has been specified with a parameter greater than 0
(SECCNT=1, or SECCNT=2, or SECCNT=3), the following should be noted:
 •   SECCNT>1 has no meaning for ETO terminals because ETO user control
     blocks are created and deleted dynamically; therefore, a count cannot be
     maintained.
 •   SECCNT keyword cannot be overridden in the IMS startup parameters nor on
     /NRE.
 •   When SECCNT=1, SECCNT=2, or SECCNT=3 is specified, the DFS286I
     message is sent to the master terminal. The text of the message depends
     on where the input (that caused the security violation) came from. One of
     the following DFS286I messages is sent:
     DFS286I SECURITY VIOLATION LINE x PTERM y (BTAM terminals)

     DFS286I SECURITY VIOLATION NODE nodename USER username (VTAM terminals)
          (USER username is provided for signed-on users via /SIGN)

     DFS286I SECURITY VIOLATION USERID userid PROGRAM programname
          (Issued for Automated Operator Programs)

The last DFS286I message above (referring to USERID and PROGRAM) is issued
for automated operator programs that use the DL/I ICMD call to issue IMS
commands. The message indicates that the program is not authorized to issue


                                                 Chapter 2. Implementing IMS Security   31
                         the IMS command. For ICMD call security violations, the user ID depends on
                         several things:
                             •       The type of region in which the program was executing
                             •       Whether a Get Unique (GU) call was issued
                             •       And for BMPs, whether the USER= parameter has been specified in the JCL
                                     used to start the BMP

                         Table 4 below shows the value of the user ID in the DFS286I violations message
                         for the various IMS dependent region types.

                             Table 4. DL/I ICMD Security Violation DFS286I Message USERID User ID Value
                             REGION           GU         USERID
                             TYPE             DONE
                             BMP              N/A        BMP′s JCL USER= parameter specification. See Note
                                                         below.
                             DBC              N/A        Security token passed in the Participant Adapter Parameter
                                                         List (PAPL) for DBCTL systems
                             IFP              NO         Program name
                             IFP              YES        User ID (if terminal is signed on) or LTERM name where
                                                         the transaction was issued (if terminal is not signed on).
                             MPP              NO         Program name.
                             MPP              YES        User ID (if terminal is signed on) or LTERM name where the
                                                         transaction was issued (if terminal is not signed on).
                             BMP              NO         BMP′s JCL USER= parameter specification. See Note
                                                         below.
                             BMP              YES        User ID (if terminal is signed on) or LTERM name where the
                                                         transaction was issued (if terminal is not signed on).
                             Note: If the USER= parameter does not contain a user ID, RACF uses user ID *
                             when no other user ID is available.


                         2.2.2.2 COMM Macro PASSWD= Parameter
                         The COMM macro is used to specify IMS security specifications. The parameter
                         specifications determine whether the following types of security checking will be
                         performed:
                             •       Password resource security checking. (OPTIONS= keyword)
                             •       Terminal security checking. (OPTIONS= keyword)
                             •       VTAM password security checking for the IMS VTAM ACB. (PASSWD=
                                     keyword)
                             •       Master terminal security violation notification messages. (SECCNT=
                                     keyword)

                                      Note
                             Refer to Table 2 on page 25. There are two types of password security:
                                 •    SMU password security checking (specified by NOPSWD, PASSWD, or
                                      FORPSW), and
                                 •    Another PASSWD=(pswrd1,pswrd2,pswrd3) specification for password to
                                      the IMS VTAM Application Control Block (ACB)



32   IMS V6 Security Guide
The first type of password security checking may be specified if resources, such
as commands, have been password protected. Whether the second type of
password security (for the IMS VTAM ACB) is required depends on how VTAM
was generated, which is described below.

The parameters affecting security that may be specified on the COMM macro are
shown below. The defaults for OPTIONS= are NOPSWD,NOTERMNL.
     OPTIONS=(NOPSWD,NOTERMNL),PASSWD=(pswrd1,pswrd2,pswrd3),SECCNT=0
              PASSWD TERMINAL
              FORPSW FORCTERM

The only security parameter above that could not be specified on the SECURITY
or IMSGEN macro is the PASSWD=(pswrd1,pswrd2,pswrd3) parameter.
Otherwise, the COMM macro security parameter settings have the same
meanings/results as the other macros.

The additional password keyword ,PASSWD=(pswrd1,pswrd2,pswrd3),
designates the following:
 •    When neither XRF nor RSR is used, one password (pswrd1) may (or may not)
      be specified in the VTAM ACB, depending on VTAM specifications for
      whether a password is required. This password is checked by VTAM. If no
      pswrd1 is specified, and VTAM requires pswrd1 (by virtue of the VTAM
      system generation), the IMS VTAM ACB will not be initialized.
 •    For XRF, the installation should specify two VTAM passwords
      (pswrd1,pswrd2) corresponding to the two XRF systems. If only pswrd1 is
      specified (but pswrd2 is not specified), then pswrd1 is also used as the
      password for both XRF systems.
 •    For RSR without XRF, the installation should specify at least two VTAM
      passwords (pswrd1,pswrd2). If pswrd3 is specified, it can be used only by
      the RSR tracker.
 •    For RSR with XRF, the installation will use all three VTAM passwords:
       −   pswrd1 for the active IMS (for both XRF and RSR)
       −   pswrd2 for the XRF alternate (at the RSR active site)
       −   pswrd3 for the RSR tracker

In all cases, pswrd3 can be used only for the RSR tracker. In the RSR with XRF
environment, if the installation specifies pswrd1 (but does not specify pswrd2 nor
pswrd3), pswrd1 is also used as pswrd2 and pswrd3. If only pswrd1 and pswrd2
are specified, pswrd1 is used for the RSR tracker.

In summary, the COMM macro is compatible with the IMSGEN macro with the
exception of the VTAM PASSWD= keyword. If both the COMM and IMSGEN
macros are present in system definition macros, the specifications and/or
defaults of the COMM macro override those of the IMSGEN macro.

As you have seen, unlike the COMM and IMSGEN macros, the SECURITY macro
is not limited to IMS SMU-provided security specifications. The SECURITY macro
also allows the installation to specify RACF and/or IMS security exits for
protecting IMS resources. And, as previously mentioned, the SECURITY macro:
 •    Specifications and/or defaults take precedence over COMM and IMSGEN
      security specifications.



                                                 Chapter 2. Implementing IMS Security   33
                             •   Provides keywords that maintain compatibility for IMS SMU security
                                 specifications that were used on the COMM and IMSGEN macros.

                         2.2.2.3 Keywords and Parameters Unique to the SECURITY Macro
                         Let us examine the meaning of the keywords that may be specified only on the
                         SECURITY macro. That is, these keywords could not be used and have no
                         equivalent settings on the COMM or IMSGEN macros.

                         2.2.2.4 RCLASS Keyword
                         RCLASS is a one to seven alphanumeric RACF resource class identifier
                         (class-id) used to specify which RACF class names are associated with resource
                         classes for a specific IMS control region. Think of the RCLASS value as a way to
                         identify which RACF resource classes belong to a specific IMS control region.
                         Remember, installations may run multiple IMS control regions on one MVS
                         system. Here are some examples of how the RCLASS value is used:

                         Support the Stage 1 SYSDEF macros contained in a SECURITY macro with
                         RCLASS=ABC specified for an IMS system having an IMSID=IMS1.
                         RCLASS=ABC for IMS1 would result in the RACF resource class names shown
                         in Table 5.



                             Table 5. RACF Class Names of R C L A S S = A B C for IMS System
                                  AABC        RACF AGN Class for IMS1
                                  CABC        RACF Command Class for IMS1
                                  DABC        RACF Command Grouping Class for IMS1
                                  TABC        RACF Transaction Class for IMS1
                                  GABC        RACF Transaction Grouping Class for IMS1
                                  PABC        RACF Database Class for IMS1
                                  QABC        RACF Database Grouping Class for IMS1
                                  SABC        RACF Segment Class for IMS1
                                  UABC        RACF Segment Grouping Class for IMS1
                                  FABC        RACF Field Class for IMS1
                                  HABC        RACF Field Grouping Class for IMS1
                                  OABC        RACF Other Class for IMS1
                                  WABC        RACF Other Grouping Class for IMS1


                         A second IMS, generated with an IMSID=IMS2 and RCLASSS=XYZ, would
                         result in RACF resource class names as follows:

                             Table 6 (Page 1 of 2). RACF Class Names of R C L A S S = X Y Z for IMS System
                                  AXYZ        RACF AGN Class for IMS2
                                  CXYZ        RACF Command Class for IMS2
                                  DXYZ        RACF Command Grouping Class for IMS2
                                  TXYZ        RACF Transaction Class for IMS2
                                  GXYZ        RACF Transaction Grouping Class for IMS2
                                  PXYZ        RACF Database Class for IMS2
                                  QXYZ        RACF Database Grouping Class for IMS2



34   IMS V6 Security Guide
 Table 6 (Page 2 of 2). RACF Class Names of R C L A S S = X Y Z for IMS System
      SXYZ         RACF DB Segment Class for IMS2
      UXYZ         RACF Segment Grouping Class for IMS2
      FXYZ         RACF Field Class for IMS2
      HXYZ         RACF Field Grouping Class for IMS2
      OXYZ         RACF Other Class for IMS2
      WXYZ         RACF Other Grouping Class for IMS2


As you may have noticed, the RACF class name is derived by appending one
character in front of the RCLASS value specified on the SECURITY macro. The
RCLASS value for each IMS system does not have to be unique; however there
is an advantage to assigning each IMS system a unique value. If the value is
unique, the same transaction names may be used on a production system and a
test system with different access lists for each subsystem, with no ambiguity.
The default value for the RCLASS keyword of the SECURITY macro is IMS; and
RACF is delivered with 13 default RACF class names for IMS (AIMS, CIMS,
DIMS, TIMS, GIMS, PIMS, QIMS, SIMS, UIMS, FIMS, HIMS, OIMS, and WIMS). If
the installation chooses to use different RACF class names from the default class
names for IMS, then the installation must perform the following activities:
 •   The new classes must be added to the RACF Class Descriptor Table
     (ICHRRCDE). For example, specifying RCLASS=XYZ on the SECURITY
     macro would require classes CXYZ, DXYZ, TXYZ, GXYZ, and other RACF
     classes, to be added to the RACF Class Descriptor Table. Class are added
     to the Class Descriptor Table with the RACF ICHERCDE macro.
     The new classes should be modeled according to the IMS default classes.
 •   The RACF Router Table (ICHRFR01) must be updated with the new classes.
     Classes are added to the Router Table with RACF macro ICHRFRTB.
     Note: The default class names like AIMS, CIMS, etc. are in the default
     Router Table, ICHRFR00.
 •   The new classes (for example, CXYZ, TXYZ, and other classes) must be
     activated with the RACF SETROPTS command.

In addition to the 13 default classes referenced above (AIMS, CIMS, DIMS, TIMS,
GIMS, etc.), RACF also provides the following classes that can be used by IMS:
 •   APPL class for IMS APPLID
 •   APPC/MVS uses APPCTP class for TP profiles
 •   OTMA uses FACILITY class for XCF profiles
 •   DATASET class for IMS data sets
 •   TERMINAL class for nodes

2.2.2.5 RCLASS Value and IMS Initialization
The RCLASS value determines which security profiles are used during IMS
initialization. When the IMS control region is initialized, IMS issues a
RACROUTE REQUEST=LIST, GLOBAL=NO to copy all the resources security
profiles in the specified class (for example, DXYZ, TXYZ, and RACF Other
classes used by IMS) into IMS system storage.




                                                Chapter 2. Implementing IMS Security   35
                                   Note
                             If the RACF data space option is in use, the resource security profiles are
                             loaded into a data space rather than into IMS system storage. Use of the
                             RACF data space for security profiles requires IMS V6 or a later release.


                         Using the previous example of RCLASS=XYZ for IMS2, during IMS control
                         region initialization, the RACF security profiles for IMS commands (CXYZ and
                         DXYZ) and IMS transactions (TXYZ and GXYZ) are copied into IMS system
                         storage. When IMS receives a request for an IMS resource, IMS issues:
                                 RACROUTE REQUEST=FASTAUTH,CLASS=TXYZ, ...

                         to check the user′s authority to the resource. REQUEST=FASTAUTH checks the
                         in-storage profiles for the resource class (TXYZ for the transaction class) to
                         determine the user′s authority to access a specific resource (such as the
                         PAYTRAN in the TXYZ transaction class). RACROUTE REQUEST=FASTAUTH
                         returns the status of the authorization to IMS as either:
                             •    Access allowed
                             •    Access not allowed, or
                             •    Profile not found
                         IMS treats ″profile not found″ as an unprotected resource, thus allowing access
                         by default. The Class Descriptor Table can be changed to indicate that a ″profile
                         not found″ condition results in access not allowed.

                         The RCLASS specification is valid only if the installation requests RACF for
                         authorizing IMS resources (such as sign-on user ID verification, transaction
                         authorization, and application group names, and other types of protection).
                         RACF is requested by coding TYPE=RACFTERM and/or TYPE=RACFAGN.
                         RACFTERM indicates that RACF will be used to process /SIGN ON and/or
                         perform transaction authorization security checking). RACFAGN indicates that
                         RACF will be used to check the user′s access authority for an application group
                         name (AGN).

                         When IMS V6 is used, things work the same as described above, provided that
                         RACF has been initialized using the RACF database residing on a direct access
                         storage device (DASD). If IMS V6 is used and RACF has been initialized using
                         the RACF data space (instead of DASD); then the
                                 RACROUTE REQUEST=FASTAUTH,CLASS=xxxx ...

                         uses the RACF data space instead of IMS system storage.

                         Here are a couple of important things to remember when using RACF as the
                         security manager in an IMS environment:
                             •    If RACF security profiles are accessed from DASD (meaning that the RACF
                                  data space option is not being used), an IMS online change must be done to
                                  refresh the in-storage profiles. This means that IMS /MODIFY (/MOD)
                                  commands must be issued to make the change take effect. For example,
                                  suppose that new security profiles were added for certain transactions in the
                                  TIMS class. Also suppose the RACF security administrator issued the
                                  appropriate RDEFINE and PERMIT commands to add the new transaction
                                  profiles. In order for the RACF security changes to take effect for IMS


36   IMS V6 Security Guide
     transaction resources, the following IMS commands must also be issued
     after the RACF refresh:
       /MOD PREPARE RACF.
       /MOD COMMIT.

     If these commands are not issued, the security profile changes made to the
     RACF database will not be used until IMS is reinitialized. Therefore, if
     security profile changes are made to RACF when the database option is in
     effect, make sure to issue the /MOD commands to perform the online change
     for IMS. The online change causes IMS to refresh it′s in-storage security
     information for IMS resources such as transactions and commands.
 •   If RACF security profiles are accessed from a RACF data space, a slightly
     different process is performed to implement the security changes for IMS
     resources. As previously mentioned, IMS V6 and later releases support use
     of the RACF data space. As in the example above, the appropriate RACF
     commands (RDEFINE and PERMIT) would be issued to add new security
     profiles for transactions in the TIMS class. However, when the RACF data
     space is in use, the /MOD commands (used to perform an IMS online
     security change) are not required and should not be used. Instead, after
     changing the RACF security profiles, issue a RACF SETROPTS command
     with RACLIST to refresh the profiles in the RACF data space. A sample is as
     follows:
       SETR RACLIST(TIMS) REFRESH


     Note: RACF commands can be abbreviated. The short form of the
     SETROPTS command is SETR.
     IMS will receive the security changes as soon as RACF refreshes the profiles
     in its data space. Using the RACF data space option with IMS V6 eliminates
     the need to perform online changes in IMS.

So remember, IMS V5 or IMS V6 will have to use online change (/MOD) to
refresh security profiles if the RACF data space is NOT used with IMS. If IMS V6
(and later releases) and the RACF data space option are used together, then
online change is not necessary and will not work. Use of the RACF command
(SETROPTS RACLIST) to change security profiles is required.

2.2.2.6 SECLVL Keyword
We have seen from the settings of some keywords on the SECURITY, COMM,
and IMSGEN macros that the IMS MTO has the ability to override security that
was generated (SYSGENned) without the use of the FORCE parameter. The
SECLVL keyword parameter settings on the SECURITY macro provides a similar
function for determining whether IMS sign-on verification and/or transaction
authorization processing is to be used and whether these security options may
be overridden at IMS startup. Thus, two major functions of the SECLVL keyword
are to:
 1. Determine the type of protection that is desired (such as sign-on and/or
    transaction authorization security checking)

     Note that to perform sign-on security checking for IMS, and optionally, RACF
     transaction authorization, the other keyword parameter setting that is
     needed to cause RACF to be invoked is TYPE=RACFTERM.



                                              Chapter 2. Implementing IMS Security   37
                             2. Provide parameter specifications that determine whether the master terminal
                                operator (when restarting the IMS system via /NRE or /ERE command) will
                                be able to override sign-on verification processing (issuing the /SIGN ON)
                                and/or transaction authorization processing
                               Note that when the sign-on verification FORCE option is specified, sign-on
                               verification cannot be overridden by a parameter specification on the /NRE
                               or /ERE commands, but sign-on verification can be overridden in the startup
                               parameters used for starting IMS (IMS.PROCLIB member DFSPBxxx,
                               SGN=N parameter). The startup member, DFSPBxxx, will be discussed
                               again later.

                         The SECLVL keyword specifications allow the installation to choose from the
                         following options for sign-on and transaction authorization, respectively:


                         NOSIGN       SIGNON         FORCSIGN
                         NOTRAN       TRANAUTH       FORCTRAN


                         Certain combinations of the sign-on keywords above and transaction
                         authorization keywords make sense, other combinations are not logical and will
                         not work. What is logical or illogical depends on the installation′s environment
                         (such as what is used to provide security - SMU or RACF). For example,
                         suppose the installation had decided that RACF will be used to provide
                         transaction autorization (using security profiles in the TIMS/GIMS classes).
                         RACF used the user ID to verify authority to execute the transaction. If
                         transaction authorization will be forced (FORCTRAN), then it would not be logical
                         to specify SECLVL = NOSIGN,FORCTRAN on the SECURITY macro. The reason
                         for this is that sign-on (either SIGNON or FORCSIGN) is used to supply the user
                         ID. The user ID supplied at sign-on will be used by RACF to verify authorization
                         to execute the transaction.

                         To ensure that a valid combination of sign-on and transaction authorization is
                         supplied on the SECURITY macro, follow this simple rule: first, select the level of
                         transaction authorization, then make sure the sign-on level is at least as great as
                         that of transaction authorization. The valid combinations are listed below with
                         the default in bold type.

                             Transaction   Default     Invalid

                             Parameter     Sign-on      Specification

                             NOTRAN        NOSIGN

                             NOTRAN        SIGNON

                             NOTRAN        FORCSIGN

                             TRANAUTH       SIGNON (NOSIGN is invalid with this combination

                             TRANAUTH       FORCSIGN

                             FORCTRAN       FORCSIGN (NOSIGN and SIGNON are invalid with
                                                   this combination)




38   IMS V6 Security Guide
Note that SIGNON will also be forced (SGN=F) on by IMS if TYPE=RACFCOM is
specified or ETO support is active. ETO terminals are always required to sign
on.

Now that the valid combinations have been covered, let us look at the meanings
of the parameter settings for the SECLVL keyword in Table 7.

 Table 7 (Page 1 of 2). SECLVL K e y w o r d of SECURITY Macro Summary
 Macro       Parameter               Meaning(s)/Results
             Specification
 SECURITY    SECLVL=                   •   Transaction authorization is not performed
             NOTRAN,NOSIGN                 by the IMS online system, regardless of
                                           whether security checking (for other
                                           resources, such as commands) is
                                           performed by SMU, RACF, and/or security
                                           exits.
                                       •   Sign-on is not required for static terminals.
                                       •   The MTO can issue commands to override
                                           both specifications on /NRE CHKPT 0 and
                                           /ERE COLDSYS if FORCE has not been
                                           specified.
 SECURITY    SECLVL=                   •   Transaction authorization is not performed
             NOTRAN,SIGNON                 by the IMS online system, regardless of
                                           whether security checking is performed by
                                           SMU, RACF, and/or security exits.
                                       •   Sign-on may be required for static
                                           terminals.
                                       •   The MTO can issue commands to override
                                           both specifications on /NRE CHKPT 0 and
                                           /ERE COLDSYS if FORCE has not been
                                           specified.
 SECURITY    SECLVL=                   •   Transaction authorization is not performed
             NOTRAN,FORCSIGN               by the IMS online system, regardless of
                                           whether security checking is performed by
                                           SMU, RACF, and/or security exits.
                                       •   Sign-on may be required for static
                                           terminals.
                                       •   The MTO can issue commands to override
                                           the specification for transaction
                                           authorization when IMS is cold started
                                           using /NRE CHKPT 0 or /ERE COLDSYS;
                                           but the MTO cannot override FORCED
                                           SIGNON.
 SECURITY    SECLVL=                   •   Transaction authorization is performed by
             TRANAUTH,SIGNON               the IMS online system; either by SMU,
                                           RACF, and/or security exits.
                                       •   Sign-on may be required for static
                                           terminals.
                                       •   The MTO can issue commands to override
                                           both specifications when IMS is cold
                                           started using /NRE CHKPT 0 or /ERE
                                           COLDSYS commands.




                                                 Chapter 2. Implementing IMS Security   39
                             Table 7 (Page 2 of 2). SECLVL K e y w o r d of SECURITY Macro Summary
                             Macro       Parameter               Meaning(s)/Results
                                         Specification
                             SECURITY    SECLVL=                   •   Transaction authorization is performed by
                                         TRANAUTH,FORCSIGN             the IMS online system, regardless of
                                                                       whether security checking is performed by
                                                                       SMU, RACF, and/or security exits.
                                                                   •   Sign-on may be required for static
                                                                       terminals.
                                                                   •   The MTO can issue commands to override
                                                                       the specification for transaction
                                                                       authorization when IMS cold started using
                                                                       /NRE CHKPT 0 or /ERE COLDSYS
                                                                       commands; but the MTO cannot override
                                                                       FORCED SIGNON.
                             SECURITY    SECLVL=                   •   Transaction authorization is performed
                                         FORCTRAN,FORCSIGN             and FORCED by the IMS online system,
                                                                       regardless of whether security checking is
                                                                       performed by SMU, RACF, and/or security
                                                                       exits.
                                                                   •   Sign-on may be required for static
                                                                       terminals.
                                                                   •   The MTO cannot issue commands to
                                                                       override the specification for transaction
                                                                       authorization or sign-on when IMS
                                                                       restarted.


                         2.2.2.7 TRANCMD Keyword
                         The TRANCMD keyword and parameter setting is used to specify whether AO
                         programs may issue the DL/I CMD call for issuing IMS commands. If the
                         keyword parameter is set to allow the issuing of commands from AO programs,
                         then SMU is used to do the security checking. Table 8 provides the meanings of
                         the specifications for the TRANCMD keyword.

                             Table 8 (Page 1 of 2). TRANCMD K e y w o r d of SECURITY Macro Summary
                             Macro       Parameter               Meaning(s)/Results
                                         Specification
                             SECURITY    TRANCMD=NO                •   Programs that use the DL/I CMD call to
                                                                       issue IMS commands will be allowed to
                                                                       issue the command(s) without SMU
                                                                       performing a security check.
                                                                   •   IMS.MATRIX transaction command security
                                                                       tables will not be loaded during IMS
                                                                       restart.
                                                                   •   The MTO can issue an IMS keyword
                                                                       (TRANCMDS) on the /NRE or /ERE restart
                                                                       commands to change TRANCMD security
                                                                       (or rather, turn on TRANCMD security,
                                                                       causing IMS.MATRIX to be loaded).




40   IMS V6 Security Guide
 Table 8 (Page 2 of 2). TRANCMD K e y w o r d of SECURITY Macro Summary
 Macro        Parameter               Meaning(s)/Results
              Specification
 SECURITY     TRANCMD=YES              •   Programs that use the DL/I CMD call to
                                           issue IMS commands will be checked by
                                           SMU to determine if they are
                                           allowed/authorized to issue the
                                           command(s).
                                       •   IMS.MATRIX transaction command security
                                           tables will be loaded during IMS restart.
                                       •   The MTO can issue an IMS keyword
                                           (NOTRANCMDS) on the /NRE or /ERE
                                           restart commands to change TRANCMD
                                           security (or rather, turn off TRANCMD
                                           security causing IMS.MATRIX not to be
                                           loaded).
 SECURITY     TRANCMD=FORCE            •   Programs that use the DL/I CMD call to
                                           issue IMS commands will be checked by
                                           SMU to determine if they are
                                           allowed/authorized to issue the
                                           command(s).
                                       •   IMS.MATRIX transaction command security
                                           tables must be loaded during IMS restart.
                                           User ABENDU0171 occurs if the load fails.
                                       •   The MTO cannot issue an IMS keyword
                                           that alters security on the /NRE CHKPT 0
                                           or /ERE COLDSYS restart command.


2.2.2.8 TYPE Keyword
The remaining parameters that may be coded on the SECURITY macro are
coded on the TYPE keyword. The TYPE keyword is used to specify whether:
 •   AGN security checking will be performed
 •   RACF will be called to perform sign-on user ID verification and/or transaction
     authorization
 •   DFSCTRN0 will be called to perform transaction authorization security
     checking
 •   The sign-on exit, DFSCSGN0, will be called by IMS to validate user IDs
 •   RACF will be called to perform authorization to execute a command

The TYPE keyword parameters are listed below with the defaults in bold type.
One parameter is selected (or defaulted to) from each row.


NOAGN      RACFAGN        AGNEXIT

NORACTRM RACFTERM

NOTRANEX TRANEXIT

NOSIGNEX SIGNEXIT

 NORACFCM RACFCOM

Table 9 on page 42 provides the meanings of the specifications for the TYPE=
keyword.


                                                Chapter 2. Implementing IMS Security   41
                             Table 9. TYPE K e y w o r d of SECURITY Macro Summary
                             Macro       Parameter                Meaning(s)/Results
                                         Specification
                             SECURITY    TYPE=NOAGN               AGN application resource access authorization
                                                                  will not be performed by IMS at execution
                                                                  time.
                             SECURITY    RACFAGN                  AGN application resource access authorization
                                                                  will be performed by IMS at execution time.
                                                                  RACF will be called to verify user IDs against
                                                                  AGN profiles in the AIMS class.
                             SECURITY    AGNEXIT                  AGN application resource access authorization
                                                                  will be performed by IMS at execution time.
                                                                  DFSISIS0 will be called to verify user IDs
                                                                  authority to access resources named in the
                                                                  AGNs.
                             SECURITY    TYPE=NORACTRM            RACF will not be used to perform transaction
                                                                  authorization and/or sign-on user ID
                                                                  verification. If transaction authorization will be
                                                                  implemented using SMU (by restricting
                                                                  transaction entry to one or more LTERMs),
                                                                  TRANAUTH or FORCTRAN and SIGNON or
                                                                  FORCSIGN has to be specified for SECLVL.
                             SECURITY    TYPE=RACFTERM            RACF will be used to perform both transaction
                                                                  authorization and sign-on user ID verification.
                                                                  RACFTERM requires that transaction
                                                                  authorization (TRANAUTH or FORCTRAN) and
                                                                  sign-on (SIGNON or FORCSIGN) are active.
                             SECURITY    TYPE=NOTRANEX            DFSCTRN0 will not be used to perform
                                                                  transaction authorization at IMS execution
                                                                  time. If SMU is used to perform transaction
                                                                  authorization by restricting transaction entry to
                                                                  specific LTERMs, TRANAUTH or FORCTRAN
                                                                  has to be active (specified for SECLVL).
                             SECURITY    TYPE=TRANEXIT            DFSCTRN0 will be used to perform transaction
                                                                  authorization at IMS execution time. In order
                                                                  for DFSCTRN0 to perform transaction
                                                                  authorization, either TRANAUTH or FORCTRAN
                                                                  must be active. If TRANEXIT and RACFTERM
                                                                  have both been specified on the TYPE
                                                                  keyword, RACF is called first.
                             SECURITY    TYPE=NOSIGNEX            DFSCSGN0 will not be used to validate a user
                                                                  ID. If RACF is used to validate a user ID,
                                                                  either SIGNON or FORCSIGN has to be active
                                                                  (specified on SECLVL).
                             SECURITY    TYPE=SIGNEXIT            DFSCSGN0 will be used by IMS to validate a
                                                                  user ID. Either SIGNON or FORCSIGN has to
                                                                  be active. If both SIGNEXIT and RACFTERM
                                                                  are specified on the TYPE keyword, RACF is
                                                                  called first.
                             SECURITY    TYPE=NORACFCM            RACF Command authorization security
                                                                  checking is not required for ETO terminals.
                             SECURITY    TYPE=RACFCOM               •   Command authorization will be performed
                                                                        for commands entered from ETO terminals.
                                                                    •   RACF will be called to perform the
                                                                        authorization checking for commands
                                                                        entered from ETO terminals.



42   IMS V6 Security Guide
                This concludes the topics relating to:
                 •   IMS resources that can be protected
                 •   The security facilities used to protect them (SMU, RACF, or security exits, or
                     a combination of these facilities)
                 •   The types of protection implemented when specific keywords and
                     parameters are chosen

                What happens in any installation after the security choices have been
                implemented? The answer is: something changes, which results in the
                installation requesting a change to the security environment. The next topics in
                this chapter cover ways to handle security changes.



2.3 Overriding Security Specifications Made during SYSDEF
                Imagine what would happen if every time an installation needed to make security
                changes to the environment IMS had to be taken down and regenerated
                (SYSGENed). Fortunately, most (but not all) security changes to the IMS
                environment can be effected without a SYSGEN.

                There are two ways to override security options that were selected during
                SYSDEF:
                 •   Supplying IMS with startup parameters that change the security environment
                 •   Providing the MTO with the option of issuing keywords on the /NRE CHKPT 0
                     and /ERE COLDSYS commands. The keywords entered with these
                     commands can change the security environment.


2.3.1 Supplying IMS Startup Parameters That Change Security
                The IMS startup parameters affecting the security environment are well
                documented in the IMS/ESA Administration Guide: System , SC26-8730, in the
                chapter called ″Establishing IMS Security″. The parameters are briefly reviewed
                here for your convenience.

                The IMS.PROCLIB member DFSPBxxx contains the IMS execution parameters.
                The parameters that may be used to affect security are listed below, with
                defaults highlighted in bold text. Some of the parameters change SYSDEF
                security specifications; other parameters are new execution parameters that do
                not affect SYSDEF security specifications.
                 •   The first five parameters (AOIS, APPCSE, CMDMCS, RCFTCB, and RVFY)
                     below do not override any SECURITY macro specification:
                     −   AOIS — DL/I ICMD Call Security Option:
                         AOIS=N          The DL/I ICMD call cannot be issued by a program.
                         AOIS=S          No authorization checking is done.
                         AOIS=R          Call RACF for command authorization.
                         AOIS=C          Call DFSCCMD0 for command authorization.
                         AOIS=A          Call RACF first for command authorization. Then call
                                         DFSCCMD0.
                     −   APPCSE — APPC Security Option




                                                               Chapter 2. Implementing IMS Security   43
                                     APPCSE=F       Call RACF for authorization for commands, transaction,
                                                    and additional security for dependent regions (such as
                                                    CHNG calls).
                                     APPCSE=C       Call RACF for command and transaction authorization.
                                     APPCSE=P       Check the APPC Transaction Profile (TP Profile) to see if
                                                    FULL, CHECK, or NONE has been specified for
                                                    authorization checking.
                                                    (The use of PROFILE parameter requires
                                                    PQ04181/UQ05671.)
                                     APPCSE=N       Call DFSCTRN0 for transaction authorization and call
                                                    DFSCCMD0 for command authorization, if they exist in
                                                    IMS.RESLIB.
                                 −   CMDMCS — MCS/EMCS Command Option
                                     CMDMCS=N       IMS commands cannot be entered from an MCS
                                                    console. N, or no, is not a valid specification for DB
                                                    Control (DBCTL) systems.
                                     CMDMCS=Y       IMS commands can be entered from MCS/EMCS
                                                    consoles by entering the command recognition character
                                                    (CRC) followed by the command text. Y, or yes, is not a
                                                    valid specification for DB Control (DBCTL) systems.
                                     CMDMCS=R       IMS commands can be entered from MCS/EMCS
                                                    consoles by entering the command recognition character
                                                    (CRC) followed by the command text. Call RACF to
                                                    determine if the MVS console user ID is authorized to
                                                    issue the command.
                                     CMDMCS=C       IMS commands can be entered from MCS/EMCS
                                                    consoles by entering the command recognition character
                                                    (CRC) followed by the command text. Call DFSCCMD0
                                                    to determine if the MVS console user ID is authorized to
                                                    issue the command.
                                     CMDMCS=B       IMS commands can be entered from MCS/EMCS
                                                    consoles by entering the command recognition character
                                                    (CRC) followed by the command text. Call RACF first to
                                                    determine if the MVS console user ID is authorized to
                                                    issue the command. Then call DFSCCMD0.
                                 −   RCFTCB — Option to Specify Number of RACF Task Control Blocks
                                     (TCBs).
                                     RCFTCB=1       One IMS RACF TCB is used for sign-on/sign-off
                                                    processing.
                                     RCFTCB=x       X is the number of IMS RACF TCBs used for
                                                    sign-on/sign-off processing, and ranges from 1 through
                                                    20 (1-20).
                             •   RVFY — Reverify option that requires a password be re-entered with the
                                 transaction and/or command.
                                 RVFY=N      Password reverification is not activated in the IMS.
                                 RVFY=Y      Password reverification is activated in the IMS system. If
                                             password reverification is performed by RACF, the user is
                                             required to re-enter his/her RACF password (that was supplied


44   IMS V6 Security Guide
                 at sign-on) with command/transaction entry when the RACF
                 security profile for the command/transaction specifies
                 REVERIFY in the APPLDATA section of the
                 command/transaction security profile.
•   ISIS — AGN Resource Access Security Option.
    This parameter is used to override TYPE=NOAGN/RACFAGN/AGNEXIT on
    the SECURITY macro.
    ISIS=0       AGN security checking will not be performed.
    ISIS=1       SMU and RACF will perform AGN security checking.
    ISIS=2       SMU and DFSISIS0 will perform AGN security checking.
    Note: There is no default for the ISIS parameter. The ISIS parameter may
    be assigned a value (0, 1, or 2) in the DFSPBxxx execution member. The
    ISIS parameter cannot be changed by the restart command.
•   RCF — Option to Specify RACF for transaction authorization, command
    authorization and/or sign-on.
    This parameter is used to override
    TYPE=NORACTRM/RACFTRM/NORACFCM/RACFCOM on the SECURITY
    macro.
    RCF=N        RACF will not be called for sign-on, transaction, or command
                 authorization.
    RCF=S        RACF will be called for command authorization for commands
                 entered for both static/ETO terminals.
    RCF=T        RACF will be called for sign-on and transaction authorization.
    RCF=C        RACF will be called for command authorization for commands
                 entered from ETO terminals.
    RCF=Y        RACF will be called for sign-on, transaction authorization, and
                 commands entered from ETO terminals.
    RCF=A        Includes T, C, and S.
    Note: If the RCF parameter is not included in DFSPBxxx execution
    parameters, the default is the value specified at system definition.
•   SGN — Option to load IMS control storage with sign-on security tables from
    IMS.MATRIXA or IMS.MATRIXB and activate the sign-on function. This
    option also controls the use of a single user ID for multiple sign-ons.
    This parameter is used to override TYPE=NOSIGN/SIGNON/FORCSIGN on
    the SECURITY macro.
    SGN=N        Sign-on tables are not loaded from IMS.MATRIXA or
                 IMS.MATRIXB unless overridden by the MTO.
    SGN=Y        Sign-on tables are loaded from IMS.MATRIXA or IMS.MATRIXB
                 unless overridden by the MTO.
    SGN=F        Sign-on tables are loaded from IMS.MATRIXA or IMS.MATRIXB
                 and cannot be overridden by the MTO.
    SGN=M        A single user ID can sign on to multiple static/ETO terminals
                 (multiple sign-on capability).
    SGN=Z        Sign-on tables are loaded from IMS.MATRIXA or IMS.MATRIXB
                 unless overridden by the MTO. Multiple sign-ons are allowed
                 for a single user ID.



                                              Chapter 2. Implementing IMS Security   45
                                 SGN=G       Sign-on tables are loaded from IMS.MATRIXA or IMS.MATRIXB
                                             and cannot be overridden by the MTO. Multiple sign-ons are
                                             allowed for a single user ID.
                             •   TRN — Transaction Authorization Checking
                                 This parameter is used to override TYPE=NOTRAN/TRANAUTH and
                                 FORCSIGN on the SECURITY macro.
                                 TRN=N       Transaction Authorization Checking is not performed unless
                                             overridden by the MTO on the /NRE command
                                 TRN=Y       Transaction Authorization Checking is performed unless
                                             overridden by the MTO on the /NRE command
                                 TRN=F       Transaction Authorization Checking is performed and cannot be
                                             overridden by the MTO

                         The second method for overriding security is by allowing the MTO to change the
                         security (that was in effect during the last execution of IMS) when IMS is
                         restarted (normally or by emergency).


2.3.2 Overriding Security Choices on /NRE and/or /ERE Commands
                         There are two types of commands that may be issued to change the IMS security
                         environment:
                             •   Keywords that may be added to the /NRE CHKPT 0 and/or /ERE COLDSYS
                                 restart commands that are issued by the MTO.
                             •   A /SECURE command that may be issued by the MTO. The /SECURE
                                 command is a separate, distinct IMS command. As such, it is not a keyword
                                 on the /NRE or /ERE command. This command is used to specify or change
                                 the security for transaction and/or commands entered from APPC or OTMA
                                 environments.

                         Table 10 lists the keywords (that may be issued on the /NRE CHKPT 0 and /ERE
                         COLDSYS commands) and their meanings. A cold start is required to make the
                         security changes take effect when the changes are made by issuing the security
                         commands on the restart command. The COLDSYS keyword is required when
                         making security changes using the /ERE command.

                             Table 10. /NRE and /ERE Security Keywords and Meanings
                             Keywords                         Meanings
                             TERMINAL/NOTERMINAL              Activate/Deactivate SMU terminal security
                             PASSWORD/NOPASSWORD              Activate/Deactivate SMU password security
                             TRANCMDS/NOTRANCMDS              Activate/Deactivate SMU transaction command
                                                              (AO-CMD call) security
                             TRANAUTH/NOTRANAUTH              Activate/Deactivate transaction authorization
                                                              (RACF and/or SMU)
                             CMDAUTH/NOCMDAUTH                Set/Reset command authorization for ETO and
                                                              static terminals
                             CMDAUTHE/NOCMDAUTHE              Set command authorization for ETO terminals
                                                              only but reset command authorization for ETO
                                                              and static terminals
                             MULTSIGN/SNGLSIGN                Allow multiple/single sign-on per single user ID
                             USER/NOUSER                      Activate/Deactivate sign-on security



46   IMS V6 Security Guide
One additional table is required to fully understand specifying IMS security
options at startup. Table 11 on page 48 shows the restart command options that
affect security.




                                           Chapter 2. Implementing IMS Security   47
 Table 11 (Page 1 of 2). Security Options on the /NRESTART or /ERE COLDSYS Command
 System                      JCL       /NRE or
 Security      Macro         Exec      /ERE
 Macro         Options       Parame-   Command
 Name                        ters      Input         System Security Level after Restart
 SECLVL        =NOSIGN       SGN=N     USER          Sign-on is active.
                                       TRANAUTH      Sign-on and transaction authorization are active.
                                       CMDAUTH       Sign-on, static, and ETO command authorization
                                                     are active.
                                       CMDAUTHE      Sign-on and ETO command authorization are
                                                     active.
               =SIGNON       SGN=Y     NOUSER        Sign-on not active.

                             SGN=Z

                                 —————————— —————————— —————————— ——————————
               —————————— ——————————
               =TRANAUTH  TRN=Y  NOUSER     Sign-on and transaction authorization are not
                                            active.
                                 NOTRANAUTH Transaction authorization is not active. Sign-on is
                                            active.
                                 —————————— —————————— —————————— ——————————
               —————————— ——————————
               =NOTRAN    TRN=N  TRANAUTH   Sign-on and transaction authorization are active.

                                 —————————— —————————— —————————— ——————————
               —————————— ——————————
               =FORCTRAN  TRN=F             Sign-on and transaction authorization are
                                            enforced.
                                 —————————— —————————— —————————— ——————————
               —————————— ——————————
               =FORCSIGN  SGN=F             Sign-on is enforced.

                             SGN=G                   Sign-on is enforced. Multiple sign-ons per user.

 TYPE          =RACFCOM      RCF=C          Sign-on and command authorization for ETO are
                                       NOUSER
                                            not active.
                                 NOCMDAUTHE Command authorization (for ETO and static users)
                                            are not active.
                                 NOCMDAUTH  Command authorization (for ETO and static users)
                                            are not active.
                                 —————————— —————————— —————————— ——————————
                          ——————————
                          RCF=S  NOUSER     Sign-on and command authorization (for ETO and
                                            static users) are not active.
                                 NOCMDAUTHE Command authorization (for ETO and static users)
                                            are not active.
                                 NOCMDAUTH  Command authorization (for ETO and static users)
                                            are not active.
                                 CMDAUTHE   Command authorization for ETO users is active,
                                            and command authorization for static users is not
                                            active.
                                 —————————— —————————— —————————— ——————————
               —————————— ——————————
               =NORACFCM  RCF=N  CMDAUTHE   Sign-on and command authorization for ETO are
                                            active.
                                 CMDAUTH    Sign-on and command authorization for ETO and
                                            static users are active.
 TERMINAL      =NO               TERMINAL   Terminal security is active.

               =YES                    NOTERMINAL    Terminal security is not active.

               =FORCE                                Terminal security is enforced (NOTERMINAL
                                                     invalid).
 PASSWD        =NO                     PSWD          Password security is active.




48   IMS V6 Security Guide
Table 11 (Page 2 of 2). Security Options on the /NRESTART or /ERE COLDSYS Command
System                       JCL        /NRE or
Security   Macro             Exec       /ERE
Macro      Options           Parame-    Command
Name                         ters       Input         System Security Level after Restart
           =YES                         NOPSWD        Password security is not active.

           =FORCE                                     Password security is enforced (NOPASSWORD
                                                      invalid).
TRANCMD    =NO                          TRANCMDS      Transaction command security is active.

           =YES                         NOTRANCMDS    Transaction command security is not active.

           =FORCE                                     Transaction command security is enforced
                                                      (NOTRANCMDS invalid)


                     One thing that has not been covered so far is how to change the security
                     environment in the APPC and/or OTMA environments. The MTO can change the
                     security environment for transaction and command input that has been received
                     from APPC (LU6.2 users) and/or OTMA users with the /SECURE command. The
                     format of the command is:
                       ──/SEC──┬─APPC─┬──┬─FULL────┬─────────────────────────────────────────────
                               └─OTMA─┘ ├─CHECK───┤
                                         ├─PROFILE─┤
                                         └─NONE────┘


                     The default for the /SECURE command is FULL , which causes the user′s ACEE to
                     be propagated to the dependent region. This may have an impact on
                     performance; so the installation should review use of the other three parameters
                     (CHECK, PROFILE, and NONE).

                     The /SEC APPC command overrides the default of FULL. The /SEC APPC
                     command also overrides the value of the APPCSE= startup parameter.
                     Table 12 lists the keywords (that may be issued) on the /SECure command and
                     their meanings.

                      Table 12. /SECURE Keywords and Their Meanings
                      Command          Keyword          Parameter and Meaning
                      /SEC             APPC or OTMA     FULL - Use RACF for transaction and command
                                                        authorization. Propagate ACEE to dependent
                                                        region.
                      /SEC             APPC or OTMA     CHECK - Use RACF for transaction and
                                                        command authorization. Do not propagate
                                                        ACEE to dependent region.
                      /SEC             APPC or OTMA     PROFILE - Use the TP profile (for APPC) or the
                                                        security data section of the message prefix (for
                                                        OTMA) to set the security level for each
                                                        transaction.
                      /SEC             APPC or OTMA     NONE - Call DFSCTRN0 for transaction and call
                                                        DFSCCMD0 for command authorization. Do not
                                                        call RACF.




                                                                   Chapter 2. Implementing IMS Security    49
2.4 Summary
                         This chapter covered the following subjects:
                             •   IMS Resource types that can be protected
                                 −   Terminals (static, ETO, and LTERMS). We learned that static terminals
                                     (both physical terminals and logical terminals) may be protected by SMU.
                                     Static terminals (physical terminals) may also be protected by RACF.
                                     RACF is the preferred facility in most installations. The default for ETO
                                     terminals is to perform sign-on, and security checking is performed by
                                     checking the user′s (user ID) authorization to the requested resource
                                     (such as a transaction or command). Authorization checking for input
                                     from ETO terminals is performed by RACF. SMU does not support
                                     authorization checking from ETO terminals.
                                 −   Commands. As with terminals, commands may be protected by SMU
                                     and/or RACF. If the level of command security provided by either SMU
                                     or RACF is insufficient to meet installation requirements, DFSCCMD0
                                     may be customized by the installation to meet their requirements. SMU
                                     is used to secure AO programs issuing the DL/I CMD call; whereas RACF
                                     is used to secure AO programs issuing the DL/I ICMD call. The RACF
                                     REVERIFY password security option is also supported for command
                                     authorization.
                                     Command authorization checking may be performed by more than one
                                     security facility: such as SMU and DFSCCMD0, or RACF and DFSCCMD0.
                                     When multiple security facilities are used SMU/RACF is called first and
                                     DFSCCMD0 is invoked second.
                                     A new IMS execution parameter (CMDMCS) is used to determine
                                     whether IMS commands may be issued from MVS consoles and if
                                     commands are allowed, whether RACF and/or DFSCCMD0 will be used
                                     to perform authorization security checking. This parameter is valid for
                                     DB/DC and DCCTL environments (not valid for DBCTL).
                                 −   Transactions. Transaction authorization may be performed by SMU
                                     and/or RACF. If additional security checking is needed the installation
                                     may customize DFSCTRN0 to meet its requirements. The RACF
                                     REVERIFY password security option is also supported for transaction
                                     authorization.
                                     Transaction authorization checking may be performed by more than one
                                     security facility, such as SMU and DFSCTRN0, or RACF and DFSCTRN0.
                                     When multiple security facilities are used SMU/RACF is called first and
                                     DFSCTRN0 is called after a successful return code from SMU/RACF.
                                 −   Databases. OSAM, VSAM, and Fast Path DEDB databases may be
                                     secured by RACF in the classes PIMS or QIMS. The same is true for
                                     database segments (SIMS/UIMS), database fields (FIMS/HIMS), and other
                                     user defined segments in the database (OIMS/WIMS). The above RACF
                                     classes are used to provide security for IMS databases. These RACF
                                     classes must be used in conjunction with the DL/I AUTH call.
                                      - PIMS/QIMS for securing database records
                                      - SIMS/UIMS for securing segment(s) within a database record
                                      - FIMS/HIMS for securing field(s) within a segment




50   IMS V6 Security Guide
         - OIMS/WIMS for securing other (user defined) information in a
           database record
        The AUTH call is issued by the application program and is used to
        provide application-based security. Optionally, IMS databases may be
        password protected using SMU and/or secured through the /LOCK DB
        command. If /LOCK and /UNLOCK are used to secure access to the
        database, caution should be taken to assign passwords to the commands
        in order to restrict their use.
        Another way to secure an IMS database is through specification of
        segment/field sensitivity when the PSBGEN is performed.
    −   Dependent regions and the online system. Dependent regions may be
        protected by restricting what can execute in the dependent regions.
        Specification of the AGN=xxxxxxxx parameter in the JCL or the
        procedure used to initialize the dependent region restricts the region to
        executing only one AGN group.
    −   PSBs and online application programs. AGN security is used to secure
        PSBs and online application programs. Including the PSB and/or
        transaction codes in an AGN group, performing a SMUGEN, and
        authorizing user IDs to the AGN in the RACF AIMS class (or providing
        authorization through DFSISIS0) are the ways protection is provided.
        PSBs scheduled as the result of an APSB call from a CPI-C driven
        program can be secured through use of the RACF AIMS class. For CPI-C
        programs, APSB SAF security overrides SMU AGN security. APSB SAF
        security also provides transaction authorization based on the user ID of
        the end user (rather than on PSB name).
    −   IMS control program/region. The IMS control program/region may be
        secured in RACF APPL class.
    −   IMS system data sets. IMS system data sets may be secured using the
        RACF DATASET class.
    −   Connections. The RACF class used to secure IMS resources from APPC,
        OTMA, CICS/DBCTL depends on the environment used. For example,
        APPC security profiles are in the RACF APPCTP class, whereas the IMS
        transactions used by APPC are secured in the RACF TIMS class.
        Chapter 8, “IMS Resources Accessed from Other Environments” on
        page 147 covers the security facilities and options available for these
        environments:
         -   APPC
         -   MSC
         -   OTMA and ITOC
         -   CICS/DBCTL
•   The security option (or type of protection) that is used for implementing
    security for each resource type is as follows:
    −   TERMINALS. Sign-on for physical terminals, and restricting that can be
        entered from a terminal using LTERM security.
    −   COMMANDS. Command authorization based on user ID (RACF and/or
        DFSCCMD0); Restrict commands to entry from specific LTERMs (SMU
        and/or DFSCCMD0); Assign passwords to commands (SMU or RACF).
        COMMANDS issued from AO programs. IMS uses SMU security to check
        authorization for commands issued by programs using the DL/I CMD call.


                                              Chapter 2. Implementing IMS Security   51
                                     The SMU input statements identify which AO transactions can issue
                                     specific IMS commands.
                                     IMS invokes RACF to perform command authorization for AO programs
                                     that issue IMS commands using the DL/I ICMD call. RACF verifies
                                     whether the user ID is authorized to issue the command. The user ID
                                     used to verify authorization depends on whether the user is signed on, a
                                     GU call was issued, and/or the type of region in which the program is
                                     running.
                                 −   TRANSACTIONS. Transaction authorization may be performed using the
                                     user ID supplied at sign-on (RACF and/or DFSCTRN0). Or, transaction
                                     authorization may be performed by restricting entry of the transaction to
                                     specific LTERMS (SMU and/or DFSCTRN0).
                                     If DFSCTRN0 is used, it is invoked after RACF/SMU.
                                     Transactions may also be secured using password protection. You
                                     should password-protect transactions by assigning a password to be
                                     provided upon transaction entry (RACF REVERIFY or SMU password
                                     security).
                                 −   DATABASE/SEGMENT/FIELD. Authorization to use database (and/or
                                     access segment/field) is checked based on user ID (RACF and/or AUTH
                                     call for additional security checking). Assign database a password
                                     (SMU). Segment-level and/or field-level sensitivity protection (PSBGEN
                                     protection option).
                                 −   DEPENDENT REGIONS/ONLINE SYSTEM. AGN resource access security
                                     (SMU and RACF; or SMU and DFSISIS0).
                                 −   PSB and ONLINE APPLICATION PROGRAMS. AGN resource access
                                     security (SMU and RACF, or SMU and DFSISIS0). APSB SAF security for
                                     CPI-C driven programs.
                                 −   IMS CONTROL PROGRAM/REGION. Authorization checking based on
                                     user ID (RACF APPL class).
                                 −   IMS SYSTEM DATA SETS. RACF DATASET class; or OS password
                                     protection facility.
                                 −   OTHER SYSTEMS. /SECURE command for command and transaction
                                     authorization based on the user ID of the submitting user, where input
                                     was received from APPC/OTMA client (SAF and RACF). AGN resource
                                     access security is used for CICS/DBCTL users (SMU and RACF) or (SMU
                                     and DFSISIS0). MSC environments can use either SMU, RACF,
                                     DFSCTRN0, and/or DFSCTSE0 for transaction authorization.
                             •   Specifying IMS security choices at SYSDEF
                                 −   The keywords and parameters on the SECURITY macro were covered.
                                     The PASSWD, TERMNL, and TRANCMD keywords define password,
                                     sign-on and transaction authorization, and AO program security
                                     requirements that will be enforced by SMU.
                                 −   The RCLASS keyword determines the RACF class names in the class
                                     descriptor table. The RACF class names (such as TIMS, CIMS, PIMS and
                                     so forth) will be used to define security profiles for transactions,
                                     commands, databases and other IMS resources.
                                 −   The SECCNT keyword applies to both RACF and SMU environments and
                                     is used to report security violations to the MVS console.



52   IMS V6 Security Guide
     −   Parameters on the SECLVL keyword apply to both RACF and SMU, and
         are used to determine whether transaction authorization and sign-on will
         be enforced.
     −   Parameters on the TYPE keyword specify whether the following will be
         performed:
          - AGN security checking
          - DFSCTRN0 transaction authorization checking
          - DFSCSGN0 sign-on authorization checking
         Specifications on the TYPE keyword also designate whether RACF will be
         used for sign-on and transaction authorization, and command
         authorization.
 •   How to override security specifications made on IMS macros during SYSDEF
     −   SYSDEF security specifications may be overridden using the IMS
         execution parameters provided in DFSPBxxx member of IMS.PROCLIB.
         DFSPBxxx supplies IMS with startup parameters during IMS initialization.
         Security specifications may also be changed by the MTO. The MTO can
         change security by adding keywords to the /NRE or /ERE COLDSYS
         commands when restarting IMS. Security options for APPC and OTMA
         users may be changed by issuing the /SECURE command.

Now that you have a basic understanding of the wide range of security options
available in IMS, we will look at security for each resource type independently in
the remaining chapters.




                                              Chapter 2. Implementing IMS Security   53
54   IMS V6 Security Guide
Chapter 3. Securing IMS Terminals

                         This chapter covers the following topics:
                             •   Securing IMS terminals
                                 −   Static terminals
                                 −   ETO terminals
                             •   Output message security for static and ETO terminals
                             •   Bypass security checking routine
                             •   Restricting command and transaction entry to specific LTERM(s)

                         There are several ways to implement security for IMS terminals. Requiring IMS
                         terminal users to log on and sign on are options to use in securing access from
                         terminals. Logging on to IMS establishes a session between the terminal and
                         IMS. Signing on to a terminal identifies a user to IMS. Forcing users to sign-on
                         (either by requiring a user ID and password on an IMS-generated sign-on
                         screen/message or by entering the /SIGn ON command) is a way of having the
                         user provide a user ID to IMS prior to gaining access to IMS resources.

                         The methods to secure access to IMS resources from terminals are:
                             •   Autosignoff and Autologoff (for ETO terminals)
                             •   Terminal-user security (for static and ETO terminals)
                             •   Sign-on verification security
                             •   Password security for /IAM, /LOCK, and /UNLOCK commands, and
                             •   Resource access security



3.1 Autosignoff and Autologoff for IMS Terminals
                         Autosignoff and autologoff may or may not be considered a mechanism for
                         providing security for the terminal. What these facilities provide are the ability to
                         sign off and/or log off terminals that are idle for a specified amount of time. One
                         of the most basic concepts involved in terminal security is to ensure that
                         unattended terminals that have been logged on and/or signed on do not present
                         a security exposure.

                         IMS provides two execution parameters for the installation to control the
                         exposure. Autosignoff and autologoff timeout facilities are supported for ETO
                         terminals and users. These facilities provide the following:
                             •   Autosignoff involves deallocating the user from an idle session. Users are
                                 automatically signed off if no activity occurs within an allotted time.
                                 Automatically signed-off users must sign on again to use the session. The
                                 installation determines the time value on the ASOT= execution parameter in
                                 DFSPBxxx member of IMS.PROCLIB.
                             •   Autologoff involves terminating a session with IMS for a terminal that has
                                 been signed off for an allotted period. After an allotted time the terminal is
                                 automatically logged off. The installation determines the time value on the
                                 ALOT= execution parameter in DFSPBxxx member of IMS.PROCLIB, or on
                                 the logon descriptor used to create the session control blocks.



© Copyright IBM Corp. 1999                                                                                    55
                         ASOT and ALOT are optional parameters. These parameters provide a minimal
                         level of security for IMS ETO terminals. The remaining topics in this chapter
                         provide additional facilities that may be used in conjunction with autosignoff and
                         autologoff.



3.2 Additional Security for Static and/or ETO Terminals
                         Additional facilities may be used to provide security for physical terminals.
                             •   Terminal-user security is a RACF facility wherein security profiles are
                                 created in TERMINAL or GTERMINL classes to restrict sign-on from specific
                                 static and/or ETO terminals to authorized users only. The TERMINAL and
                                 GTERMINL classes may also be used with RACF security labels. You can
                                 use security labels to associate a specific security level with a set of (zero or
                                 more) security categories. Security labels, when associated with resources,
                                 users, and jobs, provide the following advantages over security levels and
                                 security categories:
                                 −   Security labels can be assigned to data that is not necessarily protected
                                     by a resource profile. For example, spool files are assigned the security
                                     label of their creators. In many cases, data that has been assigned a
                                     security label retains that security label from the time the data is created
                                     until the data is deleted. For example, when a spool file is created by a
                                     user or job that is running under a security label, the spool file is
                                     assigned the security label of the user or job. The spool file retains that
                                     security label until the spool file itself is deleted (which can be long after
                                     the user logs off or the job ends).
                                 −   Users can log on with different security labels at different times but with
                                     the same user ID. Without security labels, a user always has the same
                                     (default) security level and categories.
                                 −   Output printed for a user or job by the Print Services Facility (PSF) can
                                     have a PSF identification label related to the security label of the user or
                                     job printed on every page.
                                 −   It is easier to maintain the security classification of users and data
                                     (changing the definition of a security label affects all users and resources
                                     that have that security label. You need not make the same change for
                                     many different profiles as you would for security levels and categories).
                             •   Sign-on verification security is the use of SYSDEF macros and RACF (or an
                                 installation provided sign-on exit) to identify a particular user to IMS.
                             •   Password security for IMS commands (/IAM, /LOCK, and /UNLOCK) is the
                                 use of SMU utility control statements to assign passwords to commands that
                                 may be used to alter, secure, or grant access to IMS resources. SMU
                                 security facilities are applicable to statically defined resources. To restrict
                                 the use of these commands in the ETO environment, either:
                                 −   REVERIFY can be specified in the APPLDATA section of the security
                                     profile(s) used to secure the commands, or
                                 −   The entry of these commands can be restricted to being entered only by
                                     authorized groups/user IDs.
                             •   Resource authorization security checking uses the concept of protecting
                                 transaction and/or command (rather than the terminal), and restricting the
                                 use of the protected transaction/command to authorized users.



56   IMS V6 Security Guide
                The method used to secure a terminal depends on whether the terminal is a
                physical terminal (static or ETO) or an LTERM.



3.3 Securing IMS Terminals
                One of the ways to access IMS resources is from terminals in the network. The
                terminals may have been previously defined to IMS in SYSDEF macros (such as
                TERMINAL macro statements); or the terminal may not have been previously
                defined. IMS terminals that have been defined to IMS in Stage 1 SYSDEF input
                macros (TERMINAL and optionally, TYPE macros) are known as static terminals.
                Terminals (accessing IMS) that have not been defined to IMS using TERMINAL
                macros in SYSDEF Stage 1 input are known as ETO terminals. Since the security
                options for each type of terminal depends, to some extent, on whether it is a
                static or ETO terminal; the security options for each will be presented separately.

                Regardless of whether an IMS terminal is statically defined or dynamically
                defined using ETO, some installations have implemented ″physical″ security for
                terminals that have high security requirements. That is, the terminals have been
                located in areas that are behind locked doors (or secured areas).

                Both SMU and RACF can secure a user′s access to a terminal. However, they
                implement the sign-on enforcement in different ways. SMU can be used to
                require all (or some) IMS terminal users to sign on, but it requires either RACF
                or the Sign On/Sign Off Security Exit Routine (DFSCSGN0) to verify that the user
                ID supplied during sign-on is a valid user ID. RACF can also require all
                terminals to perform sign-on when all the transactions and commands have
                RACF security profiles defined. RACF can also verify that the user ID supplied at
                sign-on is a valid user ID.

                Using the RACF approach (called terminal-user security) restricts the users to
                signing on to terminals that the user has been authorized to use. RACF′ s
                terminal-user security could be implemented in a fashion where only terminals
                that are restricted to use by specific user IDs/groups can be secured.
                Otherwise, all other terminals can be unrestricted and available for use by all.
                Terminal-user security supports both static and/or ETO terminals.


3.3.1 Terminal-User Security for Static and ETO Terminals
                Terminal-user security is implemented by using the RACF TERMINAL class (or
                GTERMINL for groups of IMS terminals sharing a common security profile).
                Security profiles are created in one of these classes for terminals requiring
                restricted access. User IDs/groups allowed to use the restricted terminals are
                authorized to access IMS using the terminals, and these terminal users must
                perform sign-on. For RACF to enforce sign-on for terminals secured using the
                TERMINAL class, the IMS procedure or startup member DFSPBxxx must specify
                any valid value for RCF= except N. RCF=N will result in RACF not being called
                for any type of security checking.

                While not covered in this book, the reader should be aware that RACF security
                labels may be used in conjunction with terminal-user security. Use of security
                labels offers an even more granular level of terminal security. For information
                on security labels and the use of SECLABEL class with TERMINAL/GTERMINL
                classes, please refer to RACF books.




                                                                Chapter 3. Securing IMS Terminals   57
                         During IMS initialization, a RACROUTE REQUEST=LIST request is sent to RACF
                         to build in-storage (resident) copies of command and transaction resource
                         profiles for the IMS subsystem being initialized.

                         The TERMINAL and GTERMINL RACF classes contain general resource profiles
                         for IMS terminals (LUNAMEs/NODE names). The TERMINAL class is used to
                         protect a single terminal with one security profile. The GTERMINL class is used
                         to protect a number of terminals (having the same security requirements) with
                         one security profile. An installation may have some terminals secured using
                         security profiles in the TERMINAL class while other terminals may be secured by
                         a group security profile in the GTERMINL class. While the installation can use
                         both the TERMINAL and GTERMINL classes, a terminal should only be secured
                         using one of the two classes. When the IMS procedure or the DFSPBxxx
                         member contain a vaild value for the RCF= parameter (a value other than
                         RCF=N) and the TERMINAL class has been activated, RACF checks the user′ s
                         authority to use the terminal.

                         An example showing the RACF commands to secure access to a group of IMS
                         terminals (NODE267, NODE168, and NODE148) has been provided in Figure 1.
                         The security profile (DEPT35) is created (RDEFINEd) in the GTERMINL class
                         (securing the group of terminals with a universal access (UACC) of NONE. Users
                         in DEPT35 are the only users that will be allowed to use these terminals to
                         access IMS. In other words, user IDs that are not connected to the DEPT35
                         group would not be able to use these terminals to access IMS.


                             RDEFINE GTERMINL DEPT35 UACC(NONE) ADDMEM(NODE267 NODE168 NODE148)

                             PERMIT DEPT35 CLASS(GTERMINL) ID(FINANCE) ACCESS(READ)

                         Figure 1. RACF Commands to Create Security Profiles and Authorize Users

                         Next, depending on whether the RACF database or data space is in use, one of
                         the actions in Figure 2 would be taken to refresh security profiles used to
                         enforce security for accessing IMS from the terminals.


                             /MOD PREPARE RACF
                             /MOD COMMIT

                             -or-

                             SETROPTS RACLIST(TERMINAL) REFRESH

                         Figure 2. /MODIFY and SETROPTS Commands That Refresh In-Storage Profiles

                         Note that the terminals were defined in the GTERMINL class, but the SETROPTS
                         refresh is performed on the TERMINAL class. Grouping classes, such as the
                         GTERMINL class, are not refreshed. The reason for this is that the TERMINAL
                         class and the related GTERMINL class have the same posit value. When RACF
                         refreshes the TERMINAL class, the GTERMINl class will automatically be
                         refreshed.

                         One of the advantages of using the TERMINAL/GTERMINL class of RACF is that
                         you can limit the security profiles to only the number of terminals that require
                         terminal-user security. That is, the TERMINAL/GTERMINL classes can be
                         activated with a UACC of READ. Doing so allows all terminals that do not have a


58   IMS V6 Security Guide
security profile in either of the classes (TERMINAL/GTERMINL) to access IMS.
Thus, IMS terminals that are not defined to RACF are allowed to access IMS with
UACC of READ. For the TERMINAL class, RACF treats CONTROL and UPDATE
authority as READ authority. UACC of EXECUTE is for for controlled programs
only. Only those IMS node names that are protected by security profiles with a
UACC of NONE in the TERMINAL/GTERMINL class would be restricted to use by
authorized user IDs/groups. If a terminal is not protected by a security profile in
the TERMINAL/GTERMINL classes it is considered unrestricted from a RACF
point of view.

Another advantage of terminal-user security is that when security profiles are
created in the TERMINAL/GTERMINL classes, the WHEN and TIME keywords may
be used to restrict the days and hours/minutes the terminals may access the
IMS online system.

To activate a class with a UACC of READ, the RACF SETRopts command would
be issued. The RACF RDEFINE command would be used to restrict the terminals
in DEPT35 to use by the FINANCE group. The FINANCE group could only access
IMS online resources on weekdays between 7:00 a.m. and 6:00 p.m. Figure 3
provides examples of the RACF commands to accomplish this. The example
does not take into consideration differences in time zones. RACF does provide
facilities for handling time zone differences (through the use of the TIMEZONE
keyword on the PERMIT command).


   SETR CLASSACT(GTERMINL) TERMINAL(READ)

   RDEFINE GTERMINL DEPT35 UACC(NONE) ADDMEM(MO1RF267 MO3RF168 MO4GG148)
           WHEN(DAYS(WEEKDAYS) TIME(0700:1800))

   PERMIT DEPT35 CLASS(GTERMINL) ID(FINANCE) ACCESS(READ)

Figure 3. Activating a RACF Class, Defining Security Profiles, and Authorizing Users

Prior to securing access to IMS terminals the installation should plan for
handling situations where the terminal is inoperative or unavailable. If an end
user or group has access to IMS resources from a single terminal and the
terminal is secured with RACF terminal-user security, and if the terminal
becomes inoperative, RACF TERMINAL/GTERMINL profiles must be changed and
refreshed (through the use of the IMS /MOD commands or the SETR RACLIST
command). LTERM(s) associated with the inoperative terminal must be
reassigned to the terminal that will now be used for input/output. These
considerations, and other considerations (such as vendor products that
dynamically assign LUs/Node names), make it necessary for the installation′ s
security staff to evaluate use of RACF terminal-user security.

Since RACF provides extensive security for IMS resources (such as transactions,
commands, databases, system data sets, and the like), many installations do not
require terminal-user security. For these installations, securing access by user
IDs (or groups) to commands, transactions, and databases is sufficient to protect
the IMS resources. And remember, IMS security exits can also be used to
extend the security capabilities to meet the installation′s requirements.




                                                    Chapter 3. Securing IMS Terminals   59
3.3.2 Sign-On Verification Security for Static Terminals
                         There are two approaches to implementing security for static terminals:
                             •   IMS terminals are associated with logical terminals (LTERMs) using the
                                 /ASSIGN command. Input from the terminal and/or output to the terminal is
                                 done through the LTERM(s) assigned to the terminal. The first approach to
                                 implementing security for terminals that have been statically defined is to
                                 associate with each LTERM in the network a list of transactions and/or
                                 commands eligible for entry.
                                 This approach uses SMU facilities to implement the security, and is
                                 sometimes referred to as LTERM-based security.
                             •   Have the end users identify themselves (by signing on) each time they use a
                                 terminal and authorize the set of transactions and commands eligible for
                                 entry.
                                 It is recommended that both sign-on and transaction/command authorization
                                 be performed. The reason is that if sign-on is required and
                                 transaction/command authorization is performed internally by IMS (SMU
                                 security restricting transaction/command entry to authorized LTERMs), the
                                 user ID supplied at sign-on cannot be verified. To verify that the user ID
                                 supplied at sign-on is valid, IMS requires either RACF (or compatible
                                 product) or an exit routine (DFSCTRN0 for transactions and DFSCCMD0 for
                                 commands).
                                 RACF or a comparable product may be used with this (the preferred)
                                 approach.

                         3.3.2.1 Using SMU to Enforce Sign-On Verification Security
                         Sign-on is optional for statically defined terminals. To enforce sign-on
                         verification security using SMU, the SECURITY macro should be coded to specify:
                             •   Either SECLVL=SIGNON, or
                             •   SECLVL=FORCSIGN

                         The SECURITY macro keywords specify that sign-on may be required for some
                         or all terminals used to access IMS resources. Another way of stating the
                         meaning of these specifications is: this IMS subsystem may require sign-on
                         verification security checking (SECLVL=SIGNON/FORCSIGN) and the table of the
                         terminals required to perform sign-on will be loaded from IMS.MATRIXA or
                         IMS.MATRIXB. The terminals that will be required to perform sign-on prior to
                         accessing IMS resources are identified in the input to SMU. Figure 4 on
                         page 61 provides examples of SMU input statements.




60   IMS V6 Security Guide
 1) All terminals must perform sign-on to gain access to IMS.

        )( SIGN
           STERM       ALL

 2) The VTAM terminals listed below must perform sign-on to
    gain access to IMS.

        )( SIGN
           STERM   4
           STERM   09
           STERM   105
           STERM   V3270

 3) The BTAM terminals listed below must perform sign-on to
    gain access to IMS.

        )( SIGN
           STERM LINE 3 TERMINAL 4
           STERM LINE 5 TERMINAL 2


Figure 4. SMU Input Statements for Sign-On Verification (Examples)

The execution of SMU builds and loads the IMS.MATRIX data set with the
sign-on offset list (sign-on table/matrix) and the terminal offset list (terminal
table/matrix). When IMS is initialized, it loads the IMS.MATRIXx tables in order
to enforce sign-on for terminals requiring sign-on. Of course, this assumes that
the security environment has not been changed by overriding sign-on verification
in DFSPBxxx or with parameters on the /NRE or /ERE commands.

IMS security (using SMU) has some limitations, which is why RACF was cited as
the preferred method. If SMU is used the following limitations apply:
 •   A maximum of 65,535 terminals may be defined to SMU as terminal requiring
     sign-on verification. This will be covered later in 3.3.2.2, “LTERM-Based
     Security Using SMU” on page 62.
 •   SMU security does not provide user ID-based sign-on verification security. In
     other words, SMU has no facilities for checking the user ID of the user that
     signs on. SMU can enforce that the command and/or transaction was
     entered through a specific LTERM. Therefore, to verify that the user ID
     supplied is a valid user ID (for signing on to IMS); either RACF or the Sign
     On/Off Security Exit Routine (DFSCSGN0) must also be used.
 •   SMU does not provide sign-on support for ETO terminals. SMU enforces
     sign-on verification only for static terminals.
 •   If multiple IMS subsystems are used, and each IMS has one or more unique
     resources defined to it; then a unique IMS.MATRIX must be used for each
     IMS subsystem.

Once the installation has determined which terminals will be required to perform
sign-on, the next level of security for the terminal in the SMU security
environment is called LTERM-based security.




                                                   Chapter 3. Securing IMS Terminals   61
                         3.3.2.2 LTERM-Based Security Using SMU
                         In the SMU environment, LTERM-based security restricts the entry of some IMS
                         commands and/or transactions to specific LTERMs. As shown in Chapter 2,
                         “Implementing IMS Security” on page 11 IMS commands and transactions are
                         restricted to entry from specific LTERMs by providing input statements to SMU.
                         Sample SMU input is repeated in Figure 5 for your convenience.


                                 )( TERMINAL   LT36SST
                                    COMMAND    CHANGE
                                    COMMAND    DISPLAY
                                    COMMAND    START
                                    COMMAND    STOP

                                 )( TRANSACT   ACCTCHG
                                    TERMINAL   A8751111
                                    TERMINAL   A8751112

                         Figure 5. SMU Input Statements (Examples)

                         LTERM-based security allows the installation to define a set of commands and/or
                         transactions that are authorized for use by specified LTERM(s). A maximum of
                         32767 different patterns for these commands and transactions may be defined,
                         with a pattern being a unique set of commands and/or transactions issued by
                         one or more terminals. For example, two terminals issuing the same set of
                         commands constitute one pattern, whereas two terminals issuing different sets of
                         commands constitute two patterns. LTERM resource access security does not
                         require an external user exit routine, but this type of security can be enhanced
                         through use of the Sign On/Sign Off Security Exit routine.

                         RACF may also be used to provide transaction and command authorization
                         security for static terminals and it does not have the limitations stated above.

                         3.3.2.3 Using RACF to Enforce Sign-on Verification Security
                         RACF provides user ID-based sign-on verification security checking. To enforce
                         sign-on verification security using RACF, the SECLVL and TYPE keywords on the
                         SECURITY macro should be coded to specify:
                             •    SECLVL=SIGNON or SECLVL=FORCSIGN, and
                             •    TYPE=RACFTERM

                         The SECLVL=SIGNON/FORCSIGN indicates to IMS that sign-on verification
                         security checking is required. The TYPE=RACFTERM specifies that IMS will call
                         RACF to perform sign-on verification security checking. If the SECURITY macro
                         was not coded to specify the above, the installation can enforce sign-on by
                         specifying the appropriate RCF=x, (where x is not equal to the value ′ N′) in the
                         IMS execution parameters contained in the IMS procedure (or the DFSPBxxx
                         member) or issue the appropriate parameter on the /NRE or /ERE restart
                         command.

                         If the SECURITY macro has been coded as specified above, terminal users can
                         optionally issue the /SIGn ON command. The reason for saying that users can
                         optionally issue the /SIGN ON is that the SMU input specifies specifically which
                         terminals will be forced to sign on. SMU input determines if forced sign-on will
                         be in effect for all IMS terminals, or if forced sign-on will be in effect for the
                         terminals specified in the SMU input.


62   IMS V6 Security Guide
If the users have been defined to RACF and provide the correct passwords, the
/SIGn ON command is accepted. A rejected sign-on results in an IMS sign-on
error message and an X′10′ log record is written.

In the event that a user has not been defined to RACF, ask the RACF security
administrator to define the user to RACF. This is done using the RACF
ADDUSER command. A sample ADDUSER command is shown below.
     ADDUSER user ID NAME(user-name)

Let′s examine how RACF enforces sign-on verification security.

3.3.2.4 User ID-Based Security Using RACF
The approach used by RACF (when sign-on verification is used) is to verify that
the user ID has been authorized to access the IMS resource (transaction or
command) that is being requested from the terminal. So, from a RACF
perspective, if the installation wanted to use RACF to require all IMS terminal
users to perform sign-on, then all IMS commands and transactions would need
to be secured using RACF security profiles that have been created in the
appropriate RACF resource classes.

Implementing and administering security profiles for every command, every
transaction, and other IMS resources could become burdensome in large
installations. Thus the methodology used in most installations has been to
secure only the resources that require protection. When the terminal user
requests an IMS resource that has been protected, RACF does not allow access
to the resource until the user has performed sign-on with a valid, authorized
user ID. If the terminal user did not perform sign-on and requests a protected
resource, access to the resource is denied. Or if the user did perform sign-on
and is not authorized to access the resource, access is also denied.

Sign-on and command/transaction authorization security checking using RACF
provide the installation with the ability to secure valuable resources while
making security administration and auditing for violations less complex.
Auditing for security violations is important in most installations. RACF reports
resource assess violations in SMF Type 80 records. The RACF Report Writer can
be used to create reports from Type 80 records.

Like RACF, IMS also logs sign-on and resource access security violations. The
violations are logged in IMS X′10′ log records. The X′10′ log record contains the
following types of sign-on verification violations:
 •   Rejected sign-on
     See Table 13 on page 73 for possible reasons sign-on was rejected.
 •   The password is omitted, when one is required
 •   The password is incorrect for authorization, or the password is misspelled
For IMS signed-on static terminal users, the RACF user ID from the RACF token
(which is an encapsulation or representation of the security characteristics of a
resource, user or job) is placed in several IMS log records:
 •   Sign-on log record (X′16′)
 •   Security violation log record (X′10′)
 •   The input message log record (X′01′)
 •   The output message log record (X′03′)


                                                Chapter 3. Securing IMS Terminals   63
                             •   All database change log records (X′50′, X′51′, and X′52′)
                             •   Sign-off log record (X′16′)
                         The user ID in the IMS log records provide the capability to use the log records
                         as an audit trail. While IMS still logs these records whether or not RACF is
                         used, in an SMU-only security environment there is no way to authenticate the
                         user ID that was supplied.

                         There are several other advantages to using RACF for sign-on verification
                         security for static terminals:
                             •   RACF users may be restricted to certain days/times for signing on to the IMS
                                 online system. The RACF ADDUSER command is used to do this.
                             •   Terminals may be restricted to signing on to the IMS online system by days
                                 and/or time (hours/minutes during each day). Terminals in the
                                 TERMINAL/GTERMINL classes may be restricted by adding the WHEN clause
                                 to either the RDEFINE or RALTER commands.
                             •   RACF supports sign-on verification for both static and ETO terminals.
                             •   There is no prescribed limit to the number of security profiles that can be
                                 defined to RACF.

                         As previously mentioned, SMU only provides support for static terminals. A
                         security product, like RACF, provides support for both static and ETO terminals.
                         As installations migrate to security products like RACF, it may be necessary to
                         have two security profiles for a while: one for resources protected by SMU;
                         another for resources protected by RACF. Installations should plan on migrating
                         to a total solution security product, like RACF or an equivalent product.


3.3.3 Sign-On Verification Security for ETO Terminals
                         As you have noticed, sign-on is optional for statically defined terminals. Sign-on
                         is required for VTAM ETO terminals. The /SIGN and /RCLSDST commands are
                         the only commands that can be entered from an ETO terminal before sign-on.

                         The installation can determine whether security checking will be bypassed for
                         any/all ETO terminals. If security checking is not bypassed, ETO can enhance
                         the security of the IMS system by providing security features that allow the
                         installation to control:
                             •   The physical connection of terminals to IMS using the TERMINAL or
                                 GTERMINL RACF classes (and optionally the SECLABEL RACF class)
                             •   User sign-on to IMS using a valid RACF user ID and password, and
                                 optionally supplying a group name
                             •   Whether output message queuing will be queued by user ID or nodes
                         Sign-on is the act a terminal user performs to identify that user to IMS. When
                         the terminal is an ETO terminal, the sign-on process also creates a user
                         structure and connects the user structure to the terminal structure. The user
                         structure contains a subpool queue control block (SPQB) and one or more
                         LTERMS (represented by the communications name table (CNT) in the diagram).
                         The physical terminal is represented by the VTAM Terminal Control Block
                         (VTCB). (Refer to Figure 6 on page 65). Sign-off is the act a terminal user
                         performs in order to end identification of a user to IMS. When the terminal is an
                         ETO terminal, the sign-off process usually disconnects the user structure from
                         the terminal structure and deletes the user structure.


64   IMS V6 Security Guide
Figure 6. Sign-on Verification for ETO Terminals

                        Sign-on is always required to identify and allocate a specific LTERM (or set of
                        LTERMs) by USER name. With ETO, dynamic LTERMs are managed separately
                        from the terminals and are assigned a user name. The user can obtain output
                        only after signing on. This ETO implementation results in ″output security″
                        where output is associated with a specific user rather than with the terminal.
                        This dynamic LTERM-to-user association is maintained until the user signs off;
                        and it remains after sign-off if IMS does not delete the user structure.

                        To implement RACF security for IMS resources requested through ETO
                        terminals, follow the same process used for securing static terminals:
                         •   SECURITY macro specification (SECLVL=SIGNON/FORCSIGN,
                             TYPE=RACFTERM)
                         •   Define the protected resources to RACF with a UACC=NONE
                         •   Authorize (PERMIT) user IDs/groups to the protected resources
                        If the SECURITY macro specifications were not coded as above when the IMS
                        system was generated, the RCF= and SGN= startup parameters may be used
                        to override SYSDEF specifications. To get the new security environment
                        established (using RCF= and SGN=) a cold start is initially required. The cold
                        start is required because when IMS is terminated in the normal manner


                                                                       Chapter 3. Securing IMS Terminals   65
                         (/CHEckpoint command), IMS writes an X′4001′ checkpoint log record that
                         contains the security environment at shutdown. IMS uses the information in this
                         log record during a warm start or emergency restart (that is, not a COLDSYS) to
                         restore the security environment that was in effect at shutdown. Once the cold
                         start has been completed with IMS using the RCF= and/or SGN= execution
                         parameters, subsequent initializations of IMS may be done using a warm start or
                         emergency restart; and the new security environment is in effect.

                         3.3.3.1 RACF and ETO Devices
                         Command and transaction input from ETO terminals is similar to resource
                         access from static terminals. That is, the ETO user signs on with a user ID and
                         password. A request for a protected resource (such as a command or
                         transaction) goes through authorization processing. If RACF is used as the
                         security manager, access to secured resources is authorized/denied using the
                         appropriate RACF classes:
                             •   Secured commands are authorized using CIMS/DIMS
                             •   Secured transactions using TIMS/GIMS

                         Input from ETO terminals can be validated by RACF, security exits (such as
                         DFSCCMD0 or DFSCTRN0), or by both RACF and an exit. If the installation has
                         not requested resource protection of any type, and DFSCCMD0 is in IMS.RESLIB,
                         it will be used to provide command authorization. If DFSCCMD0 has not been
                         modified, or is not present in IMS.RESLIB, ETO terminal users receive the same
                         level of command security as default terminal security for static terminals. That
                         is, IMS defaults to the command authorization equivalent to the default terminal
                         security available for static terminals. For ETO environments, this is called
                         default security, and this type of security allows a small subset of commands to
                         be entered from any ETO terminal.

                         When ETO is active (ETO=Y execution parameter) in an IMS system, all
                         attempts to sign on from a VTAM ETO terminal (except OTMA and LU6.2 users)
                         cause IMS to call the Sign-on Exit, DFSSGNX0, if it is present in IMS.RESLIB.
                         This exit can determine the user ID of the ETO user that is signing on. When a
                         non-unique user ID is used (such as a group user ID being used to support a
                         group/department sharing the user ID), ″output security″ is no longer available.
                         DFSSGNX0 can be customized to suffix non-unique user IDs in a manner such
                         that the user ID is unique. The SIGNON Exit routine (DFSSGNX0) processes
                         sign-on requests prior to IMS calling RACF or the Sign-on/Signoff Security Exit
                         (DFSCSGN0). IMS does not call RACF or DFSCSGN0 if DFSSGNX0 rejects the
                         sign-on attempt.

                         3.3.3.2 Consideration for the Sign-On Process from ETO Terminals
                         The sign-on of an ETO terminal user was designed to use RACF (or an
                         equivalent product) for user ID and password verification (which is optional).
                         Sign-on may be done automatically and without password verification, if
                         required. ETO terminal users must enter valid sign-on data before IMS accepts
                         any commands (other than /SIGN or /RCLSDST) or transactions. For 3270-type
                         terminals, the sign-on data may be entered into the IMS Sign-on panel,
                         DFS3649A (See Figure 7 on page 67).




66   IMS V6 Security Guide
         DFS3649A /SIGN COMMAND REQUIRED FOR IMS IMS1

         DATE:     09/10/98      TIME: 12:09:55

         NODE NAME: SNR236NA

         USERID:

         PASSWORD:

         USER DESCRIPTOR:
         GROUP NAME:
         NEW PASSWORD:

            OUTPUT SECURITY AVAILABLE

         ( REJECTED reason )

Figure 7. DFS3649A Sign-on Message/Screen

Users can concurrently sign on to one or more terminals. These terminals can
be a combination of both ETO and static terminals. For multiple sign-on
capability, the SGN=M execution parameter must be specified. For ETO
terminals, the name of the user structure that represents the user to IMS must
be unique. One of the following four methods can be used to make the
user-structure unique:
 •   Use DFSSGNX0 to append a one to three character suffix to the user ID. The
     length of the suffix is determined by whether:
     −    Multiple sign-on capability is active
     −    Shared queues is implemented
     The total length of the user ID cannot exceed eight characters. Use a
     naming convention that ensures unique user IDs.
 •   Use DFSSGNX0 to specify that the user-structure name is the same as the
     node name.
 •   Use DFSSGNX0 to specify a name that is unrelated to the user ID or the node
     name.
 •   Specify a user descriptor name that is the same as the node name, causing
     the name of the user-structure to be the same as the node name.
Unless SGN=M (to enable multiple sign-ons) is specified, the user ID for an ETO
terminal user must be unique. If the user ID is used as the user-structure name,
it must be unique, regardless of whether SGN=M is specified. If the user ID is
not used as the user-structure name (for example, by using the DFSSGNX0
routine), SGN=M must be specified for multiple sign-ons. The security exits are
covered in more detail in Chapter 10, “IMS Security Exits” on page 181.




                                                  Chapter 3. Securing IMS Terminals   67
3.3.4 Output Message Security for Static and ETO Terminals
                         For static terminal users, output is queued to an LTERM assigned to the
                         terminal. Unlike the static terminal, the ETO terminal conversation belongs with
                         the user-structure and follows the user from terminal to terminal. Therefore,
                         output security is available for the ETO user that uses his/her unique RACF user
                         ID when signing on, and the user structure is created using that user ID.

                         Output message security for static terminals is terminal based, whereas for ETO,
                         output messages are user based. Anyone using the static terminal (that has
                         output queued to the LTERMs associated with the terminal) can receive the
                         output. Therefore, the security of the output may be compromised in the static
                         terminal environment.


                         A terminal user can generally determine whether or not the terminal is ETO or
                         static from the DFS3650 session status message, which indicates OUTPUT SECURITY
                         AVAILABLE for ETO terminals. If the DFS3650 message indicates NO OUTPUT
                         SECURITY AVAILABLE for an ETO terminal, then either DFSSGNX0 or a node user
                         descriptor was used to associate the output with the terminal, rather than the
                         user.

                         Users should be educated on output security (or lack thereof) so they do not
                         become confused when they sometimes use static terminals and other times use
                         ETO terminals.


3.3.5 Bypass Security Checking Routine
                         DFSSGNX0 can specify that security checking be bypassed for a particular
                         sign-on attempt. It may be necessary in some installations to bypass security
                         checking, for example, to allow a user ID to be shared among a group of users.

                         Also consider the case for printers. Most printers cannot perform sign-on, thus it
                         is a common practice to have IMS autologon printers. For dynamic ISC, SLU-P,
                         Finance, and output-only devices, user sign-on data must be provided at session
                         initiation. IMS validates the sign-on data and allocates LTERMs to the terminals
                         based on:
                             •   User descriptors in IMS.PROCLIB
                             •   Applicable LTERM and user option defaults
                             •   Sign-on exit routine output
                         If sign-on data is not provided during session initiation for an output-only device,
                         IMS issues message DFS2085 (with return code 264) to the MTO. If sign-on data
                         is omitted for dynamic ISC, SLU-P, or Finance terminals, IMS issues messages
                         DFS3645 and DFS3672.

                         The sample DFSSGNX0 provided in the IMS.TMSOURCE library is coded such
                         that if autologon is in progress (and printers can be autologged on) security
                         checking is bypassed. The sample exit sets the security checking bypass flag if
                         the sign-on has been initiated by an IMS autologon. See Figure 8 on page 69
                         for an example of how to bypass security checking when the USEQNSEC is set
                         by DFSSGNX0. The example shown is for printers.




68   IMS V6 Security Guide
     *                                                                     *
     */////////////////////////////////////////////////////////////////////*
     * SAMPLE FOR BYPASSING SECURITY WHEN AUTO LOGON IS IN PROGRESS        *
     *    - THIS FUNCTION IS USED TO BYPASS ALL SECURITY CHECKING FOR      *
     *    - A SIGNON.                                                      *
     * SET OPTIONS=TRANRESP AND MSGDEL=NOTERM FOR AUTO LOGON DEVICES       *
     *---------------------------------------------------------------------*
              TM    USEQFLG1,USEQATLN         AUTO LOGON IN PROGRESS?      *
              BNO SECBYPSX                     NO, GOTO NEXT SAMPLE        *
              OI    USEQFLG2,USEQTRES+USEQMNTF TRANRESP,MSGDEL=NOTERM      *
              OI    USEQFLG1,USEQNSEC          YES, SET SECURITY BYPASS BIT*
              B     SAMPLEND                  GOTO END OF SAMPLE           *
     SECBYPSX DS    0H                                                     *
     */////////////////////////////////////////////////////////////////////*
     *                                                                     *

Figure 8. Sample Code to Bypass Security Checking in DFSSGNX0

Any type of ETO terminal can bypass user verification security checking during
sign-on by using DFSSGNX0. A security authorization check may still occur if the
user is signing on to an existing user structure with an active IMS conversation.
That is, if the user requests that sign-on use the node name as the user
structure name, and the user structure exists at sign-on time with an active
conversation, the user signing on must be authorized to use that conversational
transaction. If not authorized, the sign-on will be rejected. The authorization
check can be bypassed, if necessary, if DFSSGNX0 sets on the USEQNCAC
FLAG.

Since the Sign-on Exit is the main ETO customization tool, it provides the ability
to customize many aspects of ETO. These functions of the Sign-on Exit Routine
are covered in Chapter 11, “IMS Version 6 Security Enhancements” on
page 191.

3.3.5.1 ETO and IMS V6
There are some ETO enhancements in IMS V6. The IMS V6 enhancements for
ETO that affect security are:
 •    ETO terminals can now immediately time out for:
      −   Sign-on without activity (ASOT or automatic sign-off time)
      −   Logon without sign-on (ALOT or automatic logoff time)
      by specifying a sign-off or logoff value of zero. This results in an immediate
      sign-off after all available output has been sent and a possible immediate
      logoff during sign-off processing when no other users are on the ETO
      autologon queue for a particular terminal.
 •    ETO now supports an automatic logoff or sign-off value of zero and 10-1440
      minutes.




                                                   Chapter 3. Securing IMS Terminals   69
3.4 Password Security for /IAM, /LOCK, and /UNLOCK
                         SMU may be used to provide password security for /IAM, /LOCK, and /UNLOCK
                         commands. /IAM is used to sign on to IMS from a terminal that is on a
                         non-VTAM attached switched communications line. /LOCK PTERM specifies that
                         the sending and receiving of messages to and from the entering physical
                         terminal is to be stopped. /UNLOCK PTERM specifies that physical terminal (and
                         LTERMs assigned to it) is to be unlocked.

                         Assigning passwords to these commands is not required if the commands are
                         protected using RACF (rather than SMU). Securing these commands in the
                         CIMS/DIMS classes and authorizing appropriate users restricts the use of the
                         commands to authorized users. If the installation desires additional assurance
                         that the user who issues one of these commands is the same user who
                         performed sign-on; the RACF REVERIFY function may be used. REVERIFY
                         requires the user to enter his/her password with the command, each time the
                         command is entered. REVERIFY is covered in more detail the the Chapter 4,
                         “Securing IMS Commands” on page 77 and Chapter 6, “IMS Databases and IMS
                         Data Sets” on page 127.



3.5 LTERM-Based Security
                         LTERM-based security is provided by SMU. Chapter 2, “Implementing IMS
                         Security” on page 11 covers implementing LTERM-based security. A brief
                         review is provided here.

                         LTERM based security is a level of security that restricts the entry of protected
                         commands and/or transactions to entry from specific LTERMs. Commands and
                         transactions that are restricted to entry from specific LTERMs may also be
                         password protected to provide an additional level of SMU security. Thus, the
                         entry of commands and/or transactions from the physical terminal is possible
                         only when the LTERMs assigned to the terminal are authorized to the
                         commands/transactions.



3.6 Summary
                         This chapter covered ways to secure IMS terminals. A review of the information
                         presented (or implied) is summarized below.

                         There are several ways to provide security for IMS terminals:
                             •   Autosignoff and Autologoff (for ETO terminals)
                             •   Terminal-user security (for static and ETO terminals)
                             •   Sign-on verification security
                             •   Security using /IAM, /LOCK, and /UNLOCK commands, and
                             •   Securing the commands and transactions entered from terminals

                         Autosignoff and Autologoff. To minimize the risk of unauthorized access to IMS
                         from unattended terminals that have been left signed on and/or logged on; IMS
                         provides the installation with ASOT and ALOT execution parameters. ASOT and
                         ALOT may also be specified on ETO descriptors and the DFSSGNX0 and
                         DFSLGNX0 exits. These parameters determine how long a terminal can be idle
                         before it is automatically signed off and/or logged off. The value (for each


70   IMS V6 Security Guide
parameter) is specified in minutes, and the range is from zero to 1440 minutes.
The default for each parameter is 1440 (the user is never automatically signed
off/logged off). If zero is used for ASOT or ALOT, sign-off or logoff is immediate
when no input/output message is available or after the last available output
message completes.

Securing IMS terminals. Terminals that access IMS may be statically defined in
SYSDEF macros, or they may be dynamically defined to IMS. Terminals that are
dynamically defined to IMS are called ETO terminals. IMS terminals may be
secured by using terminal-user security that is implemented using RACF. Or
alternatively, sign-on may be required for some/all IMS terminals.

Terminal-user security. Both ETO and static terminals may use terminal-user
security to restrict access to the terminal. Terminal-user security is provided by
RACF. It may be implemented by specifying an RCF= value other than N,
creating terminal security profiles in the TERMINAL/GTERMINL classes and
activating the TERMINAL class. UACC of READ allows nodes to be used by any
terminal user. A UACC of NONE restricts the use of the terminal to authorized
user IDs/groups.

Sign-on verification security. Static terminals are not required to perform
sign-on unless the SYSDEF and/or IMS execution parameters require some (or
all) static terminals to perform sign-on. SMU is the facility used to enforce
some/all static terminals to perform sign-on. Authorization to access IMS
commands and transactions from static terminals may be performed by:
 •   SMU, which provides LTERM-based access protection and restricts the
     terminal command and/or transaction input to specific LTERMs.
 •   RACF, which provides protection by verifying that the user ID/group is
     authorized to the resource.
 •   DFSCCMD0 and/or DFSCTRN0 may be used to provide protection by
     performing authorization checking for commands and transactions,
     respectively. Either of these security exits may be used in conjunction with
     SMU or RACF to provide additional security checking, such as checking the
     user′s authority to include specific parameters on a command.

While the Sign On/Off Security Exit (DFSCSGN0) routine is not restricted to being
used in the SMU security environment, it may be most useful in the SMU
secured environment. DFSCSGN0 is specified by coding TYPE=SIGNEXIT on the
SECURITY macro. DFSCSGN0 can be used to verify the user ID and password
on the /SIGN ON command. If used, it also should note the when the user issues
the /SIGN OFF command. Since SMU secured environments do not have a
facility for verifying the user ID, this exit may be used, or alternatively, RACF
may be used to verify the user ID when a resource is requested from the
terminal. DFSCSGN0 may also be used in conjunction with DFSCTRN0. If
DFSCSGN0 is used in the RACF environment, it is called after RACF. If RACF
rejects the sign-on attempt, DFSCSGN0 is not called.

ETO terminals are required to perform sign-on. RACF or an equivalent security
product may be used for access and input authorization. Any type of ETO
terminal can bypass security checking by coding the Sign-on Exit (DFSSGNX0) to
bypass security checking. This is especially useful for printers, and is
sometimes used by installations that share user IDs (a group of people sharing a
user ID). The /SIGN and /RCLS     DST commands are the only IMS commands
that may be entered from an ETO terminal prior to signing on. DFSSGNX0 is the


                                                 Chapter 3. Securing IMS Terminals   71
                         main customization tool for the ETO environment. If the Sign On/Off Security Exit
                         (DFSCSGN0) is used in the ETO environment, it is called after DFSSGNX0 and
                         RACF. If DFSSGNX0 rejects the sign-on attempt, DFSCSGN0 is not called.

                         Table 13 on page 73 shows reasons for rejecting sign-on attempts.




72   IMS V6 Security Guide
Table 13 (Page 1 of 2). Reasons for Rejected Sign-On Attempts
Reason Meaning
Code
  04    User profile not defined to RACF.
  08    Password not authorized, or not specified.
  12    Password has expired.
  16    New password is invalid.
  20    User is not defined to the group.
  24    RACINIT was failed by the installation exit routine.
  28    User access has been revoked.
  32    RACF is not active.
  36    User′s access to the specified group has been revoked.
  40    OIDCARD parameter is required but not supplied.
  44    OIDCARD parameter is invalid for specified user.
  48    User is not authorized to use the terminal.
  52    User is not authorized to use the application.
  76    SIGNON internal error.
  80    Terminal is in conversation.
  88    Terminal is in Preset mode.
  92    Terminal is in Response mode.
  96    Terminal is not authorized for this conversation.
 100    Rejected by DFSCSGN0 exit routine.
 104    Storage unavailable to process request.
 112    Rejected by DFSSGNX0 exit routine.
 116    The structure of the /SIGN command is in error.
 120    Resources unavailable for command.
 124    The LTERM name returned by DFSSGNX0 exit exists as LU6.2 descriptor
        name.
 128    Syntax error detected by RACF.
 132    Storage unavailable to RACF while processing SIGNON, or internal SIGNON
        system error.
 136    Return code 104 from ARM call. Storage unavailable to complete the call.
 140    Return code 108 from ARM call. A system error caused this call to fail.
 144    User ID has more than 8 characters.
 148    Descriptor specified by the USERD could not be found, or no user descriptor
        could be found (DFSUSER could not be found.)
 152    User descriptor specified has more than 8 characters.
 156    User structure is already allocated to a terminal structure.
 160    Associated printer user structure already exist and is temporary.
 164    Descriptor name returned in the associated printer output buffer by
        DFSSGNX0 does not exist in the system.
 168    DFSUSER user descriptor does not exist in the system, and no other
        descriptor was specified to build the associated printer structure.
 172    Associated printer structures could not be obtained using DFSBCB.
 176    Specified user ID is currently in use as a dynamic user. It is unavailable at
        this time as a static user ID. Or the specified user ID is not valid for this
        terminal type because it was statically defined with the system definition
        SUBPOOL macro for use with static ISC parallel session nodes.
 180    USERD parameter cannot be specified by a static terminal.
 184    Queues returned in the user output queue buffer that modify the existing
        user structure do not belong to the existing user.
 188    Queues returned in the user output queue buffer that modify the existing
        user structure are not defined in the system.
 192    User ID returned in the user output queue buffer from DFSSGNX0 contains
        invalid characters.
 196    Associated printer user name returned in the associated print output buffer
        from DFSSGNX0 contains invalid characters.




                                                  Chapter 3. Securing IMS Terminals     73
                             Table 13 (Page 2 of 2). Reasons for Rejected Sign-On Attempts
                             Reason Meaning
                             Code
                              200    Queues returned in the user output queue buffer from DFSSGNX0 contain
                                     special prefixes reserved to IMS or contain invalid characters. If no buffer
                                     data is returned by DFSSGNX0, the parameter in error might have been
                                     entered as sign-on data.
                              204    Queues returned in the user output queue buffer from DFSSGNX0 are not
                                     unique in this IMS system. If no buffer data is returned by DFSSGNX0, then
                                     DFSUSER is used as the descriptor but an LTERM with the same name as
                                     the user ID exists.
                              208    Queues returned in the user output queue buffer from DFSSGNX0 contain
                                     names that are currently defined as transaction names in this IMS system.
                              212    User structure blocks could not be obtained using DFSBCB.
                              216    User is allocated, but is not ISC/SLU P/FINANCE.
                              220    User is allocated, and though is ISC/SLU P/FINANCE, the user address does
                                     not match the new user address.
                              224    User already exist and is trying to sign on, but sign-on has the status of
                                     having the stopped bit turned on by the /STOP USER command.
                              228    Sign-on exit routine DFSSGNX0 returned an invalid ICOMPT value that was
                                     not between 1 and 4.
                              232    Sign-on exit routine DFSSGNX0 returned an invalid COMPT value that was
                                     not between 1 and 4.
                              236    User already existed as a real user and not a temporary user, but the user
                                     does not have any queues.
                              240    Static or dynamic terminal with this user ID already exists on the system.
                              244    LU6, SLU P, or FINANCE ETO terminal entered a /SIGN command, but there
                                     are no user structures available under this terminal.
                              248    Associated print buffer from DFSSGNX0 has a LUNAME that does not follow
                                     the correct naming conventions.
                              252    Associated print buffer from DFSSGNX0 has a logon descriptor that does not
                                     follow the correct naming conventions.
                              256    Associated print buffer from DFSSGNX0 has a mode table name that does
                                     not follow the correct naming conventions.
                              260    Static user was not found for the user allocation of a static ISC parallel
                                     session, a dynamic user was used for all user allocation of a static ISC
                                     parallel session, or a static user was used for the sign-on to an ETO terminal
                                     session.
                              264    Session initiation occurred for an ETO terminal that is an output-only device,
                                     but no sign-on data (user ID and optional user password and user
                                     descriptor) was included. The session is terminated.
                              268    MSGDEL specifications for the USER and static ISC parallel session terminal
                                     did not match. They must be the same.
                              272    The user structure name has been overridden by DFSSGNX0 exit, either
                                     because a name was provided in USEQUSTN or as a result of suffixing. This
                                     name exists as a user descriptor and, therefore, cannot be used for a user
                                     structure name by the user signing on.
                              276    The user already exists and is currently being used by a part of an /ASSIGN,
                                     /STOP, or /OPNDST command.
                              280    An LTERM name with a suffix added contained more than 8 characters.
                              284    Temporary user structure is currently in use by another ITASK. Wait a
                                     moment and try again.
                              304    Password verification failed.




74   IMS V6 Security Guide
With ETO, dynamic LTERMs are managed separately from the terminal and
assigned a user name. The LTERM-to-USER association (user-structure) allows
output to be queued to the user, rather than to the terminal (as with static
terminals). This provides the user with output security. However, if ETO
terminals sign on using a nonuser name, such as node name, output queued to
LTERMs is associated with the terminal rather than the user. This will result in
no output security for ETO terminals.

Restricting entry of commands/transactions to specific LTERMs. The entry of
commands and transactions is restricted to specific LTERMs. The input to SMU
identifies the protected commands and transactions and the LTERMs that can be
used for entering the commands and transactions. Commands and transactions
can only be entered on terminals that have the specific (authorized) LTERMs
assigned to them. The LTERM assignment is done in SYSDEF macros by
positioning the NAME (LTERM) macro(s) immediately following the TERMINAL
macro. Or the /ASSign command may be used to reassign the LTERM to a
different physical terminal.

This concludes the topics on securing IMS terminals. Securing IMS commands
will be covered next in Chapter 4, “Securing IMS Commands” on page 77.




                                                Chapter 3. Securing IMS Terminals   75
76   IMS V6 Security Guide
Chapter 4. Securing IMS Commands

                         This chapter covers securing IMS commands using one or a combination of the
                         following security facilities:
                         Facility        Description
                         SMU             Uses a combination of LTERM, password and transaction
                                         statements. SMU can be used as stand-alone or in conjunction
                                         with the Command Authorization Exit routine (DFSCCMD0).
                         RACF            Protects at a command level using the CIMS/DIMS classes. RACF
                                         can be used as stand-alone or in conjunction with the Command
                                         Authorization Exit routine (DFSCCMD0).
                         DFSCCMD0 The Command Authorization exit routine can be used stand-alone
                                  or in conjunction with SMU or RACF. Unlike the other options,
                                  DFSCCMD0 can be used to protect down to the keyword/parameter
                                  level.

                         Default terminal security is enforced when IMS is generated with no security.
                         This provides a minimal level of command security. Using default terminal
                         security, the commands that may be issued from a non-master terminal are
                         determined by how the commands are entered. For example, commands may
                         be entered from IMS terminals, LU 6.2 devices, MCS/E-MCS consoles, and
                         automated operator programs. The subset of IMS commands that may be issued
                         from an LU 6.2 device is different from the subset of commands that may be
                         issued by an automated operator program.



4.1 Command Protection Facilities
                         The following topics describe the means by which you can protect IMS
                         commands.


4.1.1 Using Default Terminal Security to Secure IMS Commands
                         If you don′t specify any security type in the IMSGEN, COMM or SECURITY macro,
                         IMS provides basic level of resource security called default terminal security.
                         Default terminal security provides a basic protection for commands that can be
                         issued from static terminals. ETO terminals have the same default command
                         security as static terminals, provided DFSCCMD0 is unmodified or not present in
                         IMS.RESLIB. Table 14 outlines the commands that are protected by default
                         terminal security, and where the commands may be entered when default
                         terminal security is active.

                             Table 14 (Page 1 of 3). Terminal Security Defaults for IMS Commands
                             Master Terminal                           Remote Terminal
                             /ACTIVATE
                             /ALLOCATE
                             /ASSIGN
                             /BROADCAST                                /BROADCAST
                             /CANCEL                                   /CANCEL
                             /CHANGE



© Copyright IBM Corp. 1999                                                                               77
                             Table 14 (Page 2 of 3). Terminal Security Defaults for IMS Commands
                             Master Terminal                           Remote Terminal
                             /CHECKPOINT
                             /CLSDST
                             /COMPT
                             /CQCHKPT
                             /CQQUERY
                             /CQSET
                             /DBDUMP
                             /DBRECOVERY
                             /DELETE
                             /DEQUEUE
                             /DISPLAY
                             /END                                      /END
                             /ERESTART
                             /EXCLUSIVE                                /EXCLUSIVE
                             /EXIT                                     /EXIT
                             /FORMAT                                   /FORMAT
                             /HOLD                                     /HOLD
                                                                       /IAM
                             /IDLE
                             /LOCK                                     /LOCK
                             /LOG                                      /LOG
                             /LOOPTEST                                 /LOOPTEST
                             /MODIFY
                             /MONITOR
                             /MSASSIGN
                             /MSVERIFY
                             /NRESTART
                             /OPNDST
                             /PSTOP
                             /PURGE
                             /QUIESCE
                             /RCLSDST                                  /RCLSDST
                                                                       /RCOMPT
                             /RDISPLAY                                 /RDISPLAY
                             /RELEASE                                  /RELEASE
                             /RESET                                    /RESET
                             /RMxxxxxx                                 /RMLIST
                             /RSTART
                             /RTAKEOVER
                             /SECURE



78   IMS V6 Security Guide
                Table 14 (Page 3 of 3). Terminal Security Defaults for IMS Commands
                Master Terminal                           Remote Terminal
                /SET                                      /SET
                /SIGN                                     /SIGN
                /SMCOPY
                /SSR
                /START
                /STOP
                /SWITCH
                /TEST                                     /TEST
                /TRACE
                /UNLOCK                                   /UNLOCK
                /VUNLOAD


              While default terminal security provides limited security, more granular security
              can be achieved by using either SMU, RACF and/or DFSCCMD0.

              Default terminal security is in effect for each IMS command. If one command is
              explicitly protected using SMU, other commands are still protected by default
              terminal security until they are explicitly protected by SMU also.

              If you want to turn off default terminal security, use RACF for command
              authorization security checking. Update the IMS execution parameter (in the
              startup procedure or DFSPBxxx) with RCF=A, C, S or Y. Once done, you need to
              perform a cold start for the security change to be effective. A cold start is
              required because for IMS warm starts, the security environment is established
              from the checkpoint log record taken from the previous IMS execution.


4.1.2 Using SMU to Secure IMS Commands
              SMU can be used to provide additional security, over and above security
              provided by default terminal security. Due to the cumbersome nature and
              limitations of SMU, it is preferable to use a combination of RACF and/or exit
              routine DFSCCMD0 where possible. SMU cannot be used to protect commands
              entered from ETO terminals or from LU 6.2 devices, and it cannot provide
              transaction command security for DL/I ICMD calls. SMU may be used to provide
              transaction command security for DL/I CMD calls. SMU provides the following
              ways to secure IMS commands:
               •   Assign a password to each command that requires protection . Using
                   password protection for commands, each time a command is entered the
                   user is also required to enter the password that protects the command.
               •   Restrict the entry of specific commands to one or more LTERMs. This
                   method of command security restricts the entry of commands to one or more
                   LTERMs. Users will not be able to enter a protected command from a
                   terminal that has LTERMs assigned to it that are not authorized for entering
                   the command.
              SMU also supports assigning both that is, assigning a password to a command
              and restricting that same command to entry from specific LTERMs. Securing
              IMS commands using SMU requires the following:



                                                                 Chapter 4. Securing IMS Commands   79
                             •   Coding PASSWD=YES or FORCE on the SECURITY macro for password
                                 security.
                             •   Coding TERMNL=YES or FORCE on the SECURITY macro for restricting the
                                 entry of commands to specific LTERMs.
                             •   Coding SMU input statements to specify which commands will be secured.
                             •   Executing the SMU utility, or performing an SMU GEN.
                         SMU input statements are coded using control and data statements. A
                         SECURITY procedure is created as a member of IMS.PROCLIB during Stage 2.
                         The procedure executes the SMU utility. The control and data statements coded
                         by the installation are used as input to the SMU utility. Table 15 describes the
                         combination of control and data statements that can be used to protect
                         commands using SMU.

                             Table 15. Command Authorization Using SMU
                             Control Statement                Data Statement
                             COMMAND                          PASSWORD and/or TERMINAL (LTERM name)
                             CTRANS                           TCOMMAND
                             TCOMMAND                         CTRANS
                             PASSWORD                         COMMAND
                             TERMINAL (LTERM name)            COMMAND


                         Figure 9 on page 81 gives some examples of command protection using SMU.




80   IMS V6 Security Guide
                1) Command STOP has password and terminal (LTERM) protection.
                   The STOP command must have the valid password supplied on command
                   entry and the STOP command can only be entered from the terminal that
                   has LTERM TERM1 assigned to it.
                     )( COMMAND    STOP
                         PASSWORD PW1
                         TERMINAL TERM1

                2) Commands that can be issued by the Automated Operator transaction AOTRAN.
                     )( CTRANS     AOTRAN
                         TCOMMAND DISPLAY
                         TCOMMAND RSTART
                         TCOMMAND STOP

                3) Command START can be issued by the Automated Operator transactions.
                   FIN1 and FIN2
                     )( TCOMMAND START
                         CTRANS    FIN1
                         CTRANS    FIN2

                4) Password PW2 protects the DISPLAY and DEQUEUE commands.
                     )( PASSWORD PW2
                         COMMAND DISPLAY
                         COMMAND DEQUEUE

                5) Command entry is restricted to entry from LTERM TERM1.
                     )( TERMINAL TERM1
                         COMMAND BROADCAST
                         COMMAND START
                         COMMAND STOP


               Figure 9. SMU Command Protection Examples

               IMS commands that can be entered by default from any terminal are called
               non-default-secured commands. If a non-default-secured command is listed in
               the SMU input, it becomes a secured command. No other LTERM (including the
               MTO and system console) can issue a secured command unless it is listed in the
               SMU input, with the command in the LTERM′s command profile.

               A further consideration for LTERM command profiles is their assignment to a
               physical terminal (PTERM). If a chain of LTERMs are associated with a terminal
               from which commands are entered, the first-in-chain (first NAME macro that
               follows TERMINAL macro in stage one input) needs a command profile. If that
               first LTERM becomes unavailable, others in the chain are not eligible to enter
               commands unless they, too, have command profiles defined in SMU.


4.1.3 Using the KEYWD Macro to Limit the Scope of IMS Commands
               The KEYWD macro allows you to:
                •   Control whether the ALL parameter can be used with IMS commands where
                    the ALL keyword is valid.
                •   Stop users from issuing the ALL parameter with the DISPLAY command.
               The format is:




                                                            Chapter 4. Securing IMS Commands   81
                         KEYWD
                              keyword,LAST=NO|YES,ALL=YES|NO|DIS ow:

                         where keyword is the new or changed keyword.

                         The ALL specifications are described below:
                         ALL=YES         This is the default, no controls are in place.
                         ALL=NO          This prevents the use of the ALL parameter with all IMS commands
                                         that apply to the keyword being changed, except for commands
                                         issued from AOI programs.
                         ALL=DIS         This prevents the use of the ALL parameter with all /DIS commands
                                         that apply to the keyword being changed, except for commands
                                         issued from AOI programs.

                         Examples of the use of the KEYWD macro to limit the scope of IMS commands
                         are shown below:
                             •   Specifying ALL=NO for the keyword LTERM prevents the use of the ALL
                                 parameter for the following terminal entered commands:
                                     /BROADCAST LTERM ALL
                                     /DISPLAY ASSIGNMENT LTERM ALL
                                     /DISPLAY LTERM ALL
                                     /LOCK LTERM ALL
                                     /PSTOP LTERM ALL
                                     /PURGE LTERM ALL
                                     /START LTERM ALL
                                     /STOP LTERM ALL
                                     /UNLOCK LTERM ALL

                             •   Specifying ALL=DIS prevents the use of the ALL parameter with all
                                 /DISPLAY commands that apply to the keyword being changed (except for
                                 commands issued from AOI programs). Specifying ALL=DIS for the
                                 keyword LTERM prevents the use of the ALL parameter for the following
                                 commands:


                                     /DISPLAY ASSIGNMENT LTERM ALL
                                     /DISPLAY LTERM ALL


                         An alternative to using the KEYWD macro is to use RACF and DFSCCMD0 to
                         restrict the use of keywords on IMS commands.


4.1.4 Using RACF to Secure IMS Commands
                         IMS commands are protected by the creation of profiles in the CIMS/DIMS
                         classes. The first three characters of the IMS command are defined within the
                         RACF CIMS class to protect that command. For example, DIS is defined in the
                         CIMS class to create a security profile for the DISPLAY command. Generic
                         profiles such as RM* can be defined to protect multiple commands, however, a
                         fully qualified profile, such as RML, will override the generic profile.

                         Rather than define individual CIMS profiles for each IMS command, commands
                         with the same authorized users/groups can be grouped together in DIMS
                         profiles. Grouping IMS commands under a single security profile allows you to

82   IMS V6 Security Guide
define a smaller subset of profiles to administer. RACF groups (rather than
individual user IDs) should be added to the access list of CIMS/DIMS profiles,
again for ease of administration. Also, when groups are authorized security
profiles, neither an IMS nor RACF refresh is required when you connect or
disconnect a user to or from a group that is already on the access list of a
CIMS/DIMS profile that has been refreshed previously.

You should decide which commands should be secured in the CIMS class and
which commands should be secured in the DIMS class. If you decide to use
DIMS security profiles, the same command should not be added to multiple
DIMS profiles to ensure there is not an access conflict.

In Figure 10, two DIMS profiles have been created to protect all IMS commands.
Profile ENDUSER has a universal access of READ that allows all users to issue
the commands defined within it. Profile SYSPROG has the IMS system
programmer group (IMSPROG) on the access list. Only user IDs connected to
this group can issue the commands protected by this profile. There is no need to
define the commands in the CIMS class if you decide to use DIMS.


 RDEFINE DIMS ENDUSER OWNER(IMS) UACC(READ)
 RALTER DIMS ENDUSER ADDMEM(BRO CAN DIS END EXC EXI FOR HOL LOG LOO +
                             RCL RCO RDI REL RES RML SET SIG TES)

 RDEFINE DIMS SYSPROG OWNER(IMS) UACC(NONE)
 RALTER DIMS SYSPROG ADDMEM(ACT ALL ASS CHA CHE CLS     COM CQ* DBD DBR +
                             DEL DEQ ERE IAM IDL LOC    MOD MON MSA MSV +
                             NRE OPN PST PUR QUI RM*    RST RTA SEC SMC +
                             SSR STA STO SWI TRA UNL    VUN)
 PERMIT SYSPROG CLASS(DIMS) ID(IMSPROG) ACCESS(READ)

Figure 10. RACF Command Protection Example Using DIMS

Figure 11 shows how to define CIMS profiles to protect the EXIT and STOP
commands. The EXIT command has a universal access of read and so can be
issued by all users. The STOP command has group IMSPROG on the access list,
and only users connected to this group can issue this command.



   RDEFINE CIMS EXI OWNER(IMS) UACC(READ)

   RDEFINE CIMS STO OWNER(IMS) UACC(NONE)
   PERMIT STO CLASS(CIMS) ID(IMSPROG) ACCESS(READ)


Figure 11. RACF Command Protection Example Using CIMS

Once the profiles are created or subsequent access granted, a refresh of the
RACF CIMS/DIMS profiles is required. First determine whether the RACF data
space is supported (RACF 2.1 and above) and whether IMS is at Release 6. If so,
issue the SET RACF OPTIONS (SETR) command to REFRESH the security profiles
in the CIMS class using:

    SETR RACLIST(CIMS) REFRESH

If the data space is not supported and/or IMS is at Release 5 or below, issue the
following IMS online change commands to refresh the in-storage security


                                               Chapter 4. Securing IMS Commands   83
                         information used by IMS. The commands are issued in the the order shown
                         below:
                             1. /MOD PREPARE RACF
                             2. /MOD COMMIT

                         The message:


                             DFS3432 RACF PARAMETER INVALID IF RACF DATA SPACE USED

                         is issued if the /MOD PREPARE RACF command is issued when the RACF data
                         space is being used. The SETROPTS command is preferable as it performs a
                         refresh without requiring the applications to suspend work momentarily for
                         performing an online change.


4.1.5 Using DFSCCMD0 to Secure IMS Commands
                         When the Command Authorization exit routine (DFSCCMD0) is included in
                         IMS.RESLIB, the exit routine provides a command authorization check for
                         commands entered from terminals. The Command Authorization exit routine can
                         work independently or in conjunction with SMU or RACF. The Command
                         Authorization exit routine is called for each IMS/ESA command. Default terminal
                         security, RACF, or SMU password and terminal security is called first to perform
                         the authorization. The return code is passed to the Command Authorization exit
                         routine. DFSCCMD0 performs a final verification and determines the success or
                         failure of the command authorization. DFSCCMD0 can be used alone also to
                         perform the verification. If you want to establish a command authorization level
                         more discrete than that provided by SMU or RACF, you can examine
                         DFSCCMD0′s input command buffer. DFSCCMD0′s input command buffer
                         contains the complete command stream and allows for restriction at a keyword
                         and parameter level. If DFSCCMD0 exists in IMS.RESLIB, DFSCCMD0 is called
                         for all device types including static, ETO, LU 6.2, and MCS/E-MCS devices.

                         This exit can be used with SMU or RACF. The return code the exit issues
                         determines the success or failure of the command authorization. The exit can
                         be used to override either SMU or RACF. Table 16 shows the attributes for the
                         Command Authorization exit routine

                             Table 16 (Page 1 of 2). Command Authorization Exit Routine Attributes
                             Attribute            Description
                             IMS environments     DB/DC, DBCTL, DCCTL.


                             Naming               You must name this exit routine DFSCCMD0.
                             convention
                             Link editing         You can assemble the sample exit routine or one that you
                                                  write using the standard IMS macro and copy files and include
                                                  it in IMS.RESLIB. You must manually link edit this routine with
                                                  DFSCSI00 to use IMS callable services.




84   IMS V6 Security Guide
                 Table 16 (Page 2 of 2). Command Authorization Exit Routine Attributes
                 Attribute            Description
                 Including the        Include DFSCCMD0 in IMS.RESLIB. This routine is required if
                 routine              one or both of the following parameters is specified in the IMS,
                                      DBC or DCC procedures:
                                       •   AOIS = A or C
                                       •   CMDMCS = B or C
                                      If you specify one of these parameters and do not include
                                      DFSCCMD0 in IMS.RESLIB, IMS system initialization ends with
                                      a U0718 abend. Otherwise, the routine is optional.
                 IMS callable         This exit routine can use callable storage services. DFSCCMD0
                 services             is defined to IMS as a standard user exit. Exit routines that are
                                      defined to IMS receive the callable service token in the
                                      standard exit parameter list. This exit routine must issue an
                                      initialization call (DFSCSII0) to use callable services and must
                                      be manually link edited with DFSCSI00.
                 Sample routine       IMS.SVSOURCE.
                 location




4.2 Terminal Entered Commands
               The following topic discusses command protection available for commands
               issued from static and ETO terminals. In both cases the RVFY= parameter in the
               IMS procedure can be used to force reverification that the user entering a
               command from a terminal is the same user that logged on. The RACF command
               is:
                 RDEFINE CIMS command UACC(NONE) APPLDATA(′ REVERIFY′ )


               Difficulties can occur if you are using SMU to password protect commands and
               RACF to protect commands where the REVERIFY function has also been
               specified as APPLDATA. In this scenario, all users needing to issue a particular
               command would need to log on with the same password (which is the password
               assigned to protect the command with SMU). Therefore, it is recommended that
               the RACF REVERIFY option be used instead of SMU password protection. The
               RACF REVERIFY options cause each authorized user of a command to enter
               his/her individual RACF password each time the command is entered.


4.2.1 Commands Entered from Static Terminals
               Commands issued from static terminals are automatically protected by default
               terminal security when no other form of command security has been specified.
               SMU, RACF and/or DFSCCMD0 can be used to provide a greater level of security
               for terminals defined statically at system definition. If SMU or RACF are
               requested, they perform the command authorization; if not, default terminal
               security checks the authorization. The return code from SMU, RACF or default
               terminal security is passed to DFSCCMD0. IMS calls the exit routine (if it is
               included in the system) for commands entered from terminals regardless of the
               result of SMU, RACF or the default terminal security check. The return code
               from the exit routine determines authorization. Examples one, four and five in
               Figure 9 on page 81 provide examples of how commands issued from static
               terminals can be protected using SMU. Figure 10 on page 83 and Figure 11 on



                                                                  Chapter 4. Securing IMS Commands    85
                         page 83 show how commands entered from static terminals can be protected
                         using RACF.

                         SMU uses restricting command entry to specific LTERM and/or PASSWORDS to
                         protect commands. RACF uses the signed-on user ID for command authorization
                         checking.


4.2.2 Commands Entered from ETO Terminals
                         RACF can be used to secure IMS resources requested from ETO terminals. If
                         greater granularity is required than RACF can provide, the Command
                         Authorization exit routine can be used for commands entered from terminals that
                         are defined dynamically using ETO. If RACF is requested and the user is signed
                         on, RACF performs the command authorization. IMS passes the RACF return
                         code to the Command Authorization exit routine. IMS calls the exit routine (if it is
                         included in the system) for commands entered from terminals, regardless of the
                         result of the RACF security check.

                         If RACF is to be used for command authorization, the RCF parameter must be
                         set to A, C, S or Y:
                         A     Includes options T, C, and S.
                         C     Specifies that RACF is to be used for ETO terminal command
                               authorization.
                         N     Specifies that no sign-on, transaction, or command authorization is to be
                               performed by RACF.
                         S     Specifies that RACF is to be used for static and ETO terminal command
                               authorization. Includes option C.
                         T     Specifies that RACF is to be used for sign-on and transaction
                               authorization.
                         Y     Includes options T and C.

                         If RACF is not requested, but the Command Authorization exit routine is included
                         in the system, IMS calls the exit routine and performs command authorization.
                         The sample exit performs command authorization at the command level only
                         (rather than the command and keyword levels). The installation can customize
                         the exit to perform command authorization at the command and keyword levels.
                         If neither RACF nor the Command Authorization exit routine is included, IMS
                         provides command authorization equivalent to the default terminal security
                         available for static terminals.

                         The /SIGN and /RCLSDST commands are the only commands that can be
                         entered from an ETO terminal before sign-on. Although these commands cause
                         IMS to call the Command Authorization exit routine, neither RACF nor the exit
                         routine authorizes the commands.

                         To use RACF to verify command authorization for ETO terminals, code
                         RACFCOM in the security macro. RACF will not be called if NORACFCM is coded
                         (this is the default) unless the DFSPBxxx member of IMS.PROCLIB contains an
                         execution parameter of either RCF=C, RCF=S, RCF=Y or RCF=A.




86   IMS V6 Security Guide
               Figure 12. IMS Command Authorization Processing Flow




4.3 Securing Commands Issued by Automated Operator Programs
               Automated operator (AO) applications are application programs that issue IMS
               operator commands using DL/I calls. Since automated operator issued
               commands can compromise command security, you can prevent the program
               from issuing sensitive commands that may modify IMS resources. AO
               applications can use two different DL/I calls to issue commands, CMD and ICMD.
               This section lists which IMS commands can be issued using each of these calls
               and describes command security for AO applications. AO applications using the
               CMD call use SMU for security. AO applications using the ICMD call use RACF
               and/or DFSCCMD0 for command authorization. Command and keyword
               authorization checking may be performed for AO programs using DFSCCMD0, or
               by using RACF to authorize the command and DFSCCMD0 to authorize the
               keyword used on the command. The sample DFSCCMD0 exit routine provides
               an example of ICMD call command authorization checking.

               Fast Path exclusive transactions cannot be defined as AO transactions.



                                                              Chapter 4. Securing IMS Commands   87
4.3.1 AO Programs That Issue the DL/I CMD Call
                         If you are using the CMD call to issue IMS commands, transactions can be
                         defined as AO transactions using SMU. AO transactions are invoked in the same
                         way any IMS transaction is invoked. When AO application programs are using
                         the CMD call to issue commands, transaction command security is used to
                         authorize the transaction to security profiles. AO application programs can be
                         viewed as pseudo terminals capable of issuing operator commands. Terminal
                         security cannot be used to build a command authorization profile for a pseudo
                         terminal. SMU allows you to relate commands to a transaction by using
                         TCOMMAND data statements along with a CTRAN statement. AO transactions
                         run as IMS applications with the authority to issue one or more IMS commands.
                         For example, an AO application can be scheduled (to process an AO transaction)
                         after a normal restart of IMS to start IMS resources. The AO application would
                         consist of those commands regularly used by the master terminal operator
                         (MTO) after IMS is active.

                         The commands the AO program can issue are defined to SMU. Or, as an
                         alternative, the AO programs that can issue specific commands may be defined
                         to SMU. SMU transaction command security matrixes specify which transactions
                         can issue commands, and the commands allowed for each AO transaction.

                         Using SMU, you can:
                             •   Specify whether AO programs can issue IMS commands using the DL/I CMD
                                 call.
                             •   Specify which AO transactions can issue commands.
                             •   Specify that an AO application can issue all commands allowed as indicated
                                 by the system definition produced list of allowed commands.

                         Only those AO transactions specified to SMU are allowed to enter commands
                         when commands are issued using the CMD call. Also, SMU applies only to AO
                         applications issuing commands using the CMD call. SMU cannot be used to
                         secure commands issued using the ICMD call. Conversely, RACF cannot be
                         used to secure commands issued using the CMD call. RACF is used to secure
                         commands issued using the ICMD call.

                         You must use a security option to authorize an online application program to
                         issue IMS commands using the DL/I CMD and GCMD calls. You make the
                         authorization by associating the transaction that invokes the program with a list
                         of commands that the program is designed to use. In the case of an automated
                         operator program, you need to specify all the commands the program is
                         designed to use. Options two and three in Table 15 on page 80 provide
                         examples of how commands issued by CMD calls can be protected using SMU.
                         Option two shows the input statements to define the list of commands that may
                         be issued by a transaction. Option three shows a list of AO transactions that can
                         issue the START command. Either or both methods may be input to SMU for
                         authorizing commands issued from AO programs using the CMD call.

                         DFSCCMD0 does not provide support for command authorization for commands
                         issued from AO programs using the DL/I CMD call.




88   IMS V6 Security Guide
4.3.2 AO Programs That Issue the DL/I ICMD Call
               You can secure the commands issued by an ICMD call using RACF and/or
               DFSCCMD0. RACF lets you specify the user ID of the automated operator
               application that can issue an IMS command on the access list of each protected
               command. Both the sample DFSCCMD0 exit and RACF let you do authorization
               checking at the command level during ICMD processing. DFSCCMD0 also lets
               you secure commands issued in the ICMD call at the keyword, and/or resource
               name level. A scheme used by some installations is to use RACF for authorizing
               the command and DFSCCMD0 for authorizing the keyword.

               To specify RACF, DFSCCMD0, or both for securing commands issued using ICMD
               calls, use the AOIS parameter in the DFSPBxxx member of IMS.PROCLIB, as
               shown in Table 17:

                 Table 17. AO ICMD Call Command Security
                  AOIS         Description
                 Parameter
                       A       Includes options C and R below. RACF is called first. Then the security
                               authorization facility (SAF) return code, RACF return code, and RACF
                               reason code are passed to DFSCCMD0. These return codes are
                               decoded into a security code, which is also passed to DFSCCMD0 for
                               processing.
                       C       Specifies that DFSCCMD0 is to be called for command authorization.
                       N       This is the default. It specifies that the DL/I call ICMD cannot be issued
                               by an application program.
                       R       Specifies that RACF is to be called for command authorization.
                       S       Specifies that no authorization checking is to be done.


               Since AOIS is not included in the checkpoint record, you can change the AOIS
               value each time IMS is initialized.

               The user ID that is passed to RACF for command authorization for AO programs
               varies. The user ID used to determine if the command will be processed may be
               a person′s RACF user ID, an IMS LTERM name, or a program name. See
               Table 4 on page 32 to see how IMS determines the user ID that is passed to
               RACF for performing the authorization check.

               The CDBM CICS AO transaction uses the DL/I ICMD call for issuing IMS
               commands in a DBCTL environment. The CICS user ID passed in the PAPL is
               the user ID of the CICS address space.

               The following is an example of how you could use the RACF CIMS class to
               protect the START command, then allow an ICMD call from an AO program
               having a user ID of PAYREQ:
                     RDEFINE CIMS STA OWNER(IMS) UACC(NONE)
                     PERMIT STA CLASS(CIMS) ID(PAYREQ) ACCESS(READ)


               The following commands and keywords cannot be issued from AO programs:
                 •    The commands /END, /EXIT, and /EXCLUSIVE if they have no keywords
                 •    /CHECKPOINT keywords ABDUMP, DUMPQ, FREEZE, PURGE, and QUIESCE
                 •    /LOCK keywords LTERM, NODE, and PTERM


                                                                     Chapter 4. Securing IMS Commands       89
                             •   /UNLOCK keywords LTERM, NODE, PTERM, and SYSTEM



4.4 Commands Entered from MCS or E-MCS Consoles
                         You can now enter IMS commands from a Multiple Console Support (MCS) or an
                         Extended Multiple Console Support (E-MCS) terminal to all the IMS systems on
                         each MVS in a sysplex environment. This is done by preceding the IMS
                         command with an MVS ROUTE *ALL command. MCS/E-MCS command support
                         is enabled using the CMDMCS execution parameter. The E-MCS terminal is
                         capable of aggregating the command responses from the IMS subsystems,
                         whereas the MCS terminal is not.

                         Commands entered from MCS or E-MCS consoles can be protected by RACF
                         and/or DFSCCMD0. DFSCCMD0 is called during command processing to check
                         that the terminal is authorized to issue the command. DFSCCMD0 lets you
                         secure commands at the command verb, keyword, and resource levels. To
                         specify one or both methods, use the CMDMCS parameter (new to IMS V6) in the
                         DFSPBxxx member of IMS.PROCLIB. CMDMCS is specified as shown in
                         Table 18 for DB/DC and DC systems and Table 19 for DBCTL systems:

                             Table 18. MCS and E-MCS Command Security for DB/DC
                             CMDMCS      Sub-parameters for DB/DC and DC Systems
                             Parameter
                                 N       Commands cannot be entered from an MCS console. This is the default .
                                 Y       Commands can be entered from an MCS or E-MSC console by entering
                                         the command recognition character (CRC) followed by the command
                                         text. All commands are allowed with CRC.
                                 R       Commands can be entered from an MCS console in the form CRC
                                         followed by the command text. The system calls RACF (or equivalent) to
                                         verify that the user ID of the console is authorized to issue the
                                         command.
                                 C       Commands can be entered from an MCS console in the form CRC
                                         followed by the command text. DFSCCMDO is called to verify that the
                                         user ID of the console is authorized to issue the command.
                                 B       Include options R and C. RACF (or equivalent) is called first. After RACF
                                         is called, the SAF return code, RACF return code and RACF reason code
                                         are passed to DFSCCMD0. The return codes are decoded into a security
                                         code that is also passed to DFSCCMD0. DFSCCMD0 determines if the
                                         command is authorized for the user ID of the console.


                             Table 19 (Page 1 of 2). MCS and E-MCS Com mand Security for DBCTL
                             CMDMCS      Sub-parameters for DBCTL Systems
                             Parameter
                                 R       Commands can be entered from an MCS console in the form CRC
                                         followed by the command text. The system calls RACF (or equivalent) to
                                         verify that the user ID of the console is authorized to issue the
                                         command.
                                 C       Commands can be entered from an MCS console in the form CRC
                                         followed by the command text. DFSCCMDO is called to verify that the
                                         user ID of the console is authorized to issue the command.




90   IMS V6 Security Guide
 Table 19 (Page 2 of 2). MCS and E-MCS Com mand Security for DBCTL
 CMDMCS        Sub-parameters for DBCTL Systems
 Parameter
      B        Includes options R and C. RACF (or equivalent) is called first. After
               RACF is called, the SAF return code, RACF return code and RACF
               reason are passed to DFSCCMD0. These return codes are decoded into
               a security code that is also passed to DFSCCMD0. DFSCCMD0
               determines whether the command is authorized for the user ID of the
               console.
 Note: This is an optional sub-parameter for DBCTL systems. If you do not select B,
 C, or R, commands can be entered from an MCS console. Neither RACF nor
 DFSCCMD0 is called to verify that the user ID of the console is authorized to issue
 the command. This differs from DB/DC and DCC systems in that if CMDMCS is not
 specified, the default is N which means that MCS/E-MCS consoles in DB/DC and DCC
 systems cannot issue IMS commands.


The user ID used for command authorization (for commands entered from
MCS/E-MCS consoles) is the console ID. The console ID is used only if NAME is
not coded in the CONSOLExx member. NAME is required for E-MCS consoles.
The TSO user ID is used for SDSF terminals. See the JES systems programmer
in your installation to obtain the console IDs for MCS/E-MCS consoles. RACF
security profiles will need to be created for these consoles in the CONSOLE
class. Groups/user IDs can be authorized to use the consoles, and the console
user IDs can be PERMITTED to IMS command security profiles in the CIMS/DIMS
classes.

To implement MCS/E-MCS command authorization checking, code the CMDMCS
execution parameter to specify R, C, or B. Then follow the steps listed below:
 •   To control the use of MCS consoles, take the following steps:
      1. Ask your system programmer for the following information:
          a. The NAME or console ID of the console to be protected. Console IDs
             can change with each MVS IPL so NAME should be used instead of
             console ID.
          b. The universal access authority (UACC) to specify for the console
           c. The operator ID or group ID of the operators to w hom you want to
              grant access.
          d. The security label to be assigned to that console (if security labels
             are being used).
      2. Create a profile for each console using the RDEFINE command:


                    RDEFINE CONSOLE console-id UACC(NONE)
          For example, the following command defines a profile for console 22 and
          specifies a UACC of NONE:
                    RDEFINE CONSOLE 22 UACC(NONE)

      3. If console logon is required or automatic as specified in the CONSOLxx
         member of SYS1.PARMLIB, use the PERMIT command to allow users and
         groups to use the console. You must give a user at least READ access
         authority to the console. Otherwise, the user is not authorized to use the
         console.


                                                  Chapter 4. Securing IMS Commands     91
                                 For example, the following command grants group OPRGRP1 and user
                                 JONES READ access authority to console 22:


                                           PERMIT 22 CLASS(CONSOLE) ID(OPRGRP1 JONES) ACCESS(READ)
                                 Warning: After you define a console and protect it with a UACC NONE,
                                 no one can log on to the console until you grant access authority to the
                                 console profile.
                                 For consoles, the valid access authorities are:


                                    NONE (Allows no access)

                                    READ (Authorizes RACF-defined users to LOGON to the specified console)

                              4. Authorize each MCS/E-MCS console user ID to each IMS command
                                 profile (in CIMS/DIMS) you want the console to be able to issue:
                                    PERMIT DIS CLASS(CIMS) ID(22) ACCESS(READ)

                              5. When you are ready to start using the protection defined in the profiles,
                                 activate the CONSOLE class and activate SETROPTS RACLIST
                                 processing for the CONSOLE class. SETROPTS RACLIST processing
                                 helps ensure high performance when access authorities are checked.
                                 You can do these two actions in one command:
                                    SETROPTS CLASSACT(CONSOLE) RACLIST(CONSOLE)


4.5 APPC (LU 6.2)
                         When an IMS command is received from an LU 6.2 device, the Command
                         Authorization exit routine is called if it has been included in the system. The exit
                         routine is called after a RACF call is made, regardless of the result of the RACF
                         security check. If neither RACF nor the Command Authorization exit routine is
                         available to authorize the command, a default level of command security is
                         provided by IMS for commands from APPC devices. When default terminal
                         security is active in the IMS environment, only the following commands may be
                         issued from APPC/LU 6.2 devices: /BROADCAST, /LOG, /RDISPLAY and
                         /RMLIST.

                         The APPCSE parameter specifies the type of APPC RACF security at startup,
                         where:
                         C     CHECK — Specifies RACF command and transaction authorization
                               checking.
                         F     FULL — Specifies RACF command, transaction security checking and
                               additional security for dependent regions. This is the default.
                         N     NONE — Specifies no RACF authorization checking for IMS resources.
                               Specifying this does not affect APPC/MVS RACF security. However, if
                               DFSCCMD0 has been included in the IMS system, it is called for command
                               authorization. If DFSCCMD0 has not been included in the system, default
                               terminal security restricts the commands that can be issued from the LU
                               6.2 device to the four commands listed above.




92   IMS V6 Security Guide
           P           PROFILE — Specifies the use of command and transaction security in the
                       TP profile or the default profile.
           The value you specify for this keyword has an equivalent value you can specify
           in the /SECURE APPC command. The first character you specify applies to the
           APPCSE keyword. In other words the values of C, F, N, or P are valid values for
           the APPCSE= execution parameter. If the /SECURE APPC command is issued
           (rather than the APPCSE= execution parameter) to establish the APPC security
           level the values of CHECK, FULL, NONE, and PROFILE are valid keywords on the
           /SECURE command. The following example illustrates the valid parameters for
           the APPCSE execution parameter and the SECURE APPC command:
                   APPCSE=C     or   /SECURE   APPC   CHECK
                   APPCSE=F     or   /SECURE   APPC   FULL
                   APPCSE=N     or   /SECURE   APPC   NONE
                   APPCSE=P     or   /SECURE   APPC   PROFILE

           The /SECURE APPC command overrides the value you specify in the APPCSE=
           execution parameter. Use the /DISPLAY APPC command to show the security
           level that is in effect. When IMS starts, the default is full security.



4.6 OTMA
           The Command Authorization exit routine can be used with IMS Open Transaction
           Manager Access (OTMA). DFSCCMD0 is an optional exit routine for commands
           entered from IMS terminals, including LU 6.2 and OTMA. If the exit is included in
           the system, it will be called for commands entered from terminals. A default
           level of command security is provided by IMS for commands from OTMA clients
           and servers when:
               •    RACF is not used (/SECURE OTMA NONE), and
               •    DFSCCMD0 is also not used.
           When default terminal security is active in the IMS environment, only the
           following commands may be issued from OTMA clients:


                   /BROADCAST, /LOCK, /LOG, /RDISPLAY and /UNLOCK.


           Use the /DISPLAY OTMA command to show the security level that is currently in
           effect. The security setting is retained after a warm or emergency restart. When
           IMS is cold started, the security will default to FULL. Unlike APPC, there is not an
           execution parameter (like APPCSE for APPC) for specifying OTMA security.
           Instead, the /SECURE OTMA xxxx command is used to control the RACF security
           level for input from OTMA clients, where xxxx is equal to:
           CHECK              Causes existing RACF calls to be made. IMS commands are checked
                              using the CIMS RACF resource class; IMS transactions are checked
                              using TIMS.
           FULL               Causes the same processing as the CHECK parameter but uses
                              additional RACF calls to create the security environment for
                              dependent regions. This is the default.
           NONE               Does not call RACF within IMS for security verification. However, if
                              DFSCCMD0 has been included in the IMS system, it is called to
                              perform authorization checking for commands entered from a
                              terminal.

                                                                  Chapter 4. Securing IMS Commands   93
                                        If DFSCCMD0 has not been included in the system, default terminal
                                        security restricts the commands that can be issued by an OTMA client
                                        to the five commands listed above.
                         PROFILE        Causes the values in the Security Data section of the OTMA message
                                        prefix to be used.

                         If you use RACF for security, the facility class profile IMSXCF.group.member
                         (client member) must be defined. If this is defined and IMS security is not set to
                         NONE, the user ID in the token for the client bid request must be valid (the user
                         ID must have read access to the token). If a command has not been protected in
                         the CIMS/DIMS classes, the command is allowed regardless of the option set by
                         the /SECURE OTMA command.

                         If DFSCCMD0 is used to authorize a command issued from OTMA clients also,
                         OTMA issues a RACHECK to validate the command. OTMA passes only the
                         command verb (rather than the entire command string / command and
                         keywords) to the exit for verification.



4.7 CICS
                         IMS commands may be issued by CICS users. The following topics address
                         issuing commands in the DBCTL and ISC environments.


4.7.1 CICS-DBCTL
                         IMS operations can be done from an IMS master terminal operator console, but
                         you are advised to have a secondary MVS console that is specifically dedicated
                         to DBCTL. We refer to this as the DBCTL console. ″Appendix D, Summary of
                         DBCTL Operator Commands″ CICS Transaction Server for OS/390 CICS IMS
                         Database Control Guide , SC33-1700 (a CICS publication), or Interoperability
                         Between VSE DL/I and OS/390 IMS DBCTL , SG24-5249, shows the IMS commands
                         and keywords that may be issued in the DBCTL environment.

                         With IMS/ESA 5.1 onward, you can choose to issue operator commands to
                         DBCTL from a CICS terminal, using a CICS-supplied automated operator (AO)
                         transaction, CDBM. The CDBM AO transaction is described in ″CDBM Operator
                         Transaction″ in CICS Transaction Server for OS/390 CICS IMS Database Control
                         Guide , SC33-1700, or Interoperability Between VSE DL/I and OS/390 IMS DBCTL ,
                         SG24-5249. CDBM uses the AOI commands that can be issued across the
                         database resource adapter (DRA) interface between CICS and DBCTL. To use
                         CDBM you must:
                             •   Have a DBCTL system running IMS/ESA 5.1, or later.
                             •   Generate and add to the DBCTL system, a       PSB named DFHDBMP.
                                 Specifying parallel scheduling for this PSB   enables multiple CDBM
                                 transactions to be active at the same time.   DFHDBMP need not have any
                                 associated PCBs when generating the PSB       (PSBGEN). Examples of input for
                                 the Stage 1 and PSBGEN are:
                                   APPLCTN PSB=DFHDBMP,PGMTYPE=BATCH,SCHDTYP=PARALLEL
                                           (Sample Stage 1 input)

                                   PSBGEN LANG=ASSEM,PSBNAME=DFHDBMP,IOASIZE=1000
                                          (Sample PSBGEN input)


94   IMS V6 Security Guide
                 To implement IMS command authorization for DBCTL environments, CICS
                 installations should use RACF for authorizing groups/user IDs to the CDBM
                 transaction. This level of transaction security is provided using CICS and RACF.

                 The CICS user ID can be authorized to IMS commands that are secured by RACF
                 in CIMS/DIMS classes. Since the CDBM is an AO transaction, the AOIS=
                 parameter in the IMS execution parameters (in DFSPBxxx) must be code to
                 specify AOIS=R for RACF command authorization checking, or AOIS=C if the
                 Command Authorization Exit will be used for more granular command and
                 keyword level authorization checking. Remember that the default for AOIS is N,
                 which means that AO programs like CDBM cannot issue IMS commands. The
                 following example shows how to authorize issuing IMS commands from the
                 CDBM tranaction. A security profile for the STOP command is created in the
                 CIMS RACF class. The user ID for the CICS address space is PERMITTED to the
                 security profile for the STOP command.


                      RDEFINE CIMS STO OWNER(IMS) UACC(NONE)
                      PERMIT STO CLASS(CIMS) ID(CICSusid) ACCESS(READ)


                 The CICS user ID is passed in the Participant Adapter Parameter List (PAPL)
                 when CICS connects to DBCTL. The PAPL is part of the database resource
                 adapter (DRA). The DRA is a component of the CICS-DBCTL interface in the
                 CICS address space. Its functions include requesting connection and
                 disconnection from DBCTL, telling CICS when a shutdown of DBCTL has been
                 requested or if DBCTL has failed, managing threads, establishing contact with
                 the DBCTL address space, and loading the DRA startup parameter table.

                 The CICS address space user ID should be authorized to IMS commands in the
                 RACF CIMS/DIMS classes. Prior to authorizing the CICS user ID to IMS
                 CIMS/DIMS security profiles, the installation should review the IMS commands
                 that can be issued from the CDBM CICS transaction. RACF checks whether the
                 CICS user ID supplied at CICS startup is authorized to the IMS command. The
                 CICS user ID supplied in the DRA is obtained by one of the following means:
                  •    The User ID supplied in the JOB statement of the CICS startup job, or
                  •    The User ID supplied in the started procedure table


4.7.2 CICS—ISC
                 Permitting a CICS application to issue IMS commands via the ISC session
                 introduces IMS dependencies into the CICS application program. The
                 consequences of this decision should be weighed before this facility is used.

                 A CICS application program can issue IMS commands by using a SEND/RECEIVE
                 or START/RECEIVE application program interface. However, the application
                 cannot directly issue the IMS commands /DISPLAY, /RDISPLAY, /FORMAT, and
                 /TEST. The IMS command verb is embedded in the message and cannot be
                 specified in the PROCESS parameter of the BUILD ATTACH command.

                 If these commands are issued with SEND (without LAST), IMS returns an
                 LUSTATUS NO-OP as the reply to force an end-bracket status. IMS replies to
                 these commands by sending the reply ATTACH BB/EB. CICS must use RECEIVE
                 to obtain the reply. If a command is issued with SEND LAST, the reply message,
                 when it is returned, is processed by a CICS transaction whose name has been
                 previously specified in the RPROCESS field of the BUILD ATTACH.


                                                                 Chapter 4. Securing IMS Commands   95
                         If a command is issued using START/RETRIEVE, the reply is returned with both
                         the ATTACH and SCHEDULER FM headers. You can use the /TEST command for
                         testing communication protocols and editing facilities on an ISC session when
                         IMS is a back end to a CICS front end. Test mode requires the SEND/RECEIVE
                         application program interface to be used.




96   IMS V6 Security Guide
Chapter 5. Securing IMS Transactions

                         This chapter covers the following topics:
                             •   Securing IMS transactions
                                 −   IMS initialization options that affect transaction authorization using RACF
                                 −   The impact of sign-on requests on transaction authorization processing
                                     using RACF
                                 −   SMU Security Checking for IMS transactions
                                 −   RACF Security Checking for IMS transactions
                             •   DL/I CMD and ICMD call transaction authorization processing
                             •   DL/I CHNG call transaction authorization processing using RACF

                         Transaction authorization is key to protecting the resources of the IMS system.
                         IMS transactions may be protected by RACF or an equivalent product that uses
                         the SAF interface, SMU, or the Transaction Authorization Exit routine
                         (DFSCTRN0). The strategic direction for securing IMS resources is with a
                         product such as RACF, so this chapter provides more detailed information for
                         transaction authorization using RACF.

                         Transaction authorization checking using RACF is accomplished in three stages.
                         These are:
                             •   At control region initialization, RACF will be requested to build in-storage
                                 profiles for the transactions that will be checked against a user′s privilege.
                                 The profiles can be refreshed using the Online Change facility of IMS or by
                                 the RACF using the SETROPTS REFRESH command.
                             •   At user sign-on, RACF will be requested to build tables that can be used to
                                 identify a user and the user′s privilege.
                             •   At transaction authorization time, RACF will be requested to compare the
                                 in-storage transaction profiles against the user′s access privilege (authority)
                                 and return either an ″authorized″ or ″not authorized″ indication to IMS.



5.1 Securing IMS Transactions
                         As described in Chapter 2, “Implementing IMS Security” on page 11, IMS
                         transactions may be secured by RACF, SMU, DFSCTRN0, or a combination of
                         DFSCTRN0 with RACF or SMU. Since DFSCTRN0 is described in Chapter 11,
                         “IMS Version 6 Security Enhancements” on page 191, this section will focus
                         briefly on implementing transaction authorization using SMU and RACF.

                         To perform transaction authorization, the SECURITY macro should be coded to
                         specify:
                             •   SECLVL=TRANAUTH,SIGNON or
                             •   SECLVL=FORCTRAN,FORCSIGN
                                 One of these sets of parameters is required for transaction authorization,
                                 unless the TRN=, RCF=, and/or TRANAUTH override parameters are
                                 specified.
                             •   TYPE=RACFAGN, or


© Copyright IBM Corp. 1999                                                                                        97
                             •   TYPE=AGNEXIT
                                 The AGN specification is needed only if AGN security checking is required by
                                 the installation. If transactions have been included in AGN groups, the
                                 TYPE= statement should be coded as shown above. Either RACF or the
                                 AGNEXIT (DFSISIS0) is needed to verify the user′s authorization to resources
                                 included in the AGN group.
                             •   ISIS=0, or ISIS=1, or ISIS=2


5.1.1 SMU Transaction Authorization
                         Transaction authorization using SMU is limited in that SMU cannot perform user
                         ID verification. SMU security is requested by specifying one or both of the
                         following on the SECURITY macro:
                             •   PASSWD=YES or PASSWD=FORCE (for password security)
                             •   TERMNL=YES or TERMNL=FORCE (for terminal security)
                         Transaction authorization provided by SMU is limited to the following two
                         options:
                             1. Assigning a password to the transaction (PASSWD=YES or FORCE)
                                 Each time the transaction is entered the password must be entered as well.
                                 The transaction is assigned a password using the SMU GEN process where
                                 the input statements to SMU provide the transaction code and the password.
                             2. Restricting the transaction to entry from specific LTERMs (TERMNL=YES or
                                FORCE)
                                 This method of SMU transaction authorization only allows the transaction
                                 code to be entered from authorized LTERMs. The transaction code and
                                 LTERMs authorized to enter the transaction are specified using the SMU GEN
                                 process. SMU input statements contain the transaction code and the
                                 LTERM(s) names where the transaction can be entered.

                         SMU does allow a transaction to have both a password and to be restricted to
                         entry from specific LTERMs. The matrix tables containing passwords and
                         LTERMs have size restrictions. Although some installations have successfully
                         defined more than 65,535 LTERMs, the supported limitation is 65,535 of each
                         resource type.

                         SMU security facilities cannot perform user ID verification. Thus, there is no way
                         to ensure that the terminal user has provided a valid user ID during sign-on (if
                         sign-on is required), or that the user ID is authorized to the transaction. If user
                         ID verification is required in the SMU secured environment, then either RACF or
                         DFSCTRN0 must be used with SMU.


5.1.2 RACF Transaction Authorization
                         RACF transaction authorization does not have the limitations of SMU security.
                         When RACF is used for transaction authorization, user ID verification and
                         transaction authorization are performed for secured IMS transactions. To secure
                         an IMS transaction using RACF, simply perform the following steps:
                             •   Code the RCLASS= parameter of the SECURITY macro to a value or accept
                                 the default value IMS.
                             •   Code the DFSPBxxx execution options that specify RACF for transaction
                                 authorization:


98   IMS V6 Security Guide
                       −    RCF=A, RCF=T, or RCF=Y
                       −    TRN=Y or TRN=F
                       −    A O I S = A o r A O I S = R (for command authorization for commands issued
                            by automated operator programs)
                       −    APPCSE=C or APPCSE=F (if APPC is in use)
                       −    ISIS=1 (if AGN security is in place)
                   •   Define the security profiles in the TIMS or GIMS RACF class for transactions
                       that are protected, and authorize groups (or user IDs) to the protected
                       transactions.
                       In the following example a security profile is created in the TIMS
                       (Transaction IMS) RACF class for the IMSTX1 transaction. GROUPX is
                       authorized to execute transaction IMSTX1:
                           RDEFINE TIMS IMSTX1 UACC(NONE)
                           PERMIT IMSTX1 CLASS(TIMS) ID(GROUPX) ACCESS(READ)
                   •   If RACF has not been used for transaction authorization, cold start IMS.
                       If RACF has been used for IMS transaction authorization and new transaction
                       security profiles are added to the RACF database, simply refresh the RACF
                       class(s) and IMS in-storage security profiles if needed. The SETROPTS (set
                       RACF options) RACF command can be used to refresh security information in
                       the RACF data space. IMS in-storage information is refreshed using online
                       change commands (/MODIFY PREPARE RACF and /MODIFY COMMIT):


                           SETROPTS RACLIST(TIMS) REFRESH

                           /MOD PREPARE RACF.
                           /MOD COMMIT.
                       A refresh of the IMS in-storage information is needed only in customer
                       installations where the RACF data space option is not in use. If the RACF
                       data space option is in use, the IMS online change is not needed (and will
                       not work if performed).

                 Once these steps have been taken, RACF transaction authorization checking is
                 in effect.



5.2 IMS Initialization
                 When IMS is initialized, flags are set to indicate whether transaction
                 authorization is in effect. Flags are also set to indicate whether RACF, SMU,
                 DFSCTRN0, RACF and DFSCTRN0, or SMU and DFSCTRN0 will be used for
                 transaction authorization security checking. Therefore, it is important to
                 understand what security options are used as a result of IMS initialization. The
                 next section describes how IMS security options are set during IMS initialization.


5.2.1 Set Security Options in Effect
                 During initialization processing, IMS sets a number of RACF security options.
                 The first process determines the IMS RACF security environment after IMS has
                 been started. IMS determines the environment depending on:
                   •   The way in which IMS is started, warm or cold




                                                                   Chapter 5. Securing IMS Transactions   99
                          •    Whether the MTO has requested changes to the security environment by
                               entering keywords that affect security on the /NRE or /ERE command
                          •    Whether security checking for a specific resource type has been specified as
                               FORCE

                        5.2.1.1 Emergency Restart Security Options Used
                        During initialization, IMS checks to see if an emergency restart (/ERE) command
                        has been entered. If so, IMS determines if the COLDSYS keyword is present on
                        the /ERE command. If this is a non-COLDSYS /ERE, IMS establishes the security
                        environment from a checkpoint log record. Thus, the MTO cannot enter
                        keywords that change the security environment on the /ERE command, unless
                        the command is /ERE COLDSYS. Keywords that change the IMS security in
                        effect can only be entered on the emergency restart command when it has this
                        form:
                              /ERE COLDSYS.

                        5.2.1.2 Cold Start Security Options Used
                        For IMS cold starts (/ERE COLDSYS or /NRE CHKPT 0), IMS establishes security
                        based on SYSDEF security specifications on the SECURITY macro. Next, IMS
                        checks the execution parameters that have been specified in DFSPBxxx to
                        determine if any of the parameters change the security specifications requested
                        on the SECURITY macro. If so, the execution parameters override the SYSDEF
                        security specification(s). Finally, to complete the establishment of the security
                        environment during a cold start, IMS examines the restart command (/NRE
                        CHKPT 0 or /ERE COLDSYS) entered by the MTO to see if any security keywords
                        were entered on the command and if so, establishes the requested security
                        level. The MTO makes the final determination on whether security checking will
                        be in effect for IMS resources. An exception to this rule is that the MTO cannot
                        override security specifications that have been FORCED. Examples of security
                        specifications that have been FORCED are:


                              SECLVL=FORCTRAN,FORCSIGN (on the   SECURITY macro)
                              TERMINAL=FORCE           (on the   SECURITY macro)
                              PASSWD=FORCE             (on the   SECURITY macro)
                              TRANCMD=FORCE            (on the   SECURITY macro)
                              TRN=F           (DFSPBxxx member   of IMS.PROCLIB)
                              SGN=F           (DFSPBxxx member   of IMS.PROCLIB)

                        5.2.1.3 Warm Start Security Options Used
                        For a warm start, IMS establishes the security environment from the checkpoint
                        log record.

                        5.2.1.4 Keywords Used to Alter Transaction Security on IMS
                        Restart
                        It has been mentioned several times that security keywords may be entered on
                        the /ERE COLDSYS and /NRE CHKPT 0 restart commands. Table 20 on
                        page 101 lists the keywords that affect transaction authorization that may be
                        used on the restart commands, and shows the effect of each. Remember that
                        these keywords can only be issued by the MTO if FORCE has not been specified
                        for the resource security enforcement level.




100   IMS V6 Security Guide
                  Table 20. Keywords Used to Alter Security on IMS Restart
                  Restart Security Commands       Effect of Keyword
                  TERMINAL/NOTERMINAL             Activate/Deactivate SMU Terminal Security
                  PASSWORD/NOPASSWORD             Activate/Deactivate SMU Password Security
                  TRANCMDS/NOTRANCMDS             Activate/Deactivate SMU TRANCMD Security
                  TRANAUTH/NOTRANAUTH             Activate/Deactivate Transaction Authorization
                                                  (RACF and/or DFSCTRN0)


                 Figure 13 on page 102 provides a diagram of the initialization of the IMS
                 security environment.

                 It should be noted that the following keywords can alter the security environment
                 on IMS restart:
                  •   CMDAUTH/NOCMDAUTH
                  •   CMDAUTHE/NOCMDAUTHE
                  •   MULTSIGN/SNGLSIGN
                  •   USER/NOUSER
                 These keywords were not included in the table because they affect command
                 authorization and sign-on security rather than transaction security.


5.2.2 Transaction Authorization in Effect
                 Transaction authorization follows the same logic flow as shown in Figure 13 on
                 page 102. During IMS initialization, the /NRE or /ERE COLDSYS restart
                 command is checked for the presence of the TRANAUTH and NOTRANAUTH
                 keywords. Figure 14 on page 103 shows the process flow. Note the similarity
                 between this diagram and Figure 13 on page 102.




                                                              Chapter 5. Securing IMS Transactions   101
Figure 13. IMS Initialization




102    IMS V6 Security Guide
Figure 14. Establishing IMS Transaction Authorization Security

                        Warm starts and emergency restarts (/ERE restart command without the
                        COLDSYS keyword) cannot include the TRANAUTH nor the NOTRANAUTH
                        keywords. The checkpoint log record is used to establish the transaction
                        authorization environment. This results in these restarts having the same level
                        of transaction security that was in effect when IMS took the restart checkpoint.

                        For IMS cold starts (/NRE CHKPT 0 and /ERE COLDSYS), IMS uses the system
                        definition security specifications from the SECURITY macro to establish whether
                        the transaction authorization will be in effect. Next, IMS examines the
                        DFSPBxxx member of IMS.PROCLIB to determine if any security specifications
                        from system definition have been overridden in the execution parameters
                        supplied in DFSPBxxx. The final opportunity to override transaction
                        authorization is on the /NRE CHKPT 0 or /ERE COLDSYS command used to start
                        IMS. To state this another way:




                                                                    Chapter 5. Securing IMS Transactions   103
                          1. IMS examines the SECURITY macro to determine if SECLVL=TRANAUTH,
                             SECLVL=NOTRAN, or SECLVL=FORCTRAN, and then IMS establishes the
                             requeste level of transaction authorization.
                          2. Then, IMS examines the T R N = execution parameter in the DFSPBxxx
                             member of IMS.PROCLIB. If the TRN= parameter is not specified (or if
                             TRN= is not set to a value, such as TRN=, ) in DFSPBxxx, IMS keeps the
                             transaction authorization level specified by the setting of SECLVL. I f T R N =
                             contains a value ( TRN=N, TRN=Y, or TRN=F), the value specified
                             overrides the SECLVL specification, and the requested transaction
                             authorization level is established.
                          3. Finally, when the /NRE CHKPT 0 or /ERE COLDSYS command is entered by
                             the MTO, IMS checks to see if the MTO entered either TRANAUTH or
                             NOTRANAUTH keywords on the IMS restart command. If one of these
                             keywords was entered on the /NRE CHKPT 0 or /ERE COLDSYS command,
                             IMS establishes the requested level of transaction authorization unless
                             SECLVL=FORCTRAN or TRN=F has been established by the SECURITY
                             macro or DFSPBxxx, respectively. The MTO cannot override FORCED
                             transaction authorization.

                        While this chapter focuses on transaction authorization, the process for
                        establishing the IMS security environment is the same for other resource types.
                        That is, during IMS restart, IMS examines the /ERE COLDSYS, /NRE, /NRE
                        CHKPT 0, and /ERE restart commands to determine whether the security
                        environment will be established from the checkpoint log record. For /ERE
                        COLDSYS and /NRE CHKPT 0 restart commands, IMS also determines if the
                        MTO has requested a change to the security environment based on the
                        keywords (See Figure 13 on page 102) on the restart commands. After IMS has
                        determined the transaction authorization level of security checking, the same
                        process is used to set the security level for the following IMS resources. It
                        should also be noted that during IMS restart the order for establishment is
                        important. Therefore, the following list is arranged in the order in which the
                        security environment is established:
                          1. Establish the base security environment (from checkpoint log record or from
                             SYSDEF/DFSPBxxx). Then change the security level for resource (if FORCE
                             is not specified) to what is requested on the keywords on the /ERE COLDSYS
                             and /NRE CHKPT 0 restart commands.
                          2. Transaction authorization security level established
                          3. ETO command authorization security level established
                          4. ETO and static command authorization level established
                          5. Sign-on (user verification) enforcement level established
                          6. Multiple sign-on enforcement level established

                        IMS goes through the same process for each resource type. That is, IMS
                        examines the restart command for security parameters that determine whether
                        authorization checking will be changed for transactions, commands, sign-on, and
                        multiple sign-ons. When the security environment has been established, IMS
                        also performs the following during restart:
                          •   Determines if ETO=Y has been specified. If so, IMS sets an option to force
                              sign-on for ETO terminals.
                          •   Then, IMS begins RACF initialization. The following actions are taken during
                              RACF initialization:


104   IMS V6 Security Guide
                     1. Sign-on security level is SET.
                     2. If RACF command authorization security level was established, the RACF
                        CIMS class is RACLISTed.
                     3. If TRANAUTH, APPC, or OTMA is active in this IMS, the RACF TIMS class
                        is RACLISTed.
                •   And finally, when TIMS is RACLISTed, the optional RACF classes for the DL/I
                    AUTH call (PIMS SIMS FIMS OIMS and corresponding grouping classes for
                    these classes) are also RACLISTed based on sharing a common POSIT value
                    in the classes.

               Now that you understand the process for establishing the security environment
               when IMS is restarted, let us examine how IMS processes sign-on/sign-off
               requests. This is important to understand when RACF is used to provide
               transaction authorization, because RACF performs transaction authorization
               checking based on the user ID (and optionally group) entered at sign-on.



5.3 Processing SIGNON and SIGNOFF Requests
               During IMS initialization, IMS determined the appropriate level of security for
               each resource type by setting options each time a change in resource security
               was requested by either:
                •   SYSDEF SECURITY macro settings
                •   DFSPBxxx execution parameters
                •   /NRE CHKPT 0 or /ERE COLDSYS (security keywords entered on the
                    command)

               When IMS restart is completed, the security for IMS resources has been
               established. At this point, IMS initializes the RACF Task Control Block (TCB).
               The RACF TCB is used to process sign-on and sign-off requests. IMS may use
               from one to 20 RACF TCBs to process sign-on/sign-off requests. The DFSPBxxx
               execution parameter member of IMS.PROCLIB is used to determine the number
               of RACF TCBs used during IMS execution. The parameter RCFTCB= specifies
               a value between one and 20 to indicate the number of RACF TCBs. If the
               RCFTCB parameter is not included in DFSPBxxx (or is coded as RCFTCB=,),
               the value used is the default value of 1.

               As IMS processes the sign-on/sign-off requests, multiple RACF TCBs are used to
               process the requests if the RCFTCB parameter has been specified with a value
               greater than one. The benefit of multiple RACF SIGNON TCBs can be realized
               when using multiple RACF databases.



5.4 RACF Security Checking for IMS Transactions
               When an IMS transaction code is entered from a terminal, IMS initially
               determines whether RACF is active in the system or if SMU should be invoked.
               Then IMS determines if sign-on has already been done. If sign-on has not been
               done, IMS determines whether sign-on must be performed. (It should be noted
               here that certain types of terminals are not required to perform sign-on, for
               example LU6, Finance, and SLUP devices). If sign-on is required and the user
               has not performed sign-on, a message is sent to the terminal user indicating that
               sign-on is required.



                                                           Chapter 5. Securing IMS Transactions   105
                        Suppose the user had already successfully performed sign-on before the
                        transaction code was entered. Then, IMS determines:
                          •    If RACF transaction security is active
                          •    Whether the destination is preset
                          •    Whether a password was supplied with the input data (for the REVERIFY
                               function)

                        When IMS has determined that RACF transaction authorization is active, IMS
                        calls RACF to invoke the TRANAUTH function. IMS also determines whether the
                        destination has been preset. For conversational transactions, the destination
                        would have been set initially. The authorization would already have been
                        checked, so there is no need to validate the password for a preset destination or
                        an IMS conversation (other than the first input). IMS calls RACF to perform the
                        security check and indicates to RACF whether a password has been omitted in
                        the input. If a password was entered at sign-on, it is passed to RACF. If a
                        password was not entered at sign-on, IMS indicates no password by the
                        presence of a 0 in the register that would have contained the password. IMS
                        passes the following information to RACF in the authorization request:
                          •    Pointer to the SCD
                          •    Pointer to the CTB
                          •    Password or 0

                        RACF checks the TIMS or GIMS RACF class for a security profile that protects
                        the transaction. The following example shows how to define a transaction
                        security profile to RACF, and authorize the user IDs of COLEMAN, TAYLOR and
                        any user ID connected to the DSCSTAFF department/group.
                              RDEFINE TIMS TRAN1 UACC(NONE)
                              PERMIT TRAN1 CLASS(TIMS) ACCESS(READ) ID(COLEMAN TAYLOR DSCSTAFF)

                        If a security profile does not exist, from an IMS perspective the transaction is
                        unprotected and may be executed by any user that has been defined to RACF,
                        unless the the IMS transaction class (such TIMS or TXXX) descriptor has been
                        changed. If a security profile exists, RACF determines whether the user ID
                        provided at sign-on (or the group the user is a member of) is on the access list
                        for that security profile. If the user ID (or group) is on the access list, RACF
                        returns to IMS with a return code that indicates the authorization is successful. If
                        the user ID (or group) is not on the access list, RACF indicates a security error
                        by returning a non-zero return code. See Table 21 for the return codes.

                          Table 21. Return Codes of RACF Security Checking
                                 Return   Description
                                  Code
                                      0   Security OK
                                      4   Sign-on Needed
                                      8   Security Error and Register 8 contains actual RC or message number
                                     12   No Password
                                     16   Password Security Error
                                     20   Terminal Security Error




106   IMS V6 Security Guide
For RACF authorization failures, IMS also takes some actions once control has
been returned.
 •   If the terminal user had entered a transaction code that was protected by
     RACF, and the transaction authorization failed, the terminal user is sent the
     DFS2469W error message. The message contains a return code for why
     transaction authorization failed.
 •   The IMS master terminal may also be sent a message (depending on the
     value of SECCNT, number of security violations for the terminal user, and/or
     static versus ETO terminal).
 •   IMS logs the security violation in the OLDS.
     The MVS console is sent a RACF security violation message that reads:
       ICH408I USER(user ID) GROUP(groupname) NAME(JOHN DOE)
       PART CL(TIMS    ) INSUFFICIENT ACCESS AUTHORITY FROM tranname (G)
       ACCESS INTENT (READ    ) ACCESS ALLOWED(NONE)

Some of the reasons for transaction authorization failure are provided by the
DFS2469W IMS message below. This message is sent to the user terminal with
one of the return codes shown:
            DFS2469W TRANSACTION REJECTED reason
RC=08       User is not authorized for this transaction code by RACF, or
            Sign-on Required. Transaction is RACF-protected and the user is not
            signed on.
RC=12       RACF not active.
RC=16       RACF exit gave an invalid return code.
RC=20       RACF is not installed or an incorrect level of RACF is installed.
RC=24       The RACF profile has a conditional access list, the port-of-entry field
            in the security token is filled with blanks, and the port-of-entry class is
            active.
RC=28       The resource class was selected by RACROUTE
            REQUEST=LIST,GLOBAL=YES, but the RACF data space was
            deleted.
RC=36       User verification is required; no password supplied.
RC=40       User verification failed password.

The following diagrams show the logic flow when RACF is used for IMS
transaction authorization. IMS performs some initial security checking prior to
calling RACF, and IMS also performs some security checking after RACF has
returned control to IMS. The security logic that IMS executes depends on
whether the terminal user has performed sign-on. Refer to Figure 15 on
page 108.




                                               Chapter 5. Securing IMS Transactions   107
Figure 15. Transaction Authorization for Signed-On User (Part 1 of 4)




108   IMS V6 Security Guide
Figure 16. Transaction Authorization for Signed-On User (Part 2 of 4)


                                                                        Chapter 5. Securing IMS Transactions   109
                        Figure 17. Transaction Authorization for Signed-On User (Part 3 of 4)




110   IMS V6 Security Guide
Figure 18. Transaction Authorization for Signed-On User (Part 4 of 4)

A high level view of IMS transaction authorization processing using RACF has
been presented. Sometimes the application that processes a transaction
performs an action that causes IMS to perform additional authorization checking.
The actions, or functions, that an application program can request that
automatically cause IMS authorization checking modules to be invoked are:


                                                Chapter 5. Securing IMS Transactions   111
                          •   Command (CMD) call and/or Issue Command (ICMD) call
                          •   Change (CHNG) call issued to a modifiable I/O-PCB
                          •   Deferred conversational program-to-program switch
                              The Insert (ISRT) call for a scratchpad area (SPA) contains a transaction
                              name and the originating terminal and destination SMB are not on a remote
                              system
                          •   Allocate PSB (APSB)
                          •   Authorization (AUTH) call
                          •   When the /SET, /RELEASE, /LOCK, and /UNLOCK commands contain
                              transaction names

                        Let us examine the security options for each of these types of transactions.



5.5 DL/I CMD and ICMD Call Transaction Authorization
                        The DL/I CMD call and ICMD call have been presented in Chapter 4, “Securing
                        IMS Commands” on page 77. Therefore, these DL/I calls will be reviewed in this
                        section.

                        IMS commands can be entered from a terminal. Or, IMS commands may be
                        entered from an application program. If the application program that issues the
                        IMS command is a message-driven program (MPP or BMP), the end user enters
                        an IMS transaction code that is processed by an application program that uses
                        the CMD or ICMD call to execute an IMS command. Application programs that
                        issue IMS commands are known as automated operator (AO) programs. AO
                        programs that use the CMD call to issue IMS commands are also referred to as
                        Type 1 AO application programs, whereas AO programs that use the ICMD call
                        to issue IMS commands are referred to as Type 2 AO application programs.

                        In order for an application program to enter an IMS command, the application
                        program must issue either the DL/I CMD call or the DL/I ICMD call. The
                        following example shows the statements an application program would contain
                        to execute to issue the /DIS ACTIVE command. The formats for both (CMD call
                        and ICMD call) are as follows.
                          •   For CMD Call: Use a CALL FUNCTION statement to contain the CMD function
                              and a CALL DATA statement to contain the command data:
                                   L       CMD
                                   L Z0132 DATA /DIS      ACTIVE
                          •   For ICMD Call: Use a CALL FUNCTION statement to contain the ICMD
                              function. Use a CALL DATA statement to contain the command.
                                   L       ICMD
                                   L Z0132 DATA /DIS ACTIVE

                        As you know, application programs issuing the CMD call may be secured using
                        SMU and/or DFSCCMD0 only. Application programs issuing the ICMD call may
                        be secured using RACF (or an equivalent security product) and/or DFSCCMD0.
                        SMU and RACF can secure IMS commands at the command level. For example,
                        /DIS can be secured by either security facility. However, neither SMU nor RACF
                        can secure command keywords. Therefore, using the /DIS ACTIVE command,
                        neither SMU nor RACF can restrict the use of the ACTIVE keyword on the
                        DISPLAY command. DFSCCMD0 can provide command authorization at the


112   IMS V6 Security Guide
                command and/or keyword levels. If an installation uses SMU or RACF to provide
                command level authorization checking, DFSCCMD0 can be used to provide
                keyword level security. This provides the installation with the capability to
                restrict keywords used on commands to authorized LTERMs or users. Therefore,
                using the above /DIS example, /DIS ACTIVE can be restricted to one set of
                LTERMs/users, while /DIS NODE can be restricted to a different set of
                LTERMs/users.


5.5.1 Using DFSCCMD0 with AO Applications
                The Command Authorization exit routine can be used with automated operator
                (AO) applications that issue the ICMD call. The exit may not be used with AO
                applications issuing the CMD call. The routine is called for AO applications
                when the AOIS parameter is specified as A or C in the IMS, DBC, or DCC
                procedure (DFSPBxxx member of IMS.PROCLIB) when RACF is used to perform
                authorization checking for ICMD calls. DFSCCMD0 is called during ICMD/CMD
                processing to check that the AO application was authorized to issue the
                command that it issued. DFSCCMD0 lets you secure commands issued using
                the ICMD call at the command verb, keyword, and/or resource name level.

                Security for AO programs consists of controlling which applications can issue the
                ICMD call and which commands they can specify using ICMD.

                You can use the Command Authorization exit routine with a security product,
                such as RACF. DFSCCMD0 is linked into the IMS.RESLIB concatenation (if it will
                be used for command authorization for AO programs). The parameter list for
                DFSCCMD0 identifies who issued the command, whether RACF was called, and
                the security check return code. The return code that the exit routine issues
                ultimately determines the success or failure of the command authorization. The
                exit routine can override the outcome of RACF. This sample DFSCCMD0 exit
                routine includes routines for terminals defined using the ETO feature, commands
                entered with ICMD calls, and commands entered from MCS/E-MCS consoles.

                Let us begin by examining the process for Type 1 AO transaction authorization in
                the SMU environment. Then the process for Type 2 AO transaction authorization
                (in the RACF environment) will be covered.


5.5.2 Type 1 AO Transaction Authorization
                IMS uses SMU to perform transaction authorization (restrict transaction entry to
                specific LTERMs) if the TERMNL=YES or TERMNL=FORCE is coded on the
                SECURITY macro. IMS performs command authorization checking for Type 1 AO
                applications if the TRANCMD=YES or TRANCMD=FORCE has been specified on
                the SECURITY macro. If TRANCMS=NO is specified, Type 1 AO programs are
                allowed to issue IMS commands without security checking being performed. The
                list of IMS commands that may be issued by the AO program is provided in
                IMS/ESA Customization Guide , SC26-8732, in the chapter called ″Automated
                Operator (AO) Application Program (GU, GN, CMD, and GCMD calls)″. SMU
                provides transaction authorization security checking by restricting transaction
                input to specific LTERM(s) and optionally, a password may also be assigned to
                protect the transaction. The input to SMU for securing the transaction is done
                using the TRANSACT control statement and the TERMINAL and/or PASSWORD
                data statements. The IMS commands that can be issued by the application
                program that processes the transaction may be provided to SMU in one of two
                ways:



                                                            Chapter 5. Securing IMS Transactions   113
                          •    Specifying the TCOMMAND control statement with the CTRANS data
                               statement, or
                          •    Specifying the CTRANS control statement with the TCOMMAND data
                               statement

                        The following SMU input statements are used to illustrate how transaction
                        security and AO program security requirements are defined to SMU. An AO
                        transaction, namely AOTRAN, is restricted to entry from LTERM A8751111; no
                        other LTERM may be used to enter the AOTRAN transaction code. AOTRAN is
                        also protected by the password PSWD1. The AO program that processes
                        AOTRAN can issue the IMS /DISPLAY command. Since either the CTRANS or
                        TCOMMAND control statements may be used to specify the commands that may
                        be issued from the AO program, examples are shown for both methods:
                        Example A:

                              )( TRANSACT AOTRAN
                                 PASSWORD PSWD1
                                 TERMINAL A8751111

                              )( CTRANS AOTRAN
                                 TCOMMAND DIS


                        Example B:

                              )( TRANSACT AOTRAN
                                 PASSWORD PSWD1
                                 TERMINAL A8751111

                              )( TCOMMAND DIS
                                 CTRANS AOTRAN

                        An SMU GEN run with the input statements used in Example A would result in
                        the following SMU transaction authorization checking and enforcement, and
                        transaction command authorization checking and enforcement:
                          •    Each time the AOTRAN transaction code is entered from A8751111, the
                               password PSWD1 must be supplied.
                          •    The AOTRAN transaction could be entered only from the physical terminal
                               that has LTERM A8751111 assigned to it.
                          •    The application program that processes AOTRAN uses the DL/I CMD call to
                               issue only one IMS command, the DISPLAY command. Attempts by the
                               application program to issue any other IMS command would result in:
                                −   The command not being executed, and
                                −   A security violation

                        SMU input statements used in Example B would result in the following SMU
                        transaction authorization checking and enforcement, and transaction command
                        authorization checking and enforcement:
                          •    Each time the AOTRAN transaction code is entered from A8751111, the
                               password PSWD1 must be supplied.
                          •    The AOTRAN transaction could only be entered from the physical terminal
                               that has LTERM A8751111 assigned to it.



114   IMS V6 Security Guide
 •   The DISPLAY command can be issued from only one Type 1 AO program,
     namely the application program that processes AOTRAN.
As you may have noticed, the CTRANS control statement is used to specify the
IMS command(s) a specific transaction can issue, whereas the TCOMMAND
control statement is used to specify all the Type 1 AO program(s) that can issue
a specific IMS command.

IMS uses tables within the IMS.MATRIXA or IMS.MATRIXB security data sets to
provide transaction authorization and transaction command authorization. For
the above example, the following matrix tables are used to provide the resource
security indicated:
 •   Communication Password Table/Matrix (DFSISPBx)
 •   Terminal Offset List (DFSISTLx)
 •   Transaction Command Matrix (DFSISTCx)
 •   Transaction Offset List and Table (DFSISTTx)

When SMU is used to secure IMS transactions, IMS loads IMS.MATRIXx tables
into control storage during IMS restart. The tables are referenced during IMS
online execution to enforce security specifications from:
 •   SYSDEF SECURITY macro specifications
 •   Startup/execution security parameters in DFSPBxxx
 •   MTO entered security keywords on the /NRE CHKPT 0 or /ERE COLDSYS
     commands
 •   The checkpoint IMS log record with the checkpoint security values

IMS sets flags at IMS restart to indicate which security options are in effect.
Using our example above where the AOTRAN was assigned a password and
restricted to entry from one LTERM, let us follow the security checking that
would be performed each time the AOTRAN transaction code is entered:
 1. IMS checks a flag to determine if password security checking is active
    (PASSWD=YES/FORCE).
 2. The password matrix tables are checked to determine if the transaction
    AOTRAN is protected by a password. Since the transaction is password
    protected, IMS examines the input to see if a password was supplied with
    the transaction code and data:
      •   If no password is supplied, transaction entry is disallowed, and a
          message is sent to the terminal user:
            DFS062 REQUIRED PASSWORD NOT PRESENT.
      •   If the password supplied with the transaction code is incorrect, a
          message is sent to the terminal user to indicate that an incorrect
          password was used:
            DFS066 PASSWORD SECURITY VIOLATION.
          Note: The actual violation message received by the user could vary
          depending on whether sign-on was performed, whether the terminal was
          defined statically or using ETO, and so forth.
          Also, security violation messages may be sent to the MVS console/MTO
          based on the value of SECCNT= parameter on the SECURITY macro.



                                               Chapter 5. Securing IMS Transactions   115
                               •   The security violation is logged (OLDS).
                               •   If the correct password is supplied, then SMU security checking
                                   continues with LTERM authorization checking.
                          3. Next, IMS checks a flag to determine if SMU terminal security is active
                             (TERMNL=YES/FORCE).
                          4. The communications terminal matrix is checked to determine if the LTERM
                             A8751111 can be used for the entry of transaction AOTRAN.
                               •   If the LTERM is not authorized for transaction entry, a message is sent to
                                   the terminal user:
                                        DFS067 TERMINAL SECURITY VIOLATION     (I: sss/name, D: sss/name)
                                   If the optional part of the message is printed it includes:
                                   I:           Inputting system
                                   sss          sss field following I: is the SYSID of the input system
                                   name         Destination of the message (transaction code or LTERM)
                                   D:           Destination or processing system
                                   sss          sss field following D: is the SYSID of the processing system
                                   name         Destination of the message (transaction code or LTERM)
                                   (A security violation message may also be sent to the MVS Console/MTO
                                   depending on the value of SECCNT= parameter of the SECURITY
                                   macro.)
                               •   The security violation is logged (OLDS).
                               •   If LTERM A8751111 is authorized for the entry of AOTRAN, the
                                   transaction input is allowed or accepted.

                        Assume AOTRAN has been accepted and queued for              processing. It can now be
                        processed by the application program. If transaction        command authorization
                        checking is active (TRANCMD=YES or FORCE on the             SECURITY macro), when
                        the application issues the DL/I CMD call IMS invokes        security checking modules
                        to determine whether:
                          •   The flag for transaction command authorization checking is set.
                          •   The transaction command matrix tables (DFSISTCx) contain security data for
                              authorizing AOTRAN to issue IMS commands. And if AOTRAN can issue IMS
                              commands, the subset of exact IMS commands AOTRAN can issue:
                              −    If the transaction is not authorized to the command, the application
                                   program is sent a CD status code indicating a security violation, the MVS
                                   console and/or IMS master terminal are sent appropriate security
                                   violation messages, and the terminal user is sent an error message
                                   indicating a security violation.
                              −    A non-zero return code is returned to IMS (indicating to disallow the
                                   command).
                          •   If AOTRAN has been authorized to issue the DISPLAY command, a
                              successful return code is returned to IMS.

                        If transaction command authorization has not been activated (TRANCMD=NO)
                        then the command is processed providing it is a command that can be issued by
                        a Type 1 AO program. The list of commands that may be issued by a Type 1 AO


116   IMS V6 Security Guide
                program are provided in IMS/ESA Customization Guide , SC26-8732, in the
                chapter called ″Automated Operator (AO) Application Program (GMSG, ICMD,
                and RCMD Calls)″.

                As previously mentioned, SMU has limitations. SMU matrix tables/offset list are
                limited to a 65,535 resource maximum. Therefore, AO programs should be
                secured using a security product like RACF where there are no known
                limitations.


5.5.3 Type 2 AO Transaction Authorization
                Transaction authorization processing using RACF has been covered earlier in
                this chapter. Therefore when a transaction code (such as AOTRAN) is entered
                from the terminal, the previously described RACF transaction authorization
                checking is performed. A brief review of RACF transaction authorization
                checking is provided below:
                 •   When transaction authorization (TRANAUTH=YES/FORCE) has been
                     specified and RCF=A/T/Y (A, T, or Y) has also been specified in the
                     execution parameters, IMS calls RACF (using a RACROUTE macro) to
                     perform transaction authorization.
                     End users are required to perform sign-on if they access transactions that
                     have been secured using RACF, because the sign-on process provides the
                     user ID that RACF will use to perform security checking.
                 •   A security profile is created for the transaction (such as AOTRAN) in the
                     RACF TIMS/GIMS class:
                         RDEFINE CIMS DIS UACC(NONE)
                         PERMIT DIS CLASS(CIMS) ACCESS(READ) ID(USERID1 A8751111
                                   DBAGRP OPNSGRP AOPGM)
                     In the above example a security profile is created for the DISPLAY command
                     in the RACF CIMS class. The following users are authorized to issue the
                     /DIS command:
                     −    USERID1 (the user/person that has a user ID of USERID1.
                     −    A8751111 (LTERM name if terminal user is not signed on).
                     −    DBAGRP (user IDs connected to the database administration group).
                     −    OPNSGRP (user IDs connected to the operations group).
                     −    AOPGM (AO PSBname, or BMP′s JCL USER= parameter specification).
                     The security profiles that RACF and IMS use for transaction authorization are
                     refreshed so security checking can take place for the secured transaction.
                 •   Password protection for transactions is provided by specifying REVERIFY in
                     the application (APPLDATA) data section of the security profile.
                     If REVERIFY is used, rather than assign a password to the transaction (as
                     when using SMU security), the terminal user′s RACF password is supplied
                     with transaction input. Thus, using our AOTRAN example, the PSWD1 would
                     not be specified, rather the REVERIFY APPLDATA would cause RACF to
                     require the user to re-enter his or her RACF password with the AOTRAN.
                 •   IMS calls RACF (using RACROUTE) to determine if the user is authorized for
                     the transaction.
                 •   RACF checks the access list to determine if the user (or the group to which
                     the user belongs) is authorized to the transaction.


                                                             Chapter 5. Securing IMS Transactions   117
                          •   RACF returns a return code to IMS indicating whether the user is authorized.
                              If a security profile for the transaction does not exist (the transaction is not
                              protected), RACF indicates to IMS that a security profile was not found.
                          •   IMS makes the decision to allow or disallow entry of the transaction based
                              on the RACF return code.
                              If the RACF return code indicates the user is not authorized, IMS does not
                              allow the transaction input from the terminal. IMS allows the transaction
                              input if the RACF return code indicates that the:
                              −   Transaction was unprotected, or
                              −   User ID and/or group is authorized

                        After the transaction has been accepted by IMS, it can be processed by the
                        application program. The AOIS= execution parameter value determines
                        whether AO programs will be allowed to issue IMS commands using the ICMD
                        call, and if AO programs can issue commands, which subset of IMS commands
                        each AO program can issue. The default for AOIS= is N (no), which denotes
                        that AO programs are not authorized to issue IMS commands. W h e n A O I S = A
                        or R, RACF is called to perform command authorization. Unlike the SMU
                        secured environment, a security generation is not required when RACF is used
                        to authorize AO program issued IMS commands. When application programs
                        issue the DL/I ICMD call to issue IMS commands, the following steps are taken
                        to implement RACF security checking:
                          1. Create a security profile for the command/commands in the CIMS/DIMS
                             RACF class.
                              A profile could already exist for the command (or group of commands) that
                              the AO program issues. If the profile already exists, perform step 2.
                          2. Simply PERMIT the appropriate user ID(s), for example, the user IDs/groups
                             or the PSBname of the AO program.
                          3. Refresh RACF and/or IMS in-storage security profiles as needed.

                        As mentioned previously, the user ID used to determine whether the user is
                        authorized to issued the command depends on:
                          •   The type of region in which the AO programs is executing
                          •   Whether the program issued a GU
                          •   Whether the user that submitted the transaction is signed on
                          •   Whether the USER= parameter has been supplied in the JCL
                        Table 22 was presented in an earlier chapter, and is provided again for your
                        reference.

                          Table 22 (Page 1 of 2). DL/I ICMD USERID VALUE
                          REGION      GU         USERID
                          TYPE        DONE
                          BMP         N/A        Non-message-driven BMP′s JCL USER= parameter
                                                 specification. See Note below for non-message driven BMP.
                          DBT         N/A        Security token passed in the PAPL
                          IFP         NO         Program name
                          IFP         YES        User ID (if terminal is signed on), or LTERM name where the
                                                 transaction was issued (if terminal is not signed on)



118   IMS V6 Security Guide
                 Table 22 (Page 2 of 2). DL/I ICMD USERID VALUE
                 REGION      GU         USERID
                 TYPE        DONE
                 MPP         NO         Program name
                 MPP         YES        User ID (if terminal is signed on), or LTERM name where the
                                        transaction was issued (if terminal is not signed on)
                 BMP         NO         Message-driven BMP′s JCL USER= parameter specification.
                                        See Note for message-driven BMP)
                 BMP         YES        Message-driven BMP′s user ID (if terminal is signed on), or
                                        LTERM name where the transaction was issued (if terminal is
                                        not signed on)
                 Note: For a BMP if the USER= parameter does not contain a user ID, RACF uses a
                 user ID of 0000000 when no other user ID is available.


                A good status code (bb) is returned if the AO program is authorized to issue the
                DL/I ICMD call. RACF returns a 0 return code when the program is authorized to
                issue the command. If DFSCCMD0 is used in conjunction with RACF, IMS passes
                the RACF reason/return code to DFSCCMD0. Regardless of whether RACF
                provided a zero or non-zero reason/return code, DFSCCMD0 is passed the
                reason/return code from IMS, and DFSCCMD0 determines whether the program
                is allowed/disallowed to issue the command.


5.5.4 Security Errors Related to ICMD/CMD Calls
                The following are common security error messages, abend codes, and DL/I
                status codes received when an authorization failure occurs for DL/I ICMD or
                CMD call processing:
                  DFS2180I AUTOMATED OPERATOR USER EXIT ERROR--CODE=x.
                Code (Dec)         Meaning
                14                 The exit routine returned with a reply code other than 0 for a
                                   command entered either internally by IMS or by the DL/I ICMD
                                   call. The processing for the command proceeds normally. The
                                   exit routine is not called for command response messages for
                                   commands entered either internally by IMS or by the DL/I ICMD
                                   call.
                ABENDU0718         Issued by DFSIINB0 CSECT LOADXITS when the attempted load
                                   of DFSCCMD0 fails and ICMD security is implemented using
                                   RACF (or it equivalent), the Command Authorization exit routine,
                                   or both. No error messages are issued before this abend.
                                   Register 15 contains the return code.
                ABENDU0071         A standard abend issued by DFSXLIC0. DFSXLIC0 invokes
                                   lower-level modules to perform specific initialization tasks. The
                                   ABENDU0071 is the result of a nonzero return code passed back
                                   to DFSXLIC0 from one of the lower-level modules. Register 14
                                   in the abend SVRB should be used to isolate to a specific label
                                   below. Register 12 is the base register; register 15 contains the
                                   return code.
                                   Explanation: A valid IMS command was specified in the I/O area
                                   of an ICMD call. However, the command as specified is not
                                   allowed from an application. See IMS/ESA Operations Guide ,
                                   SC26-8741.


                                                               Chapter 5. Securing IMS Transactions   119
                        0110 or 0038      DL/I Return and Reason Code explanations
                                          Explanation: An AO application tried to issue an IMS command.
                                          The ICMD call is not authorized from any program because the
                                          IMS execution parameter AOIS= was specified as N.
                        CB or CD          Status Code returned to application program and IMS error
                                          message sent to MTO/user.
                                          DFS286I SECURITY VIOLATION USERID user ID PROGRAM
                                          programname (sent to MTO)
                                          DFS2467, DFS3649, or DFS3662 message with return code sent to
                                          terminal user.



5.6 DL/I CHNG Call Transaction Authorization
                        A program-to-program message switch occurs when one MPP sends a message
                        to another online program (another MPP or a transaction-oriented BMP). To do
                        this, use an alternate PCB and use some of the same options in an an alternate
                        PCB to send messages to alternate terminals. If you send messages to only one
                        application program, then you can define the alternate PCB with the transaction
                        code for that application program during PSB generation. If you send messages
                        to more than one application program, you can define the alternate PCB as
                        modifiable.

                        When an alternate modifiable PCB is used, IMS Transaction Manager
                        automatically does some security checking when you issue the CHNG call to set
                        the destination of the alternate modifiable PCB. The terminal that enters the
                        transaction code that causes the message switch must be authorized to enter
                        the transaction code that the CHNG call places in the alternate modifiable PCB.
                        IMS TM does not do any security checking when you issue the ISRT call.

                        The user ID used for transaction authorization is the user ID in the USERID field
                        of the I/O-PCB. An I/O PCB contains 10 fields. Table 23 shows the fields used
                        by authorization checking, their lengths, and the applicable environment for each
                        field.

                          Table 23 (Page 1 of 2). Fields of I/O PCB Used for Authorization Checking
                          Field        Description
                          Name
                          LTERM        This field contains the name of the terminal that sent the message.
                          Name.        When your program retrieves an input message, IMS places the name of
                                       the LTERM that sent the message in this field.




120   IMS V6 Security Guide
 Table 23 (Page 2 of 2). Fields of I/O PCB Used for Authorization Checking
 Field        Description
 Name
 User ID.     The use of this field is connected with RACF sign-on security. If sign-on
              is not active in the system, this field contains blanks. If sign-on is active
              in the system, the field contains one of the following:
                •   The user′s identification (user ID of the signed-on user) from the
                    source terminal.
                •   The LTERM name of the source terminal if sign-on is not active for
                    that terminal.
                •   The value from the USER= keyword on the JOB statement of the
                    source BMP, if the message was created by a batch-oriented BMP.
                    If USER= is not specified, the PSBNAME of the source BMP is used.
                    (In IMS V6, the DFSDCxxx member of IMS.PROCLIB allows the
                    installation to decide whether the USER= parameter from JCL will
                    be used to specify the user ID, or whether PSBNAME will be used.
                    PSBNAME is the default if BMPUSID is not specified in DFSDCxxx.)
              The same factors that are used to determine the user ID used with DL/I
              ICMD call authorization are used for the CHNG call. Thus, the message
              region type, whether a GU was issued, whether the terminal user was
              signed on, and whether USER= has been specified for a BMP apply in
              determining the user ID.
 Group        The group name, which is used by DB2 to provide security for SQL calls,
 Name.        is created through IMS transactions.
              Three instances that apply to the group name are:
                •   If you use RACF and SIGNON on your IMS system, the RACROUTE
                    SAF (extract) call returns an eight-character group name.
                •   If you use your own security package on your IMS system, the
                    RACROUTE SAF call returns any eight-character name from the
                    package and treats it as a group name. If the RACROUTE SAF call
                    returns a return code of 4 or 8, a group name was not returned, and
                    IMS blanks out the group name field.
                •   If you use LU 6.2 (APPC), the transaction header can contain a group
                    name.
 Note:   Three of the fields in the I/O PCB may be used for authorization checking.


When the CHNG call is used with an alternate modifiable PCB in an IMS
back-end system, such as back-end IMS in a shared queues group or an MSC
system, the ACEE is not available to the back-end system. In these
circumstances, the ACEE must be dynamically created in the dependent region
of the back-end system in order to perform RACF authorization checking.
Dynamically building the ACEE in the back-end system may increase the time
required to process the CHNG call.

If none of the above user IDs are defined to the back-end system (for example,
the terminal user′s user ID, LTERM name, PSBname, USER= specification from
the JCL, 0000000 do not have a RACF user ID on the IMS executing the CHNG
call), a default user ID is used. If an IMS BMP has PARDLI=1 specified or an
IMS system is specified with LSO=Y, then the default security environment is
the environment of the IMS control region that is created with the user ID that is
associated with the IMS control region. Otherwise, the default security
environment is that of the IMS dependent region that is created with the user ID
that is associated with the IMS dependent region.



                                                  Chapter 5. Securing IMS Transactions   121
                        Installations migrating from prior IMS versions to IMS V6 should note that if the
                        USER= user ID specification is provided in the BMP′s JCL, it may be used. (In
                        IMS V5 and below, the PSBname was used as the user ID field of the message
                        rather than the USER= user ID specification.) If a RACF user ID does not exist
                        in the back-end system for the USER= user ID specification or for the PSBname,
                        SMF security violation messages may occur and be logged. The SMF violations
                        are logged to alert security auditing staff that the default (user ID of the control
                        region/message region) was used. The SMF violations may be eliminated by
                        creating a RACF user ID on the back-end system for the USER= user ID
                        specification or for the PSBname.

                        The security checking that is done in RACF when you issue a CHNG call for a
                        program-to-program message switch is the same checking that is done in an
                        environment that uses the SMU. When an IMS TM application program issues a
                        CHNG call, that call invokes RACF, and a check is made to determine whether
                        the originating user is authorized for the transaction code just issued. If, instead
                        of using the CHNG call, the program issues an ISRT call against a preset
                        alternate PCB, no security check is made, regardless of the environment.

                        With program-to-program switching through the DL/I CHNG call or by changing
                        the transaction code in the SPA, you can use RACF, an exit routine, or both, to
                        check transaction authorization. In addition, as the application program
                        associated with the transaction produces database changes, the user ID is
                        logged with the change records on the IMS system log to identify the changes
                        performed by a specific user.

                        The DFSBSEX0 exit can be coded to bypass security checking for the CHNG call.
                        The exit can be customized to:
                          •   Bypass invoking the SAF interface on a CHNG call, an AUTH call, and a
                              deferred conversational program switch
                          •   Bypass invoking the SAF interface on a CHNG call, an AUTH call, and a
                              deferred conversational program switch, and bypass the calls to the
                              DFSCTRN0 and DFSCTSE0 user exits.

                        Deferred conversational program switches, presented later, also includes
                        information on security processing used with the CHNG call.


5.6.1 CHNG Call Issued from OTMA Transaction
                        If a CHNG call is issued from an OTMA submitted transaction, the destination is
                        assumed to be the same OTMA client (the TPIPE name is set by the CHNG call).
                        This behavior can be altered by the OTMA Prerouting and Destination Resolution
                        exit routines. An IMS application program that issues a CHNG call to an
                        alternate PCB (specifying an options list) does not cause IMS to call the OTMA
                        Prerouting and Destination Resolution exit routines to determine the destination.
                        However, an IMS application program that issues a CHNG call to an alternate
                        PCB (specifying an APPC descriptor) does cause IMS to call the OTMA exit
                        routines to determine the destination. The application program can still issue
                        ISRT calls to the I/O PCB to send data to an OTMA destination.




122   IMS V6 Security Guide
5.7 Deferred Conversational Program-to-Program Message Switches
               A conversational program can use a deferred program switch or an immediate
               program switch. During a deferred program switch, the program responds to the
               originating terminal but causes the next input from the the terminal to go to
               another conversational program.

               IMS conversational deferred program switches (that occur in the same IMS as
               the inputting terminal) perform an authorization check to determine whether the
               user who entered the transaction is authorized to use the IMS resource. RACF
               or SMU may be used for authorization checking.

               To perform a RACF authorization from the dependent region, a security
               environment first must be established. If the dependent region is part of the
               same IMS as the inputting terminal, and the user who entered the transaction is
               still signed on, then the security environment that is created in the IMS control
               region at sign-on is used for the authorization call. The security environment that
               is created at sign-on is not available under the following conditions:
                •   The dependent region is part of the same IMS as the inputting terminal, but
                    the user has signed off.
                •   The dependent region is part of another IMS, connected to the IMS with the
                    inputting terminal by an MSC link.
                •   The dependent region is part of another IMS in a sysplex with IMS shared
                    message queues support.

               In these conditions, the security environment must be dynamically created in
               order to perform the RACF authorization check. The dynamically created
               security environment is kept until IMS is done with the message (until the next
               sync point or GET UNIQUE).

               The user ID used for authorization follows the same methodology for CHNG calls
               and ICMD calls.

               Using SMU to secure transactions for an LTERM provides security only for the
               IMS on which the security check is being made (local or front-end IMS), and only
               if the resources are defined to that IMS. IMS back ends can use SMU LTERM
               security for the CHNG call and for deferred conversational program switches. In
               general, SMU can be used for security only if the control blocks that are required
               for the security check are local to the IMS that is making the check.

               The DFSBSEX0 exit routine may be used to control authorization checking in a
               dependent region. The DFSBSEX0 exit routine can be used to request that IMS
               bypass some part of the security processing in the dependent region when a
               deferred conversational program switch occurs for a message that did not
               originate from an OTMA or LU6.2 device. In an IMS dependent region, IMS may
               invoke the SAF interface (RACF, or equivalent product) on a CHNG call, an AUTH
               call, and a deferred conversational program switch. Use of the DFSBSEX0 exit
               can cause IMS to bypass the dynamic creation of the security environment. In
               this case, the default security environment of the IMS control region or the IMS
               dependent region is used for the SAF call. If the processing for this return call is
               running in cross memory mode (it is not a BMP or is not running with LSO=Y),
               the processing uses the security environment of the dependent region. In IMS
               5.1, the security environment of the Control Region was always used as the
               default.


                                                            Chapter 5. Securing IMS Transactions   123
5.8 DL/I APSB Call Transaction Authorization
                        The Allocate PSB (APSB) call is used to allocate a PSB for a
                        CPI-Communications-driven application program. These types of applications
                        programs are used for conversations that include LU 6.2 devices.

                        In CPI-Communications-driven application programs, resource access security
                        (AGN authorization checking) can restrict the use of a PSB by using the AGN. If
                        the PSB is an unauthorized resource, IMS rejects the DL/I allocate PSB (APSB)
                        call but does not abend the program.

                        APSB security has been enhanced to handle this problem and provide user ID
                        verification for the APSB call. The enhancement will be discussed in
                        Chapter 11, “IMS Version 6 Security Enhancements” on page 191. This
                        enhancement provides the ability to authorize a particular CPI-C-driven
                        application program access to PSBs regardless of what region the program is
                        running in or what the associated AGN table for that region specifies.


5.8.1 APSB Security Errors
                        The following types of security errors can be encountered when applications
                        issue the APSB call. The DL/I return/reason codes and descriptions are listed for
                        your convenience.
                        DL/I Code      Description
                        0108/0308      IMS encountered a PSB authorization failure while attempting to
                                       allocate the PSB. Security checking used the application group
                                       name (AGN) table. Either the AGN table did not exist or the PSB
                                       name was not defined in the table.
                        0108/032C      During PSB allocation, an invalid processing intent was
                                       encountered.
                        0110/0050      A CPI-C-driven application issued an APSB call. IMS determined
                                       that the user ID is not authorized by RACF (or its equivalent) to use
                                       the PSB. Field AIBERRXT of the AIB contains additional
                                       information.



5.9 Summary
                        This chapter covered the following topics:

                          •   Securing IMS Transactions
                              IMS transactions may be secured using RACF, SMU, DFSCTRN0, a
                              combination of RACF/DFSCTRN0, or a combination of SMU/DFSCTRN0.
                          •   IMS restart options that affect transaction authorization using RACF
                              The transaction authorization options are set from:
                              −   The checkpoint log record for emergency restarts and warm starts
                              −   The SECURITY macro, DFSPBxxx overrides, and MTO entered
                                  TRANAUTH/NOTRANAUTH override keyword specifications for cold starts
                                  (/NRE CHKPT 0 or /ERE COLDSYS)
                          •   The impact of sign-on requests on transaction authorization processing using
                              RACF



124   IMS V6 Security Guide
    The sign-on process provides a user ID, password, and optionally a group
    name to IMS. When the terminal user performs sign-on (or an exit performs
    sign-on for the user), a security environment is created for the user until
    sign-off occurs. IMS uses the security environment when issuing the
    RACROUTE request to RACF for transaction authorization checking.
    If RACF is used for transaction authorization, the user must perform sign-on
    (to supply a user ID, and optionally a group name). SMU cannot perform
    user ID verification, as it is terminal-based security.
•   RACF Security Checking for IMS transactions
    The RCLASS= value on the security macro determines the RACF class
    names. The default for RCLASS= is ′IMS′, which results in RACF class
    names of TIMS and GIMS for IMS transactions. TIMS and GIMS RACF
    classes contain security profiles for IMS transactions. When sign-on has
    been performed and transaction authorization is active in an IMS subsystem,
    IMS invokes RACF upon entry of each transaction code. RACF checks the
    TIMS/GIMS classes for the existence of a security profile for the transaction.
    The name assigned to the transaction code (TRANSACT macro) is the name
    of the security profile in the TIMS class. Transactions having identical
    groups of user IDs/group names may be listed/grouped under one security
    profile in the GIMS (grouping IMS) class.
    RACF returns a return/reason code to IMS for unauthorized users, a zero
    return code for authorized users, and a security profile not found condition
    code for unprotected transactions. IMS allows the user to execute a
    transaction that is classified as ″unprotected″. Additional security may be
    provided in the area of transaction authorization when the RACF ′REVERIFY′
    option is specified in the APPLDATA section of the security profile. This
    feature requires the user to enter his or her RACF password along with the
    transaction, each time the transaction code is entered.
•   DL/I CMD and ICMD calls transaction authorization processing using RACF
    IMS application programs that issue IMS commands must use either the DL/I
    ICMD or DL/I CMD call. Installations may also use DFSCCMD0 for
    authorizing AO programs to issue IMS commands. And, DFSCCMD0 may be
    used in conjunction with RACF or SMU. If the exit is used with RACF or
    SMU, it is called after RACF or SMU, and DFSCCMD0 ultimately decides
    whether to allow/disallow the AO program to issue the command.
    The user ID used for authorizing AO programs to issue IMS commands
    depends on several factors, for example, whether the user is signed on.
    DL/I CMD call security is provided by SMU facilities. AO
    transactions/programs are defined using CTRANS and TCOMMAND input
    statements to the SMU utility. The transactions/commands could also have
    been protected by assigning a password to the transaction, restricting which
    LTERMs can be used to input the transaction, or both. The number of
    passwords and LTERMs that can be defined using SMU have a finite limit,
    usually around 65,535 for each.
    The DL/I ICMD call security is provided by RACF. User ID verification (the
    user that submitted the transaction) is performed. IMS is notified that RACF
    is to be called for authorizing AO programs issuing an ICMD call when
    AOIS= parameter of DFSPBxxx has a value that specifies RACF (or RACF
    and DFSCCMD0).
•   DL/I CHNG call transaction authorization processing using RACF



                                            Chapter 5. Securing IMS Transactions   125
                              When the CHNG call is used to ISRT to an alternate modifiable PCB, IMS
                              Transaction Manager automatically does some security checking. When you
                              issue the CHNG call to set the destination of the alternate modifiable PCB,
                              the user that entered the transaction code that caused the message switch
                              must be authorized to enter the transaction code that the CHNG call places
                              in the alternate modifiable PCB. IMS TM does not do any security checking
                              when you issue the ISRT call.
                              The user ID used in authorization checking depends on the same factors
                              cited for ICMDs.
                              CHNG calls issued from back-end systems (shared queues group or MSC
                              systems) do not have the security environment established for performing a
                              security check. Therefore, the installation can choose to have the security
                              environment dynamically established in the dependent region, or to bypass
                              security checking using the DFSBSEX0 installation coded security exit
                              routine.
                          •   APSB security
                              If AGN security is active in a dependent region where a CPI-C program has
                              been scheduled and the CPI-C program issues the APSB call, a security
                              failure may occur if the requested PSB has been secured as part of an AGN
                              group. The APSB security facilities have been enhanced to eliminate this
                              problem when IMS V6 is used with RACF 1.9.2 or higher.




126   IMS V6 Security Guide
Chapter 6. IMS Databases and IMS Data Sets

                         IMS databases can be protected using SMU, RACF or during the PSB generation
                         (PSBGEN) process. This chapter describes how the various options can be
                         implemented.

                         IMS data sets can be secured using RACF.



6.1 SMU
                         Protecting the /LOCK and /UNLOCK commands is a way access to a database
                         can be controlled. If a database is locked, a user would need to be authorized to
                         issue the /UNLOCK command in order to access it. When access to the
                         database is no longer required, the /LOCK command can be issued to prevent it
                         from being accessed by an unauthorized user ID. The /LOCK and /UNLOCK
                         commands can be password protected also using SMU or DFSCCMD0.

                         SMU can be used to password protect IMS databases. The following is an
                         example of how to assign a password to a specific database:


                             )( DATABASE     ACCTLOG
                                 PASSWORD    LOG

                         Once the database has been password protected using SMU, the /LOCK
                         command can be issued to prohibit use of the database.


                              /LOCK DATABASE ACCTLOG(LOG)

                         Note that the database password was supplied on the /LOCK command. If the
                         LOG password had not been supplied with the /LOCK command, IMS would not
                         have locked the database. Before a command (that accesses the database) is
                         accepted, you can require an accompanying password. (The accompanying
                         password was assigned above in the SMU GEN input statements.) The
                         password is entered within parentheses immediately following the command
                         verb or keyword. The password protection provided by the security maintenance
                         utility (SMU) prevents a change of status of the database by the /LOCK or
                         /UNLOCK command unless the correct password is supplied on the command.

                         LOCK prevents subsequently scheduled programs from accessing the database.
                         /LOCK DATABASE does not close the database or affect currently scheduled
                         programs. If the database is a DEDB or MSDB, programs using the database
                         will not be scheduled. For other databases, the programs will still be scheduled.
                         If the INIT call was issued, a call against the database will result in a BA status
                         code, otherwise a pseudo abend U3303 occurs. For DBCTL, CCTL can specify
                         LONG or SHORT when it schedules a PSB. If the database is currently scheduled
                         to a LONG thread, the command is rejected. If not, the thread completes before
                         the command is acted upon. For the results of issuing this command on a
                         shared secondary index, see Appendix D, Shared Secondary Index Database
                         Commands of the IMS/ESA Operator ′ s Reference , SC26-8742.

                         Certain commands that successfully alter IMS resources are written to the
                         system log as X′02′ records and are reprocessed during emergency restart.



© Copyright IBM Corp. 1999                                                                              127
                        /LOCK is such a command; therefore, it is reprocessed during emergency
                        restart.

                        The database can be unlocked using the /UNLOCK DATABASE command, as
                        shown in the example below:


                              /UNLOCK DATABASE ACCTLOG(LOG)

                        UNLOCK releases resources that, in most cases, have been previously locked by
                        a /LOCK command. IMS/ESA Operator ′ s Reference , SC26-8742, contains
                        descriptions of the exceptions. UNLOCK DATABASE is valid only if entered from
                        the master terminal, the system console, a TCO script, or an AOI application
                        program. For the results of issuing this command on a shared secondary index,
                        see Appendix D, Shared Secondary Index Database Commands of IMS/ESA
                        Operator ′ s Reference , SC26-8742.

                        Use of the /LOCK and /UNLOCK commands to prohibit access to IMS databases
                        is global in scope and affects all users of the database.
                          •   When the databases are locked, access by all users is disallowed.
                          •   When the databases are unlocked, access by all users is allowed.
                        The PSBGEN process and RACF provide more robust security for IMS databases.



6.2 PSBGEN
                        An IMS application program can only access data to which it is sensitive. You
                        can control access to the data on three levels:
                          •   Segment Sensitivity can be used to prevent an application program from
                              accessing segments within a particular database.
                          •   Field Level Sensitivity can be used to prevent an application program for
                              accessing fields within a particular segment.
                          •   Key Sensitivity can be used to allow a program to access segments below a
                              segment to which it has no access.

                        Segment and field level sensitivity are defined in the PSB for the application
                        program. Key sensitivity is defined in the processing option for the segment.
                        Processing options indicate to IMS exactly how a particular program may
                        manipulate the data.


6.2.1 Segment Sensitivity
                        This tells IMS which segments in a hierarchy the program is allowed to access,
                        using the SENSEG statement. You define the database hierarchy in the DBD.
                        You also specify a processing option for each hierarchy that the application
                        program processes, and this is done within the DB PCB that represents each
                        hierarchy. You can specify one processing option for all the segments in the
                        hierarchy. Or alternatively, you can specify different processing options for
                        individual segments within the hierarchy.

                        Access to the segment is controlled by the way the PCB and the parameter
                        values for the PROCOPT keyword have been specified. The PROCOPT parameter
                        keyword can have a maximum of four values assigned to it.




128   IMS V6 Security Guide
                 Refer to the IMS/ESA Utilities Reference: System , SC26-8770 for more information
                 regarding the PROCOPT parameter and its use with Fast Path.


6.2.2 Field Level Sensitivity
                 DBDs and PSBs can be coded to tell IMS which fields within a particular
                 segment a program is allowed to access using the SENFLD statement. You may
                 wish to do this if the segment contains fields with confidential information and
                 the program is not required to access them all. By defining a segment for the
                 application with only the required fields, you prevent the program from
                 accessing the ones that aren′t required. Field level sensitivity acts as a mask for
                 the fields to which you want to restrict access. Also it can be used to control the
                 replace function at the field level to help ensure database integrity.


6.2.3 Key Sensitivity
                 To access a particular segment, an application program must have access to all
                 the segments at a higher level in the segment hierarchy. If you want a program
                 to access a segment that′s below a segment it cannot access, you must use key
                 sensitivity. When a sensitive segment statement has a processing option of K, it
                 cannot access that segment but can pass beyond that to the segment′ s
                 dependents. When the program accesses the dependents, IMS returns the
                 segment′s key that′s been accessed to the program.




                                                       Chapter 6. IMS Databases and IMS Data Sets   129
6.2.4 PSB Generation Example
                        Figure 19 is an example of how Segment and Field Level Sensitivity can be
                        specified in a PSB generation. Segment2 is comprised of two fields, FLD1 and
                        FLD2.



                                                     ┌─────────────┐
                                                     │             │
                                                     │ SEGMENT1 │
                                                     │             │
                                                     └──────┬──────┘
                                                            │
                                     ┌──────────────────────┴──────────────────────┐
                                     │                                             │
                                     │                                             │
                              ┌──────┴──────┐                               ┌──────┴──────┐
                              │             │                               │             │
                              │ SEGMENT2 │                                  │ SEGMENT3 │
                              │             │                               │             │
                              └─────────────┘                               └─────────────┘


                        Figure 19. Sample Database Structure



                        //PSBGEN JOB MSGLEVEL=1
                        //       EXEC PSBGEN,MBR=APPLPGM1
                        //C.SYSIN DD *

                                       PCB      TYPE=DB,DBDNAME=EGDBD1,PROCOPT=GRP,KEYLEN=20
                                       SENSEG   NAME=SEGMENT1,PARENT=0
                                       SENSEG   NAME=SEGMENT2,PARENT=SEGMENT1
                                       SENFLD   NAME=FLD1,START=1
                                       SENFLD   NAME=FLD2,START=10
                                       SENSEG   NAME=SEGMENT3,PARENT=SEGMENT1
                                       PSBGEN   LANG=ASSEM,PSBNAME=EGPCB1
                                       END
                        /*




6.3 RACF
                        RACF can be used to protect both the database and the data sets that make up
                        an IMS database. The RACF database classes PIMS/QIMS, SIMS/UIMS,
                        FIMS/HIMS, and OIMS/WIMS are used to protect IMS databases, and the RACF
                        DATASET class is used to protect individual data sets. The database classes are
                        used exclusively by IMS systems, whereas the RACF DATASET class can be
                        used by many MVS subsystems.

                        Installations desiring to implement application-based security have the option of
                        using the DL/I AUTH call which is used with the RACF classes for databases (for
                        example, PIMS). IMS applications may issue the DL/I AUTH call to check the
                        database security but are not required to honor the RACF return code.
                        Applications that do not use the DL/I AUTH call may continue to access the
                        database as allowed by their PSBs. The IMS database can be secured using the
                        database classes only when application provided security (using the DL/I AUTH


130   IMS V6 Security Guide
               call) is in place. This is true for each of the following RACF classes used to
               secure IMS databases:
                •    PIMS/QIMS (secures IMS database at database record level)
                •    SIMS/UIMS (secures segment(s) in an IMS database record)
                •    FIMS/HIMS (secures field(s) in an IMS database segment)
                •    OIMS/WIMS (secures other user defined segment(s)/field(s) in an IMS
                     database record)

               When IMS data sets comprising a database (or even IMS system data sets) are
               secured using the DATASET class, the application does not have to perform any
               authorization checking. Nor does the application have to issue an AUTH call.
               Refer 6.3.3, “Securing IMS Data Sets” on page 135 for additional information.


6.3.1 Database Records, Segments and Fields
               The DLISAS or control-region started task user ID must be authorized to access
               IMS databases secured using the PIMS/QIMS, SIMS/UIMS, FIMS/HIMS, and
               OIMS/WIMS RACF classes. If the IMS system address spaces are started as
               batch jobs, the user ID is supplied on the USER= parameter in the JCL used to
               start the job. In this case the USER= user ID specification should be
               PERMITTED to the RACF security profiles in PIMS/QIMS, SIMS/UIMS, FIMS/HIMS,
               and OIMS/WIMS. This access is dependent on the type of environment that is
               executing. The user ID requires UPDATE access to the database unless it′ s
               VSAM in which case CONTROL access is necessary. Examples are provided
               below for creating security profiles and authorizing groups/user IDs in the RACF
               PIMS/QIMS, SIMS/UIMS, FIMS/HIMS, and OIMS/WIMS RACF classes.

               This example shows how to grant group access (GROUPX) to a group of
               databases (REG1DB, REG2kDB and REG3DB) secured by a profile (CUSTDBS) in
               the database grouping class (QIMS)


                    RDEFINE QIMS CUSTDBS UACC(NONE)
                    RALTER QIMS CUSTDBS ADDMEM(REG1DB REG2DB REG3DB)
                    PERMIT CUSTDBS CLASS(QIMS) ID(GROUPX) ACCESS(READ)
               The following example shows how to grant group READ access (GROUPY) to a
               database segment (CUSTNAME) secured by profile (CUSTNAME) in the segment
               (SIMS) class. The example also shows the DLISAS region has been authorized
               to update the CUSTNAME segment.


                    RDEFINE SIMS CUSTNAME UACC(NONE)
                    PERMIT CUSTNAME CLASS(SIMS) ID(GROUPY) ACCESS(READ)
                    PERMIT CUSTNAME CLASS(SIMS) ID(DLISAS) ACCESS(UPDATE)
               The following example shows how to grant group READ access (GROUPZ) to a
               database field (ACCTNO) secured by profile (ACCTNO) in the field (FIMS) class.
               The example also shows the DLISAS region has been authorized to update the
               ACCTNO field.


                    RDEFINE FIMS ACCTNO UACC(NONE)
                    PERMIT ACCTNO CLASS(FIMS) ID(GROUPZ) ACCESS(READ)
                    PERMIT ACCTNO CLASS(FIMS) ID(DLISAS) ACCESS(UPDATE)

               The following describes the access requirements for different database types:



                                                      Chapter 6. IMS Databases and IMS Data Sets   131
                          •   VSAM full function database
                              −   Online Environment — If a user ID is used for the DLISAS started
                                  procedure, it requires authorization. If a user ID is not used for DLISAS,
                                  the control region′s user ID is utilized.
                              −   Batch Environment — The user ID submitting the job requires
                                  authorization.
                          •   OSAM full function database
                              −   Online Environment — The DLISAS started task user ID requires access.
                              −   Batch Environment — The user ID submitting the job requires access.
                          •   Fast Path DEDBs
                              −   Online Environment — The control region′s started task user ID requires
                                  access.
                              −   Batch Environment — Not applicable.




132   IMS V6 Security Guide
6.3.2 DL/I AUTH Call Protection
                The RACF database can be used to store user-unique information. The AUTH
                call gives application programs access to the RACF database security data, and
                a way to control access to application-defined resources. Thus, application
                programs can obtain security information about a particular user.

                This type of security checking is at the discretion of the application. The PIMS,
                SIMS, FIMS and OIMS classes can only be used to protect databases that are
                accessed via DL/I AUTH calls. There is no direct relationship between IMS and
                these classes and IMS will not attempt verification on any of the resource names
                defined for these classes or used in the AUTH call. The resources only have
                meaning to the application, and the relationship needs to be defined for each
                application using the DL/I AUTH call. Table 24 describes the various resources
                and the RACF classes that can be used to protect them:

                 Table 24. RACF Protection of IMS Resources from DL/I AUTH Calls
                 Resource         RACF Class       RACF             Protects
                                                   Grouping
                                                   Class
                 Database         PIMS             QIMS             Logical sections of a database
                 Segment          SIMS             UIMS             Segments within a database
                 Field            FIMS             HIMS             Fields within a segment
                 Other            OIMS             WIMS             Installation defined resources
                 Note: PIMS, SIMS, FIMS and OIMS are RACLISTed only when TIMS is RACLISTed.
                 The classes must first be activated.


                Table 25 provides an example of how RACF can be used to protect the data
                within a database. Database ABC is broken into two logical sections called
                LOGIC1 and LOGIC2. LOGIC1 has one segment and two fields; LOGIC2 has two
                segments. All the resources need to be protected by RACF;

                 Table 25. RACF Protection of Database Resources
                 Generic          Resource         RACF Command
                 Name
                 DATABASE         LOGIC1           PERMIT LOGIC1 CLA(PIMS) ID(uuuuuu)


                 SEGMENT          SEG11            PERMIT SEG11 CLA(SIMS) ID(uuuuuu)


                 FIELD            FLD11            PERMIT FLD11 CLA(FIMS) ID(uuuuuu)
                 FIELD            FLD12            PERMIT FLD12 CLA(FIMS) ID(uuuuuu)
                 DATABASE         LOGIC2           PERMIT LOGIC2 CLA(PIMS) ID(uuuuuu)


                 SEGMENT          SEG21            PERMIT SEG21 CLA(SIMS) ID(uuuuuu)


                 SEGMENT          SEG22            PERMIT SEG22 CLA(SIMS) ID(uuuuuu)


                 Note: This assumes the RACF profiles have been defined already with RDEFINE
                 xIMS nnnnn UACC(NONE), where nnnnn is the resource name and x is the type of
                 RACF class being defined. RACF grouping profiles can be implemented in the same
                 manner, however, the grouping name is arbitrary and the resources need to be
                 ADDMEMed to it.


                                                      Chapter 6. IMS Databases and IMS Data Sets     133
                        In this scenario, the PIMS class protects the logical partitions of the database;
                        represented by resource LOGIC1 and LOGIC2. Class SIMS protects segments
                        SEG11, SEG21, SEG22 and class FIMS protects the fields FLD11 and FLD12. RACF
                        user IDs or groups need to be permitted to these resources as necessary.

                        To determine whether the user of a transaction has been granted access to a
                        resource, the application issues a DL/I AUTH call with a generic name of
                        DATABASE, SEGMENT or FIELD and a resource name of LOGIC1, SEG21, FLD11
                        and so forth.

                        If the user ID has access to the resource defined in RACF, the application
                        receives a PCB status code of blanks allowing the user ID to access the data. If
                        the user ID doesn′t have access, a status code of A4 is returned to the
                        application and access is denied. Other types of security errors can occur when
                        using the AUTH call. The DL/I return and reason codes and descriptions of the
                        error codes are shown below:

                        DL/I AIB Return     DL/I AIB        Description
                                            Reason Code
                        0108                00224           Security UTOKEN not found.
                        0108                0080            An ACEE could not be created for the authorization
                                                            check for the AUTH call.
                        0110                000C            The user is not authorized for access to the
                                                            resource name in the class requested in the AUTH
                                                            call. No ″installation data″ is returned.

                        The RACF class OIMS, associated with the generic class of OTHER, can be used
                        to represent other resources the application may wish to protect. An example of
                        this could be views of DB2 tables. The level of protection you implement is
                        dependent on the granularity you are trying to achieve.

                        An Authorization (AUTH) call verifies each user′s security authorization. It
                        determines whether a user is authorized to access the resources specified on
                        the AUTH call. AUTH is issued with an I/O PCB and its function depends on the
                        application program. Authorization checking depends on the dependent region
                        type and whether a GU call has been issued. The call functions are:
                          •   In BMPs, AUTH uses the user ID of the IMS control region or installation
                              specific user exits to determine the status of the call.
                          •   For BMPs that have issued a successful GU call to the I/O PCB, AUTH
                              functions as it does in an MPP.
                          •   In MPPs, AUTH verifies user authorization with RACF for the specified
                              resource classes of those resources used by the application program.

                        Because the call can request RACF user data to be passed back in the I/O area
                        as installation data, the processing of the call always results in changes to the
                        STATUS field in the I/O area. This STATUS field notifies the application of the
                        status of installation data in the I/O area: available or not available. It might not
                        be available because the installation data is not defined or the originating user is
                        no longer signed on to the IMS system.

                        Either of the supported security exits for transaction authorization (DFSCTRN0 or
                        DFSCTSE0) can present installation data upon return to IMS. If an exit returns
                        installation data, the data is returned to the application even if the parameter list
                        did not contain the USERDATA parameter. The STATUS field is set to indicate



134   IMS V6 Security Guide
                the origination of the installation data. The STATUS field indicates the presence
                of either RACF installation data or security exit installation data.

                The application program also receives notification of the actual RACF return
                code. This return code, presented as FEEDBACK in the I/O area, can be used by
                the application program to detect inconsistent operational modes and take
                alternate action. Examples of inconsistent operational modes are the proper
                RACF classes not being defined or the requested resource not properly defined
                to RACF.

                By checking the FEEDBACK, EXITRC, and STATUS in the I/O area, the
                application program can be sensitive to issues such as the proper RACF
                definitions and resources not being defined. If RACF is being used, and the
                AUTH call references any resources that are not defined, the PCB status code is
                set to blanks and the FEEDBACK field of the I/O area is set to indicate that the
                resource is not protected.

                Because the value for EXITRC is provided by a user security exit, use of this field
                must be made with an understanding of exit operation and the knowledge that
                any changes to the exit can result in application errors. If due to operational
                errors, the proper resources are not protected, the application can deal with the
                error in any way. This feedback can make operational control simpler and give
                the application more flexibility.

                The DL/I AUTH call is a DC function and is of little value (prior to IMS V6) if a
                user is not currently signed on to a terminal when the transaction executes. IMS
                V6 addresses this limitation as IMS can dynamically create the security
                environment in the dependent region when the user is not currently signed on to
                a terminal when the transaction executes.

                Since some BMPs perform message processing functions identical to MPP
                regions, these BMPs can utilize the AUTH call in the same way as the MPP
                regions. If the BMP is not transaction driven, the AUTH call has little value.
                Prior to IMS V6, any AUTH calls issued in this environment result in the user ID
                of the IMS control region being used to control the access to the database. (In
                IMS V6, with the BMPUSID= parameter of the DFSDCxx member, the user ID of
                U S E R = on the JOB card can be used.) It may be possible to utilize the
                Security Reverification Exit routine, DFSCTSE0, to provide more flexibility if the
                authorization function is required for a BMP that is not processing transactions.


6.3.3 Securing IMS Data Sets
                Securing IMS databases using the RACF PIMS/QIMS, SIMS/UIMS, FIMS/HIMS,
                and OIMS/WIMS classes was covered in the previous topic. One of the
                considerations for securing databases in the database classes is that the
                installation requires application-based security. Application programs need to
                issue the DL/I AUTH call to utilize the above RACF classes.

                Securing IMS data sets in the DATASET class does not require the use of an
                application-based security product, nor is the DATASET class used in conjunction
                with the AUTH call. Installations that do not require application-based security
                may want to consider securing data sets in the RACF DATASET class. IMS
                system data sets, user application program libraries, and database data sets
                may be secured using the DATASET class.




                                                       Chapter 6. IMS Databases and IMS Data Sets   135
                        The Add Dataset Descriptor (ADDSD) RACF command is used to define security
                        profiles for data sets in the DATASET class. Profiles in the DATASET class may
                        be discrete (fully qualified data set name) or generic. Refer to RACF
                        publications for determining whether discrete or generic data set profiles are
                        required by your installation. The following examples show how to use the
                        RACF DATASET class to secure IMS system data sets:


                         ADDSD ′ PARTS.DBDS′    UACC(NONE) GENERIC
                         PERMIT ′ PARTS.DBDS′   ID(IMSCTRL DLISAS) ACCESS(UPDATE)


                         ADDSD ′ IMS.RESLIB′    UACC(NONE) GENERIC
                         PERMIT ′ IMS.RESLIB′   ID(IMSCTRL DBRC DLISAS) ACCESS(UPDATE)


                        As with other RACF classes, you must make sure the DATASET class has been
                        activated (using the SETROPTS command) and refresh the in-storage security
                        information used by RACF and/or IMS.

                        Figure 20 provides an example of the errors that may be encountered if a
                        terminal user tries to access a transaction when the DLISAS region has not been
                        authorized to the database (or data set):



                          ERROR RETURNED TO USER′ S TERMINAL

                          Unresolved DL/I Status ″AI″ on call GU against DBPCB DBPCB01
                          Return Code=0900 Reason Code=0000 Date=mm/dd/yy Time=00:00:00
                          Probable Cause: Data management OPEN error
                          IMS ID=IMSR      Release=610 Type=DB/DC     Region=MPP      Id=1
                          Program=DFSSAM02 PSB=DFSSAM02 Tran=PART     Userid=IMS35    Group=IMSUSE


                          ERRORS RETURNED TO MVS CONSOLE/SDSF LOG

                          ICH408I USER(IMSDLI) GROUP(STC) NAME(DLISAS STARTED TASK) 818
                            IMS.APPL.DI21PART CL(DATASET ) VOL(TOTIM5)
                            INSUFFICIENT ACCESS AUTHORITY
                            FROM IMS.APPL.DI21PART (G)
                            ACCESS INTENT(CONTROL) ACCESS ALLOWED(NONE )
                          DFS0735I SAF ACCESS FAILED-R01 DI21PART-DI21PART RC=056,REASON=0006
                                  IMSR
                          DFS0730I UNABLE TO OPEN DATA SET WITH DDNAME DI21PART FOR REASON R,01
                           DATABASE DI21PART TRN PART     IMSR


                        Figure 20. Sample Access Error to VSAM Database

                        The DFS error messages indicate that the database could not be accessed
                        because RACF did not allow IMS to access the database (with the DDNAME of
                        DI21PART) at the required level.




136   IMS V6 Security Guide
6.3.4 Summary
                IMS data can be protected (or have access to them stopped) in several ways:
                 •   Using SMU to assign a password to the database, and stopping access to the
                     database by locking it. Users authorized to lock or unlock the database are
                     given the database password, which is required on the /LOCK and /UNLOCK
                     commands once the database has been password protected.
                 •   RACF can be used with application-based security programs that will issue
                     the DL/I AUTH call to ensure that the user ID of a signed-on user is
                     authorized to the data.
                 •   RACF can also be used to secure data in the DATASET class. The IMS
                     address space that owns the DD statements for the data sets is authorized
                     (PERMITTED) to the data sets in this class.

                Installations have a choice of whether databases/database data sets should be
                secured in the DATABASE/SEGMENT/FIELD/OTHER or in the DATASET class.
                One criterion for deciding which class(s) to implement is whether
                application-based security is required. The DATABASE, SEGMENT, FIELD, and
                OTHER classes in conjunction with the security provided by the application
                issuing the AUTH call, support verification of whether the user ID (of the users
                that submitted the transaction) is authorized to access the database. Securing a
                database′s data sets in the DATASET class does not verify whether the user ID
                of the terminal user is authorized to the data sets. Using the DATASET class, if
                the IMS control region or the DLISAS region is authorized to a data set, the user
                can access the data if he/she is authorized to submit the transaction that caused
                the data set to be accessed.




                                                      Chapter 6. IMS Databases and IMS Data Sets   137
138   IMS V6 Security Guide
Chapter 7. Securing Access to the IMS System

                         This chapter describes how to prevent unauthorized access to the IMS system.
                         The topics covered are:
                             •   Protecting system data sets
                             •   Protecting the IMS control region
                             •   Restricting access to dependent regions



7.1 Protecting System Data Sets
                         RACF should be used to protect the system data sets and user application
                         program libraries from unauthorized use. This ensures only the people
                         responsible for maintaining IMS can make changes to the various data sets. The
                         data sets will need to be protected per your installation requirements. IMS
                         system data sets can be protected in the RACF DATASET class. The ADDSD
                         RACF command is used to add security profiles for data sets in the DATASET
                         class. A couple of examples are listed in Figure 21:



                             1) ADDSD ′ IMS.**′ OWNER(IMS)
                                PERMIT ′ IMS.**′ ID(IMSPROG STCIMS) ACCESS(ALTER)


                             2) ADDSD ′ IMS.PSBLIB′ GEN OWNER(IMS)
                                PERMIT ′ IMS.PSBLIB′ GEN ID(IMSPROG) ACCESS(ALTER)
                                PERMIT ′ IMS.PSBLIB′ GEN ID(STCIMS) ACCESS(READ)

                                   ADDSD ′ IMS.MATRIX′ GEN OWNER(IMS)
                                   PERMIT ′ IMS.MATRIX′ GEN ID(IMSPROG) ACCESS(ALTER)
                                   PERMIT ′ IMS.MATRIX′ GEN ID(STCIMS) ACCESS(UPDATE)

                                   ADDSD    ′ IMS.xxxxxx′   GEN   OWNER(IMS)
                                   PERMIT   ′ IMS.xxxxxx′   GEN   ID(IMSPROG)   ACCESS(aaaaaa)
                                   PERMIT   ′ IMS.xxxxxx′   GEN   ID(STCIMS)    ACCESS(aaaaaa)
                                   PERMIT   ′ IMS.xxxxxx′   GEN   ID(IMSDBA)    ACCESS(aaaaaa)
                                   PERMIT   ′ IMS.xxxxxx′   GEN   ID(IMSPROD)   ACCESS(aaaaaa)
                                   PERMIT   ′ IMS.xxxxxx′   GEN   ID(uuuuuu)    ACCESS(aaaaaa)


                             Where xxxxxx represents other qualifiers in the data set name,
                             uuuuuu represents other groups/user IDs, and aaaaaa represents
                             the level of access required.

                         Figure 21. IMS Data Sets Protection

                         In the first scenario, a basic profile has been created to protect all IMS system
                         data sets. This assumes that they all start with a high level qualifier (HLQ) of
                         IMS. The IMS system programming group (IMSPROG) and the IMS started task
                         user ID (STCIMS) have been granted ALTER access to all the data sets. While
                         there isn′t much granularity in the protection provided by this profile, the system
                         has been secured from general user access.




© Copyright IBM Corp. 1999                                                                               139
                              Note
                          IMS generally doesn′t require ALTER access to system data sets, however, if
                          you are using generation data groups (GDGs) for your recovery log data sets
                          (RLDSs), system log data sets (SLDSs) or other data sets, ALTER access
                          must be granted.


                        In the second scenario, more fully qualified profiles have been created allowing
                        you to tailor your requirements as needed. For example, you may not want the
                        IMS system programmers to have ALTER access to all the IMS libraries and
                        there may be a couple of libraries you want your DBAs or an automated batch
                        procedure to read or update.



7.2 Protecting the IMS Control Region
                        The APPL class in RACF can be used to restrict access to an IMS control region
                        to just those users who need the access. This can be accomplished by issuing
                        the following command:
                              RDEFINE APPL xxxx UACC(NONE)

                              PERMIT xxxx CLASS(APPL) ID(uuuuuu) ACCESS(READ)

                        In the above example xxxx is equal to the value of the IMSID parameter in the
                        IMSCTRL Macro and uuuuuu is equal to a RACF group/user ID that is being
                        granted access to the system. The IMSID parameter uniquely identifies the
                        control region within a single MVS image;the SYSGEN default is IMSA.

                        IMS supplies the control region′s application identifier to RACF during IMS
                        initialization. RACF checks to see if the user who is signing on has access to the
                        resource defined in the APPL class. If no profile in the APPL class has been
                        defined to RACF, it is assumed that the IMS control region is unprotected. RACF
                        makes this check only at the time a terminal operator uses the /SIGN ON
                        command. When IMS requires users to sign on, all users of a particular IMS
                        control region must be identified, and their user IDs, or the names of the groups
                        to which they belong, must be in the access list for that particular control region
                        security profile in the APPL class.



7.3 Restricting Access to Dependent Regions
                        Application group name (AGN) resource access security prevents the use of
                        unauthorized resources within a dependent region. It stops also the IMS Control
                        Region from starting an unauthorized dependent region.

                        You specify, in the SECURITY macro during system definition, whether AGN
                        resource access security will be included and whether RACF or a user exit
                        routine (DFSISIS0) will be used for the user ID authorization/validation. Table 26
                        on page 141 gives a summary:




140   IMS V6 Security Guide
 Table 26. AGN Function of T y p e = x x x K e y w o r d of SECURITY Macro
 Keyword                          Description
 SECURITY TYPE=NOAGN              No AGN security checking will be performed.
 SECURITY                         AGN security checking is active. RACF will be used to
 TYPE=RACFAGN                     verify the user ID or group authorization to use
                                  resources identified in the AGN.
 SECURITY                         AGN security checking is active. DFSISIS0 will be used
 TYPE=AGNEXIT                     to verity the user ID or group authorization to use
                                  resources identified in the AGN.


You define, through SMU, a list of IMS resources to be secured and assign a
unique application group name (AGN) to each group in the list. The security
maintenance utility (SMU) places the AGNs in a table (in IMS.MATRIXA or
IMS.MATRIXB) the IMS system recognizes. IMS prevents the use of resources
(specified in an AGN group) by a dependent message region unless the
dependent region is authorized to use the resources listed in the AGN group.
RACF or DFSISIS0 must be used to authorize the start of a dependent message
region that will use AGN secured resources.

The SECURITY macro parameter T Y P E = and the IMS execution parameter
I S I S = are used to determine the type of AGN security that will be used. The
ISIS parameter specification in DFSPBxxx can be used to override the SECURITY
macro specifications. Table 27 shows the SECURITY macro keyword settings
and the equivalent ISIS parameters, and how they affect security:

 Table 27. Parameters Used to Secure a Dependent Region
 Parameter               Result
 TYPE=NOAGN              AGN application resource access authorization will not be
 and I S I S = 0         performed by IMS at execution time.
 TYPE=RACFAGN            AGN application resource access authorization will be
 and I S I S = 1         performed by IMS at execution time. RACF/SMU will be called
                         to verify user IDs against AGN profiles in the AIMS class.
 TYPE=AGNEXIT            AGN application resource access authorization will be
 and I S I S = 2         performed by IMS at execution time. DFSISIS0/SMU will be
                         called to verify the user IDs authority to access resources in
                         the AGNs.
 Note:   TYPE=NOAGN is the default in the SECURITY Macro.


Table 28 on page 142 shows how the ISIS parameter setting can be used to
override SECURITY macro TYPE= AGN security specification:




                                           Chapter 7. Securing Access to the IMS System   141
                          Table 28. Overriding the SECURITY Macro AGN Specification
                          JCL (DFSPBxxx) Parameter and Value       SECURITY Macro Override
                          ISIS=0                                   TYPE=RACFAGN
                                                                   TYPE=AGNEXIT
                          ISIS=1                                   TYPE=NOAGN
                          ISIS=2                                   TYPE=NOAGN


                        A dependent region can be authorized to process a group of transactions
                        secured by an AGN. The AGN groups can include the PSBs, transactions and
                        input LTERMs that are valid for the AGN. The resources secured in the AGN
                        group are declared in the input to SMU. You must use RACF or DFSISIS0 also to
                        authorize user IDs, such as the user ID of the dependent region, to use the AGN
                        group.

                        The following examples provide SMU input statements and RACF commands
                        required to implement AGN security. Example 1 shows how to specify the
                        resources that will be included in AGN1. TXN2 and TXN4 can be entered only
                        from the terminal that has LTERM3 assigned to it:


                          Example 1

                                         )( AGN         AGN1
                                             AGTRAN     TXN2
                                             AGTRAN     TXN4
                                             AGLTERM    LTERM3
                          Note: TXN2, TXN4, and LTERM3 are the IMS resources included in the
                          AGN named AGN1. TXN2 and TXN4 can be entered only from LTERM3.

                        Figure 22. AGN Security Definitions

                        Example 2 shows how AGN resource access security using SMU and RACF is
                        implemented for the AGN named APPL8. The AGN named APPL8 has two PSBs,
                        PSB11 and PSB33. PSB11 and PSB33 are named/grouped in the APPL8 using
                        the SMU input statements shown. The AGN group name, APPL8, is secured in
                        the RACF AIMS class by creating a security profile called APPL8 in the AIMS
                        class. The dependent region, IMSBATCH, is authorized to schedule PSB11 and
                        PSB33. Other dependent regions will not be allowed to schedule PSB11 or
                        PSB33 once they have been secured as part of an AGN group unless:
                          •   Additional AGN groups that also contain PSB11 and/or PSB33 are created.
                          •   The additional dependent regions are authorized to the AGN group and
                              specify the AGN name on the AGN= dependent region JCL.
                        The SMU input statements and RACF commands have been illustrated.




142   IMS V6 Security Guide
 Example 2

                   )( AGN       APPL8
                       AGPSB    PSB11
                       AGPSB    PSB33


                   RDEFINE AIMS APPL8 OWNER(IMS)
                   PERMIT APPL8 CLA(AIMS) ID(IMSBATCH)

Figure 23. AGN Security Definitions

Example 2 above illustrated two of the three steps that must be taken to
implement AGN resource access security. Namely, Example 2 showed sample
SMU input and the RACF definitions/commands. The third step that must be
performed is to specify which dependent regions can use resources named in
the AGN group. The specification is done by coding the AGN= parameter on
the dependent region startup JCL to match the AGN group name. Using
Example 2, any dependent regions that are required to schedule PSB11 and/or
PSB33 must have AGN=APPL8 coded as a parameter in the region′s startup
JCL.

In lieu of RACF, DFSISIS0 can be used to authorize the starting of a dependent
region and authorizing groups or user IDs to use the resources in the AGN
group. A dependent region starts when a match occurs between a name entry
(such as APPL8) in the application group name table and the name assigned to
the AGN= keyword of the EXEC statement in the dependent region′s startup JCL
or the CCTL DRA startup table. When the IMS control program calls this exit
routine, two registers contain pointers to the sources that are to be compared by
this exit routine. The sample DFSISIS0 exit routine supplied with IMS must be
replaced or customized with the installation′s AGN authorization specifications.
(The sample routine supplied refuses authorization to all callers by notifying the
IMS control program that an invalid dependent region has tried to start.) The
use of the exit routine is specified by coding the AGNEXIT parameter for the
TYPE keyword in the SECURITY macro.

The following resources can be authorized for use by dependent regions:
 •   BMP regions
     −   Transaction codes
     −   PSBs
     −   Logical terminals
 •   MPP regions
     −   Transaction codes
     −   Logical terminals
 •   IFP regions
     −   PSBs
     −   Logical terminals
 •   CICS DRA Threads
     −   PSBs



                                        Chapter 7. Securing Access to the IMS System   143
                              −   ODBA Threads
                                       - PSBs

                        In order to control the application programs that are authorized to use a
                        dependent region, group them under an AGN, such as APPL8. The JCL that
                        starts up a dependent region stipulates which group of application programs are
                        eligible to be scheduled. Further validation restricts that region′s use to the
                        PSBs, transaction codes, or LTERM names associated with the AGN.

                        Figure 24 gives an example of JCL code that starts a dependent region. In this
                        case it′s the IMSBATCH procedure.



                                  //        PROC MBR=IMSBATCH,PSB=,IN=,OUT=,
                                  //             OPT=N,SPIE=0,TEST=0,DIRCA=000,
                                  //             PRLD=,STIMER=,CKPTID=,PARDLI=,
                                  //             CPUTIME=,NBA=,OBA=,IMSID=IMSA,AGN=APPL8,
                                  //             SSM=,PREINIT=,RGN=56K,SOUT=A,
                                  //             SYS2=,ALTID=,APARM=,LOCKMAX=


                        Figure 24. AGN Security Definitions

                        The use of the AGN ties the two-part protection together. The dependent region
                        and resource authorization are implemented by the SMU and RACF or DFSISIS0.
                        Figure 22 on page 142 and Figure 24 give examples of AGN protection for
                        arbitrary AGN APPL8.

                        To summarize, you can prevent an unauthorized dependent region from starting
                        or from using AGN secured resources by performing the following three steps:
                          •   Code the AGN parameter in the EXEC statement of the dependent region
                              JCL.
                              The AGN= parameter in the JCL is the same name associated with the
                              RACF AIMS AGN security profile name and the AGN name provided on the
                              AGN SMU input control statement.
                          •   Use the security maintenance utility to create an entry in the AGN table, with
                              the same name used by the AGN= parameter on the JCL.
                              Then, if RACF is used, define a security profile for the AGN in the AIMS class
                              and PERMIT the dependent region user ID/group allowed to access the AGN.
                              A different AGN must be assigned to every BMP or CCTL region.
                          •   For SMU and RACF AGN secured environments, create a RACF user ID for
                              the dependent region using the RACF ADDUSER command.
                              A different user ID is assigned to the job cards of all dependent region JCL.
                              These user IDs must be defined in RACF. All AGN names assigned to
                              dependent region JCL are logically related to the AIMS class in RACF. RACF
                              connects the user ID to its appropriate AGN source. RACF prevents starting
                              a dependent region if the user ID of the started task is not permitted.
                              Alternatively, for SMU and DFSISIS0 to authorize the region,the exit routine
                              must compare the AGN entries in the application group name table to the
                              AGN name associated with the started task. A mismatch prevents starting
                              the dependent region.

                        Two important concepts to understand about AGN resource access security are:


144   IMS V6 Security Guide
               •   If the JCL used to start the dependent region has the AGN= parameter
                   coded to specify an AGN (for example, AGN=APPL8), the dependent region
                   can use resources only specified in the AGN group (such as PSB11 and/or
                   PSB33). An attempt by the dependent region to use other IMS resources will
                   result in IMS abending the dependent region.
               •   The resources named in the AGN group are protected. That is, the
                   resources in the AGN may be used by only authorized dependent regions or
                   other authorized resources. For example, IBMBATCH was authorized to
                   APPL8 (using the RACF PERMIT command). If a different dependent region,
                   such as DFSMPR1 (a message processing region), attempted to schedule
                   PSB11 or PSB33, the schedule attempt would fail. An exception to this is
                   when APSB SAF security has been implemented for CPI-C-driven transaction
                   programs.

              One way to allow multiple dependent regions to access the resources protected
              by an AGN security is to create multiple AGNs that include the same resource.
              For example, another AGN group, APPL9, could be created, which also contained
              PSB11, PSB33, and other resources as required. Then, the dependent region
              DFSMPR1 could be authorized to AGN APPL9, thus allowing DFSMPR1 to
              schedule PSB11 and/or PSB33.

              You can secure a PSB specified on an allocate PSB (APSB) call from a common
              programming interface for communications (CPIC) driven application program
              using the MVS System Authorization Facility (SAF). APSB SAF security overrides
              APSB AGN Table security. RACF 1.9.2 or later supports APSB SAF security.
              APSB security provides the capability to use the RACF AIMS class to define
              PSBs. Therefore, the AIMS class can contain security profiles for AGNs and
              PSBs. Care should be taken to ensure that PSB security profile names in the
              AIMS class do not conflict with AGN security profile names in the AIMS class.
              APSB SAF security is covered in greater detail in Chapter 10, “IMS Security
              Exits” on page 181.



7.4 Summary
              The IMS system can be protected in a number of ways:
               •   IMS system data sets can be protected by securing the data sets in the
                   RACF DATASET class.
               •   Access to the IMS control region can be secured using the RACF APPL
                   class.
                   This is accomplished by creating a security profile for the IMS control region
                   in the RACF APPL class and authorizing groups/user IDs.
               •   Access to dependent regions and IMS resources can be secured using AGN
                   security. AGN security restricts the resources that can be used or accessed
                   by a dependent region and restricts the dependent region to using only the
                   resources defined in its AGN. The same IMS resource, such as a PSB, may
                   be specified in multiple AGNs. AGN security is implemented using either
                   SMU and RACF, or SMU and DFSISIS0 (the AGNEXIT).
                   To implement AGN security using SMU and RACF, the following steps are
                   required:
                   −   Define the AGN resource groups using SMU input statements, and
                       execute the security maintenance utility (SMU).



                                                    Chapter 7. Securing Access to the IMS System   145
                              −   Define security profiles for the AGN groups in the RACF AIMS class, and
                                  authorize (PERMIT) groups/user IDs.
                                  If the default RCLASS value of ′IMS′ has been used, the AIMS class is
                                  already activated. If RCLASS on the SECURITY macro has a value other
                                  than IMS, make sure the Axxx class is activated. RACF classes can be
                                  activated using the SETROPTS CLASSACT command.
                              −   Code the AGN= parameter on the JCL used to start the dependent
                                  region. The AGN= specification has to match the AGN name specified
                                  to SMU and the AIMS security profile name used to define the profile to
                                  RACF.
                              −   Create a RACF user ID for the dependent region, and connect the
                                  dependent region to the appropriate RACF group.
                              −   Refresh the security profiles used by RACF and/or IMS.




146   IMS V6 Security Guide
Chapter 8. IMS Resources Accessed from Other Environments

                         This chapter covers securing access to IMS applications and data from other
                         subsystems and/or networks. Securing access to IMS from the following
                         environments is presented:
                             •   APPC
                             •   MSC
                             •   OTMA and ITOC
                             •   MQSeries
                             •   CICS DBCTL



8.1 Advanced Program-to-Program Communications (APPC)
                         The security options for APPC/IMS and LU 6.2 application programs are quite
                         extensive. The partner systems can range from a single-user terminal, such as
                         an Aptiva, to a multi-user system, such as VM/ESA. All systems can have their
                         own complex security environment. Security for IMS can be simple or complex.

                         Every transaction program name (TPN) must pass a security check before it is
                         executed. The user ID that initiates the transaction is identified on the LU 6.2
                         format header (FMH5). If no user ID exists because you specify
                         SECURITY=NONE, you can access only resources that are not defined with
                         UACC (NONE). Any TPNs that are accessible in all circumstances should not be
                         defined with UACC (NONE). The TPN security definition is required.

                         The LU 6.2 protocol provides a standard architecture that allows a transaction
                         program (TP) to pass security information on the ALLOCATE verb. The security
                         parameters are:
                             •   NONE
                             •   PROGRAM
                             •   SAME
                         APPC/MVS uses the system authorization facility (SAF) interface, so products
                         such as RACF, are invoked to protect the resources. The actual security
                         mechanism consists of two parts:
                             •   First, the information passed on the ALLOCATE (FMH5 ATTACH header) is
                                 checked to see the security level.
                                 −   If SECURITY=NONE is specified, APPC/MVS does no checking. Instead
                                     APPC/MVS builds a special security profile that corresponds to
                                     SECURITY=NONE. This allows access to MVS, and IMS resources have
                                     universal access (UACC) specified at any level other than NONE.
                                     Resources with UACC(NONE) or without UACC specified cannot be
                                     accessed. However, if DFSCCMD0 or DFSCTRN0 is present in the
                                     IMS.RESLIB (or concatenation), the appropriate exit is invoked for
                                     command/transaction authorization.
                                 −    If SECURITY=PGM is specified, the user ID and password and
                                     optionally a profile name (that is used as a group name) are to be
                                     passed on the ALLOCATE verb and are validated by RACF.



© Copyright IBM Corp. 1999                                                                                147
                               −   SECURITY=SAME specifies a user ID and indicates that the sending
                                   system has already verified the user. If SECURITY=SAME is specified
                                   and the Already_Verified indicator is on, the user ID has been validated.
                                   The assumption is that the sending system has already verified the user
                                   and so there is no need to validate the user or even send a password.
                          •   Secondly, when one of the above methods establishes the user, APPC/MVS
                              verifies that the user ID can execute the specific TP name. This is done
                              based on the security profile defined (for transactions received from APPC
                              users) in the RACF APPCTP class. MVS verifies that the user′s user ID
                              RACF security access profile has ACCESS (EXECUTE) for the entity
                              dbtoken.x.tpname in the CLASS (APPCTP). The value of dbtoken is the
                              dbtoken value specified in the TP_Profile data set, such as in the example
                              below for ACCTPAY based on the APPCTPxx parameter specified for this LU.
                              The value of x is either the user ID, group or SYS1.

                        The following provides a sample RACF command for creating a TP profile. The
                        example illustrates how you can use the RDEFINE command to define a
                        transaction program profile named ACCTPAY and specify a UACC of READ. A
                        UACC of READ allows all users to read the transaction program profile.
                              RDEFINE APPCTP ACCTPAY UACC(READ)

                        You can protect a transaction program profile by specifying a UACC of NONE.
                        You can then create an access list that contains only those users who need
                        access to the transaction program profile. The following example shows how
                        you can define a transaction program profile named ACCTPAY and give it a
                        UACC of NONE, and then authorize (PERMIT) LU6.2/APPC user′s (USERA and
                        USERB) to execute the TP:


                              RDEFINE APPCTP ACCTPAY UACC(NONE)
                              PERMIT ACCTPAY CLASS(APPCTP) ID(USERA USERB)

                        If either of these security checks fails, APPC/MVS rejects the transaction and
                        IMS never sees it. It is also possible to implement additional verification, using
                        session level security and port of entry checks. These use the RACF resource
                        classes of APPCLU and APPCPORT, respectively.

                        If the APPC/MVS authorizes the user′s authority to execute the TP, the TP is
                        scheduled in an IMS dependent region. Scheduling information for LU 6.2
                        CPI-Communications-driven application programs is defined in a TP_Profile entry
                        managed by APPC/MVS. Figure 25 on page 149 and Figure 26 on page 149 are
                        examples of TP_Profile entries created using the TP_Profile dialog. Figure 25 on
                        page 149 is a TP_Profile of a standard/modified-standard transaction program,
                        whereas Figure 26 on page 149 is a TP_Profile for a CPI-C-driven transaction
                        program.




148   IMS V6 Security Guide
 ----------------------------- IMS TP_Profile Panel ----------------------
 TP Name . . . : ACCTPAY
 Transaction Code . . . . . ACCTTRAN
 Security Type . . . . . . CHECK      (NONE,CHECK,FULL, default=CHECK)
 CPI Communications Driven Options
 Transaction Class . . . . ._____     (Range 1 - 255, default=1)
     Maximum Regions . . . ._____     (Range 0 - 255, default=1)

 Comments . . .                       (Optional 1 to 10 lines)
 > TP_PROFILE Created 10/8/98________________________________________
 > Access IMS ACCT DATABASE via. program DFSSAMXX___________________
 > __________________________________________________________________
 > __________________________________________________________________
 > __________________________________________________________________
 > __________________________________________________________________
 > __________________________________________________________________
 > __________________________________________________________________
 > __________________________________________________________________
 > __________________________________________________________________
  PF01 = Help     PF03 = Exit     PF12 = Cancel     Enter = Accept


Figure 25. TP_Profile (Standard/Modified-Standard Transaction Program)




 ----------------------------- IMS TP_Profile Panel ----------------------
 TP Name . . . : BILLING
 Transaction Code . . . . .
 Security Type . . . . . . CHECK      (NONE,CHECK,FULL, default=CHECK)
 CPI Communications Driven Options
 Transaction Class . . . . .__1__     (Range 1 - 255, default=1)
     Maximum Regions . . . .__2__     (Range 0 - 255, default=1)

 Comments . . .                       (Optional 1 to 10 lines)
 > TP_PROFILE Created 10/8/98________________________________________
 > Access IMS BILLING DATABASE via. program DFSSAMXY_________________
 > __________________________________________________________________
 > __________________________________________________________________
 > __________________________________________________________________
 > __________________________________________________________________
 > __________________________________________________________________
 > __________________________________________________________________
 > __________________________________________________________________
 > __________________________________________________________________
  PF01 = Help     PF03 = Exit     PF12 = Cancel     Enter = Accept


Figure 26. TP_Profile (CPI-C Program)

The existence of an IMS definition in IMS generation macros (see Figure 27 on
page 150) or by the IMS online change process causes the transaction to be
considered a standard DL/I or modified-standard application.




                          Chapter 8. IMS Resources Accessed from Other Environments   149
                              IMS system definition macro:

                                 APPLCTN PSB=ACCTPSB,PGMTYPE=TP               *HIDAM/OSAM
                                 TRANSACT CODE=ACCTTRAN,MODE=SNGL,                            X
                                        MSGTYPE=(SNGLSEG,NONRESPONSE,1)


                        Figure 27. TP_Profile (CPI-C Program)

                        CPI Communications-driven transaction programs are defined only in the
                        TP_Profile. The definition is by TPN. Therefore, for CPI-C transactions the
                        transaction has not been defined to IMS. MVS drives an IMS exit that
                        dynamically creates the control blocks required for CPI-C transactions. When
                        APPC/IMS recognizes a CPI-Communications-driven application program for the
                        first time after restart, it dynamically builds an IMS transaction. IMS dynamically
                        builds the definition for CPI-Communications-driven application programs when a
                        transaction is presented for scheduling by APPC/MVS, based on the APPC/MVS
                        TP_Profile definition after IMS restart.

                        APPC/IMS security is activated by the APPCSE=F, C, P, or N execution
                        parameter, or by issuing the /SECURE APPC xxxx command, where xxxx
                        specifies FULL, CHECK, PROFILE, or NONE.

                        The security check in IMS is based on the IMS transaction code or executed
                        command name. If the TPN is DFSAPPC, no additional security check occurs. If
                        RACF is used on your system, MVS rejects the transaction if RACF is not active.
                        The IMS command name or transaction code associated with the TPN is used in
                        the RACF resource class associated with this IMS system (″CIMS″ for
                        commands, or ″TIMS″ for transactions are the default RACF classes). Refer to
                        Figure 25 on page 149 for examples of how to create the RACF security profiles
                        used to authorize users to IMS transactions. The examples are provided for
                        transaction ACCTTRAN (a standard DL/I or modified standard application) and
                        for BILLING (a CPI-C application).



                              Standard and modified-standard example:
                                  RDEFINE TIMS ACCTTRAN UACC(NONE)
                                  PERMIT ACCTTRAN CLASS(TIMS) ID(USERA USERB)

                              CPI-C example:
                                  RDEFINE TIMS BILLING UACC(NONE)
                                  PERMIT BILLING CLASS(TIMS) ID(USERA USERB)


                        Figure 28. Create RACF TIMS Security Profiles for APPC Transactions

                        If the RACF check is successful, the Transaction Authorization exit routine
                        (DFSCTRN0) is called for transactions, and DFSCCMD0 is called for command
                        authorization if either exit is in the IMS.RESLIB (or the concatenation). However,
                        the following rules apply to RACF:
                          •   For commands, default security applies only if RACF is not used.
                          •   For remote transactions, RACF is optional.
                        Otherwise, the exit routines make the security decision if included in the IMS
                        system.

150   IMS V6 Security Guide
                When a CPI-C program issues an allocate PSB (APSB) call for an IMS resource,
                RACF and/or DFSCTRN0 provides authorization checking. If APSB SAF security
                has been enabled, IMS PSBs can have security profiles in the AIMS (Axxxxxxx)
                RACF class to secure PSBs when the transaction input is received from a CPI-C
                environment. The SAF calls RACF to authorize the user ID of of the terminal
                user that submitted the LU6.2 transaction to execute the PSB that was requested
                on the APSB call.

                More detailed explanations of security can be found in OS/390 MVS/ESA
                Planning: APPC/MVS Management , GC28-1807 and APPC System Definitions in
                MVS/ESA and OS/2 , GG66-3224.

                The intended environment executes APPC/IMS with RACF security active. It is
                possible to run with RACF not active in the APPC/IMS system, but it is not
                possible to run with RACF not active in the MVS system. In this sense, RACF is
                mandatory for LU 6.2.

                The complexity of the security environment is derived partly from the many
                resources involved (VTAM, MVS, and IMS) and the granularity of protection that
                is possible. The security definitions must be coordinated closely for successful
                operation of the application system.

                APPC/IMS requires security using the system authorization facility (SAF)
                interface to RACF, or an equivalent security environment. RACF is optional for
                remote transactions from LU 6.2 application programs. APPC/IMS supports both
                the Transaction Authorization exit routine (DFSCTRN0) and the Command
                Authorization exit routine (DFSCCMD0). The defaults for APPC security
                (APPCSE= and for the /SECURE APPC command) are FULL in both cases,
                meaning that the security environment will be cloned in the IMS dependent
                region for every APPC entered transaction.


8.1.1 APPC Restrictions
                The following restrictions apply when using APPC/IMS:
                 •   APPC/IMS does not support SMU security.
                 •   APPC/IMS does not support the /SIGN command, because it is not required
                     to validate the user ID. MVS validates user IDs when using RACF, therefore,
                     each APPC/IMS message has a validated user ID.
                 •   TP names must be in uppercase.
                 •   The RACF class APPCTP must be activated (using SETROPTS CLASSACT
                     command).



8.2 Multiple Systems Coupling (MSC) Networks
                MSC is used by many installations to provide users a single systems image for
                their application processing needs. Using the facilities of MSC, IMS will
                automatically route transactions to the correct IMS system for processing.
                Terminal responses are automatically routed back to the inputting terminal.

                In the MSC environment, you should perform as much security checking as is
                required for the primary message. User verification and transaction
                authorization are checked at the time of terminal input. That is, the authorization
                is checked on the IMS system where the terminal user enters the transaction.



                                         Chapter 8. IMS Resources Accessed from Other Environments   151
                        Please refer to Figure 29 on page 152. If a user submits a transaction to IMSA,
                        and the transaction will be MSC routed to IMSB for processing, the transaction
                        authorization check should take place on IMSA. IMSA can perform the
                        authorization check because the transaction is statically defined as a remote
                        transaction.




                                                      IMSA               IMSB
                                                   ┌────────┐         ┌────────┐
                                                   │        │         │        │
                                     TRANX         │ TRANX │ ───── │ TRANX │
                                  ┌─────────┐ ──── │ Remote │    /    │ Local │
                                  │ Terminal│      │        │ ───── │          │
                                  └─────────┘      │        │ MSC Link│        │
                                      user         │        │         │        │
                                                   └────────┘         └────────┘


                        Figure 29. Transaction Routing Example I

                        When the transaction is routed to IMSB for processing, IMSB could also have
                        transaction authorization turned on for the transaction. Transactions received by
                        directed routing on a link are passed to the transaction authorization module for
                        authorization checking. Transactions that have not been protected with a
                        password are accepted. For example, SMU has not been used to assign a
                        password to the transaction, and the RACF ″reverify″ has not been specified in
                        the APPLDATA section of the RACF security profile contained in the TIMS class.
                        Passwords are not passed across the MSC link, therefore, transaction
                        authorization checking would fail on IMSB if a password is required.

                        Hopefully, you have noticed that the RACF profiles protecting a transaction (or
                        any other IMS resource) should be synchronized. If IMSA and IMSB have
                        different transaction authorization checking for the same transaction, problems
                        can occur.

                        Transaction authorization is requested in several different places by IMS. The
                        area that will be focused on in the MSC environment is the transaction
                        authorization request that is done when IMS is processing the DL/I CHNG call.
                        Transaction authorization checking is done each time the CHNG call is issued
                        and the resulting return code to the application is either blanks, indicating the
                        user is authorized for the transaction referenced in the CHNG call, or an A4
                        status code, indicating the user is not authorized.


8.2.1 Transaction Authorization for the DL/I CHNG Call
                        A problem in the area of MSC security can arise if the installation does not have
                        an understanding of authorization processing for the CHNG call.

                        When processing the change call in a local system, IMS has the control blocks
                        associated with the inputting terminal, therefore, the local IMS can perform the
                        authorization checking. See Figure 30 on page 153.




152   IMS V6 Security Guide
                              IMSA               IMSB
                           ┌────────┐         ┌────────┐
                           │ TRANX │          │        │
                           │ Remote │         │        │
             TRANY         │        │ ───── │ TRANX │
          ┌─────────┐ ──── │ TRANY │     /    │ Local │
          │ Terminal│      │ Local │ ───── │           │
          └─────────┘      │        │ MSC Link│ TRANZ │
              user         │ TRANZ │          │ Local │
                           │ Remote │         │        │
                           └────────┘         └────────┘



Figure 30. Transaction Routing Example II

If the application program that processes TRANY on IMSA issues the CHNG call,
and if the user has not signed off, IMSA has all the required control blocks to
check the user′s authorization to a different transaction (the one that is
requested on the CHNG call, for example, TRANZ).

When processing a CHNG call on a remote MSC system, such as IMSB, IMSB
will not be able to find the control blocks associated with the inputting terminal.
Refer Figure 31 below where TRANX is input from a terminal attached to IMSA.
The application that processes TRANX is on IMSB. When the application running
on IMSB issues a CHNG call, requesting TRANZ for example, the control blocks
that represent the terminal user′s privilege (created when the user issued /SIGN
ON command on IMSA) and the inputting terminal control blocks are not
available on IMSB. Thus, the control blocks required for the security check are
on IMSA.




                          IMSA               IMSB
                       ┌────────┐         ┌────────┐
                       │ TRANX │          │        │
                       │ Remote │         │        │
         TRANX         │        │ ───── │ TRANX │ IMSPROD is
      ┌─────────┐ ──── │ TRANY │     /    │ Local │ the userid
      │ Terminal│      │ Local │ ───── │           │ for IMSB
      └─────────┘      │        │ MSC Link│ TRANZ │
         USERA         │ TRANZ │          │ Local │
         LTERM1        │ Remote │         │        │
                       └────────┘         └────────┘



Figure 31. Transaction Routing Example III

In Figure 31 scenario IMSB must make the decision to allow or reject the CHNG
call (requesting TRANZ) without access to the actual privilege of the terminal
user (USERA) on IMSA. In other words, the security environment for the user and
the terminal has been established on IMSA, rather than IMSB.




                          Chapter 8. IMS Resources Accessed from Other Environments   153
                        In this case, the default is for IMSB to create dynamically a security environment
                        in the dependent region for USERA and/or LTERM1. You can choose not to have
                        IMSs dynamically create a security environment through the use of the
                        DFSBSEX0 user exit. The user ID used for the authorization call will be one of
                        the following:
                          •    USERA - if the user was signed on when TRANX was entered, and the
                               security environment for USERA is available or can be created
                          •    LTERM1 - if the user was not signed on when TRANX was entered, but a
                               security environment can be created for LTERM1
                          •    IMSBPROD - if USERA and LTERM1 cannot be used and LSO=Y
                          •    IMSBDEP -if USERA and LTERM1 cannot be used and LSO=Y is not
                               specified

                        If the authorization call to RACF (using one of the security environments based
                        on one of the user IDs shown above) is unsuccessful (such as not authorized),
                        the CHNG call will result in a status code of A4 being returned to the application
                        program, and the message for TRANZ will not be inserted.

                        If IMSB′s user ID has been authorized (PERMITTED) to TRANZ, the insert of the
                        message is allowed.

                        If these RACF commands had been previously issued, the message for TRANZ
                        will be inserted;


                              RDEFINE TIMS TRANZ UACC(NONE)
                              PERMIT TRANZ CLASS(TIMS) ID(IMSBPROD) ACCESS(READ)

                        Depending on how your installation defined a resource, such as a transaction, to
                        RACF, will determine if SMF logs a security violation message. The SMF
                        violation notification is important because otherwise, auditors may not be able to
                        detect that users have attempted access to protected resources.

                        Another option for handling a failed authorization attempt for the situation
                        described in Figure 31 on page 153 is to utilize the Security Reverification Exit
                        (DFSCTSE0) on IMSB for authorizing unknown users. A description of DFSCTSE0
                        is provided in Chapter 10, “IMS Security Exits” on page 181.



8.3 Open Transaction Manager Access (OTMA) Clients
                        Security deserves increased focus and attention when your IMS systems are
                        WEB enabled. Prior to V5 of IMS/ESA, the extent of the IMS systems security
                        domain primarily concerned the IMS system itself and its related SNA
                        connections, except for APPC connections, where IMS could be directly
                        connected to an APPC client via APPC/MVS. With V5, OTMA was introduced and
                        opened up IMS to connectivity from non-SNA clients, through the architected
                        OTMA interface. With the explosive growth in the requirement to access legacy
                        mainframe data via the Internet for conducting business, another gateway into
                        IMS was introduced, namely the IMS TCP/IP OTMA connection (commonly
                        referred to as ITOC), which provides the communication platform to access IMS
                        using the TCP/IP protocol, through the architected OTMA interface. TCP/IP
                        connectivity offers multiple solutions to connect to a host system. No matter what
                        type of TCP/IP client tries to connect to IMS, each such clients must:
                          •    Prove their right origin



154   IMS V6 Security Guide
 •   Say who they are

Security administration no longer just resides at the mainframe host level but
also affects other levels of computing. This section will primarily focus on the
security aspects of OTMA and ITOC. For a review of security regarding the
Internet in general, refer to Chapter 4 of Connecting IMS to the World Wide Web:
A Practical Guide to IMS Connectivity , SG24-2220, where issues such as proxy
servers, socks servers, encryption etc. are described and explained.

OTMA provides various levels of security checking that can be implemented.
These are independent of the optional RACF verification that can be performed
by ITOC. OTMA verifies security in two instances:
 •   When a client bids to connect
 •   When processing an input message from a client

When a client sends a Client Bid command to OTMA to connect, OTMA has to
verify that the client is sufficiently authorized to connect to OTMA. The data
passed in the Security Data section of the Client Bid message is used to RACF
verify the client′s authorization. The IMSXCF.group.member (client member
name) must be defined to RACF in the FACILITY class as ITOC adheres to this
protocol.

The /SECURE command is used to control the RACF security level for input from
OTMA clients. It is used for administrative control of the IMS environment and as
an emergency operations control command to stop RACF activity without
requiring an IMS shutdown. /SECURE OTMA is used with the CHECK, FULL,
NONE or PROFILE parameters.

The /DISPLAY OTMA command can be used to show the security level that is
currently in effect. After an IMS cold start, the security default is FULL. IMS
retains OTMA security settings (established by a /SECURE OTMA command)
after a warm start or emergency restart. For OTMA there is no IMS execution
parameter similar to APPCSE, as for APPC. So, after the cold start, the level of
security has to be changed by this command, if something other than FULL is
desired.

The meaning of the parameters in /SECURE OTMA command is as follows:
CHECK       Causes existing RACF calls to be made. IMS commands are checked
            using the RACF resource class of CIMS. IMS transactions are checked
            using TIMS.
FULL        Causes the same processing as the CHECK parameter but uses
            additional RACF calls to create the security environment for
            dependent regions.
NONE        Does not call RACF within IMS for security verification.
PROFILE     Causes the values in the Security Data section of the OTMA message
            prefix for each transaction to be used. The PROFILE keyword is used
            to specify or bypass RACF security for individual transactions. This
            can be important if you do not want the performance overhead of
            processing security for your entire transaction workload. You specify
            the security for each transaction by setting the values in the
            security-data section of the OTMA message prefix.




                          Chapter 8. IMS Resources Accessed from Other Environments   155
                        If RACF is used for security, the XCF group name and the member name
                        IMSXCF.group.member has to be defined in the FACILITY class.

                        If the IMSXCF.group.member is not defined in the FACILITY class, a Client Bid is
                        not allowed. You should use the /SECURE OTMA PROFILE command so that
                        subsequent transactions can be processed according to the values in the
                        Security Data section of the OTMA message prefix for each transaction.

                        If the group name and IMS member name (IMSXCF.group.member) are defined
                        in the FACILITY class and if IMS security is not set to NONE, the user ID in the
                        token for the Client Bid must be valid (that is, have READ access to the profile).

                        Only transactions or commands that must be protected belong to the TIMS or
                        CIMS classes. If the transaction is not in the TIMS class or the command is not
                        in the CIMS class, the transaction is allowed regardless of the option set by the
                        /SECURE OTMA command.

                        The XCF client must be MVS authorized.

                        For OTMA applications defined with full security, security is kept until the
                        application ends. The Client Bid request for a client includes:
                          •   Accessor Environment Element (ACEE) aging value.
                          •   Hash table size. The hash table contains the USERID and TIMESTAMP (of
                              the last RACINIT command). The table size must be large enough to hold the
                              total number of expected user IDs.
                          •   The client user token. The user token is optional except when RACF security
                              is used, and is identified in the security section of the message prefix. You
                              can specify No Security Checking for the security flag in the security data
                              section of the message prefix for any transaction. If RACF security is used,
                              the user token is mandatory for a Client Bid. If the user token (for a Client
                              Bid) fails RACF verification, the client will receive a NAK message from the
                              server.

                        If you specify /SECURE OTMA NONE, IMS does not use RACF for security
                        verification, regardless of what security is specified by the class for a Client Bid
                        or for transactions. If you specify /SECURE OTMA PROFILE (NONE, FULL or
                        CHECK), IMS will check the Message Data Security section.

                        8.3.1.1 OTMA Callable Interface (C/I)
                        A new RACF facility class IMSXCF.OTMACI has to be defined for the OTMA C/I to
                        protect XCF groups from any unauthorized caller. When the RACF resource is
                        defined, RACF RACHECK is invoked before OTMA C/I performs an XCF JOIN.
                        This method protects the access to XCF, the XCF group, and the member. This
                        RACF checking is performed only when an unauthorized caller is using OTMA
                        C/I. Additional security characteristics remain consistent with OTMA in IMS 6.1.


8.3.2 ITOC Security
                        The ITOC task can be started as a procedure (via the MVS START command, or
                        as a job (with submitted JCL). In either case, ITOC must be authorized to
                        execute in an environment where the appropriate MVS supervisor functions and
                        storage keys can be accessed. To achieve the above, you must:
                          •   APF the ITOC run-time libraries (If it is IMS V5 and you are using a separate
                              library for BPE, remember to authorize the BPE library as well).


156   IMS V6 Security Guide
 •   Update the MVS PPT (Program Properties Table) to allow ITOC to execute in
     supervisor mode and in storage key 7 (same as IMS).

Failure to perform these required authorization functions will result in an
HWSX0912E error message, when a startup of ITOC is attempted.

8.3.2.1 Joining ITOC to XCF
Once the ITOC address space is started with the correct level of MVS
authorization, it has to join the XCF group before connecting to the relevant IMS
datastore as an OTMA client. The parameters required for ITOC to join an
appropriate XCF group successfully is twofold:
 •   The XCF group that ITOC needs to join must be defined to MVS in the
     appropriate COUPLExx member in SYS1.PARMLIB. Refer to the appropriate
     MVS Initialization and Tuning Reference Guide for further information.
 •   The XCF group that ITOC needs to join is also the group defined in the
     DATASTORE parameter in the HWSCFG configuration file.

The ITOC uses the GROUP=, MEMBER= and TMEMBER= parameters to:
 •   Specify the XCF group it wants to join
 •   Specify the XCF member name by which the ITOC will be known to the XCF
     group
 •   Specify the partner member in the group with which it wants to communicate
     (in our case, the IMS datastore)

Failure to specify the correct parameters will result in either the HWSO1210W,
HWSO1215W or HWSO1220W messages to be issued.

8.3.2.2 Connecting ITOC to OTMA
Before ITOC can send any messages to IMS via OTMA for processing, ITOC has
to identify itself as an OTMA client to OTMA. This is achieved by issuing an
OTMA command of the type Client Bid, passing the required security data to
OTMA for verification. If your IMS is RACF protected, the user ID passed by ITOC
in the Client Bid must have READ access to the FACILITIES class entry
IMSXCF.group.member in RACF. If rejected by RACF, the Client Bid is denied
and ITOC cannot connect to IMS as an OTMA client.

The user ID mentioned above is either the user ID used to start ITOC as a
started procedure or the user ID explicitly defined on the job card if starting ITOC
as a job.

8.3.2.3 User Verification
Once ITOC has successfully joined the XCF group and connected as an OTMA
client to IMS, you have the option to let ITOC do RACF user ID and password
verification of each client on a per message basis. This facility is driven by the
RACF=Y or N parameter as specified in the HWSCFG configuration file. The
user ID and password can be set up in two places:
 •   The originating client can build and send the security data as part of the
     message that is sent to ITOC via TCP/IP
 •   The user message exit that gets driven after ITOC has received the complete
     message from the TCP/IP client




                          Chapter 8. IMS Resources Accessed from Other Environments   157
                        Once ITOC receives control back from the user message exit and the RACF=
                        option is set to Y, ITOC issues the RACF call to verify the user ID and password.
                        If not authorized, the message is rejected and sent back to the originating client.

                        8.3.2.4 User Exit Security
                        The last option available with ITOC security is available in the user exit that is
                        driven by ITOC after the complete message has been received from the TCP/IP
                        client. This option is really open-ended to such a degree that the user exit can
                        perform any data manipulation or checking that it wishes to, which can include
                        RACF verification or any other security verification that the author of the exit
                        wishes to implement and execute. This is totally separate from the optional user
                        ID and password verification performed by ITOC.


8.3.3 OTMA Security Restrictions
                        The following is a list of OTMA restrictions pertaining to security:
                          •   OTMA messages cannot be encrypted.
                          •   All user IDs must be verified by RACF, unless the client specifies no security
                              checking in the security data section of the message prefix.



8.4 Message Queuing Series (MQSeries)
                        Each MQSeries message that passes across the bridge contains the following
                        security information:
                          •   A user ID contained in the UserIdentifier field of the MQMD structure
                          •   The security scope contained in the SecurityScope field of the MQIIH
                              structure (if the MQIIH structure is present)
                          •   A Utoken (unless the MQSeries sub system has CONTROL or ALTER access
                              to the relevant IMSXCF.xcfgname.xcfmname profile)

                        The security checks made depend on the setting by the IMS command /SECURE
                        OTMA, as follows:
                        NONE         No security checks are made for the transaction.
                        CHECK        The UserIdentifier field of the MQMD structure is passed to IMS for
                                     transaction or command authority checking. An ACEE is built in the
                                     IMS control region.
                        FULL         The UserIdentifier field of the MQMD structure is passed to IMS for
                                     transaction or command authority checking. An ACEE is built in the
                                     IMS dependent region and the IMS control region.
                        PROFILE      The UserIdentifier field of the MQMD structure is passed to IMS for
                                     transaction or command authority checking

                        The SecurityScope field in the MQIIH structure is used to determine whether to
                        build an ACEE in the IMS dependent region as well as the control region. If you
                        do not use /SECURE OTMA PROFILE, any value specified in the SecurityScope
                        field of the MQIIH structure is ignored.




158   IMS V6 Security Guide
8.4.1.1 Connecting to IMS
The MQSeries IMS bridge is an OTMA client. The connection to IMS operates
under the user ID of the MQSeries for MVS/ESA address space. This is normally
defined as a member of the started task group. This user ID must be granted
access to the OTMA group (unless the /SECURE OTMA setting is NONE). To do
this, define the following profile in the FACILITY class:
  IMSXCF.xcfgname.xcfmname

Where xcfgname is the XCF group name and xcfmname is the XCF member
name of MQSeries. You must give your MQSeries subsystem user ID read
access to this profile.

If profile qmgr.NO.SUBSYS.SECURITY exists in the MQADMIN class, no user ID
will be passed to IMS and the connection will fail unless the /SECURE OTMA
setting is NONE.

8.4.1.2 Application Access Control
For each IMS system that the MQSeries IMS bridge connects to, you can define
the following RACF profile in the FACILITY class to determine how much security
checking is performed for each message passed to the IMS system.
  IMSXCF.xcfgname.xcfmname

Where xcfgname is the XCF group name and xcfmname is the XCF member
name for IMS. (You need to define a separate profile for each IMS system.)

The access level you allow for the MQSeries subsystem user ID in this profile is
returned to MQSeries when the MQSeries IMS bridge connects to IMS, and
indicates the level of security that is required on subsequent transactions. For
subsequent transactions, MQSeries requests the appropriate services from
RACF and, where the user ID is authorized, passes the message to IMS. The
following access level information can be returned:
NONE       This indicates that maximum security is required, that is,
           authentication is required for every transaction. A check is made to
           verify that the user ID specified in the UserIdentifier field of the
           MQMD structure, and the password or passticket in the Authenticator
           field of the MQIIH structure are known to RACF and are a valid
           combination. A Utoken is created with a password or passticket, and
           passed to IMS; the Utoken is not cached. If profile
           qmgr.NO.SUBSYS.SECURITY exists in the MQADMIN class, this level
           of security overrides whatever is defined in the profile.
READ       This indicates that the same authentication is to be performed as
           above under the following circumstances:
            •   The first time that a specific user ID is encountered
            •   When the user ID has been encountered before but the cached
                Utoken was not created with a password or passticket
           MQSeries requests a Utoken if required and passes it to IMS. If a
           request to reverify security has been implemented, all cached
           information is lost and a Utoken is requested the first time each user
           ID is subsequently encountered.
UPDATE     A check is made that the user ID in the UserIdentifier field of the
           MQMD structure is known to RACF. A Utoken is built and passed to
           IMS; the Utoken is cached.


                          Chapter 8. IMS Resources Accessed from Other Environments   159
                        CONTROL/ALTER
                                          These indicate that no security Utokens need to be provided for any
                                          user IDs for this IMS system. (You would probably use this for
                                          development and test systems only.)
                          •        This access is defined when MQSeries connects to IMS and lasts for the
                                   duration of the connection. To change the security level, the access to the
                                   security profile must be changed and then the bridge stopped and restarted
                                   (for example, by stopping and restarting OTMA).
                          •        If you change the authorities in the FACILITY class, you must issue the RACF
                                   command SETROPTS RACLIST(FACILITY) REFRESH to activate the changes.
                          •        You can use a password or a passticket, but you must remember that the
                                   MQSeries IMS bridge does not encrypt data.
                          •        Some of the above might be affected by security settings in IMS, using the
                                   /SECURE OTMA command.

                        8.4.1.3 RESLEVEL and IMS Connections
                        RESLEVEL is a RACF profile that controls the number of user IDs checked for
                        MQSeries resource security. Normally, when a user attempts to access an
                        MQSeries resource, RACF checks the relevant user ID or IDs to see if access is
                        allowed to that resource. By defining a RESLEVEL profile you can control
                        whether zero, one or two user IDs are checked. For an IMS user accessing an
                        MQSeries resource, RESLEVEL checking takes place for dependent regions. Up
                        to two IMS user IDs can be checked. You can add RESLEVEL profile entries to
                        control whether checking is carried out on zero, one, or both user IDs.

                        By default, when an API resource security check is made for an IMS adapter, two
                        user IDs are checked to see if access is allowed to the resource. The first user
                        ID checked is that of the address space of the IMS region. This is taken from
                        either the USER field from the job card or the user ID assigned to the region
                        from the MVS started procedures table (SPT). The second user ID checked is
                        associated with the work being done in the dependent region. It is determined
                        according to the type of the dependent region as shown in Table 29:

                          Table 29. How the Second User ID is Determined for the IMS Adapter
                          Types of Dependent Region                      Hierarchy for Determining the Second
                                                                         User ID
                               •    BMP message driven and successful     1. User ID associated with the IMS
                                    GET UNIQUE issued                        transaction if the user is signed on
                               •    IFP and GET UNIQUE issued             2. LTERM name if available
                               •    MPP                                   3. PSBNAME
                               •    BMP message driven and successful     1. User ID associated with the IMS
                                    GET UNIQUE not issued                    dependent region address space if
                               •    BMP not message driven                   this is not all blanks or zeros
                               •    IFP and GET UNIQUE not issued         2. PSBNAME


                        When an application tries to connect to MQSeries, MQSeries checks the access
                        that the user ID associated with the adapter has to a profile in the MQADMIN
                        class called.
                              ssid.RESLEVEL

                        The user IDs associated with each adapter are the IMS region started task user
                        ID for the IMS adapter. This check is always performed unless the


160   IMS V6 Security Guide
           ssid.NO.SUBSYS.SECURITY switch has been set. If there is no RESLEVEL profile,
           MQSeries enables checking of both the job and task (or alternate user) ID for an
           IMS connection. If there is a RESLEVEL profile, the level of checking depends on
           the environment and access level for the profile. Table 30 shows the checks
           made for IMS connections:

            Table 30. Checks Made at Different RACF Access Levels for the IMS Adapter
            RACF Access        Level of Checking
            NONE               Check the IMS address space user ID and the IMS second user ID.
            READ               Check the IMS address space user ID.
            UPDATE             Check the IMS address space user ID.
            CONTROL            No check.


            ALTER              No check.


           8.4.1.4 Using RACF Passtickets in the IMS Header
           If you want    to use a passticket instead of a password in the IMS header (MQIIH),
           you should    use an application name as if you were creating a passticket for an
           MVS batch     job. That is, the APPL field should be of the form MVSxxxx, where
           xxxx is the   SMFID of the MVS system on which the target queue manager runs.

           A passticket is built from a user ID, the target application name (APPL), and a
           secret key. It is an 8 byte value containing uppercase alphabetic and numeric
           characters. It can be used only once, and is valid for 20 minutes centered on the
           time that it was created. For full information about passtickets, see the OS/390
           Security Server (RACF) Security Administrator ′ s Guide , SC28-1915.

           Passtickets in IMS headers are given to RACF by MQSeries, not IMS.



8.5 CICS
           When using CICS with DBCTL, you may want to use one or more of the following
           optional security facilities:
            •   PSB authorization checking by CICS
            •   Resource access security checking by DBCTL

           At PSB scheduling time, CICS invokes security checking to find out whether the
           terminal user is authorized to access the PSB. The actual check is carried out by
           an external security manager, such as RACF, or your own security program.
           Although PSB scheduling requests are sent to DBCTL for processing, CICS does
           PSB authorization checking.

           DBCTL views all the resources that can be accessed by one particular CICS
           system or BMP as a single entity. Resources in this context means one or more
           PSBs. The set of PSBs that one CICS or BMP can access are grouped together
           in an entity called an application group. Each application group has a name,
           AGN, and the AGNs are defined in matrix data sets.

           Application groups, and the names of the resources within those groups, are
           placed in tables in DBCTL′s security matrix data set(s) using the IMS security
           maintenance utility. You can use the IMS online change facility to bring new
           security tables online.


                                      Chapter 8. IMS Resources Accessed from Other Environments   161
                        The AGN that CICS intends to use is specified in the DRA startup table
                        referenced by CICS when it attempts to connect to DBCTL. You can assign the
                        same AGN to different CICS systems, if necessary.

                        DBCTL resource access security checking provides the following:
                          •   Checking at connect time
                              When CICS or a BMP connects to DBCTL, DBCTL initiates a check to find out
                              if CICS or the BMP is authorized to an application group name (AGN). The
                              check is carried out either by RACF in conjunction with SMU or by a user
                              exit routine (DFSISIS0) and SMU:
                               1. RACF and DBCTL checking at connect time
                                 This check has two parts:
                                  −   RACF checks whether the user ID supplied in the JOB statement of
                                      the CICS startup job (or in the started procedure table), or BMP JCL,
                                      is authorized to access the AGN supplied by CICS or the BMP during
                                      the connect request.
                                  −   If the above check is successful, DBCTL carries out the second part
                                      of the check. This involves verifying that the supplied AGN is in the
                                      matrix data sets used for this DBCTL startup.
                               2. DBCTL and user exit routine (DFSISIS0) may be used instead of RACF
                                  and SMU. DFSISIS0 should be coded to allow or refuse authorization by
                                  setting the appropriate return code.
                              If you use DBCTL connect-time checking, you must also use DBCTL PSB
                              schedule-time checking. That is, you can use both of these checks, or
                              neither, but you cannot use only one of them.
                          •   Checking at PSB schedule time
                              This is completely unrelated to and independent of the PSB authorization
                              checking by CICS.

                        For additional CICS security information refer to CICS Transaction Server for
                        OS/390 CICS RACF Security Guide , SC33-1701.


8.5.1 Implementing AGN Security
                        All of the above information was taken from the CICS Transaction Server for
                        OS/390 CICS IMS Database Control Guide , SC33-1700. What has been added in
                        this book are samples showing how to perform/implement the security. The
                        steps provided here are merely for guidance, thus the actions that may need to
                        be done for your installation may not be the same. The following has been
                        prepared to help you implement AGN security using the security maintenance
                        utility (SMU) and RACF. Please review all of the security information in the
                        above referenced book prior to performing the steps below:
                          1. If you install DBCTL using the IVP supplied jobs, at step IV2C201T you
                             prepare a Stage 1 source deck in order to generate a DBCTL system.
                             Sample Stage 1 source for DBCTL (the DBC sample) is provided in the
                             IMS/ESA Installation Volume I: Installation and Verification, GC26-8736. The
                             information you will need to understand to implement security comes from
                             the macros listed below. The parameters that you will need to note have
                             been highlighted in bold text:




162   IMS V6 Security Guide
   *
   * SAMPLE IMSCTRL MACRO FOR A DBCTL SYSTEM
   *
    IMSCTRL SYSTEM=(VS/2,(ALL,DBCTL),4.3),                               X
                      :
                      :
                      CMDCHAR=/,                                         X
                      DBRC=(YES,YES),                                    X
                      DBRCNM=DBRC,                                       X
                      DLINM=DLISAS,                                      X
                      IMSID=IMSP,                                    X
                      NAMECHK=(YES,S1),                                  X
                      :
                      :
                      MAXCLAS=016
  The APPLCTN macros correspond to PDIR (of CICS table) entries:
   APPLCTN   PSB=DFHDBMP,PGMTYPE=BATCH,SCHDTYP=PARALLEL
   APPLCTN   PSB=DFSIVP6,PGMTYPE=BATCH,SCHDTYP=PARALLEL
   APPLCTN   PSB=DFSIVP61,PGMTYPE=BATCH,SCHDTYP=PARALLEL
   APPLCTN   PSB=DFSIVP62,PGMTYPE=BATCH,SCHDTYP=PARALLEL
   APPLCTN   PSB=DFSIVP64,PGMTYPE=BATCH,SCHDTYP=PARALLEL
   APPLCTN   PSB=DFSIVP65,PGMTYPE=BATCH,SCHDTYP=PARALLEL
  Ensure RACF class and type keyword are coded as in the following example:
   SECURITY RCLASS=IMS,TYPE=RACFAGN
  The following sample IMSGEN macro will generate IMS Stage 2 jobs for
  DBCTL system generation processing:
    IMSGEN ASM=(H,SYSLIN),ASMPRT=OFF,                                        X
           LKPRT=(XREF,LIST),LKSIZE=(880K,64K),LKRGN=900K,                   X
           SUFFIX=I,                                                         X
           SURVEY=YES,                                                       X
           MACLIB=ALL,                                                       X
           NODE=(IVPEXE61,                                                   X
           IMSIVP.IVP61,                                                     X
           IMSIVP.IVP61),                                                    X
           OBJDSET=IMSIVP.IVP61.OBJDSET,                                     X
           PROCLIB=YES,                                                  X
           :
           :
    END ,
2. After you have run the following system definition jobs:
  IV2C301J        JOB - Run SYSDEF STAGE2 >>> See Description, and
  IV2C401J        JOB - Run SMP/E JCLIN

  you will notice the next task is to edit the proclib members:
  IV2C402T        TASK - Edit IMS PROCLIB Members).
  As part of Stage 2 processing, a procedure library was created because you
  specified PROCLIB=YES on the IMSGEN macro. (After the procedure library
  has been built initially, you should change the parameter to PROCLIB=NO
  so that future Stage 2 generations do not overlay any changes you have
  made to procedures.) Contained in the procedure library is a member called
  SECURITY. This procedure is run in order to define to IMS the PSBs that
  require AGN security. The PSBs were named in Stage 1 on the APPLCTN
  macros. The SECURITY procedure executes the IMS security maintenance


                        Chapter 8. IMS Resources Accessed from Other Environments   163
                              utility (SMU). AGN security requires that the SMU utility be run. Executing
                              the SMU utility does the following:
                               •    Identifies the PSBs that IMS will be required to secure.
                               •    Loads a matrix data set with the security information. The information is
                                    loaded into a staging matrix data set. You will be required to copy the
                                    information into an execution matrix data set that the IMS system uses.
                                    You will copy the security information in the step:
                                    IV2E315J         JOB - Copy Staging Libraries.

                               •    After the security information has been copied (via job IV2E315J) into the
                                    appropriate MATRIXA and MATRIXB data sets, IMS can implement the
                                    security when it is initialized. When IMS is initialized, it loads the
                                    MATRIXA or MATRIXB tables containing the security information into IMS
                                    control storage. During IMS execution, IMS references the in-core matrix
                                    tables to enforce security choices that have been made using SMU.
                              Prior to running the SMU utility using the SECURITY procedure, you will need
                              to define the AGN groups that name the PSBs to be secured. Based on the
                              sample macros presented here, the input statements are coded for an AGN
                              group called CICSAGN1:


                                   )( AGN            CICSAGN1
                                             AGPSB   DFSIVP6
                                             AGPSB   DFSIVP61
                                             AGPSB   DFSIVP62
                                             AGPSB   DFSIVP64
                                             AGPSB   DFSIVP65
                              The SECURITY procedure from proclib contains the following DD statement:
                                   //SYSIN     DD DSN=NO.SYSIN.DD.ASTERISK
                              You will need to modify the DSN= parameter to point to the data set
                              containing the AGN statements above.
                          3. Run the SMU utility using the above input statements. Run IVP job:
                                   IV2E313J FUNCTION: ESTABLISH IMS SECURITY
                              to execute the SECURITY procedure.
                          4. IVP job
                                   IV2E315J FUNCTION: COPY STAGING LIBRARIES
                              is used to copy the staging libraries to execution libraries. Thus, the security
                              tables built by executing the SECURITY procedure in IV2E313J will be copied
                              to MATRIXA when you have completed running IV2E315J. You should also
                              copy the security tables to MATRIXB .
                              Now that you have completed the AGN group security definitions to IMS, you
                              need to make some security definitions to RACF. The above AGN SECURITY
                              SMU generation that you just completed identified to IMS the names of the
                              PSBs that you want secured. IMS does not know which CICS subsystems
                              will be allowed to schedule PSBs that have been protected in the AGN
                              group. Also, IMS SMU security facilities so not have the capability to verify
                              user IDs. All IMS knows is that the PSBs have been protected. When AGN
                              security is turned on, either RACF or DFSISIS0 must be used to determine
                              which user IDs are authorized to use the PSB. To verify the CICS subsystem
                              user IDs that can access PSBs in the protected AGN group, you need RACF.


164   IMS V6 Security Guide
5. Define security profiles for the AGN group(s) in RACF and authorize CICS
   user IDs.
  Security profiles for resources are defined in RACF classes. In the example,
  we specified that RACF would be used for AGN user ID authorization when
  the TYPE=RACFAGN was specified on the SECURITY macro.
  The name of the RACF class used to define AGN security profiles is
  Axxxxxxx, where xxxxxxx is the value specified on the RCLASS= parameter
  of the SECURITY macro coded in Stage 1 input. The sample SECURITY
  macro above was specified as RCLASS=IMS. Therefore, the name of the
  RACF class that is derived (and will be used) for creating AGN security
  profiles is AIMS (which is derived from ″A + I M S ″ from the RCLASS
  parameter). If we had used the value of RCLASS=XYZ on the SECURITY
  macro, for example, then the RACF class AXYZ would be used for creating
  the AGN security profiles.
  The RACF class AIMS is the default (because RCLASS=IMS is the default
  for RCLASS in IMS). When you use RCLASS=IMS on the SECURITY macro,
  RACF already contains the AIMS class, so you do not have to create the
  class. Also the AIMS class is already activated for you. The RACF default
  classes are activated during RACF installation. It is recommended that you
  use the default classes to avoid having to create new RACF class descriptor
  table entries and having to activate the new classes, especially if you are
  unfamiliar with DBCTL security.
  Two RACF commands are used to create the security profile and authorize
  the CICS user ID(s). The RDEFINE command is used to define a security
  profile for the AGN called CICSAGN1. The PERMIT command is used to
  authorize the user ID of the CICS address space . The CICS user ID is passed
  in the Participant Adapter Parameter List (PAPL) when CICS connects to
  DBCTL. The PAPL is part of the database resource adapter (DRA). The DRA
  is a component of the CICS-DBCTL interface in the CICS address space. Its
  functions include:
    •   Requesting connection and disconnection from DBCTL
    •   Telling CICS when a shutdown of DBCTL has been requested, or if
        DBCTL has failed
    •   Managing threads
    •   Establishing contact with the DBCTL address space
    •   Loading the DRA startup parameter table
  Continuing to use the example, the following RACF commands are issued:
        RDEFINE AIMS CICSAGN1 OWNER(IMSADMIN)
        PERMIT CICSAGN1 CLASS(AIMS) ID(cics_user ID)
  You have now secured the CICSAGN1 AGN group using IMS and RACF. The
  PSBs that were secured were identified to IMS through the SMU generation
  that you performed by executing the SECURITY procedure, providing as input
  the AGN statements. Then you defined a security profile for the AGN called
  CICSAGN1 in the RACF AIMS class, and used the PERMIT command to
  authorize the user ID of the CICS subsystem(s) allowed to schedule a PSB
  named in the AGN.
6. Next, the CICS subsystems that are allowed to use PSBs in the AGN group
   CICSAGN1 must pass a user ID in the PAPL when they connect to DBCTL.




                         Chapter 8. IMS Resources Accessed from Other Environments   165
                               The database resource adapter (DRA) must be generated to specify the IMS
                               system the CICS subsystem is connecting to and the AGN this CICS
                               subsystem is authorized to use. Using the example, the following
                               parameters are supplied in the DRA:
                                 •   DBCTLID=IMSP
                                 •   AGN=CICSAGN1
                               A sample of the JCL used to generate a DRA is included in Figure 32 on
                               page 167 with the DBCTLID and AGN specifications highlighted. The
                               DBCTLID used in the DRA has to match the IMSID=IMSP, specified on the
                               IMSCTRL macro in system definition macros. CICSAGN1 was the name we
                               assigned to the AGN when the SMU input was coded to name the PSBs that
                               were secured in the AGN group.
                               Different AGN group names can be used for each CICS system, if you like;
                               and the same PSB(s) can be named in multiple AGN groups. For example,
                               the following AGN group names could have been coded:
                               )( AGN           CICSAGN1
                                        AGPSB   DFSIVP6
                                        AGPSB   DFSIVP61
                                        AGPSB   DFSIVP64
                                        AGPSB   DFSIVP65

                               )( AGN           CICSAGN2
                                        AGPSB   DFSIVP61
                                        AGPSB   DFSIVP62
                                        AGPSB   DFSIVP64
                                        AGPSB   DFSIVP65
                          7. Specify the I S I S = 1 execution parameter in the DBC procedure used to start
                             DBCTL. The default DFSPBDBC (or DFSPBxxx) member of the IMS
                             procedure library must contain an ISIS=x value in order to initialize IMS.
                             ISIS=1 specifies that RACF will be used to perform authorization checking
                             for AGN security. Even though the SECURITY macro contained RACFAGN,
                             the ISIS specification is also required as a startup parameter. To turn off
                             AGN security checking, simply start IMS using ISIS=0.

                        The above description is on IMS and CICS security prospect only. For complete
                        IMS DBCTL system generation, refer to Interoperability Between VSE DL/I and
                        OS/390 IMS DBCTL , SG24-5249.


8.5.2 Implementing Automated Operator Program Security
                        Did you notice that one APPLCTN macro was not used in the above example?
                              APPLCTN PSB=DFHDBMP,PGMTYPE=BATCH,SCHDTYP=PARALLEL

                        CICS provides an automated operator transaction, CDBM, which enables DBCTL
                        operator commands to be input from a CICS screen, as described in CICS
                        Transaction Server for OS/390 CICS IMS Database Control Guide , SC33-1700.
                        CDBM uses the AOI commands (available from IMS/ESA 5.1 onward) that can be
                        issued across the DRA interface between CICS and DBCTL.

                        To use CDBM you must:
                          •    Have a DBCTL system running IMS/ESA 5.1 or later.
                          •    Generate, and add to the DBCTL system, a PSB named DFHDBMP.
                               Specifying parallel scheduling for this PSB enables multiple CDBM

166   IMS V6 Security Guide
 JCL you can copy to generate a DRA.

 //DRAJOB JOB 1,PGMERID,MSGCLASS=A,MSGLEVEL=(1,1),
 //         CLASS=A,NOTIFY=PGMERID
 //ASM EXEC PGM=IEV90,
 //       PARM=′ DECK,NOOBJECT,LIST,XREF(SHORT),ALIGN′ ,
 //       REGION=4096K
 //SYSLIB DD DSN=IMS.OPTIONS,DISP=SHR
 //       DD DSN=IMS.GENLIB,DISP=SHR
 //       DD DSN=IMS.GENLIBA,DISP=SHR
 //       DD DSN=IMS.GENLIBB,DISP=SHR
 //       DD DSN=SYS1.MACLIB,DISP=SHR
 //*
 //SYSUT1 DD UNIT=SYSDA,SPACE=(1700,(400,400))
 //SYSUT2 DD UNIT=SYSDA,SPACE=(1700,(400,400))
 //SYSUT3 DD UNIT=SYSDA,SPACE=(1700,(400,400))
 //SYSPUNCH DD DSN=&&OBJMOD,
 //       DISP=(,PASS),UNIT=SYSDA,
 //       DCB=(RECFM=FB,LRECL=80,BLKSIZE=400),
 //       SPACE=(400,(100,100))
 //SYSPRINT DD SYSOUT=*
 //SYSIN DD *
 PZP      TITLE ′ DATABASE RESOURCE ADAPTER STARTUP PARAMETER TABLE′
 DFSPZP00 CSECT
          EJECT
          DFSPRP DSECT=NO,
                 DBCTLID=IMSP,
                 DDNAME=CCTLDD,
                 DSNAME=IMS.RESLIB,
                 MAXTHRD=99,
                 MINTHRD=10,
                 TIMER=60,
                 USERID=,
                 CNBA=10,
                 FPBUF=,
                 FPBOF=,
                 TIMEOUT=60,
                 SOD=A,
                 AGN=CICSAGN1
          END
 /*
 //LNKEDT EXEC PGM=IEWL,
 //       PARM=′ LIST,XREF,LET,NCAL′
 //SYSUT1 DD UNIT=SYSDA,SPACE=(1024,(100,50))
 //SYSPRINT DD SYSOUT=*
 //SYSLMOD DD DSN=IMS.RESLIB,DISP=SHR
 //SYSLIN DD DISP=(OLD,DELETE),DSN=&&OBJMOD
 //         DD DDNAME=SYSIN
 //SYSIN    DD *
    NAME DFSPZP00(R)
 /*

Figure 32. Sample JCL to Generate DRA

   transactions to be active at the same time. DFHDBMP need not have any
   associated PCBs. Example input for the PSBGEN is:
     PSBGEN LANG=ASSEM,PSBNAME=DFHDBMP,IOASIZE=1000


                        Chapter 8. IMS Resources Accessed from Other Environments   167
                        You will need to define to IMS whether automated operator programs, like
                        DFHDBMP, can issue IMS commands. And you will need to create and/or
                        authorize the CICS address space user ID to the RACF security profiles for the
                        commands DFHDBMP can issue. There are two types of automated operator
                        (AO) programs:
                          •   AO programs that use the DL/I issue ICMD call.
                              The CDBM transaction results in the scheduling of DFHDBMP in DBCTL.
                              DFHDBMP uses the ICMD call to issue IMS commands.
                          •   AO programs that use the DL/I CMD call.

                        When AO programs use the ICMD call, you signify the type of security using an
                        IMS execution parameter, AOIS=x, where x has a value of A, C, N, R, or S.
                        There is not a system definition macro used to designate security for ICMD call
                        AO programs, so the security for this type of AO program must be specified
                        using the AOIS parameter. The default is N, meaning AO programs can not issue
                        IMS commands.

                        When AO programs use the CMD call to issue IMS commands, the Stage 1 input
                        on the SECURITY macro must include the parameter TRANCMD=YES or
                        TRANCMD=FORCE. There is not an execution parameter to specify turning
                        CMD call AO program security on and off; however the security for these types
                        of AO programs can be changed when IMS is initialized. This is done by
                        including one of the TRANCMDS or NOTRANCMDS keywords on the any of the
                        following IMS restart commands:
                          •   /NRE
                          •   /NRE CHKPT 0
                          •   /ERE COLDSYS

                        AO programs that use the CMD call can only be secured using SMU. The type of
                        security provided by SMU for these types of AO programs in the DBCTL
                        environment is to assign a password to each command that is to be protected.
                        See Chapter 4, “Securing IMS Commands” on page 77 for examples on
                        securing AO programs that use the CMD call.

                        Since our example is for DFHDBMP, which uses the ICMD call, we do not need
                        to specify a parameter on the SECURITY macro. However we do need to supply
                        a value for AOIS in the DBCTL startup procedure. The DBC procedure, used to
                        start the DBCTL system, points to a member of the IMS procedure library that
                        contains the IMS execution parameters. The member name, DFSPBxxx has a
                        default member name of DFSPBDBC. The AOIS specifies whether RACF and the
                        Command Authorization exit routine (DFSCCMD0) are to be used with AO
                        applications for command security. Code one of the following values for the
                        AOIS= parameter:
                        AOIS Description
                        A       Includes options C and R below. RACF is called first. Then the security
                                authorization facility (SAF) return code, RACF return code, and RACF
                                reason code are passed to DFSCCMD0. These return codes are decoded
                                into a security code, which is also passed to DFSCCMD0 for processing.
                        C       Specifies that DFSCCMD0 is to be called for command authorization.
                        N       Specifies that the DL/I call ICMD cannot be issued by an application
                                program. This is the default.



168   IMS V6 Security Guide
R           Specifies that RACF is to be called for command authorization.
S           Specifies that no authorization checking is to be done.

This example uses RACF for security, thus AOIS=R is specified in the
DFSPBDBC member of the IMS procedure library. Now that IMS has been
notified (by AOIS=R) that AO programs can execute IMS commands and that
RACF will provide the authorization check, we will need to define the command
security profiles in the RACF class for commands: CIMS or DIMS. (Refer to
Chapter 4, “Securing IMS Commands” on page 77 for additional examples.)
Again, the CIMS and DIMS RACF class names were derived from:
        C + RCLASS value on the SECURITY macro = CIMS
        D + RCLASS value on the SECURITY macro = DIMS

All of the commands issued by an AO can be grouped together in a DIMS
security profile; or a security profile can be created for each IMS command in
the CIMS class. Figure 33 are examples of the RACF commands required to
define command security profiles and authorize user IDs.



         RDEFINE CIMS STO OWNER(IMS) UACC(NONE)
         PERMIT STO CLASS(CIMS) ID(DFHDBMP) ACCESS(READ)
         PERMIT STO CLASS(CIMS) ID(cics_user ID) ACCESS(READ)

         RDEFINE DIMS CICSUSR1 OWNER(IMS) UACC(READ)
         RALTER DIMS CICSUSR1 ADDMEM(STA STO NRE DIS)
         PERMIT CICSUSR1 CLASS(DIMS) ID(DFHDBMP) ACCESS(READ)
         PERMIT CICSUSR1 CLASS(DIMS) ID(cics_user ID) ACCESS(READ)

         RDEFINE DIMS CICSUSR2 OWNER(IMS) UACC(NONE)
         RALTER DIMS CICSUSR2 ADDMEM(DBR DIS STA STO SWI)
         PERMIT CICSUSR2 CLASS(DIMS) ID(cics_user ID) ACCESS(READ)
         PERMIT CICSUSR2 CLASS(DIMS) ID(DFHDBMP) ACCESS(READ)

Figure 33. RACF Command Protection Example Using CIMS and DIMS

Review Table 4 on page 32 to gain an understanding of the user ID that will be
used for DFHDBMP when an authorization call is made to RACF.

In the first example, a security profile in the command class (CIMS) is created
for the /STOP command. The universal access is NONE. The DFHDBMP user ID
has been authorized to issue the /STOP command. Note that command security
profile names in the CIMS class must be the first three characters in the
command. Therefore, the IMS STOP command has a security profile name of
STO. DIMS profile names can be greater than three characters.

The second and third examples show how to create command profiles in the
DIMS class which is used to secure groups of commands.

The CICS address space user ID should be authorized to IMS commands in the
RACF CIMS/DIMS classes. Prior to authorizing the CICS user ID to IMS
CIMS/DIMS security profiles, the installation should review the IMS commands
that can be issued from the CDBM CICS transaction. RACF checks whether the
CICS user ID supplied at CICS startup is authorized to the IMS command. The
CICS user ID supplied in the DRA is obtained by one of the following means:
    •    The user ID supplied in the JOB statement of the CICS startup job


                              Chapter 8. IMS Resources Accessed from Other Environments   169
                          •   The user ID supplied in the started procedure table



8.6 Summary
                        This chapter covered securing access to IMS applications and data from other
                        subsystems and/or networks:
                          •   APPC. The IMS/APPC environment is secured using the SAF/RACF and/or
                              security exits.
                          •   MSC. As much security checking as possible should be done in the
                              front-end system. The security environment for the dependent region is used
                              for authorization checks on the back-end system when the security
                              environment for the user who entered the transaction is not available. The
                              DFSBSEX0 and/or DFSCTSE0 user exit(s) can be used to customize the
                              security processing in the back-end system.
                          •   OTMA and ITOC RACF and/or security provide protection for resources
                              accessed from OTMA and/or ITOC environments.
                          •   CICS DBCTL. AGN security is provided by SMU and RACF. AO security can
                              be provided by either SMU or RACF, depending on whether the program
                              used the CMD or ICMD DL/I call to issue the command.




170   IMS V6 Security Guide
Chapter 9. IMS Security in a Shared Queues Environment

                         This chapter describes the security considerations for operating IMS in a shared
                         queues environment. The following topics are covered:
                             •   Front-end command and transaction authorization considerations
                             •   Back-end command and transaction authorization considerations
                             •   Authorizing connections to shared queues structures

                         In a shared queues environment, IMS acts as a front end for terminals, as a back
                         end for processing, or as both simultaneously. Consequently, the user must
                         consider security based on the role that the IMS subsystem is playing.

                         The two environments in which front-end processing can be split from back-end
                         processing are multiple systems coupling (MSC) and shared queues. See
                         Figure 34.




                         Figure 34. IMS Front-End and Back-End Systems

                         IMSA and IMSB are members of a shared queues group. IMSA and IMSB
                         access full function and EMH messages queues structures using CQS. The
                         primary and overflow message queues reside in the coupling facility (CF). IMSA
                         is the front-end system for LT1, and IMSA is a back-end system for LT2 and LT3.
                         IMSB is the front end for LT2 and a back end for LT1 and LT3. IMSB is attached
                         via an MSC link to IMSC. IMSC is the front end for LT3, and a back end for LT1
                         and LT2. It should be noted here that some installations configure systems
                         participating in a shared queues environment in a manner such that all the
                         LTERMs are assigned to the front end and transactions are on the back-end
                         systems.




© Copyright IBM Corp. 1999                                                                            171
9.1   Front-End Security
                        An IMS front end in a shared queues environment is the IMS system to which
                        the terminal user is attached, or the local system on which a job is submitted.
                        The same facilities that provide resource authorization checking for a
                        non-shared queues environment perform authorization checking in a front-end
                        system. That is, RACF, SMU, and security exits may be used to secure IMS
                        resources on the front end.

                        IMS systems in a shared queues group may use the RACF data spaces on the
                        MVS images on which each IMS runs. Care should be taken to ensure that the
                        RACF systems on each of the MVS images share the same RACF database. The
                        RACF data spaces are loaded from the RACF database. If the RACF system has
                        been brought up using a data space instead of the RACF database, IMS will use
                        the RACF data space. During IMS initialization, IMS V6 checks to determine
                        whether RACF is using a data space or the RACF database.


9.1.1 Front-End Command Authorization
                        Terminal entered commands are not placed on the shared queues. These
                        commands are executed on the IMS system on which the command is entered
                        (front-end IMS). Therefore, terminal-entered commands are secured using the
                        same facilities (SMU, RACF, and/or DFSCCMD0) and in the same manner as
                        non-shared queues IMS systems. And on front-end systems, DFSCCMD0 should
                        work the same as in a non-shared queues environment.

                        Securing commands using RACF has some definite advantages over SMU in a
                        shared queues environment. When the RACF data space or database is shared
                        among IMS systems in a shared queues group, one set of RACF profiles may be
                        used by all the systems. So when a change is made that affects command
                        authorization, all IMS systems sharing the same RACF security profiles can take
                        advantage of the change immediately. With SMU, the change would have to be
                        made on each IMS system in the shared queues group. Therefore, in a shared
                        queues environment, securing a command with SMU on one of the IMS systems
                        in a shared queues group does not secure the command on other IMSs in the
                        group.

                        Unlike terminal entered commands, automated operator programs are placed on
                        the shared queues. If multiple IMS systems in a shared queues group have the
                        same AO program statically defined, any IMS to which the AO
                        transaction/program has been defined can retrieve the message and process the
                        commands issued by the program. In a shared queues environment, this could
                        result in commands being processed on the wrong IMS system. If your
                        installation intends for commands to be processed on the IMS system where the
                        AO transaction or program is entered/submitted, you will need to establish an
                        affinity between where the transaction is entered (or where the program is
                        submitted) and where it gets processed.

                        To ensure that AO programs do not issue IMS commands that can alter the
                        resources on the wrong IMS, code SERIAL=YES on the TRANSACT macro. In a
                        shared queues environment, SERIAL=YES will allow only the IMS where the
                        transaction was entered to retrieve and process the message.




172   IMS V6 Security Guide
Figure 35. Authorization Processing in SMQ Environment

Using Figure 35 as an example, if SERIAL=YES is coded on the TRANSACT
macros for TRANA on both IMSA and IMSB, IMSA can only retrieve the message
from the shared queues and process TRANA when it is entered from a terminal
attached to IMSA. Likewise, IMSB can only retrieve the message from the
shared queues and process TRANA when it is entered from a terminal attached
to IMSB.

MVS supports up to 32 IMS systems in a shared queues group. Each IMS
subsystem in the shared queues group is required to have a master terminal
(except DBCTL systems). This could become an operations management
challenge. To facilitate issuing IMS commands from a single source/place in
sysplex environments, IMS supports issuing IMS commands from MCS/E-MCS
consoles. Of course, in many customer installations, hundreds of terminals may
be MCS/E-MCS (such as SDSF terminals) consoles. Therefore, it is important to
be able to decide which consoles will be authorized to issue IMS commands.
Whether command authorization for commands entered from MCS/E-MCS
consoles can be done depends on the security facility used for command
security checking.

SMU does not provide support for securing commands issued from MCS/E-MCS
consoles. Either RACF and/or DFSCCMD0 can be used to secure commands
issued from MCS/E-MCS consoles, and DFSCCMD0 can secure commands at the
command and keyword levels. The console ID is the user ID that is PERMITTED
to security profiles protecting commands in the CIMS/DIMS classes:


                             Chapter 9. IMS Security in a Shared Queues Environment   173
                              RDEFINE CIMS NRE OWNER(IMS) UACC(NONE)
                              PERMIT NRE CLASS(CIMS) ID(console ID) ACCESS(READ)

9.1.2 Front-End Transaction Authorization
                        Front-end resource authorization in a shared queues environment is similar to
                        resource security in a non-shared queues environment. Either SMU, RACF,
                        and/or DFSCTRN0 can be used to provide transaction authorization in front-end
                        environments. However, there are some considerations.

                        SMU can be used to secure AGNs, AO programs issuing the DL/I CMD call, and
                        transactions in the local IMS front end. RACF can be used to secure
                        transactions, AO programs issuing the DL/I ICMD call, and provide user ID
                        verification for AGN groups.

                        9.1.2.1 SMU
                        SMU security in a shared queues environment will affect the front end only. In
                        general, SMU can only be used for security in a shared queues environment
                        when:
                          1. The control blocks required for security checking are local to the IMS making
                             the security check, and
                          2. Resource protection has been requested for the resource type
                        This means that when SMU is used to secure a resource in the shared queues
                        environment, the resource being secured must be statically defined to the IMS
                        making the security check. Securing a resource with SMU on the front end IMS
                        does not secure the resource on the back-end IMS systems. Take a look at
                        Figure 35 on page 173. TRANA is statically defined to both IMSA and IMSB.
                        SMU password and/or LTERM-based (restrict LTERMs where TRANA can be
                        entered) security can be provided for TRANA. However, using SMU to secure
                        TRANA on IMSA does not secure entering TRANA from IMSB. Therefore, in a
                        shared queues environment, when SMU is used for transaction and command
                        security, the resource should be secured on all the IMS systems participating in
                        the shared queues group.

                        Refer to Figure 35 on page 173. Note that IMSB does not have TRANB statically
                        defined. In a shared queues environment, it is possible to have TRANB
                        submitted from a terminal attached to IMSB. IMSB can queue the message for
                        TRANB on the shared queues, and the message can be retrieved and processed
                        by IMSA, where TRANB has been statically defined. In this situation, SMU
                        cannot provide transaction authorization for TRANB on IMSB because SMU does
                        not support security checking for dynamically defined resources.

                        SMU does support authorization checking for DL/I CHNG calls and deferred
                        conversational program-to-program switches. SMU does not support:
                          •    Authorization checking for the DL/I AUTH call
                          •    Authorization checking for messages from APPC or OTMA




174   IMS V6 Security Guide
9.1.2.2 RACF
The security profiles in a RACF database or data space can be shared by
multiple IMS subsystems. Therefore, the installation has the option of changing
security profiles on the IMS subsystem and having the change take effect on all
sharing subsystems. Unlike SMU, RACF does provide security for dynamically
defined transactions (or SMBs). Therefore, in Figure 35 on page 173, when
TRANB is submitted from a terminal attached to IMSB, IMSB issues a
RACROUTE request to RACF to authorize the user ID of the terminal user. Since
the security information about the user and the transaction is in the RACF data
space (or database), RACF can perform the authorization checking.

Since transaction authorization takes place at transaction entry on the front end
prior to placing a message on the shared queues, there is no need to perform
transaction authorization for the transaction if it is retrieved and processed by a
back-end system. The security check has already been done.

RACF can also be used to provide security for AO transactions and programs.
As with SMU, in order to ensure the commands issued by the AO program are
executed on the IMS for which the commands are intended, SERIAL=YES must
be coded on the TRANSACT or APPLCTN macro to establish an affinity to the
IMS where the command should be executed.

In addition to providing support for the DL/I CHNG call and deferred
program-to-program switches, RACF also provides authorization checking for the
DL/I AUTH call. RACF also supports transaction authorization for messages
received from APPC and OTMA environments.

9.1.2.3 Considerations for Front-End Security
When users have multiple sign-on capability, care has to be taken to ensure that
each LTERM is active in only one IMS subsystem in the shared queues group.
Although LTERMs definitions can be cloned in IMS systems in the shared queues
group, an LTERM should only be active in one IMS. Otherwise, output security
could be compromised.

In a shared queues environment where the RACF database (or data space) is not
shared, in order for resource authorization to work properly security profiles
must be defined and kept synchronized on all the RACF databases.

When a CHNG call, AUTH call, or deferred conversational program-to-program
switch is performed in a dependent region, if the dependent region is part of the
same IMS system as the terminal where the transaction was entered (and the
user has not signed off), the security environment created at user sign-on in the
front end is used.

RACF can also be used to provide authorization for messages received from
APPC and OTMA environments. For input from APPC or OTMA, if security is
defined as FULL, the security environment has already been created before any
CHNG or AUTH call. If APPC/OTMA security is defined as NONE, RACF is not
called. However, if DFSCTRN0 (or DFSCCMD0) are in IMS.RESLIB (or the
concatenation) the exit(s) will be used for authorization. If APPC/OTMA security
is defined as CHECK, and a CHNG or AUTH call is made, a dynamic security
environment has to be created.




                             Chapter 9. IMS Security in a Shared Queues Environment   175
9.1.3 Back-End Security
                        Three processing environments exist when IMS acts as a back-end processing:
                        local, remote MSC, and remote shared queues, as shown in Figure 34 on
                        page 171.

                        When SMU is used to secure resources in a back-end system, resource
                        authorization for the resource must be active. As mentioned earlier, securing a
                        resource on a front end does not secure the resource on the back end when
                        SMU is used to provide security. Also, in order for SMU to provide security, the
                        resource must be statically defined. Figure 35 on page 173 illustrates this point
                        by showing when TRANB is entered from the terminal attached to IMSB, SMU
                        cannot be used for transaction authorization because TRANB is not statically
                        defined to IMSB. The illustration also shows that when SMU is used for
                        transaction authorization, SMU generations must be performed on both IMSA
                        and IMSB for TRANA to ensure that no matter from which system TRANA is
                        entered, authorization checking is performed.

                        RACF can be used to avoid these limitations of SMU. When the RACF database
                        is shared by IMSA and IMSB, security checking can be performed from a single
                        set of RACF security profiles, and the resource does not have to be statically
                        defined to the IMS making the security check. The Output Creation Exit (used for
                        ETO) has been enhanced specifically for the purpose of placing messages on the
                        shared queues for transactions that have not been defined to an IMS system
                        participating in a shared queues environment. If the Output Creation Exit on
                        IMSB has been coded to accept TRANB as a valid transaction code for the IMSs
                        participating in the shared queues group, IMSB can queue the message for
                        TRANB so that IMSA can process the message. Note that while IMSB can queue
                        the message to the shared queues, it cannot process TRANB because TRANB
                        has not been defined to IMSB. However, IMSB can perform the security
                        checking for entering TRANB when RACF and/or DFSCTRN0 is used for
                        transaction authorization.

                        Transaction security checking does not occur in a back-end system unless a
                        CHNG or AUTH call is issued, or a deferred conversational program-to-program
                        switch is requested. Remember the security check performed at transaction
                        entry has already been done by the front-end system prior to placing the
                        message on the shared queues. In the case where an application program
                        executing on a back-end system issues a CHNG or AUTH call, or requests a
                        deferred conversational program-to-program switch, the IMS back end does
                        perform a security check. The back-end IMS has to build a security environment
                        (an ACEE) to perform the security check. This is because the security
                        environment for the user that submitted the transaction is on the front end,
                        where the transaction was submitted. Because the back end does not have a
                        security environment built for the user that submitted the transaction, IMS can
                        build a security environment in the dependent region on the back-end system to
                        authorize the user′s authority to the transaction requested by the CHNG, AUTH,
                        or deferred conversational program-to-program switch. If the installation does
                        not want a dynamic security environment to be built, DFSBSEX0 can be used to
                        control the security processing that is done by IMS. The exit just passes back a
                        return code that can cause the dynamic creation to be bypassed when the
                        authorization check is done.

                        The security check performed on the back end as a result of the CHNG call,
                        AUTH call, or deferred conversational program-to-program switch is done using



176   IMS V6 Security Guide
one of the following user IDs that was placed in the message prefix or supplied
on the JCL:
 •   User ID of the terminal user
 •   LTERM name
 •   PSB name
 •   User ID specified by the USER= parameter in the JCL
The user ID was placed in the message prefix by the front-end system when the
transaction was entered. The front-end system derived the user ID using a
number of factors, including:
 •   Whether the terminal user was signed on
 •   Whether a GU was issued
 •   Whether the program was running in an MPR, IFP, or BMP region
 •   Whether USER= parameter was specified in the JCL

The security environment does not exist for the user ID (no ACEE) in the
back-end system and the environment has to be created. The security
environment that is created at sign-on is not available under the following
conditions:
 •   The dependent region is part of the same IMS as the inputting terminal, but
     the user has signed off.
 •   The dependent region is part of another IMS, connected to the IMS with the
     inputting terminal by an MSC link.
 •   The dependent region is part of another IMS in a sysplex with IMS shared
     message queues support.

Command authorization for back-end systems is only a consideration in the
shared queues environment when the commands are issued by an AO program
and the AO program does not have affinity to the IMS system where it was
entered. As previously mentioned, terminal entered commands are always
executed on the front-end system. AO programs can be allowed to run on
front-end or back-end systems. Where the AO program runs can be controlled
by coding SERIAL=YES on the TRANSACT or APPLCTN macros.

If AGN security is in place for back-end systems, and LTERMs are included in
AGN groups, in a shared queues environment those LTERMs must be statically
defined to the IMS back-end systems.

Using SMU to secure transactions for an LTERM provides security only for the
IMS on which the security check is being made and only if the resources are
defined to that IMS. In other words SMU can only be used for the security check
of resources that are local to the IMS making the check.

9.1.3.1 Considerations for Back-End Security
The most important consideration for back-end security involves the use of
security exits. In a shared queues environment, when a transaction is processed
by the same IMS system that was used to enter the transaction (the front-end
IMS), security exits are unaffected. However, when a transaction is entered by
one IMS (front end) and processed by a different IMS (back end), if security exits
are used in the authorization processing, there is a problem. The address of the
CTB (Register 7) is zeros in the back-end system. Many installations have coded


                             Chapter 9. IMS Security in a Shared Queues Environment   177
                        security exits in a manner   where the address of the ACEE is obtained from the
                        CTB. In a shared queues      environment, the CTB address is available on the front
                        end, but the CTB address     is not available on the back end. Consequently,
                        security exits on the back   end will not function properly.

                        If DFSCCMD0, DFSCTRN0, and/or DFSCTSE0 have been coded to use the CTB to
                        locate the ACEE, these exits will need to be modified. If there are other IMS
                        systems (that are not part of the shared queues environment) that also utilize
                        these security exits, then the installation will need to modify the exits in a
                        manner where the ACEE can be located whether shared queues is used.

                        Another consideration is that if SMU is used for security in a shared queues
                        environment, the destination of a message switch has to be statically defined in
                        the back-end system.

                        The final consideration is that when multiple sign-ons are allowed on IMS
                        systems participating in a shared queues group, output could be delivered to the
                        wrong user if the Sign-On Exit has not been coded to create unique LTERM
                        names. The uniqueness of LTERM names can be accomplished in the shared
                        queues environment by using a RACF user ID and two-character suffixes (for
                        IMSID and the number of times signed on on a single IMS):
                          •   A RACF user ID of six characters or fewer
                          •   A one-character suffix indicating the IMS system in the shared queues group
                          •   A one-character suffix indicating the number of sign-ons performed
                        For example, USERA1 could represent an LTERM name where ″USER″ is the
                        RACF user ID, ″ A″ represents IMSA, and ″1″ represents the first sign-on to IMSA
                        by this user. Whereas USERB3 represents an LTERM name where ″USER″ has
                        signed on to IMSB, and this is the ″3″ (third) sign-on for this user on IMSB. This
                        convention may be used to maintain unique LTERM names in a shared queues
                        environment.

                        If possible, a shared RACF database should be used so that security profiles are
                        synchronized. And, if MSC routing between systems in a shared queues group
                        is in place, the RACF databases at both the MSC location and the IMS shared
                        queues location should be kept synchronized to avoid security failures and/or
                        default control region security on the back-end MSC system.



9.2 Authorizing Connections to Common Queue Structures (CQS)
                        If RACF or another security product is installed, the security administrator can
                        define profiles that control the ability of clients to connect to CQS shared queue
                        structures. When a client (IMS subsystem participating in a shared queues
                        group) issues the CQSCONN request to connect to a CQS queue structure, CQS
                        issues a call to RACF:


                        RACROUTE REQUEST=AUTH

                        The call to RACF determines whether the client is authorized to access the
                        structure.

                        RACF checks the user ID of the client that issued the CQSCONN request. This
                        user ID must have at least UPDATE authority to connect to the structure through
                        CQS.

178   IMS V6 Security Guide
              The RACF security administrator should define profiles in the FACILITY class to
              control the connection to CQS structures. The profile names must be of the form
              CQSSTR.structure_name, where structure_name is the name of the primary
              structure that you define in the CQSSGxxx PROCLIB member.

              The CQSSTR.structure_name profiles only control access to the specified
              structures through CQS. They do not control direct access to the structure using
              IXL macros.

              For more information on controlling access to coupling facility structures, see
              OS/390 MVS/ESA Programming: Sysplex Services Guide , GC28-1771.

              To define a profile for a CQS primary structure named IMSMSGQ01, and to allow
              only user CQSUSER to connect to it, issue the following RACF commands:


               RDEFINE FACILITY CQSSTR.IMSMSGQ01 UACC(NONE)
               PERMIT CQSSTR.IMSMSGQ01 CLASS(FACILITY) ID(CQSUSER) ACCESS(UPDATE)

               SETROPTS CLASSACT(FACILITY)

              If you do not define a security profile in the FACILITY class for a particular CQS
              structure, the structure is not protected, and any user ID can issue a CQSCONN
              request to access the structure.



9.3 Summary
              Most resource authorization processing occurs in the front-end system, or point
              of entry.

              IMS resource authorization may or may not be affected by implementing IMS in
              a shared queues environment. Terminal-entered commands are processed by
              the IMS control region on the system where the command is input by the
              terminal user. AO program entered commands should have the TRANSACT
              and/or APPLCTN macro coded with the parameter SERIAL=YES to ensure the
              commands are executed on the correct IMS system. MCS/E-MCS command
              authorization may be performed by RACF and/or DFSCCMD0. The console ID is
              the user ID passed to RACF/DFSCCMD0 for authorization for the console to issue
              the command.

              Transaction authorization in a shared queues environment can be performed by
              SMU, RACF, and/or DFSCTRN0. SMU secures the transaction only on systems
              where TRANAUTH has been requested, and the transactions must be statically
              defined on each IMS. When RACF is used, transaction authorization for dynamic
              transactions (SMBs) can be performed.

              A major consideration for using security exits in a shared queues environment is
              when the DL/I CHNG or AUTH call is issued, or when a deferred conversational
              program-to-program switch is requested from a back-end system. If the security
              environment is not available to the back end, it has to be created dynamically,
              Security exits, such as DFSCCMD0 and DFSCTRN0, that have been customized to
              locate the address of the ACEE from the CTB will have to be modified. The
              address of the CTB is zeros in back-end systems in a shared queues
              environment.




                                           Chapter 9. IMS Security in a Shared Queues Environment   179
                        If multiple sign-on capability is allowed in the shared queues environment, the
                        Sign-On Exit must be coded to generate unique LTERM names. This can be
                        accomplished by appending a two-character suffix to the RACF user ID, where
                        one character represents the IMS identifier and the other character represents
                        the number of times the user has signed on to a particular IMS. Using this
                        naming scheme requires the RACF user ID be fewer than seven characters.




180   IMS V6 Security Guide
Chapter 10. IMS Security Exits

                         This chapter covers the following exit routines used for IMS security:
                             •   Command Authorization Exit Routine
                             •   Transaction Authorization Exit Routine
                             •   Security Reverification Exit Routine
                             •   Sign-On/Off Security Exit Routine
                             •   Sign-On Exit Routine
                             •   Build Security Environment Exit
                             •   Resource Access Exit Routine
                             •   Initialization Exit Routine

                         Table 31 shows the security routines with the related control blocks, the time
                         they receive control, and whether the exit has access to the DFSINTX0 data
                         table.

  Table 31. Security Exit Routines
  Exit Name          Function Called by                                   CNTL        Receives       Access
                                                                          Block       Control        to
                                                                                      before/after   DFSINTX0
                                                                                      RACF           Table
  DFSCCMD0           Command Authorization                                CLB | PST   After          Yes
                                                                          SCD
                     A O I S = A | C | R DFSCCMD0, RACF, Both             CTB
                                                                          CVB
                     AOIS=S No authorization needed
                     AOIS=N No ICMD by application

  DFSCTRN0           Transaction Authorization                            CTB         After          No
                                                                          CLB | PST
                                                                          SCD

  DFSCTSE0           ″Always″ called for transaction authorization.       CTB PST     After          No
                     Except when DFSBSEX0 returns with RC=16              SCD

  DFSSGNX0           Sign-On Processing                                   CLB         Before         Yes
                                                                          SCD

  DFSISIS0           Dependent Region Startup                             SCD         N/A            No
                                                                          AGN
                     ISIS = 0 | 1 | 2
                     0 = No resource access
                     1 = RACF security checking
                     2 = Using DFSISIS0

  DFSCSGN0           Sign-On Processing                                   CLB         After          No
                                                                          SCD
  DFSBSEX0           Dependent Region Scheduling                          None        After          Yes

  DFSINTX0           IMS TM Initialization                                CLB         N/A            Creates
                                                                          SCD                        Table




© Copyright IBM Corp. 1999                                                                                 181
                        Most of the exit source programs can be found in the IMS product distribution
                        source library except Build Security Environment Exit (DFSBSEX0) that is listed in
                        Appendix A, “IMS Security Exits Examples” on page 205.



10.1 Command Authorization Exit (DFSCCMD0)
                        The Command Authorization exit routine (DFSCCMD0) is used to verify that a
                        command is valid from a particular origin. DFSCCMD0 is a required exit routine
                        if it is specified to authorize commands entered from:
                          •   ICMD DL/I calls (from automated operator applications)
                          •   MVS, MCS, or E-MCS consoles

                        DFSCCMD0 is an optional exit routine for commands entered from IMS terminals,
                        including LU 6.2 and OTMA.

                        DFSCCMD0 is one of the three ways that can be used to implement command
                        authorization. The other two are:
                          •   Using RACF and a security profile based on user IDs
                          •   Using SMU and a security profile based on LTERM names

                        This exit routine verifies that the user is authorized to issue a particular
                        command. IMS does not call this exit routine for internally generated or
                        auto-restart commands.

                        You can use the Command Authorization exit routine with a security product,
                        such as SMU or RACF. The return code that the exit routine issues ultimately
                        determines the success or failure of the command authorization. The exit
                        routine can override the outcome of either SMU or RACF.

                        Transaction command security and password security provide another level of
                        access control. Transaction command security is indirectly related to a terminal.
                        If the terminal user enters a transaction to start a program that issues IMS
                        commands, both the transaction code and the set of commands that program
                        can issue must be authorized.

                        DFSCCMD0 is called during ICMD processing to check that the AO application
                        was authorized to issue the command that it issued. DFSCCMD0 lets you secure
                        commands issued in the ICMD call at more granular levels: command verb and
                        keyword level and/or resource name level. Much of the work to implement more
                        granular levels of security must be done by the writer of the exit.

                        APPC/IMS supports the Command Authorization exit routine (DFSCCMD0).
                        When an IMS command is received from an LU 6.2 application program, the
                        Command Authorization exit routine is called. The exit routine is called after a
                        RACF (or equivalent) call is made, regardless of the result of the RACF security
                        check. If neither RACF or the Command Authorization exit routine is available to
                        authorize the command, a default level of command security is provided by IMS
                        for commands from LU 6.2 application programs. The commands included in the
                        default are /BROADCAST, /LOG, and /RDISPLAY.

                        The Command Authorization exit routine can be used with terminals defined
                        statically at system definition. If SMU is requested, it performs the command
                        authorization. If SMU is not requested, default terminal security checks the
                        authorization. The return code from SMU or default terminal security is passed

182   IMS V6 Security Guide
                  to the Command Authorization exit routine. IMS calls the exit routine (if it is
                  included in the system) regardless of the result of the SMU or the default
                  terminal security check; the return code from the exit routine determines
                  authorization.

                  If RACF is not requested but the Command Authorization exit routine is included
                  in the system, IMS calls the exit routine and performs command authorization
                  only. If neither RACF nor the Command Authorization exit routine is included,
                  IMS provides command authorization equivalent to the default terminal security
                  available for static terminals.

                  This exit routine can be   used with commands entered from MCS/E-MCS
                  consoles. The routine is   called for commands from MCS/E-MCS consoles when
                  the CMDMCS parameter       is specified as B or C in the IMS, DBC, or DCC
                  procedure or DFSPBxxx      member of proclib.

                  DFSCCMD0 is called during command processing to check that the terminal is
                  authorized to issue the command.

                  At the entry to DFSCCMD0, some parameters will be provided for this routine.
                  The address to CLB, SCD, user table, CTB, USERID, CVB and the security return
                  code are provided.



10.2 Transaction Authorization Exit (DFSCTRN0)
                  The Transaction Authorization exit routine works with the Security Reverification
                  exit routine (DFSCTSE0) and the Sign-On/Off Security exit routine (DFSCSGN0) to
                  check an individual user ID for authority to use a transaction.

                  APPC/IMS supports the Transaction Authorization exit routine.


10.2.1 Overview
                  This exit routine can be used with or without RACF to verify that the user′s ID is
                  authorized to run a transaction. If both the RACF option and the Transaction
                  Authorization exit routine are selected in the IMS system definition, the exit is
                  activated after RACF verifies the transaction. If the transaction request is
                  rejected by RACF, the exit is not called. If the RACF option is not selected in the
                  IMS system definition, this exit routine can be used to verify the user ′ s
                  authorization and the password, if required, for that transaction.

                  The exit routine should have access to a table of valid user IDs, and the
                  passwords and transactions associated with each valid user ID.

                  In order to implement the DFSCTRN0 exit routine, you need to specify
                  TYPE=TRANEXIT in the SECURITY macro during Stage 1.


10.2.2 Shared Queues Environment
                  In a shared queues environment, when this exit is called from a dependent
                  region, it may be in a different IMS system on a different machine. it is therefore
                  recommended that the security verification table be the same in each IMS
                  system of the shared queues group.

                  If you use message edit routines, security is checked after the message is
                  passed through edit routine.


                                                                      Chapter 10. IMS Security Exits   183
10.2.3 Online Application Program Authorization
                        When you want to authorize an online automated operator program to issue
                        commands, you must use a security option for issuing IMS commands using the
                        DL/I CMD and GCMD calls or DLI ICMD and RCMD calls. You perform this
                        authorization by associating the transaction that invokes the program with a list
                        of commands that the program is designed to use. In the case of an automated
                        operator program, you need to specify all the commands the program is
                        designed to use.
                        Note: SMU cannot be used for transaction command security for DL/I ICMD or a
                        Retrieve Command RCMD calls. An RCMD call lets an automated operator (AO)
                        application program retrieve the second and subsequent command response
                        segments after an ICMD call. In other words, this is synonymous to CMD and
                        GCMD (Get Command).

                        When the Transaction Authorization exit routine (DFSCTRN0), Security
                        Reverification exit routine (DFSCTSE0), and the MSC Program Routing exit
                        routine (DFSCMPR0) are called in a shared queues environment as a result of an
                        application program′s AUTH or CHNG call, the address of the CTB is zero
                        because that control block may not be in the IMS subsystem making the call.



10.3 Security Reverification Exit Routine(DFSCTSE0)
                        DFSCTSE0 is the final decision maker that can override the DFSCTRN0 and RACF
                        to authorize or take authorization away from a transaction. The program source
                        listing is not in product distribution libraries and is included in Appendix A, “IMS
                        Security Exits Examples” on page 205 for your reference.

                        This module is always called for CHNG or AUTH call, with or without RACF,
                        except when DFSBSEX0 returns an RC=16. The exit either returns with a
                        Register 15 value of 0, indicating acceptance of the CHNG call, or a value of 8, to
                        tell IMS to present an A4 status code to the application.

                        If transaction AUTH is active and RACF processing is not requested, DFSCTRN0
                        and DFSCTSE0 will be called if they are specified in IMS system definition.

                        Security Reverification exit routine is an entry point in DFSCTRN0. Having this
                        module is optional. So, if you do not have this entry point, then IMS will not call
                        DFSCTSE0 . This routine can be called from both a RACF environment and
                        non-RACF environment.

                        In a RACF environment, for a CHNG call, if the RACF call is successful (returns a
                        valid return code of 0 or 4), IMS immediately calls the exit routine DFSCTRN0 if
                        DFSCTRN0 exists. In a non-RACF environment, if DFSCTSE0 is coded as an entry
                        point, IMS calls this entry point following each call to DFSCTRN0 if DFSCTRN0
                        exists. Again this applies to CHNG and AUTH calls only. IMS calls this entry
                        point regardless of the return code received from DFSCTRN0.

                        For AUTH call only, the application program always receives notification of the
                        actual RACF return code. This return code, presented as FEEDBACK in the I/O
                        area, can be used by the application program to detect inconsistent operational
                        modes and take alternate action. Examples of inconsistent operational modes
                        are the proper RACF classes not being defined or the requested resource not
                        properly defined to RACF.



184   IMS V6 Security Guide
               In a shared queues environment when DFSCTSE0 is called, the address of the
               CTB is zero because the control block may not be in the IMS subsystem making
               the call.

               DFSCTSE0 will allow the user to reevaluate transaction authorization checking
               on a DLI CHNG call or DLI AUTH call. After an AUTH or CHNG call, there are
               two parameters that come back from RACF. The second parameter indicates
               whether SMF logging is requested. If SMF logging is requested, and this exit is
               called, the user exit is responsible for SMF logging.

               The return code from the prior function is provided to this exit in register 3 at
               entry. It is the responsibility of DFSCTSE0 to keep and preserve this return code
               and to propagate the return code in register 15 upon return.

               For IMS V5 and below, when a transaction is executed in a remote MSC system,
               a security check for the user cannot be made because the user has not signed
               on to the remote system. As a result:
                •   When processing this call on a remote MSC system, IMS cannot verify the
                    user′s security profile. Instead it requests RACF to determine authorization
                    by using the user ID associated with the remote MSC system′s control region
                    instead of the user ID in the I/O PCB.
                •   Transaction Authorization exit DFSCTRN0 is not invoked unless all remote
                    transactions have been authorized to the user ID of the IMS remote control
                    region (which poses an unacceptable security risk many for MSC
                    installations). In that case, RACF responds with an ″authorized″ message
                    and exit DFSCTRN0 is called.
                •   If the above circumvention is not used, RACF on the remote system returns a
                    message of ″not authorized.″ The Transaction Authorization exit is not
                    called and the application receives an A4 status code for the CHNG call.

               The above scenario on the remote MSC system is no longer true with IMS V6
               where IMS will dynamically create the security environment for the user when
               the CHNG or AUTH Calls is issued.

               After completion of exit processing, the return code provided by the last exit
               entered is stored in the exit RC field of the I/O area.



10.4 Sign-On User Exit (DFSSGNX0)
               Sign-on user exit can be used for multiple purposes. But the main purpose of
               this exit is to accept or reject a sign-on for ETO terminals.

               You can include this installation exit routine in IMS.RESLIB when ETO is
               implemented. Other functions of DFSSGNX0 are:
                •   Multiple sessions, LTERM enablement
                •   Additions, removing extraneous keywords
                •   Telling IMS to override the TERMINAL macro′s MSGDEL parameter and
                    TRANRESP option for a specific user
                •   Locating the parameter list created by DFSLGNX0, creating user names
                    algorithmically from user IDs for each associated printer and passing the
                    printer parameters to IMS



                                                                  Chapter 10. IMS Security Exits   185
                          •   DFSSGNX0 exit routine can dynamically create node user descriptors and
                              create user structure names that are completely different from both the user
                              ID and the node name
                          •   Specify, or override, autologoff parameter and autosignoff (ASOT) values

                        DFSSGNX0 allows or disallows a sign-on attempt according to any criteria that
                        you specify, such as the maximum number of users or accepting and rejecting
                        some node names.

                        At the return time of this exit routine, if the content of R15 = 4, then the sign-on
                        will be rejected. R15=0 means to accept the sign-on.



10.5 Resource Access Exit Routine (DFSISIS0)
                        The Resource Access exit routine (DFSISIS0) authorizes starting a dependent
                        region. A region starts when a match occurs between a name entry in the
                        application group name table received by DFSISIS0 in register 1 and the name
                        assigned to the AGN keyword of the EXEC statement in member IMSBATCH or
                        IMSMSG of IMS.PROCLIB. When the IMS control program calls this exit routine,
                        register zero will have the address to SCD. The function of this routine is to
                        refuse authorization to all callers that have a mismatch of job name with AGN
                        name, by notifying the IMS control program that an invalid dependent region has
                        tried to start. The use of the exit routine is specified by coding the AGNEXIT
                        parameter for the TYPE keyword in the SECURITY macro.

                        If the AGNEXIT keyword has not been specified in the SECURITY macro for
                        system generation, then the default is NOAGN. You may chase the MVS control
                        block starting from CVT upward to find the job name you would like to authorize
                        or unauthorize.



10.6 Sign-On/Off Security Exit (DFSCSGN0)
                        Sign-On/Off Security exit routine is used to verify a user′s ID and password
                        during the sign-on process. User ID verification is a prerequisite for transaction
                        authorization checking. By specifying the TYPE keyword in the SECURITY
                        macro, you indicate, whether (SIGNEXIT) or not (NOSIGNEX) a user /SIGN ON
                        exit (DFSCSGN0) is to be called by IMS to validate a user ID. If both RACFTERM
                        and SIGNEXIT are specified, RACF is called first.

                        If TYPE=SIGNEXIT is specified in the SECURITY macro, SECLVL=SIGNON is
                        also required to enforce user ID verification. The default is NOSIGNEX.
                        However, SIGNEXIT is assumed and forced if TRANEXIT is specified and
                        NORACTRM is specified or accepted by default.

                        This exit routine can conflict with the Sign-On exit routine (DFSSGNX0).
                        Consequently, following a common logic or combining logic in both of these exit
                        routines is essential to avoid any conflict between them.

                        The two Security exit routines, DFSCSGN0 and DFSCTRN0, will usually share
                        security verification tables in the IMS nucleus (a separate table with the content
                        of user ID, password and other user data that gets included in the IMS nucleus
                        by linkage editor commands). Or the table may reside inside of one of the two
                        exit routines and be addressable by a V address constant (V-ADCON) in one exit
                        while in the other exit routine an external entry point for the table is indicated.


186   IMS V6 Security Guide
                 In a shared queues environment, when this exit is called from a dependent
                 region, it may be in a different IMS system on a different machine. Therefore, it
                 is recommended that the security verification table be the same in each IMS
                 system of the shared queues group. In an XRF environment, this user exit will
                 be invoked by the alternate system to check user ID security for both sign-on
                 and sign-off requests.



10.7 Build Security Environment Exit (DFSBSEX0)
                 The Build Security Environment exit routine provides users with a mechanism to
                 tell IMS whether to build the RACF or equivalent security environment in an IMS
                 dependent region for an application that has received its input message from
                 non-OTMA or non-LU 6.2 device. An example is an application program that
                 issues an APPC/MVS outbound allocate where input has not been received from
                 a LU 6.2 device.

                 The DFSBSEX0 exit is also used to control when IMS will perform the dynamic
                 creation of the security environment. This security exit routine has been
                 developed to keep IMS performance intact by avoiding repeated security
                 environment creation and consequent interruptions made by the numerous
                 transactions that will be generated by the back end. Consequently for AUTH and
                 CHNG calls, you may decide to avoid creation of the security environment in the
                 dependent region, based on some criteria. This can be done by using the
                 DFSBSEX0 exit routine.

                 For input from APPC or OTMA, if security is defined as FULL, the security
                 environment has already been created before any CHNG or AUTH call. If
                 APPC/OTMA security is defined as NONE, RACF is not called. If APPC/OTMA
                 security is defined as CHECK, and a CHNG or AUTH call is made, a dynamic
                 security environment has to be created.

                 A sample source program is included in Appendix A, “IMS Security Exits
                 Examples” on page 205 because it cannot be found from product distribution
                 source library.



10.8 Initialization Exit (DFSINTX0)
                 The Initialization exit routine provides enablement for password reverification of
                 a new password. Although this exit provides other services, from the security
                 point of view this is the only function in which we are interested.

                 When you use TSO and your password expires after a specified number of days,
                 you will be prompted with requesting a new password and verification of what
                 you enter as a password. This reverification guarantees the accuracy of
                 inputting a correct password and avoids a request for resetting the password to
                 the security administrator, in case the user enters a wrong password. This is
                 what IMS did not have, but it has been added in IMS V6 on the sign-on panel.

                 Now IMS supports reverification of the new password during sign-on to VTAM
                 terminals. The user exit DFSINTX0 has been enhanced and must be included
                 and coded to enable password reverification. The default is that password
                 reverification is disabled.




                                                                    Chapter 10. IMS Security Exits   187
10.8.1 Password Verification
                        Password verification can be achieved in two ways:
                          •   The VERIFY keyword on sign-on user data. This will be used to verify the
                              NEWPW keyword, which should also be present in the same user data. The
                              VERIFY keyword should follow the NEWPW key, similar to the following
                              format:
                                  ... NEWPW password VERIFY password ...

                              This will be supported for any process that invokes sign-on, including:
                              −   /SIGN command
                              −   DFS3649A screen
                              −   /OPNDST command
                              −   User data from remote logon
                          •   If the VERIFY keyword is absent in the sign-on user data, the end user will be
                              prompted to re-enter the new password specified by the NEPW keyword.
                              The new password verification message is DFS3656A, and the format is:
                                    DFS3656A IMS PASSWORD VERIFICATION
                                    PLEASE RE-ENTER NEW PASSWORD:

                        This will be supported for end-user-entered sign-on commands only: /SIGN
                        command and DFS3649A screen. New passwords entered by other processes
                        (/OPNDST command, user data from remote logon) will not be verified.

                        Verification is performed before any sign-on user exits (DFSSGNX0 and
                        DFSCSGN0) or RACF are invoked. Once verification is complete, sign-on
                        processing continues with the UVS input buffer as built from the original sign-on
                        command.

                        A new MFS message output format, DFSVERO, is used to format the DFS3656A
                        screen. Since this message has no variable output field, a NULL message is
                        built by IMS. This MODname and null message are presented to the greetings
                        message user exit, DFSGMSG0. Accordingly, this exit must be modified if
                        password verification is enabled to handle DFS3656A messages. If DFSGMSG0
                        is modified to build its own version of the DFS3656A message, it must specify a
                        user-defined MODname, since DFSVERO will always create the same formatted
                        screen.

                        DFSGMSG0 has also been enhanced to allow the exit to suppress password
                        verification. When driven for a DFS3656A message, if DFSGMSG0 indicates that
                        verification is to be bypassed, then IMS will immediately complete the sign-on
                        process rather than prompting the user for password verification.


10.8.2 Steps for Enabling Password Verification
                          1. A CTLBLKS gen is required, with M F S D F M T = Y to regen the MFS blocks (to
                             include the new DFSVERO output message format).
                          2. An IMS cold start is required.
                          3. To enable password reverification, user exit DFSINTX0 must be coded,
                             compiled and link edited into IMS.RESLIB.




188   IMS V6 Security Guide
4. If DFSGMSG0 is used, it must be examined to determine if modification is
   necessary. If a branch table is used based on the input message type, it
   must be modified to handle the new DFS3656A message. However, no
   particular processing of the DFS3656A message is required for password
   reverification.
5. If a new password is specified during user sign-on, a new DFS3656A
   message is sent to the terminal. The format of this message is:
                   DFS3656A IMS PASSWORD VERIFICATION

  The new password needs to be re-typed into the formatted non-displayed
  field on the second line of the message. Consequently, the password will
  not be displayed.
6. If the password is successfully changed, a new status appears on the
   DFS3650 screen:
                   *PWD-CHG*




                                                Chapter 10. IMS Security Exits   189
190   IMS V6 Security Guide
Chapter 11. IMS Version 6 Security Enhancements

                         IMS V6 contains several security enhancements. This chapter covers the
                         following new IMS security features:
                             •   Allocate program specification block (APSB) system authorization facility
                                 (SAF) security
                             •   Support for the RACF data space option
                             •   DFSDCxxx BMPUSID= Parameter Specification
                             •   Sysplex enhancements
                                 −   Securing IMS commands issued from MCS/E-MCS consoles
                                 −   Shared queues structure RACF FACILITY class support
                             •   Multiple RACF task control blocks (TCBs)
                             •   Enhanced REVERIFY security support
                             •   Enhanced AUTOSIGNOFF and AUTOLOGOFF options for ETO devices



11.1 APSB SAF Security
                         The DL/I allocate PSB (APSB) call is used to allocate a PSB for a Common
                         Programming Interface Communications (CPI-C) driven application program.
                         These types of application programs are used for conversations that include LU
                         6.2 devices.

                         Resource access security for CPI-C-driven application programs is controlled by
                         the following items:
                             •   The transaction class that is specified on the CLASS= keyword in the
                                 TP_Profile
                             •   The application group name (AGN) table that is assigned to the dependent
                                 regions that are capable of scheduling transactions from this particular class
                                 specification.

                         In CPI-Communications-driven application programs, AGN resource access
                         security can restrict the use of a PSB when the PSB has been secured in an
                         AGN group. If the PSB is an unauthorized resource, IMS rejects the DL/I
                         allocate PSB (APSB) call but does not abend the program. As you will recall
                         from previous chapters, when an IMS resource is part of an AGN group, only
                         authorized dependent regions can use the resources identified in the AGN.
                         Since CPI-C transactions cannot be defined (CPI-C transactions are dynamic
                         SMBs, and SMU provides support only for resources that have been statically
                         defined), the allocate PSB request is rejected by IMS if APSB security has not
                         been enabled. Thus, the CPI-C transaction cannot use a PSB (or other resource)
                         that has been secured using AGN security unless APSB security is active.

                         APSB SAF security addresses AGN resource access security pertaining to the
                         APSB application program call that can be issued from CPI-C-driven application
                         programs. This enhancement provides the ability to authorize a particular
                         CPI-C-driven application program access to PSBs regardless of what region the
                         program is running in or what the associated AGN table for that region specifies.




© Copyright IBM Corp. 1999                                                                                   191
                        APSB SAF security also provides the ability to secure PSBs by user ID for CPI-C
                        environments. System programmers now have the option of using MVS SAF,
                        which acts as a router to RACF (or to an installation-supplied processing
                        routine), to secure any PSB that is specified on an APSB call from a CPI-C-driven
                        application program.

                        In other words, APSB SAF security does two things:
                          •   Overrides AGN security for CPI-C-driven transaction programs, and
                          •   Uses RACF to determine if the user ID of the user that submitted the
                              transaction is authorized to the PSB requested in the APSB call
                        The user ID verification of the terminal user is a significant enhancement over
                        prior IMS versions. IMS V5 and below performed authorization checking on the
                        PSB name (the name of the application issuing the APSB call), rather than the
                        user′s user ID.


11.1.1 Enabling and Disabling APSB SAF Security
                        Once APSB SAF is security enabled, IMS calls SAF to secure the PSB specified
                        on an APSB call against the RACF AIMS or Axxxxxxx general resource class
                        (where xxxxxxx is the value specified on the RCLASS= parameter of the IMS
                        SECURITY macro). The RACF authorization check is based on the user ID of the
                        user that submitted the CPI-C transaction, rather than on the PSB name, as was
                        done in IMS V5 and below.

                        You can enable APSB SAF security using one of the following methods:
                          •   To enable APSB SAF security for all CPI-C applications, issue the IMS
                              command:
                                /SECURE APPC FULL
                              The /SECURE APPC FULL command clones the security environment to the
                              dependent region at execution time.
                          •   Code a value for APPCSE= in the IMS execution parameters, where the
                              value is F or P. If APPCSE=P is used, make sure that RACF=FULL is
                              specified in the TP scheduler section of the CPI-C application′s TP profile:
                                APPCSE=F

                                 or

                                APPCSE=P and RACF=FULL (in TP_Profile)
                          •   Specify RACF=FULL in the TP scheduler section of the CPI-C application′ s
                              TP profile, and issue the IMS command as:
                                RACF=FULL (TP scheduler section of TP_Profile)

                                /SECURE APPC PROFILE (Issued from Master Terminal or MVS console)
                              The command /SECURE APPC PROFILE enables APSB SAF security only for
                              the CPI-C applications that have RACF=FULL specified in the TP profile.
                              Implementing this method of APSB SAF security disables APSB SAF security
                              for all other CPI-C applications. Therefore, APSB SAF security is disabled for
                              CPI-C applications that do not have RACF=FULL in the TP scheduler section
                              of the TP profile.

                        You must also define the PSBs that you want protected by RACF (or your
                        installation exit) to the AIMS or Axxxxxxx RACF resource class. Since the AIMS

192   IMS V6 Security Guide
                resource class can contain both PSBs and AGNs, all PSB names and AGNs
                specified in the AIMS resource class should be unique. In addition, you must
                specify RCLASS=IMS (or xxxxxxx), and TYPE=RACFAGN,RACFTERM on the
                IMS SECURITY macro at IMS system generation time. The required definitions
                are illustrated below:


                 RACF definitions:

                  RDEFINE AIMS (psbname1,psbname2,,,,,psbnamen) OWNER(IMSADMIN) UACC(NONE)
                  PERMIT psbname1 CLASS(AIMS) ID(group-1,,,,group-n) ACCESS(READ)
                  PERMIT psbname2 CLASS(AIMS) ID(group-2,,,,group-n) ACCESS(READ)
                  PERMIT psbnamen CLASS(AIMS) ID(group-3,,,,group-n) ACCESS(READ)

                  SETROPTS CLASSACT(AIMS)



                 IMS definitions:

                  SECURITY TYPE=(RACFAGN,RACFTERM)
                           RCLASS=IMS

                Figure 36. RACF Definitions for APSB SAF Security

                The RACF definitions in Figure 36 assume a user ID exists for psbname1,
                psbname2, and so forth. When APSB SAF security is enabled, if the PSB is not
                defined to the AIMS resource class or the AIMS resource class is not active, the
                PSB is secured using AGN Table security if AGN resource access security is
                active. Therefore, APSB AGN table security is invoked only if APSB SAF is not
                enabled, or APSB SAF could not make a decision (for example, the PSB
                resource is not defined in RACF AIMS class).

                To disable APSB SAF security, issue the IMS command from the master terminal
                or MVS console:
                  /SECURE APPC CHECK

                 or

                  /SECURE APPC NONE.

                When APSB SAF security is disabled, IMS reverts to securing the PSB using
                AGN Table security if AGN resource access security is active.


11.1.2 Security Considerations for CPI-C-Driven Application Programs
                You can secure any PSB specified on an APSB call from a CPI-C-driven
                application program using the MVS System Authorization Facility (SAF). APSB
                SAF security overrides APSB AGN Table security. If you use RACF, you must use
                RACF 1.9.2 or later on your MVS system to gain the benefits of APSB SAF
                security.

                The following codes are returned from SAF to the application interface block
                (AIB) as a result of the APSB call.
                Return/Reason Code Description
                0000/0000              Authorization successful. PSB is allocated.


                                                   Chapter 11. IMS Version 6 Security Enhancements   193
                        0110/0050                A CPI-C-driven application issued an APSB call IMS
                                                 determined that the user ID is not authorized by RACF (or
                                                 equivalent) to use the PSB.
                        0108/0308                IMS encountered a PSB authorization failure while
                                                 attempting to allocate the PSB. Security checking the
                                                 application group name (AGN) table. Either the AGN table
                                                 did not existed the PSB name was not defined in the table.



11.2 Support for the RACF Data Space Option
                        Some resource managers, such as IMS, have high performance requirements.
                        In order to do resource authorization checking with RACF, they use RACF
                        facilities to load all of the profiles for a given class into the user′s storage area
                        (IMS control region storage area) or into a common storage area called a data
                        space (such as the RACF data space). IMS can do a ″fast″ authorization check
                        against profiles in the control region storage, or profiles in the data space, or
                        both.

                        When the RACF (or an equivalent product) data space is used, IMS can load the
                        RACF profiles for the IMS commands (CIMS/DIMS) and transactions (TIMS/GIMS)
                        into that data space instead of the IMS control region storage.

                        The RACROUTE REQUEST=LIST,GLOBAL=YES option creates in-storage
                        profiles in a data space rather than in private storage. It allows multiple address
                        spaces to share the same set of RACLISTed profiles. Each additional
                        subsystem/application that issues RACROUTE REQUEST=LIST,GLOBAL=YES
                        for the same class can access the data space already built. Profiles that are
                        globally RACLISTed for a class with RACROUTE REQUEST=LIST,GLOBAL=YES
                        can be refreshed simultaneously for all users by SETROPTS
                        RACLIST(classname) REFRESH. The refresh occurs without requiring IMS to
                        perform an online change, thereby eliminating the need to suspend work
                        momentarily for doing an IMS online change.

                        Once created, the RACF data space can be refreshed when appropriate by a
                        SETROPTS RACLIST(class_name) REFRESH command.


                              Create data space:
                                     RACROUTE REQUEST=LIST,GLOBAL=YES

                              Refresh a class in the data space:
                                     SETROPTS RACLIST(TIMS) REFRESH


                        You can also use SETROPTS NORACLIST to delete a data space created by a
                        RACROUTE REQUEST=LIST,GLOBAL=YES command. Therefore, the command
                        must operate on classes even though RACLIST=DISALLOWED is specified in the
                        RACF class descriptor table. If RACGLIST is active and RACGLIST
                        CLASS(classname) profiles exist, RACF deletes them and keeps the base
                        RACGLIST profile name.

                        The SETROPTS NORACLIST command should not be issued until all of the
                        applications that accessed the RACLIST data space by issuing a RACROUTE
                        REQUEST=LIST,ENVIR=CREATE,GLOBAL=YES have relinquished their access
                        by issuing RACROUTE REQUEST=LIST,ENVIR=DELETE requests.



194   IMS V6 Security Guide
11.2.1 RACF Data Space and IMS Online Change
                Use of the RACF data space invalidates the IMS online change support for RACF
                with the /MODIFY command. The IMS online change support is still valid, though,
                when the RACF data space is not being used.

                If the RACF data space is in use and the /MODIFY PREPARE RACF command is
                issued from IMS, the following error message will be issued:
                     DFS3432 RACF PARAMETER INVALID IF RACF DATA SPACE USED

                You can use the RACF command SETROPTS RACLIST (classname) REFRESH to
                refresh the RACF resource profiles in the RACF data space without requiring the
                IMS applications to suspend work.

                To refresh the security profiles in a RACF data space, simply:
                 •    Use the RACF menu panels (system options), or
                 •    From TSO/E issue the following RACF command:
                           SETROPTS RACLIST(classname) REFRESH

11.2.2 Considerations for Using the RACF Data Space
                IMS V6 is required for RACF data space support. IMS V6 may use the new data
                space feature, or IMS V6 can continue to use in-storage profiles. RACF 2.1 or
                later and MVS/ESA V 4.2.2 or later are also required for RACF data space
                support.

                When RACF is enabled for sysplex communication, it propagates RVARY and
                SETROPTS commands (except RVARY LIST and SETROPTS LIST) to the other
                members of the RACF data sharing group. Most SETROPTS options are
                propagated by updating the ICB, which is shared by all members of the RACF
                data sharing group. The following options are exceptions, and are propagated
                via XCF messaging services to the other members of the sysplex:
                 •    RACLIST
                 •    RACLIST REFRESH
                 •    NORACLIST
                 •    GENERIC REFRESH
                 •    GLOBAL
                 •    GLOBAL REFRESH
                 •    WHEN (PROGRAM)
                 •    WHEN (PROGRAM) REFRESH
                The RACF data sharing group member on which a propagated command is
                issued is referred to as the coordinator. This member coordinates the
                propagation of the command to the other members.

                Systems enabled for sysplex communication and running in non-data sharing
                mode can share a database with other RACF systems that are not enabled for
                sysplex communication. Systems that are not enabled for sysplex
                communication but that are sharing the database cannot exploit command
                propagation. In this mixed environment, the systems must not enter data sharing
                mode. We recommend that all systems enabled for sysplex communication and
                sharing the same RACF database be members of the same sysplex. Doing this


                                                    Chapter 11. IMS Version 6 Security Enhancements   195
                        prepares you for RACF sysplex data sharing, and ensures that commands are
                        propagated to all members of the sysplex.



11.3 BMPUSID Keyword Added to DFSDCxxx
                        Before covering the meaning of the BMPUSID keyword in the DFSDCxxx
                        procedure library member, it is helpful to understand the environment that led to
                        the creation of this keyword.

                        In IMS V5 and earlier versions, when a non-message driven BMP inserted a
                        message to an alternate PCB with a transaction as the destination, the PSB
                        name of the BMP was used (or placed) in the user ID field of the message prefix
                        (used to fill the user ID field of I/O PCB). The PSB name was used even though
                        the JCL used to start the BMP may have specified a user ID (by coding a value
                        for the USER= parameter). The user ID field in the message prefix is used for
                        transaction authorization when the message processing program that processes
                        the inserted transaction does one of the following:
                          •   Issues a DL/I CHNG call
                          •   Issues a DL/I AUTH call
                          •   A deferred conversational program-to-program switch
                        For a high level view of the concept, refer to Figure 37.




                        Figure 37. IMS Security Check Processing Flow

                        At step 4 in Figure 37, IMS security checking modules are called. The PSB
                        name of the BMP is used on the call to RACF to determine if the PSB name is
                        authorized to the IMS resource requested on the CHNG, AUTH, or deferred


196   IMS V6 Security Guide
               conversational program-to-program switch. If the resource requested is a
               protected/secured resource, and if the PSB name (of the BMP) is undefined to
               RACF as a user ID, the security check fails. IMS then makes a second
               authorization call to RACF using the default security environment. That is, IMS
               calls RACF using the user ID of the IMS control region (or the user ID of the
               message processing region). If the user ID of the control region (or message
               processing region) has been authorized to the resource, IMS allows the CHNG,
               AUTH, or deferred conversational program-to-program switch. If the user ID of
               the control region (or message processing region) has not been PERMITTED to
               the resource, a security violation occurs and IMS does not allow the CHNG,
               AUTH, or deferred conversational program-to-program switch.

               As you may have noted, this is a problem. If the user ID of either the control
               region/message processing region has been permitted to a protected resource,
               then authorization to the resource is always granted in this situation for
               undefined users (the PSB name of the BMP). Access to a secured/protected IMS
               resource by an undefined/unknown user ID (the PSB name of the BMP) has been
               allowed (using the user ID of the control/message region) without generating a
               security notification that this has occurred. This can only happen when the
               installation has authorized (using RACF PERMIT) the user ID of the
               control/message region to the protected transaction.

               On the other hand, if the user ID of the control region/message processing
               region has not been authorized to a protected resource, an authorization failure
               occurs for all undefined users (users that do not have a RACF user ID on the IMS
               subsystem where the security check was made).


11.3.1 IMS V6 BMPUSID Specification
               Some IMS installations required that in the above situation, the security check be
               performed using the user ID specified in the BMP′s USER= JCL parameter.
               Other installations required that the PSB name (of the BMP) continue to be used
               for security checking. To satisfy both requirements, IMS added the BMPUSID
               specification to the DFSDCxxx PROCLIB member. This new specification
               provides installations with a choice. Installations can now decide whether the
               PSB name or the USER= specification will be placed in the message prefix.

               The authorization processing in IMS V6 actually works the same as for prior
               versions of IMS. That is, if the user ID (whether PSB name or USER=user ID) is
               not authorized, the default security check using the user ID of the IMS control
               region/message processing region is still performed.

               The BMPUSID= keyword has been added to DFSDCxxx. The use of this
               keyword is connected with RACF security. For batch-oriented BMPs, the
               authorization user ID is dependent on the value specified for the BMPUSID=
               keyword in the DFSDCxxx IMS.PROCLIB member.

               The value for BMPUSID= specifies the system option for the value to be placed
               in the user ID field of the message prefix for a message generated by a
               non-message driven BMP. The valid values for the parameter are PSBNAME and
               USERID. Table 32 on page 198 provides the meaning of the value used.




                                                 Chapter 11. IMS Version 6 Security Enhancements   197
                          Table 32. BMPUSID=PSBNAME|USERID
                          Condition                Condition               Action
                          BMPUSID=USERID                                   The value from the USER=
                          is specified                                     keyword on the JOB statement is
                                                                           used.
                                                   USER= is not            The program′s PSB name is used.
                                                   specified on the JOB
                                                   statement
                                                   USER= has been          The program′s PSB name is used.
                                                   specified on the JOB
                                                   statement, but
                                                   BMPUSID= has not
                                                   been specified in the
                                                   DFSDCxxx member
                          BMPUSID=PSBNAME                                  The program′s PSB name is used.
                          is specified
                          BMPUSID= is not                                  The program′s PSB name is used.
                          specified at all
                          Note:   BMPUSID=PSBNAME is the default.


                        The DFSDCxxx PROCLIB member applies to the DB/DC and DCCTL
                        environments. The DC= parameter in the IMS or DCC startup procedure (or
                        DFSPBxxx) defines the DFSDCxxx IMS.PROCLIB member that is used. T h e D C =
                        parameter specifies the three-digit suffix for the DFSDCxxx member. The default
                        for xxx in the member name DFSDCxxx is 000. An example of the DFSDCxxx
                        PROCLIB member, DFSDC000, can be found in the IMS.DFSSLIBA library.


11.3.2 Considerations for BMPUSID
                        Installations migrating from prior versions of IMS (such as IMS V5 and earlier)
                        may have the USER= parameter coded in existing JCL that is used to start
                        non-message-driven BMPs. If BMPUSID=USERID and USER= user ID on the
                        JCL have been specified for a non-message driven BMP, when the installation
                        migrates to IMS V6 the USER= user ID specification will be used. Since IMS V5
                        and below used the PSB name as the user ID, the installation may not have a
                        RACF user ID defined for the USER= specification supplied in the JCL. If
                        USER= is coded on the JCL used to start a non-message-driven BMP, and the
                        value coded for USER= is not a defined RACF user ID, several things will
                        happen for the situation described earlier (MPP issues CHNG, AUTH, or deferred
                        conversational program-to-program switch when processing the message
                        inserted by the NMD BMP):
                          •   An attempt to create a security environment (ACEE) with the user ID from the
                              USER= (parameter on the JCL) will fail if not defined to RACF.
                          •   Then, the authorization check will be performed using the default user ID of
                              the IMS control or dependent region.
                              −   If either region′s user ID is authorized to the protected resource, access
                                  is allowed, just as in IMS V5 and earlier.
                                  Several things may be done to eliminate producing the SMF violations:
                                   - Code the USER= user ID on the JCL used to start
                                     non-message-driven BMPs, and specify BMPUSID=USERID in
                                     DFSDCxxx. Then create a RACF user ( user ID ) for the BMP.



198   IMS V6 Security Guide
                           Authorize the BMP to protected resources, for example, to a
                           protected transaction in the TIMS class.
                         - Create a RACF user ID for the PSB name. Authorize the PSB name
                           to the secured resource, such as a transaction protected by a TIMS
                           profile.
                •   If neither user ID (of the control region or message processing region) is
                    authorized to the protected resource, access to the resource is denied, just
                    as was done in IMS V5 and below.

               If you change the DFSDCxxx member, you must perform a cold start of IMS.



11.4 Sysplex Security Enhancements
               Two security enhancements have made to facilitate using IMS in a sysplex
               environment:
                •   The ability to secure IMS commands issued from MCS/E-MCS consoles
                •   The ability to secure connections to shared queues structures


11.4.1 Securing MCS/E-MCS Entered IMS Commands
               For enhanced systems management, you can now enter IMS commands from a
               multiple console support (MCS) or an extended multiple console support (EMCS)
               terminal to all the IMS systems on each MVS in a sysplex environment. This is
               done by preceding the IMS command with an MVS ROUTE *
               ALL,command-to-subsystem command.




               Figure 38. IMS E-MCS/MCS Support in a Sysplex Environment



                                                  Chapter 11. IMS Version 6 Security Enhancements   199
                        This support is enabled via the CMDMCS execution parameter. You can also
                        route commands to a specific IMS, all IMS systems on a specific MVS, or a set of
                        either one. This support is very flexible.

                        In order to enable command authorization for the MCS or EMCS terminal, you
                        must apply APAR OW15497 to MVS SP 5.1 or to subsequent operating systems.
                        This does not apply to the OS/390 operating system.

                        Either RACF and/or DFSCCMD0 can be used to secure IMS commands issued
                        from MCS/E-MCS consoles. RACF can be used to secure commands entered
                        from MCS/E-MCS consoles at the command level. RACF CIMS/DIMS classes
                        command security profiles are updated (PERMITTED) with the user IDs of the
                        MCS/E-MCS consoles authorized to issue IMS commands. The user ID of an
                        MCS/E-MCS console is the console ID (See your JES administrator for the
                        console IDs.).

                        DFSCCMD0 can be used with commands entered from MCS/E-MCS consoles to
                        secure commands at the command verb, keyword, and resource levels. The
                        routine is called for commands from MCS/E-MCS consoles when the CMDMCS
                        parameter is specified as B or C in the IMS, DBC, or DCC procedure or the
                        DFSPBxxx member of IMS.PROCLIB.

                        The installation determines whether IMS commands can be issued from
                        MCS/E-MCS consoles, and if so, whether RACF and/or DFSCCMD0 will be used
                        for authorization checking. The specification for the CMDMCS execution
                        parameter designates how to handle commands entered from MCS/E-MCS
                        consoles. The default is CMDMCS=N (IMS commands are not allowed from
                        MCS/E-MCS consoles). The following are the settings for CMDMCS:
                              CMDMCS MCS/E-MCS COMMAND SECURITY OPTION

                              N=Commands not allowed from MCS/E-MCS consoles (Default)
                              Y=All commands allowed from MCS/E-MCS consoles with Command Recognition Character
                              R=Call RACF for MCS/E-MCS command authorization
                              C=Call DFSCCMD0 for MCS/E-MCS command authorization
                              B=Call RACF first, then call DFSCCMD0 for command authorization

11.4.2 Authorizing Connections to Common Queue Structures (CQS)
                        If RACF or another security product is installed, the security administrator can
                        define profiles that control the ability of clients to connect to CQS shared queue
                        structures. When a client (IMS subsystem participating in a shared queues
                        group) issues the CQSCONN request to connect to a CQS queue structure, CQS
                        issues a call to RACF:
                              RACROUTE REQUEST=AUTH

                        The call to RACF determines whether the client (IMS subsystem) is authorized to
                        access the structure.

                        RACF checks the user ID of the client that issued the CQSCONN request. This
                        user ID must have at least UPDATE authority to connect to the structure through
                        CQS.

                        The RACF security administrator should define profiles in the FACILITY class to
                        control the connection to CQS structures. The profile names must be of the form
                        CQSSTR.structure_name, where structure_name is the name that you define in
                        the CQSSGxxx and CQSSLxxx PROCLIB members.


200   IMS V6 Security Guide
               The CQSSTR.structure_name profiles only control access to the specified
               structures through CQS. They do not control direct access to the structure using
               IXL macros.

               For more information on controlling access to coupling facility structures, refer to
               OS/390 MVS/ESA Programming: Sysplex Service Guide , GC28-1771.

               To define a profile for a CQS primary structure named IMSMSGQ01, and to allow
               only user CQSUSER to connect to it, issue the following RACF commands:


                RDEFINE FACILITY CQSSTR.IMSMSGQ01 UACC(NONE)
                PERMIT CQSSTR.IMSMSGQ01 CLASS(FACILITY) ID(CQSUSER) ACCESS(UPDATE)

                SETROPTS CLASSACT(FACILITY)


               CQSUSER could be a RACF group that has the user IDs of IMS subsystems in
               the shared queues group connected to it. If you do not define a security profile
               in the FACILITY class for a particular CQS structure, the structure is not
               protected, and any user ID can issue a CQSCONN request to access the
               structure.



11.5 Multiple RACF Task Control Blocks (TCBs)
               This enhancement provides a mechanism for you to achieve parallelism during
               /SIGN ON and /SIGN OFF commands, when RACF is used for sign-on verification.
               To accomplish this, IMS added a new TCB type (RCF) to process these two RACF
               calls. To attain parallelism, you must run with more than one RCF TCB and split
               the RACF data sets. If more than one RACF TCB is required, this is specified by
               the JCL (procedure used to start IMS or DFSPBxxx) execution startup parameter
               RCFTCB=xxx, where xxx can be from 1 to 20. The default value for RCFTCB is
               one.



11.6 Enhanced REVERIFY Support
               The RVFY= parameter has been added to the IMS procedure for customers who
               wish to force reverification that the operator who signed on to given terminal is
               the same one who is entering an IMS command or transaction.

               RACF reverify support has been provided in IMS for many years. Prior to IMS
               V6, each time a transaction code or command was entered, RACF performed
               reverify to determine if a password was required with transaction and/or
               command entry. For installations that did not use the reverify function, the
               additional processing done by RACF was not desired.

               Therefore, the enhancement provided in IMS V6 is the addition of an execution
               time parameter that will allow the installation to specify whether or not the
               reverify function will be active. For those installations that do utilize reverify,
               IMS will now check whether reverify is in place for each transaction and/or
               command entered.




                                                   Chapter 11. IMS Version 6 Security Enhancements   201
                              Note
                          Installations that do not use reverify can eliminate the processing overhead
                          by specifying RVFY=N in the execution parameters.


                        The default for RVFY= is N, for no. Installations that have currently specified
                        REVERIFY in the APPLDATA section of command and transaction profiles (in the
                        CIMS/DIMS and/or TIMS/GIMS RACF classes) must code RVFY=Y (for yes) in
                        the IMS startup/execution parameters. If both the RACF REVERIFY option and
                        SMU password security have been used for the same command and/or
                        transaction, the RACF user password and the SMU password must be identical.

                        The REVERIFY operand of RACF RDEFINE command is nullified during XRF
                        takeover. Users must sign on again after an XRF takeover to identify the
                        password to the new active IMS.



11.7 Enhanced AUTOSIGNOFF/AUTOLOGOFF for ETO Devices
                        Terminal users can compromise security by leaving their terminals unattended
                        while still signed on and/or logged on to IMS. IMS provides execution
                        parameters for automatically signing off and automatically logging off terminals
                        with no activity. The ASOT (automatic sign-off) and ALOT (automatic logoff)
                        parameters are used to control automatically signing off and logging off inactive
                        terminals and sessions.

                        In IMS V5 and below, the value that could be specified for ASOT was a number
                        in the range of 10 minutes to 1440 minutes. The value that could be specified for
                        ALOT was also a number in the range of 10 minutes to 1440 minutes.

                        The IMS V6 enhancement is that valid values for both ASOT and ALOT can be 0
                        or a number in the range of 10 to 1440.


11.7.1 ASOT
                        The values for the allotted time specified on the ASOT parameter in the
                         DFSPBxxx member are:
                        ASOT = 0 (IMS V6 enhancement)
                             The user is signed off immediately when no output is available to be sent.
                             This specification is normally used with autologon terminals for sign-off
                             immediately when:
                                •    No IMS input or output message is available
                                •    After the last available output message completes
                               This specification is not recommended for interactive terminals such as
                               3270′s or SLU2. These terminals sessions normally return a PA key to
                               continue following sign-on. Idle time results in immediate sign-off, not
                               waiting for terminal input. The value on the DFSPByyy member is not
                               used for these device types.
                        ASOT = (10 - 1439)
                             The user is signed off after the allotted number of minutes has elapsed
                             without terminal activity.




202   IMS V6 Security Guide
               ASOT = 1440
                    The user is never automatically signed off. This is equivalent to not having
                    automatic sign-off. The system default value for SLU-P, 3600/Finance, and
                    ISC terminals is 1440.


11.7.2 ALOT
               The values for the allotted time specified on the ALOT parameter in the
               DFSPBxxx member are:
               ALOT = 0 (IMS V6 enhancement)
                    The terminal is logged off immediately when no sign-on is in effect. This
                    specification is normally used in terminal sessions when the user is
                    signed on automatically during the logon process, for example:
                           Autologon
                           Sign-on data supplied by logon user data (BIND)
                           Sign-on data supplied by logon exit (DFSLGNX0)
                        This specification should not be used for interactive terminals sessions
                        that require a response to the DFS3649 (sign-on required) salutation
                        message. These sessions will result in immediate logoff, not waiting for
                        input sign-on.
               ALOT = (10 - 1439)
                    The session is terminated after the allotted number of minutes has
                    elapsed without a signed-on user.
               ALOT = 1440
                    The session is never automatically terminated. This is equivalent to not
                    having autologoff.



11.8 Summary
               The new security features in IMS V6 are:
                •   APSB security
                    This facility provides user ID authorization when the APSB call is issued from
                    a CPI-C-driven transaction program, and APSB SAF security can be used to
                    override AGN security for CPI-C environments.
                •   Support for the RACF data space option
                    Use of the RACF data space can provide performance enhancements to
                    sharing subsystems and eliminate the need for online security changes in
                    IMS.
                •   BMPUSID specification added to the DFSDCxxx member of IMS.PROCLIB
                    Allows the USER= user ID specification (from the JCL used to start a
                    non-message driven BMP) to be placed in the user ID field in the message
                    prefix for messages inserted to an alternate PCB where a transaction is the
                    destination.
                •   Two new security features for IMS systems that participate in sysplex
                    environments:
                    −    Securing IMS commands issued from MCS/E-MCS consoles
                         Each IMS subsystem needs a master terminal. Some installations have
                         a large number of IMS subsystems. For parallel sysplex environments,



                                                   Chapter 11. IMS Version 6 Security Enhancements   203
                                  the ability to control a large number of IMS subsystems from a single
                                  MVS console allows for easier operations and lower costs.
                                  However, since MCS/E-MCS console support extends the ability to issue
                                  IMS commands from many SDSF terminals, command entry must be
                                  regulated/secured. A new IMS parameter, CMDMCS, provides the ability
                                  to secure IMS commands entered from MCS/E-MCS consoles.
                              −   Ability to secure connections to CQS structures using the RACF FACILITY
                                  class.
                                  This is a new security feature for IMS systems participating in a shared
                                  queues environment.
                          •   Multiple RACF task control blocks (TCBs)
                              Prior to IMS V6, IMS used one RACF TCB for sign-on/sign-off processing
                              requests. This was particularly noticeable after an outage because everyone
                              attempted to sign on at once when the system became available, creating a
                              sign-on bottleneck. The bottleneck can be now relieved by using up to 20
                              RACF TCBs for sign-on/sign-off processing. Of course, for maximum
                              parallelism, the RACF data set needs to be split to take advantage of the
                              increased number of TCBs (so that the bottleneck is not moved to RACF).
                          •   Enhanced REVERIFY security support
                              Installations that do not require RACF REVERIFY security checking can turn
                              off reverify processing.
                          •   Enhanced AUTOSIGNOFF and AUTOLOGOFF options for ETO devices
                              ETO devices can specify ASOT and ALOT a value of 0, thereby further
                              minimizing security exposures due to unattended signed-on/logged-on
                              terminals.




204   IMS V6 Security Guide
Appendix A. IMS Security Exits Examples

                         The following exit program source listing cannot be found in IMS source
                         libraries. All other programs can be found in IMS source distribution libraries
                         shipped with the IMS product (see Table 33 for a summary).

                             Table 33. IMS Security Exits Source Library
                             Program       Source Library
                             DFSCCMD0      IMS610.SVSOURCE
                             DFSCSGN0      IMS610.TMSOURCE
                             DFSCTRN0      IMS610.TMSOURCE
                             DFSINTX0      IMS610.TMSOURCE
                             DFSISIS0      IMS610.TMSOURCE
                             DFSSGNX0      IMS610.TMSOURCE




A.1 Build Security Environment Exit (DFSBSEX0)
                         The Build Security Environment exit routine provides users with a mechanism to
                         tell IMS whether to build the RACF or equivalent security environment in an
                         IMS-dependent region for an application that has received its input message
                         from non-OTMA or LU 6.2 device. The following is a sample listing.



                         BSEX     TITLE ′ DFSBSEX0 USER EXIT EXAMPLE′                               00002000
                         ***********************************************************************    00003000
                         *                                                                     *    00004000
                         *                                                                     *    00006000
                         *                                                                     *    00008000
                         *                                                                     *    00008200
                         *                                                                     *    00008800
                         **************************************************************@ECPYRT**    00009800
                         *                                                                     *    00010000
                         * STATUS: IMS                                                         *    00011000
                         *                                                                     *    00012000
                         * NOTES:                                                              *    00013000
                         *                                                                     *    00014000
                         *    DEPENDENCIES: NONE                                               *    00015000
                         *                                                                     *    00016000
                         *    RESTRICTIONS: NONE                                               *    00017000
                         *                                                                     *    00018000
                         * MODULE TYPE:                                                        *    00021000
                         *                                                                     *    00022000
                         *    PROCESSOR: ASSEMBLER                                             *    00023000
                         *                                                                     *    00024000
                         *    ATTRIBUTES: REENTRANT                                            *    00025000
                         *    RUNS IN NON CROSS MEMORY MODEUNDER DEPENDENT REGION TCB, KEY7    *
                         *                                                                     *    00026000
                         * ENTRY POINT: DFSBSEX0                                               *    00027000
                         *                                                                     *    00028000
                         *    PURPOSE: SEE FUNCTION                                            *    00029000
                         *                                                                     *    00030000
                         *    LINKAGE: BALR 14,15                                              *    00031000

© Copyright IBM Corp. 1999                                                                             205
                        *                                                                       *   00032000
                        *    LINK CNTL CARDS:                                                   *   00032000
                        *                          INCLUDE LOAD(DFSBSEX0)*                          00032000
                        *                          INCLUDE LOAD(DFSCSI00)                       *   00032000
                        *                          ENTRY DFSBSEX0                               *   00032000
                        *                          NAME      DFSBSEX0(R)                        *   00032000
                        ***************************************************************@BMU0001     00052300
                        *      PROCESSOR: HLASM (HIGH LEVEL ASSEMBLER RELEASE 1)                *
                        *                                                                       *
                        *      ATTRIBUTES: REENTRANT, AMODE 31, RMODE ANY, KEY 7                *
                        *                                                                       *
                        *    ENTRY POINT: DFSBSEX0                                              *
                        *                                                                       *
                        *    INPUT REGISTERS:                                                   *
                        *                                                                       *
                        *      R1 - ADDRESS OF IMS STANDARD USER EXIT PARAMETER LIST            *
                        *      R13 - ADDRESS OF STANDARD MVS SAVEAREA                           *
                        *      R14 - RETURN ADDRESS TO IMS                                      *
                        *      R15 - ADDRESS OF DFSBSEX0                                        *
                        *      ALL OTHER REGISTERS ARE UNDEFINED                                *
                        *                                                                       *
                        *      STANDARD USER EXIT PARAMETER LIST FORMAT AS MAPPED BY            *
                        *      THE MACRO DFSSXPL:                                               *
                        *                                                                       *
                        *        SXPLVER (OFFSET X′00′) - ADDRESS OF A FULLWORD CONTAINING *
                        *                                    THE PARAMETER LIST VERSION NUMBER *
                        *                                                                       *
                        *        SXPLATOK (OFFSET X′04′) - 0 OR THE ADDRESS OF A FULLWORD       *
                        *                                    CONTAINING THE CALLABLE SERVICES *
                        *                                    TOKEN FOR THIS INSTANCE OF THE     *
                        *                                    USER EXIT                          *
                        *                                                                       *
                        *        SXPLAWRK (OFFSET X′08′) - ADDRESS OF A 512-BYTE WORK AREA      *
                        *                                                                       *
                        *        SXPLFSPL (OFFSET X′ 0C′ ) - ADDRESS OF THE BSE INTERFACE BLOCK *
                        *                                                                       *
                        *        SXPLINTX (OFFSET X′10′) - X′80000000′ OR THE ADDRESS OF        *
                        *                                    YOUR INSTALLATION′ S USER TABLE(S) *
                        *                                    BUILT BY DFSINTX0                  *
                        *                                                                       *
                        *    OUTPUT REGISTERS:                                                  *
                        *                                                                       *
                        *      R15 - RETURN CODE:                                               *
                        *                                                                       *
                        * 00                                                                    *
                        *           IMS IS NOT TO BUILD THE SECURITY ENVIRONMENT DURING         *
                        *             THE SCHEDULING PHASE OF THE TRANSACTION. THE SECURITY *
                        *             ENVIRONMENT CAN BE BUILT LATER IF NEEDED FOR              *
                        *             PROCESSING A CHNG CALL, AUTH CALL, OR A DEFERRED          *
                        *             CONVERSATIONAL PROGRAM SWITCH.                            *
                        *                                                                       *
                        *                                                                       *
                        *        04                                                             *
                        *           IMS IS TO BUILD THE SECURITY ENVIRONMENT DURING THE         *
                        *             SCHEDULING PHASE OF THE TRANSACTION. IF THE SECURITY      *
                        *             ENVIRONMENT IS NEEDED LATER BY A CHNG CALL, AUTH CALL, *
                        *             OR A DEFERRED CONVERSATIONAL PROGRAM SWITCH, THIS SAME *
                        *             SECURITY ENVIRONMENT IS USED. IF THE APPLICATION          *
                        *             PROGRAM DOES NOT EVER NEED THE SECURITY ENVIRONMENT,      *


206   IMS V6 Security Guide
*            THE BUILD OF THE SECURITY ENVIRONMENT IS UNNECESSARY.   *
* 08                                                                 *
*           INVOKE THE SAF INTERFACE (RACF, OR EQUIVALENT PRODUCT)   *
*             ON A CHNG CALL, AN AUTH CALL, AND A DEFERRED           *
*             CONVERSATIONAL PROGRAM SWITCH, BUT BYPASS THE DYNAMIC *
*             CREATION OF THE SECURITY ENVIRONMENT. IF THE           *
*             TRANSACTION IS RUNNING IN THE LOCAL SYSTEM, AND THE    *
*             USER WHO ENTERED THE TRANSACTION IS STILL SIGNED ON,   *
*             THE SECURITY ENVIRONMENT CREATED BY SIGNON IS USED.    *
*             OTHERWISE, THE DEFAULT SECURITY ENVIRONMENT OF THE IMS *
*             CONTROL REGION OR THE IMS DEPENDENT REGION IS USED FOR *
*             THE SAF CALL. THE PROCESSING FOR THIS RETURN CALL IS   *
*             RUNNING IN CROSS MEMORY MODE. IT IS NOT A BMP OR IS    *
*             NOT RUNNING WITH LSO=Y. THE PROCESSING USES THE        *
*             SECURITY ENVIRONMENT OF THE DEPENDENT REGION. IN IMS   *
*             5.1, THE SECURITY ENVIRONMENT OF THE CONTROL REGION    *
*             WAS ALWAYS USED AS THE DEFAULT.                        *
*                                                                    *
* 12                                                                 *
*           BYPASS INVOKING THE SAF INTERFACE ON A CHNG CALL, AN     *
*             AUTH CALL, AND A DEFERRED CONVERSATIONAL PROGRAM       *
*             SWITCH.                                                *
*                                                                    *
*                                                                    *
*        16                                                          *
*           BYPASS INVOKING THE SAF INTERFACE ON A CHNG CALL, AN     *
*             AUTH CALL, AND A DEFERRED CONVERSATIONAL PROGRAM       *
*             SWITCH, AND BYPASS THE CALLS TO THE DFSCTRN0 AND       *
*             DFSCTSE0 USER EXITS.                                   *
*                                                                    *
*                                                                    *
*                                                                    *
*                                                                    *
         EJECT                                                               00052400
***************************************************************              00052500
* INTERFACE:                                                         *       00052800
*                                                                    *       00053000
*       CONTENTS OF REGISTERS AT ENTRY:                              *       00054000
*              R1     = ADDRESS OF STANDARD IMS USER EXIT PARMLIST   *       00055000
*                                                                    *       00056000
*                     STANDARD PARMLIST                              *       00056900
*                      ---------                                     *       00057000
*                     |         |                                    *       00058000
*                     |---------|                                    *       00059000
*                     |         |                                    *       00060000
*                     |---------|                                    *       00061000
*                     |         |       BSE PARMLIST                 *       00061800
*                 +0C |---------| +0 |--------------------------|    *       00062000
*                     |SXPLFSPL |---->|4 BTE TRN SCHED CLASS      |  *       00063000
*                      ---------       |--------------------------|  *       00064000
*                              +X′04′ |8 BTE TRNCODE OF INPUT TRN|   *       00065000
*                                      |--------------------------|  *       00065900
*                              +X′ 0C′ |8 BTE PSBNAME             |  *       00066000
*                                      |--------------------------|  *       00067000
*                              +X′14′ |8 BTE PGMNAME              |  *       00067070
*                                      |--------------------------|  *       00067100
*                              +X′ 1C′ |8 BTE USERID/LTERM/BLANKS |  *       00067200
*                                      |--------------------------|  *       00067300
*                              +X′24′ |8 BTE GROUP NAME           |  *       00067380


                                       Appendix A. IMS Security Exits Examples   207
                        *                                         |--------------------------|    *   00067400
                        *                                 +X′32′ |32 BTE APPLIC PARM         |    *   00067500
                        *                                         |--------------------------|    *   00067600
                        *                                 +X′ 4C′ |64 BTE OF INPUT MSG/ZERO |     *   00067680
                        *                                         |--------------------------|    *   00067700
                        *                                                                         *   00068000
                        *                 R13    = SAVE AREA ADDRESS                              *   00069000
                        *                 R14    = RETURN ADDRESS                                 *   00070000
                        *                 R15    = ENTRY POINT ADDRESS                            *   00070900
                        *                                                                         *   00071000
                        *                                                                         *   00072000
                        ***************************************************************@BMU0001       00072300
                                    EJECT                                                  @BMU0001   00072400
                        ***************************************************************@BMU0001       00072500
                        *          CONTENTS OF BUILD SECURITY ENVIRONMENT EXIT PARMLIST:          *   00073000
                        *                                                                         *   00074000
                        * X′ 0 0 ′    SXPLVER     ADDRESS OF A FULLWORD CONTAINING THE PARAMETE       00075100
                        *                         LIST VERSION NUMBER.                                00075200
                        * X′04′       SXPLATOK    0 OR THE ADDRESS OF A FULLWORD CONTAINING THE       00075500
                        *                         CALLABLE SERVICES TOKEN FOR THIS INSTANCE OF        00075600
                        *                         THE ROUTINE.                                        00075800
                        * X′08′       SXPLAWRK    ADDRESS OF A 256-BYTE WORK AREA.                    00077000
                        * X′ 0C′      SXPLFSPL    ADDRESS OF THE BSE PARAMETER LIST.                  00077550
                        * X′10′       SXPLINTX    ADDRESS OF THE USER DATA TABLE LOADED BY            00077600
                        *                         DSINTX0 AT IMS INITIALIZATION TIME. THIS FIELD      00077630
                        *                         IS VALID ONLY IN IMS ENVIRONMENTS WHERE             00077650
                        *                         DFSINTX0 IS CALLED. IT WILL BE X′80000000′ IN       00077680
                        *                         ANY OTHER ENVIRONMENT.                              00077700
                        *                                                                             00077730
                        * EXTERNAL REFERENCES:                                                    *   00095000
                        *                                                                         *   00096000
                        *      ROUTINES:                                                          *   00097000
                        *                                                                         *   00098000
                        *           NON                                                           *   00099000
                        *                                                                         *   00100000
                        *      DATA AR AS:                                                        *   00101000
                        *                                                                         *   00102000
                        *           NON                                                           *   00103000
                        *                                                                         *   00104000
                        *      MVS MACROS: RETURN                                                 *   00105000
                        *                                                                         *   00106000
                        *      IMS MACROS: , DFSSXPL, REQUATE                                         00107000
                        *                                                                         *   00108000
                        *                                                                         *   00109000
                        * MESSAGES: NONE                                                          *   00110000
                        *                                                                         *   00111000
                        * ABENDS : NONE                                                           *   00112000
                        *                                                                         *   00113000
                        * CHANGE ACTIVITY: USER RESPONSIBILITY                                    *   00114000
                        *                                                                         *   00115000
                        *                                                                         *   00116000
                        ***********************************************************************       00117000
                                    EJECT                                                             00118000
                        ***********************************************************************       00119000
                        ***********************************************************************       00141000
                        *-SAVE REGISTERS AND ESTABLISH ADDRESSABILITY CONVENTIONS                     00142000
                        ***********************************************************************       00143000
                        *                                                                             00144000
                        DFSBSEX0 CSECT                                                                00144600


208   IMS V6 Security Guide
        SAVE    (14,12),,DFSBSEX0&SYSDATE&SYSTIME                       00144700
        L       R13,8(,R13)         GET NEXT SAVE LEVEL                 00144800
        LR      R12,R15             BASE REGISTER                       00144900
        USING   DFSBSEX0,R12                                            00145000
*                                                                       00145200
*********************************************************************** 00145300
* SET UP REGISTERS FOR USER EXIT                                        00145500
*********************************************************************** 00145600
         LR    R3,R1               GET A(STANDARD USER EXIT PARM LIST)
         USING SXPL,R3             MAP PARM LIST
         L     R4,SXPLFSPL         GET A(INTERFACE BLOCK)               00145000
         USING BSE,R4              MAP BSE INTERFACE BLOCK
         L     R6,SXPLINTX         GET A(DFSINTX0 TABLE)                00145000
         USING AUTHTAB,R6          MAP INTX TABLE
         SPACE 1
*                                                                       00148050
*********************************************************************** 00148100
* ASSUMPTIONS:                                                        * 00148150
* DFSINTX0 HAS LOADED A TABLE OF AUTHORIZED USERIDS & PSBNAME & PGMNAM*
* ALSO THE LAST ENTRY OF INT TABLE HAS C′ XXXXXXXX′ AS EOF IDENTIFIER
*********************************************************************** 00148200
*                                                                       00148260
         CLC BSEUID,=C′ HOTUSERS′    IS IT A KNOWN AUTHORIZED USER?
         BNE CHKHOT2
         LA    R15,16                BYPASS ALL SECURITY CHECKS
         B     DONE
CHKHOT2 EQU *
         CLC BSEUID,=C′ LESSHOTS′ IS IT A KNOWN AUTHORIZED USER?
         BNE CHKENTRY
         LA    R15,12                BYPASS SECURITY ONLY ON
         B     DONE                  CHNG/AUTH CALLS & PGM TO PGM SW
CHKENTRY EQU *
         CLC BSEPSB,PSBNAM           IS PSB NAME MATCH??
         BNE TABNXT                  BUMP THE INTX ENTRY
         CLC BSEPGM,PGMNAM           IS PGM NAME MATCH??
         BNE TABNXT                  BUMP THE INTX TAB
         CLC BSEUID,USERID           IS USER ID MATCH??
         BE    RTRN0
TABNXT EQU *
         LA    R6,24(,R6)
         CLC USERID,=C′ XXXXXXXX′    LAST ENTRY??
         BNE CHKENTRY                CHECK NEXT ENTRY
RTRN4    EQU *
         LA    R15,4                 BUILD SECURITY ENV.
         B     DONE
RTRN0    EQU *
         LA    R15,0                 DO NOT BUILD SECURITY ENV
         B     DONE
*                                                                       00220000
DONE     EQU *                                                          00221000
         L      R13,4(,R13)        GET PREVIOUS SAVE LEVEL              00221500
         RETURN (14,12),,RC=(15) RETURN WITH RETURN CODE IN R15         00222000
         EJECT                                                          00223000
*                                                                       00224000
          REQUATE                                                       00280000
*                                                                       00283000
*********************************************************************** 00284000
* CONTROL BLOCK DSECTS                                                  00285000



                                         Appendix A. IMS Security Exits Examples   209
                        ***********************************************************************   00286000
                        *                                                                         00287000
                                 PRINT GEN                                                        00288000
                        BSE      DSECT
                        BSESCLS DS CL4
                        BSETRN DS CL8
                        BSEPSB DS CL8
                        BSEPGM DS CL8
                        BSEUID DS CL8
                        BSEGRP DS CL8
                        BSEPRM DS CL32
                        BSEMSG DS CL64
                        *
                        AUTHTAB DSECT
                        USERID DS CL8
                        PSBNAM DS CL8
                        PGMNAM DS CL8
                                 DFSSXPL COMMENT=NO                                               00288500
                                 END                                                              00290000




210   IMS V6 Security Guide
A.2 Command Authorization Exit (DFSCCMD0)
              The Command Authorization exit routine (DFSCCMD0) is used to verify that a
              command and keyword combination is valid for a particular user. The following
              sample source program is developed by Robert Hain of IBM Australia. This
              sample of DFSCCMD0 has added more functionality. Not only does it make
              RACF-based security decisions on commands from terminals, ICMD calls, or the
              MCS/EMCS console interfaces, it uses the command keyword table DFSCKWD0
              to determine what three-letter keyword to use when making the RACF check, so
              all valid spellings/aliases for a keyword will all validate against a single RACF
              command profile. The return code from RACF will signal access authorized or
              access denied for the request.

              The program was developed according to Hain′s environment and the listing is
              just for reference purposes only. Users who are interested in this program are
              urged to study this program carefully. Make whatever adjustments are
              necessary to meet the environment.

              The IMS-supplied sample DFSCCMD0 exit routine maintains a list of valid user
              IDs in a table. It performs a table search before it authorizes the user ID to
              execute an IMS command. We feel such extra work is not necessary and poses
              system maintenance problems.



              CCMD     TITLE ′ COMMAND AUTHORIZATION USER EXIT′
              ***********************************************************************
              *                                                                     *
              * MODULE NAME: DFSCCMD0                                               *
              *                                                                     *
              * DESCRIPTIVE NAME: COMMAND AUTHORIZATION USER EXIT                   *
              *                                                                     *
              ***********************************************************************
              *                                                                     *
              * WRITTEN FOR IBM GLOBAL SERVICES AUSTRALIA                           *
              *            (A JOINT VENTURE WITH LEND LEASE AND TELSTRA)            *
              * TELSTRA ALLIANCE                                                    *
              * IMS SUPPORT GROUP                                                   *
              * 18 WINTERTON ROAD,                                                  *
              * CLAYTON, 3168,                                                      *
              * AUSTRALIA                                                           *
              * +61-3-9253-8028                                                     *
              *                                                                     *
              * WRITTEN FOR USE IN TELSTRA IMS SYSTEMS                              *
              *                                                                     *
              * HISTORY:     WRITTEN BY ROBERT HAIN, FEBRUARY, 1998                 *
              *              MODIFIED FOR V6.1 SUPPORT (ICMD & MCS ), APRIL, 1999 *
              *                                                                     *
              ***********************************************************************
              *                                                                     *
              * STATUS: IMS                                                         *
              *                                                                     *
              * NOTES:                                                              *
              *                                                                     *
              *    DEPENDENCIES: NONE                                               *
              *                                                                     *
              *    RESTRICTIONS: NONE                                               *
              *                                                                     *

                                                       Appendix A. IMS Security Exits Examples   211
                        * MODULE TYPE:                                                        *
                        *                                                                     *
                        *    PROCESSOR: ASSEMBLER                                             *
                        *                                                                     *
                        *    ATTRIBUTES: REENTRANT                                            *
                        *                                                                     *
                        * ENTRY POINT: DFSCCMD0                                               *
                        *                                                                     *
                        *    PURPOSE: SEE FUNCTION                                            *
                        *                                                                     *
                        *    LINKAGE: BALR 14,15                                              *
                        *                                                                     *
                        ***********************************************************************
                                 EJECT
                        ***********************************************************************
                        *                                                                     *
                        * ASSUMPTIONS : RACF HAS ALREADY BEEN CALLED                          *
                        *                                                                     *
                        *              IF PREVIOUS RACF CHECKING WAS NOT DONE, THEN           *
                        *              THIS WOULD MEAN THE COMMAND CAME FROM THE MVS CONSOLE, *
                        *              (LINE 1 PTERM 1), OR WAS A /SIGN OR /RCL COMMAND.      *
                        *                                                                     *
                        *              TERMINALS :                                            *
                        *              -----------                                            *
                        *              CTBRACFT POINTS TO RACF ACEE.                          *
                        *                                                                     *
                        *              BMPS ISSUING ICMD :                                    *
                        *              -------------------                                    *
                        *              AOIS=A ( ICMD CALLS GO TO RACF, THEN DFSCCMD0          *
                        *                       NEED TO BUILD THE RACF ACEE )                 *
                        *                                                                     *
                        *              MCS CONSOLE SUPPORT :                                  *
                        *              ---------------------                                  *
                        *              CMDMCS=B ( CMDMCS CALLS GO TO RACF, THEN DFSCCMD0      *
                        *                       NEED TO BUILD THE RACF ACEE )                 *
                        *                                                                     *
                        *              THIS EXIT DOES NOT HANDLE ANY SMU PASSWORD PROTECION *
                        *              ON THE COMMANDS. ALL COMMAND SECURITY IS ASSUMED TO *
                        *              BE UNDER RACF CONTROL                                  *
                        *                                                                     *
                        *              THIS EXIT DOES NOT HANDLE THE ONLINE DBRC COMMANDS,    *
                        *              AS THE KEYWORD DBRC IS NOT IN THE DFSCKWD0, AND AS THE *
                        *              2ND KEYWORD ON THESE IS ALWAYS DBRC, COMMAND LEVEL     *
                        *              SECURITY REMAINS.                                      *
                        *                                                                     *
                        ***********************************************************************
                                 EJECT
                        ***********************************************************************
                        *                                                                     *
                        * FUNCTION: IF THE REQUEST HAS COME FROM ANY OF THE FOLLOWING,        *
                        *              THEN THIS EXIT WILL CHECK FURTHER FOR MORE SPECIFIC    *
                        *              RACF RULES :                                           *
                        *                  - ANY TERMINAL                                     *
                        *                  - MCS/EMCS CONSOLES           ( CMDMCS= B )        *
                        *                  - ICMD CALLS FROM PROGRAMS    ( AOIS = A )         *
                        *                                                                     *
                        *              IF THE REQUEST HAS COME FROM ANY OF THE FOLLOWING,     *
                        *              THEN THIS EXIT WILL IMMEDIATLY DENY ALL ACCESS :       *
                        *                  - LU 6.2 / APPC                                    *


212   IMS V6 Security Guide
*                  - OTMA                                             *
*                                                                     *
*              IF PREVIOUS RACF CHECKING WAS DONE, AND THEIR IS NO    *
*              VALID RACF ACEE (TERMINAL NOT SIGNED ON), CHECK IF     *
*              SIGNON WAS NOT REQUIRED (MTO), AND ALLOW, ELSE, DENY. *
*                                                                     *
*              IF THE PREVIOUS RACF CHECK DENIES ACCESS, THEN NO      *
*              FURTHER CHECKING WILL BE DONE, AND ACCESS WILL CONTINUE*
*              TO BE DENIED.                                          *
*                                                                     *
*              IF THE PREVIOUS RACF CHECK ALLOWS ACCESS, THEN THE     *
*              FIRST KEYWORD IS CHECKED :                             *
*               - CHECK THIS KEYWORD AGINST THE IMS KEYWORD TABLE     *
*                 (DFSCKWD0).                                         *
*               - IF NOT FOUND, THEN EXIT WILL ALLOW COMMAND, SO IMS *
*                 CAN REJECT IT NORMALLY AS INVALID.                  *
*               - IF FOUND, THEN THE INTERNAL KEYWORD (DEFINED BY THE *
*                 IKEY MACRO) FROM DFSCKWD0 WILL BE USED FOR FURTHER *
*                 RACF VALIDATION.                                    *
*                                                                     *
*              RACF VALIDATION IS DONE AGAINST THE STRING :           *
*                 $CCCKKK                                             *
*              WHERE CCC = FIRST 3 CHARACTERS FROM COMMAND            *
*                    KKK = IKEY VALUE FROM DFSCKWD0 OF KEYWORD        *
*                                                                     *
*              IF NO RULE IS FOUND, THEN ACCESS IS ASSUMED TO BE      *
*              DENIED.                                                *
*                                                                     *
*              BASED ON INFO IN DFSCAUT0, THE /NRE AND /ERE COMMANDS *
*              ARE HANDLED DIFFERENTLY, SO IF THESE COMMANDS ARE      *
*              IDENTIFIED, THEN THE RACF CALL IS BYPASSED.            *
*                                                                     *
***********************************************************************
         EJECT
***********************************************************************
* INTERFACE:                                                          *
*                                                                     *
*       CONTENTS OF REGISTERS AT ENTRY:                               *
*              R1     = ADDRESS OF STANDARD IMS USER EXIT PARMLIST    *
*                                                                     *
*                     STANDARD PARMLIST                               *
*                      ---------                                      *
*                     ‘         ‘                                     *
*                     ‘---------‘                                     *
*                     ‘         ‘                                     *
*                     ‘---------‘                                     *
*                     ‘         ‘      DFSCCMD0 PARMLIST              *
*                 +12 ‘---------‘     ‘---------------‘               *
*                     ‘         ‘---->‘A(ECB)         ‘ +0            *
*                      ---------      ‘---------------‘               *
*                                     ‘A(SCD)         ‘ +4            *
*                                     ‘---------------‘               *
*                                     ‘A(USERTBL)     ‘ +8            *
*                                     ‘---------------‘               *
*                                     ‘A(USERID)      ‘ +12           *
*                                     ‘---------------‘               *
*                                     ‘A(CVB)         ‘ +16           *
*                                     ‘---------------‘               *
*                                     ‘SECURITY RETCOD‘ +20           *


                                        Appendix A. IMS Security Exits Examples   213
                        *                                     ‘---------------‘                *
                        *                                     ‘A(CTB)          ‘ +24           *
                        *                                     ‘---------------‘                *
                        *                                     ‘A(INPUT CMD) ‘ +28              *
                        *                                     ‘---------------‘                *
                        *                                     ‘RESERVED        ‘ +32           *
                        *                                     ‘---------------‘                *
                        *                                     ‘RACROUTE CALL ‘ +34             *
                        *                                     ‘---------------‘                *
                        *                                     ‘REQUEST TYPE ‘ +35              *
                        *                                     ‘---------------‘                *
                        *                                     ‘FOR ICMD CALLS,‘ +36            *
                        * ‘-----------------‘<---------------‘A(ICMD SECURITY‘                 *
                        * ‘SAF RETURN CODE ‘                  ‘ RETURN CODES)‘                 *
                        * ‘(ICMD CALLS ONLY)‘                 ‘                ‘               *
                        * ‘-----------------‘                  ‘FOR LU6.2,     ‘               *
                        * ‘RACF RETURN CODE ‘                 ‘A(PARTNER_LU ‘                  *
                        * ‘(ICMD CALLS ONLY)‘                 ‘ NAME)          ‘               *
                        * ‘-----------------‘                 ‘---------------‘                *
                        * ‘RACF REASON CODE ‘                                                  *
                        * ‘(ICMD/MCS CALLS) ‘                                                  *
                        * ‘-----------------‘                                                  *
                        *                                                                      *
                        *                                                                      *
                        *              R13    = SAVE AREA ADDRESS                              *
                        *              R14    = RETURN ADDRESS                                 *
                        *              R15    = ENTRY POINT ADDRESS                            *
                        *                                                                      *
                        *                                                                      *
                        ***********************************************************************
                                 EJECT
                        ***********************************************************************
                        *       CONTENTS OF COMMAND AUTHORIZATION EXIT PARMLIST:               *
                        *                                                                      *
                        *              +0     = A(ECB)                                         *
                        *                       ADDRESS OF THE ECB THE TASK IS RUNNING UNDER. *
                        *                       FOR TERMINALS, THE ECB IS THE CLB              *
                        *                       ASSOCIATED WITH THE ENTERING TERMINAL.         *
                        *                       FOR ICMD, THE ECB IS THE PST ASSOCIATED WITH *
                        *                       THE REGION THE APPLICATION IS RUNNING IN.      *
                        *              +4     = A(SCD)                                         *
                        *                       ADDRESS OF THE SCD.                            *
                        *              +8     = A(USRTBL)                                      *
                        *                       ADDRESS OF USER TABLE LOADED IN DFSINTX0.      *
                        *              +12    = A(USERID)                                      *
                        *                       ADDRESS OF USERID ASSOCIATED WITH COMMAND      *
                        *                       FOR LU6.2, USERID ASSOCIATED WITH COMMAND      *
                        *                       FOR ICMD, EITHER USERID OR PROGRAM NAME,       *
                        *                       DEPENDING ON TYPE OF REGION AND WHETHER GET *
                        *                       UNIQUE DONE:                                   *
                        *                       BMP:            USERID ON BMP JCL USER=.       *
                        *                       DBT:            SECURITY TOKEN PASSED IN PAPL. *
                        *                       IFP WITHOUT GU:PROGRAM NAME
                        *                       IFP:            USERID (SIGNED ON) OR LTERMNAME*
                        *                                       (NOT SIGNED ON) FOR TERMINAL *
                        *                                       WHERE TRAN ISSUED.             *
                        *                       MPP WITHOUT GU:PROGRAM NAME
                        *                       MPP             USERID (SIGNED ON) OR LTERMNAME*
                        *                                       (NOT SIGNED ON) FOR TERMINAL *


214   IMS V6 Security Guide
*                            WHERE TRAN ISSUED.             *
*             MSGBMP NO GU: USERID ON BMP JCL USER=         *
*             MSGBMP:        USERID (SIGNED ON) OR LTERMNAME*
*                            (NOT SIGNED ON) FOR TERMINAL *
*                            WHERE TRAN ISSUED.             *
*             FOR MCS, THE 4-BYTE USERID OF THE             *
*             MCS/EMCS TERMINAL                             *
*   +16   =   A(CVB)                                        *
*             ADDRESS OF COMMAND VERB BLOCK ASSOCIATED WITH *
*             COMMAND.                                      *
*             FOR APPC/OTMA, ADDRESS OF COMMAND VERB        *
*   +20   =   SECURITY RETCOD                               *
*             RETURN CODE FROM SECURITY OR                  *
*             MINUS 0, IF NO SECURITY CHECKING WAS DONE.    *
*             FOR NON LU6.2 TERMINALS, EITHER SMU OR RACF *
*               RETURN CODE                                 *
*             FOR LU 6.2 TERMINALS, RACF RETURN CODE        *
*             FOR OTMA, RACF RETURN CODE                    *
*             FOR ICMD OR MCS ONE OF THE FOLLOWING:         *
*               X′00000004′ - RACF NOT AVAILABLE            *
*               X′00000008′ - USERID NOT DEFINED TO RACF    *
*               X′0000000C′ - COMMAND NOT PROTECTED BY RACF *
*               X′00000010′ - USERID NOT AUTH FOR COMMAND *
*               X′80000000′ - RACF NOT CALLED(AOIS=C)       *
*                                                           *
*   +24   =   A(CTB)                                        *
*             ADDRESS OF CTB.                               *
*             FOR LU6.2 OR OTMA , CONTAINS LIMITED FIELDS. *
*             FOR ICMD, EQUALS 0.                           *
*   +28   =   A(INPUT CMD)                                  *
*             ADDRESS OF INPUT COMMAND BUFFER IN LLZZDATA *
*             FORMAT.                                       *
*   +32   =   2 RESERVED BYTES                              *
*   +34   =   RACROUTE CALL TYPE (1 BYTE)                   *
*             (ONLY APPLIES TO ICMD CALL TYPES)             *
*             =0; RACF NOT CALLED                           *
*             =1; RACROUTE VERIFY CALL                      *
*             =2; RACROUTE AUTH CALL                        *
*   +35   =   REQUEST TYPE (1 BYTE)                         *
*             TYPE OF CMD SECURITY AUTHORIZATION TO DO.     *
*             =1; TERMINAL SECURITY AUTHORIZATION,          *
*                 CALLER IS DFSICIO1.                       *
*             =2; LU6.2 TERMINAL SECURITY AUTHORIZATION,    *
*                 CALLER IS DFSRAC60.                       *
*             =3; ICMD SECURITY FOR USERID, CALLER IS       *
*                 DFSAOSC0.                                 *
*             =4; ICMD SECURITY FOR PROGRAM, CALLER IS      *
*                 DFSAOSC0.                                 *
*             =5; OTMA SECURITY                             *
*                 CALLER IS DFSYRAC0                        *
*             =6; MCS ENTERED COMMAND                       *
*   +36   =   AS DETERMINED BY REQUEST TYPE                 *
*         -   FOR ICMD CALLS,                               *
*             ADDRESS OF START OF 3 FULL WORDS OF           *
*         -   FOR ICMD/MCS CALLS,                           *
*             ADDRESS OF START OF 3 FULL WORDS OF           *
*             ICMD/MCS SECURITY RETURN CODES                *
*             (PARAMETER LIST EXTENDED TO INCLUDE           *
*             THIS ADDRESS ONLY FOR ICMD/MCS CALLS)         *


                              Appendix A. IMS Security Exits Examples   215
                        *                       THESE CODES MEANINGLESS IF AOIS=C OR          *
                        *                       CMDMCS=C WHICH MEANS RACF OR EQUIVALENT       *
                        *                       NOT CALLED.                                   *
                        *                       +0 = SAF RETURN CODE                          *
                        *                       +4 = RACF (OR EQUIVALENT) RETURN CODE         *
                        *                       +8 = RACF (OR EQUIVALENT) REASON CODE         *
                        *                     - FOR LU6.2 CALLS,                              *
                        *                       ADDRESS OF PARTNER_LUNAME (17 BYTES LONG)     *
                        *                                                                     *
                        *                                                                     *
                        *       CONTENTS OF REGISTERS AT EXIT:                                *
                        *                                                                     *
                        *              R15    = RETURN CODE                                   *
                        *              UPON RETURN THE FOLLOWING RETURN CODES WILL BE USED    *
                        *              IN R15:                                                *
                        *                                                                     *
                        *              RC=      0, USER/TERMINAL/APPLICATION IS               *
                        *                          AUTHORIZED TO ISSUE COMMAND.               *
                        *              RC=     >0, USER/TERMINAL/APPLICATION IS NOT           *
                        *                          AUTHORIZED TO ISSUE COMMAND.               *
                        *              RC=     <0, USER/TERMINAL IS NOT AUTHORIZED, THE       *
                        *                          SPECIFIED USER MESSAGE IS SENT TO THE      *
                        *                          TERMINAL ENTERING THE COMMAND. DOES NOT *
                        *                          APPLY TO REQUEST TYPE=ICMD.                *
                        *                                                                     *
                        *                                                                     *
                        *                                                                     *
                        * EXTERNAL REFERENCES:                                                *
                        *                                                                     *
                        *    ROUTINES:                                                        *
                        *                                                                     *
                        *        NONE                                                         *
                        *                                                                     *
                        *    DATA AREAS:                                                      *
                        *                                                                     *
                        *        NONE                                                         *
                        *                                                                     *
                        *    MVS MACROS: RETURN                                               *
                        *                                                                     *
                        *    IMS MACROS: DFSCMDVB, ICLI, REQUATE                              *
                        *                                                                     *
                        *                                                                     *
                        * MESSAGES: NONE                                                      *
                        *                                                                     *
                        * ABENDS : NONE                                                       *
                        *                                                                     *
                        * CHANGE ACTIVITY: USER RESPONSIBILITY                                *
                        *                                                                     *
                        *                                                                     *
                        ***********************************************************************
                        *                                                                     *
                        * REGISTER USAGE :                                                    *
                        *                                                                     *
                        *        R0    WORK REGISTER                                          *
                        *        R1    RETURN FROM EX STMT                                    *
                        *        R2    RETURN FROM EX STMT                                    *
                        *        R3    CCMD0 BASE REGISTER                                    *
                        *        R4    CMD PARSE ADDRESS / USED BY CALLABLE SERVICES          *
                        *        R5    STORAGE ADDRESS FOR EX STMTS                           *


216   IMS V6 Security Guide
*        R6    DFSCCMD PARMLIB                                        *
*        R7    RETURN ADDRESS FOR GETBUFF / FREEBUFF                  *
*        R8    LENGTH OF STORAGE FOR CALLABLE SERVICES                *
*        R9    CLB (ECB) / PST / POINTER TO STRING FOR PARSING        *
*        R10 POINTER TO RACF ACEE                                     *
*        R11 SCD / CTB / BASE FOR CCMD0                               *
*        R12 DFSCCMD0 BASE REGISTER                                   *
*        R13 NEXT SAVE LEVEL                                          *
*        R14 ′ BAL′ RETURN ADDRESSES                                  *
*        R15 CMD PARSE LENGTH / RETURN CODES                          *
*                                                                     *
***********************************************************************
         EJECT
***********************************************************************
*        SAVE REGISTERS AND ESTABLISH ADDRESSABILITY CONVENTIONS
***********************************************************************
*
DFSCCMD0 CSECT
         SAVE (14,12),,DFSCCMD0&SYSDATE&SYSTIME
         L     R13,8(,R13)         GET NEXT SAVE LEVEL
         LR    R12,R15             BASE REGISTER
         USING DFSCCMD0,R12
*
***********************************************************************
* SET UP REGISTERS FOR USER EXIT
***********************************************************************
         L     R6,12(,R1)          LOAD A(FUNCTION SPECIFIC PARMLIST)
         USING DFSCCMD,R6          PARMLIST BASE REGISTER
*
***********************************************************************
* CHECK ON WHERE THE COMMAND CAME FROM.                               *
***********************************************************************
*
         CLI CCMDTYPE,CCMDTRM      WAS IT A TERMINAL REQUEST TYPE ?
         BE    TERMINAL            YES, GO HANDLE TERMINAL REQUEST
*
         CLI CCMDTYPE,CCMDMCS      WAS IT A REQUEST FROM MCS CONSOLE ?
         BE    GOCHECK             YES, GO CHECK FURTHER
*
         CLI CCMDTYPE,CCMDIUSR WAS IT A REQUEST FROM ICMD / USERID?
         BE    GOCHECK             YES, GO CHECK FURTHER
*
         CLI CCMDTYPE,CCMDIPRG WAS IT A REQUEST FROM ICMD / PGM ?
         BE    GOCHECK             YES, GO CHECK FURTHER
*
         B     REJECT              REJECT ACCESS AND GET OUT
*
         EJECT
***********************************************************************
* IF NO PRIOR RACF CHECKING WAS DONE, THEN ALLOW, AND GET OUT.        *
* (ASSUMING IT IS A COMMAND FROM THE MVS WTOR, WHICH WILL ALWAYS BE *
* (ALLOWED).                                                          *
* /SIGN COMMAND ALSO FALLS INTO THIS CATEGORY                         *
***********************************************************************
TERMINAL DS    0H                  TERMINAL REQUEST HANDLING
*
         CLC CCMDRETC,NOSECURE WAS SIGNON NOT REQUIRED ?
         BE    ALLOWTOR            YES, CONTINUE TO ALLOW AND GET OUT
*                                  (IF WTOR, THEN SIGNON NOT REQURED


                                        Appendix A. IMS Security Exits Examples   217
                        *                                   UNLESS RESTART, THEN IS CHECKED).
                        *
                        ***********************************************************************
                        * CHECK ON THE PREVIOUS RACF CALL.                                    *
                        * GET OUT IF ACCESS PREVISOULY DENIED.                                *
                        ***********************************************************************
                        GOCHECK DS     0H
                        *
                                 CLC CCMDRETC,NOACCESS WAS COMMAND INITIALLY ALLOWED ?
                                 BE    REJECT              NO, REJECT ACCESS AND GET OUT
                        *                                  YES, CHECK FURTHER
                        *
                        ***********************************************************************
                        * GET STORAGE FOR RACF CALL(S)                                        *
                        * MADE UP OF FIXED LENGTH STORAGE, AND VARIABLE LENGTH COMMAND BUFFER *
                        ***********************************************************************
                        *
                                 LA    R8,CCMLNTH          GET FIXED LENGTH STORAGE LENGTH
                                 L     R4,CCMDCMD          GET POINTER TO COMMAND STRING
                                 USING CMDBUFF,R4          BASE REGISTER FOR COMMAND STRING
                                 AH    R8,CMDLL            ADD THE BUFFER LENGTH FOR GETMAIN
                                 DROP R4                   DON′ T NEED R4 ANYMORE
                        *
                                 BAL R7,GETBUFF            GO AND GET A BUFFER
                                 LTR R15,R15               DID WE GET IT ?
                                 BNZ ERROROUT              NO, LEAVE WITH ERROR RC
                        *
                                 USING CCMD0,R3            ADDRESS THE GETMAIN′ D STORAGE
                        *
                                 EJECT
                        ***********************************************************************
                        * CLEAR FIXED LENGTH PORTION OF GETMAINED STORAGE (CCMD0)             *
                        ***********************************************************************
                        *
                                 LA    R0,CCMD0            POINT TO BEGINNING OF STORAGE
                                 LA    R1,CCMLNTH          USE LENGTH OF FIXED LENGTH STORAGE
                                 SLR R14,R14
                                 SLR R15,R15         * ZERO LENGTH AND 0 PAD SEE PRINC. O′ OPS
                                 MVCL R0,R14
                        *
                        ***********************************************************************
                        * AS THE REAL COMMAND STRING IS PASSED TO THIS EXIT (AS CCMDCMD),     *
                        * FIRST COPY THE COMMAND STRING TO A WORKING BUFFER (CMDBUFF) SO      *
                        * THAT ALL TRANSLATIONS CAN BE DONE WITHOUT CHANGING THE ORIGINAL     *
                        * INPUT. THIS BUFFER STARTS AT THE END OF CCMD0 DSECT.                *
                        ***********************************************************************
                        COPYBUFF DS    0H
                                 L     R14,CCMDCMD         GET POINTER TO ORIGINAL CMD STRING
                                 USING CMDBUFF,R14         BASE REGISTER FOR COMMAND STRING
                                 LH    R15,CMDLL           GET THE LENGTH OF INPUT CMD & LLZZ
                                 DROP R14                  DON′ T NEED R4 ANYMORE
                        *
                                 LA    R4,CCMLNTH          USE LENGTH OF CCMD0
                                 AR    R4,R3               ADD START ADDRESS OF CCMD0 (R3)
                                 LR    R5,R15              LENGTH THE SAME AS INPUT
                        *                                  R4 NOW POINTS TO START OF BUFFER
                                 MVCL R4,R14               MOVE DATA
                        *
                                 LA    R4,CCMLNTH          AFTER MVCL, RESET R4


218   IMS V6 Security Guide
         AR    R4,R3               ADD START ADDRESS OF CCMD0 (R3)
         USING CMDBUFF,R4          BASE REGISTER FOR COMMAND BUFFER
         EJECT
***********************************************************************
* TRANSLATE COMMAND BUFFER TO UPPER CASE                               *
*                                                                      *
* THIS WILL USE THE TABLE LWRUPPR TO TRANSLATE THE INTPUT STRING TO *
* UPPER CASE ONLY.                                                     *
*                                                                      *
* PRIOR TO THE TR COMMAND, THE REGISTERS USAGE IS :                    *
*         R5 = ADDRESS OF COMMAND STRING / RACF WORKAREA ADDRESS       *
*         R15= LENGTH OF DATA TO BE PARSED (-1 FOR USE WITH EX INSTR.)*
*                                                                      *
***********************************************************************
*
XLATE    DS    0H
         LH    R15,CMDLL           GET THE LENGTH OF INPUT CMD & LLZZ
         BCTR R15,0                -1 TO GET MACHINE LENGTH
         SH    R15,FOUR            REDUCE THE LENGTH BY 4 FOR LLZZ
         BCTR R15,0                -1 AGAIN, AS WE DON′ T COUNT ′ / ′
         SR    R2,R2               ZERO R2
         LA    R5,CMDDATA          GET ADDRESS OF THE BEGINNING OF CMD
*                                      (GO PAST THE LLZZ FIELDS)
         LA    R5,1(R5)            ADD 1 TO MOVE POINTER PAST ″ / ″
*
         EX    R15,EXCONV          CONVERT TO UPPER CASE
*
         SPACE 5
***********************************************************************
* DETERMINE COMMAND AND PARAMETER COMBINATION                          *
* -------------------------------------------                          *
*                                                                      *
* THIS WILL USE THE TABLE TRTALPHA, TO PARSE THE INPUT STRING          *
* AND DETERMINE WHAT THE COMMAND IS.                                   *
*                                                                      *
* THE TRT COMMAND WILL :                                               *
* - IF THE CHARACTER IS A VALID LETTER, THE TABLE WILL MAP TO X′ 0 0 ′ *
*    WHICH MEANS NO ACTION OCCURS, AND THE NEXT CHARACTER IS CHECKED. *
*                                                                      *
* - IF THE CHARACTER IS A SPACE, THEN THE TABLE WILL MAP TO X′ 0 4 ′ , *
*         R1 = POINT TO THE SPACE BETWEEN COMMAND AND PARAMETER.       *
*         R2 = ADDRESS OF BRANCH ADDRESS + TABLE ENTRY, X′ 0 4 ′ .     *
*         CONDITION CODE 1 IS SET (SCAN NOT COMPLETED)                 *
*                                                                      *
* PRIOR TO EXSRCH EX COMMAND BEING USED,                               *
* THE FOLLOWING REGISTER CONVENTION IS USED :                          *
*    R5 = POINTER TO THE BEGINNING OF THE STRING TO BE SCANNED         *
*    R15 = MAXIMUM LENGTH TO BE SCANNED                                *
***********************************************************************
         SPACE
         EX    R15,EXSRCH          GO GET THE END OF THE CMD FIELD
         SPACE 5
***********************************************************************
* AFTER EX COMMAND, THE FOLLOWING REGISTERS ARE RETURNED :             *
*    R1 = POINTER TO THE FIRST NON-ZERO RESPONSE FROM TRT TABLE        *
*    R2 = RESPONSE FROM THE VALUE IN THE TABLE                         *
* IF THE END OF THE STRING WAS REACHED, WITHOUT FINDING A DELIMITER, *
* THEN A ZERO RETURN CODE IS ALSO RETURNED, OTHERWISE NONZERO.         *



                                        Appendix A. IMS Security Exits Examples   219
                        ***********************************************************************
                        *
                                 BZ    NOPARM              RC = 0, NO PARM FOUND
                                 CH    R2,FOUR             CHECK VALUE OF R2
                                 BNE ERRORRET              OTHERWISE, ERROR CONDITION
                                 LR    R9,R1               SAVE POINTER TO FIRST DELIMETER
                        *                                  WAS A VALID DELIMITER, SO SAVE CMD
                                 MVC COMMAND$(1),DOLLAR FILL THE FIRST CHAR WITH ′ $′
                                 MVC COMMAND(3),0(R5)      MOVE THE FIRST 3 CHARS TO KEEP CMD
                                 MVC COMMANDF(1),BLANK1 FILL THE LAST CHAR WITH BLANK
                                 B     SCANDELI            GO SCAN DELIMITERS
                                 EJECT
                        ***********************************************************************
                        * SETUP REGISTERS TO HANDLE THE SPECIAL CASE OF A ″NUL″ RETURN FROM *
                        * DFSCDWD0.                                                             *
                        ***********************************************************************
                        SCANNUL DS     0H
                                 LR    R9,R10              GET BACK R9, POINTER TO FIRST NULL
                        *                                  AFTER KEYWORD, FOR ANOTHER SEARCH
                        *
                        ***********************************************************************
                        * SCAN PAST DELIMITERS TO FIND THE KEYWORD                              *
                        * (DELIMITERS ARE SPACE, COMMA, OR EQUAL SIGN.)                         *
                        * R9 AT THIS POINT IS THE FIRST DELIMITER (USUALLY SPACE) AFTER CMD *
                        * R4 STILL POINTING AT THE BEGINNING OF THE COMMAND BUFFER              *
                        ***********************************************************************
                        SCANDELI DS    0H
                                 LR    R2,R4               GET ADDRESS OF START OF STRING
                                 AH    R2,CMDLL            ADDRESS OF THE END OF CMD STRING
                        SCANIT DS      0H
                                 LA    R9,1(,R9)           INCREMENT POINTER
                                 CR    R9,R2               END OF COMMAND STRING (R9>=R2)?
                                 BNL NOPARM                YES, HAVE GOT TO THE END
                        *                                  NO, KEEP CHECKING
                                 CLI 0(R9),C′ ′            IS THIS A SPACE
                                 BE    SCANIT              YES, GO ROUND LOOP AGAIN
                                 CLI 0(R9),C′ , ′          IS THIS A COMMA
                                 BE    SCANIT              YES, GO ROUND LOOP AGAIN
                                 CLI 0(R9),C′ = ′          IS THIS AN EQUAL SIGN
                                 BE    SCANIT              YES, GO ROUND LOOP AGAIN
                                 CLI 0(R9),C′ . ′          IS THIS AN FULL STOP
                                 BE    ENDSCAN             YES, END OF COMMAND
                                 CLI 0(R9),X′ 3F′          IS THIS AN HEX ′ 3F′ ( TERMINAL ONLY)
                                 BE    ENDSCAN             YES, END OF COMMAND
                                 SPACE 5
                        ***********************************************************************
                        * AT THIS POINT, R9 POINTS TO THE FIRST CHARACTER OF KEYWORD            *
                        *                R2 POINTS TO THE ADDRESS AFTER THE END OF CMD STRING *
                        *                R5 POINTS TO THE FIRST CHARACTER OF COMMAND            *
                        *                                                                       *
                        * SETUP REGISTERS FOR ANOTHER SCAN TO GET THE COMPLETE KEYWORD          *
                        * ------------------------------------------------------------          *
                        * PRIOR TO EX COMMAND, THE FOLLOWING REGISTER CONVENTION IS REQ′ D : *
                        *    R5 = POINTER TO THE BEGINNING OF THE STRING TO BE SCANNED          *
                        *    R15 = MAXIMUM LENGTH TO BE SCANNED                                 *
                        * AFTER EX COMMAND, THE FOLLOWING REGISTER ARE RETURNED :               *
                        *    R1 = POINTER TO THE FIRST NON-ZERO RESPONSE FROM TRT TABLE         *
                        *    R2 = RESPONSE FROM THE VALUE IN THE TABLE                          *



220   IMS V6 Security Guide
***********************************************************************
ENDSCAN DS     0H
         LR    R5,R9               MAKE R5 POINT TO START OF KEYWORD
         LR    R15,R2              R15 NOW ALSO POINTS TO END OF STRING
         SR    R15,R9              R15 NOW LENGTH OF REST OF STRING
         LTR R15,R15               CHECK R15 IS STILL > ZERO
         BZ    ERRORRET            R15 = ZERO, ERROR CONDITION
*
         BCTR R15,0                -1 TO GET MACHINE LENGTH
         EX    R15,EXSRCH          GO GET THE END OF THE CMD FIELD
*
         BNZ FNDSTRNG              RC [ 0, FOUND STRING - ALL OK
*                                  RC = 0, R9 -> END OF STRING
         LR    R9,R4               GET ADDRESS OF START OF STRING
         AH    R9,CMDLL            ADDRESS OF THE END OF CMD STRING
         SR    R9,R5               GET THE LENGTH OF KEYWORD
         B     GETKEYWD            GO GET KEYWORD
*
FNDSTRNG DS    0H
         LR    R9,R1               GET POSITION AFTER EX COMMAND
         LR    R10,R9              KEEP END OF KEYWORD, JUST IN CASE
         SR    R9,R5               GET THE LENGTH OF KEYWORD
*
***********************************************************************
*                                                                     *
* AT THIS POINT,                                                      *
* R5 = A(START OF KEYWORD)                                            *
* R9 = LENGTH OF KEYWORD                                              *
*                                                                     *
* THE DIFFERENCE IS THE LENGTH OF DATA TO BE MOVED INTO CALNAME FOR *
* VALIDATION WITH DFSCKWD0.                                           *
*                                                                     *
* IF DFSCKWD0 RETURNS SPECIAL CASE ″NUL″, GO BACK, AND TRY FOR ANOTHER*
* KEYWORD.                                                            *
*                                                                     *
***********************************************************************
GETKEYWD DS    0H
         USING CMDKEYWD,R5         TO BE ABLE TO ADDRESS THE KEYWORD
         MVC CALNAME(13),BLANK13 INITIALIZE CALNAME
         BCTR R9,0                 -1 TO GET MACHINE LENGTH FOR EX CMD
         EX    R9,COPYPARM         COPY PARM
*
         B     CHKPARM             BRANCH AROUND EXECUTE STMT
COPYPARM MVC CALNAME(0),CMDKEYWD EXECUTE STMT TO MOVE COMMAND STRING
CHKPARM DS     0H
         DROP R5
*
         BAL R7,SCANKWDT           GO SCAN KEYWORD TABLE
         TM    CALFND,CALKFND      KEYWORD FOUND ?
         BNO NOTFOUND              NO, SO ALLOW TO PROCESS, AND LET
*                                  IMS REJECT THIS AS AN INVALID CMD
         CLC CALKABBR,NUL          WAS THE RETURNED KEYWORD ″NUL″
         BE    SCANNUL             IF SO, IGNORE, AND GET ANOTHER ONE
*
         MVC COMMANDP(3),CALKABBR USE INTERNAL ABBREV OF KEYWORD
         B     CHKNRE              GO CHECK FOR A RESTART COMMAND
*
NOPARM DS      0H
         MVC COMMAND$(1),DOLLAR FILL THE FIRST CHAR WITH ′ $′


                                        Appendix A. IMS Security Exits Examples   221
                                 MVC   COMMAND(3),0(R5)   MOVE THE FIRST 3 CHARS TO KEEP CMD
                                 MVC   COMMANDP(3),BLANK3 FILL THE PARM WITH BLANKS
                                 MVC   COMMANDF(1),BLANK1 FILL THE LAST CHAR WITH BLANK
                        *
                        ***********************************************************************
                        * DUE TO COMMENTS IN DFSCAUT0, IMS HANDLES /NRE & /ERE DIFFERENTLY. *
                        * WE NEED TO CHECK FOR THESE COMMANDS, AND DON′ T CALL RACF.          *
                        ***********************************************************************
                        *
                        CHKNRE DS      0H
                        *
                                 CLC COMMAND,NRE           ARE WE DOING AN /NRE ?
                                 BE    RACFOK              YES, DON′ T DO ANY CHECKING
                                 CLC COMMAND,ERE           ARE WE DOING AN /ERE ?
                                 BE    RACFOK              YES, DON′ T DO ANY CHECKING
                        *
                                 EJECT
                        ***********************************************************************
                        * PREPARE THE RACF CLASS                                              *
                        ***********************************************************************
                        *
                        PREPCLAS DS    0H
                        *
                                 L     R11,CCMDSCD         A(SCD)
                                 USING SCD,R11             SCD BASE REGISTER
                        *
                                 MVC CCMDC(1),CMDCLAS      MAKE THE RACF CLASS
                                 MVC CCMDACID(4),SCDRACID MAKE THE RACF CLASS
                                 MVC CCMDCLSF(3),BLANK3 FILL THE LAST 3 CHARS WITH BLANKS
                        *
                                 DROP R11                  DON′ T NEED THE SCD ANY MORE
                        *
                        ***********************************************************************
                        * HOW TO WE FIND OUT THE USERID                                       *
                        ***********************************************************************
                        *
                        GETUSRID DS    0H
                                 CLI CCMDTYPE,CCMDTRM      WAS IT A TERMINAL REQUEST TYPE ?
                                 BE    RACFTERM            YES, GET USERID/ACEE FOR TERMINAL
                        *
                                 CLI CCMDTYPE,CCMDIUSR WAS IT A REQUEST FROM ICMD / USERID?
                                 BE    RACFICMD            YES, GET USERID FOR ICMD CALL
                        *
                                 CLI CCMDTYPE,CCMDIPRG WAS IT A REQUEST FROM ICMD / PGM ?
                                 BE    RACFICMD            YES, GET USERID FOR ICMD CALL
                        *
                                 CLI CCMDTYPE,CCMDMCS      WAS IT A REQUEST FROM MCS CONSOLE ?
                                 BE    RACFMCS             YES, GET USERID FOR MCS CONSOLE
                        *
                                 B     ERRORRET            NOT VALID, ERROR CONDITION
                        *
                                 EJECT
                        ***********************************************************************
                        * PREPARE THE CTB, TO USE CTBRACFT IN RACROUTE CALL - FOR TERMINALS *
                        ***********************************************************************
                        *
                        RACFTERM EQU *
                        *
                                 L     R11,CCMDCTB         A(CTB)


222   IMS V6 Security Guide
        USING CTB,R11              CTB BASE REGISTER
        L     R10,CTBRACFT         GET THE ACEE
*
         LTR   R10,R10             IS IT A VALID ADDRESS
         BNZ   CTBOK               YES, CONTINUE
*                                  NO, CTBRACFT FIELD WAS ZERO
         CLI   CTBFLAG6,CTB6SREQ   WAS /SIGN REQUIRED
         BZ    ERRORRET            YES, THEN THIS IS AN ERROR SITUATION
*
        B      ALLOW               MUST BE THE MTO, ALLOW IT
*
CTBOK    EQU *
         DROP R11                  DON′ T NEED THE CTB ANY MORE
*
        B      RACFCALL            GO DO RACF CALL
*
         EJECT
***********************************************************************
* ICMD CALL, SO GET ACEE AND PUT POINTER IN R10                       *
***********************************************************************
*
RACFICMD EQU *
*
         BAL R14,GETACEE           GO GET THE RACF ACEE
*
         LTR R10,R10               DID WE GET AN ACEE
         BZ    ERRORRET            NO, ERROR CONDITION
         B     RACFCALL            GO DO RACF CALL
*
***********************************************************************
* MCS/EMCS CALL, SO GET ACEE AND PUT POINTER IN R10                   *
***********************************************************************
*
RACFMCS EQU *
*
         BAL R14,GETACEE           GO GET THE RACF ACEE
*
         LTR R10,R10               DID WE GET AN ACEE
         BZ    ERRORRET            NO, ERROR CONDITION
         B     RACFCALL            GO DO RACF CALL
*
         EJECT
***********************************************************************
* ISSUE RACF CALL, R10 AT THIS POINT CONTAINS ADDRESS OF ACEE         *
***********************************************************************
*
RACFCALL EQU *
*
         LR    R8,R13              SAVE IMS SAVE CHAIN PTR
         LA    R13,SAFSAVE         GET SAF SAVE AREA
*
* COPY STATIC TO DYNAMIC
*
         LA    R0,CCMDCHKL
         LA    R1,CCMDCKSL
         LA    R14,CCMDCHKS
         LR    R15,R1
         MVCL R0,R14
         RACROUTE REQUEST=FASTAUTH,ATTR=READ,ACEE=(R10),CLASS=CCMDCLS, X


                                        Appendix A. IMS Security Exits Examples   223
                                       WORKA=SAFWORK,ENTITY=CCMDCMDP,MF=(E,CCMDCHKL),LOG=ASIS, X
                                       WKAREA=FAWORK,RELEASE=2.1
                                 SPACE
                                 LR    R13,R8              RESTORE IMS SAVE CHAIN PTR
                        *
                                 LTR   R15,R15             IS ACCESS ALLOWED ?
                                 BZ    RACFOK              YES, ALLOW COMMAND
                        *
                                 L     R8,NOACCESS         DENY REQUEST
                                 B     ENDRACF             SAVE FOR LATER USE, AND KEEP GOING
                        *
                        RACFOK   DS    0H                  COMMAND AUTHORIZED
                        *
                                 L     R8,ACCESS           ALLOW REQUEST
                        *
                                 EJECT
                        ***********************************************************************
                        *
                        * IF ICMD OR MCS COMMAND, THEN GO DELETE THE RACF ACEE BEFORE
                        * CONTINUING
                        *
                        ***********************************************************************
                        ENDRACF DS     0H
                        *
                                 CLI CCMDTYPE,CCMDTRM      WAS IT A TERMINAL REQUEST TYPE ?
                                 BE    RACFFREE            YES, CONTINUE NORMALLY
                        *
                        *                                  ANY OTHER TYPE OF COMMAND INPUT,
                        *                                  ASSUMED TO BE ICMD OR MCS.
                        *                                  GO DELETE THE ACEE BEFORE CONTINUING
                        ***********************************************************************
                        *
                        * DELETE THE RACF ACEE
                        * THIS TIME, R11 POINTS TO THE RACF WORKAREA
                        *
                        ***********************************************************************
                        DELACEE EQU *
                        *
                                 MVC WRKRACRP,WRKRD        INIT RACROUTE PARMLIST FOR CREATE
                                 ST    R13,WRKSAVE1        SAVE ADDRESS OF SAVEAREA
                                 LA    R13,WRKRACRS        GET ADDRESS OF RACF SAVEAREA
                        *
                                 RACROUTE REQUEST=VERIFY,ACEE=WRKACEE,ENVIR=DELETE,            X
                                       WORKA=WRKRACRW,MF=(E,WRKRACRP),RELEASE=2.1
                                 L     R13,WRKSAVE1        RESTORE ADDRESS OF SAVEAREA
                        *
                                 B     RACFFREE
                                 EJECT
                        *
                        ***********************************************************************
                        * KEYWORD NOT FOUND, SET RC=0, AND RETURN - ALLOW IMS TO REJECT IT. *
                        ***********************************************************************
                        *
                        NOTFOUND DS    0H
                                 L     R8,ACCESS           ALLOW REQUEST
                                 B     RACFFREE
                                 EJECT
                        *
                        ***********************************************************************


224   IMS V6 Security Guide
* FREE STORAGE, R8 CONTAINS RACF RETURN CODE FOR LATER USE            *
***********************************************************************
*
RACFFREE DS    0H                  COMMAND AUTHORIZATION ON RACF RC
*
         LA    R10,CCMLNTH         PRIME R10 WITH BUFFER LENGTH
         LR    R5,R3               PUT ADDRESS OF STORAGE IN R5
         BAL R7,FREEBUFF           GO AND FREE A BUFFER
         LTR R15,R15               DID WE FREE IT ?
         BNZ ERROROUT              NO, ERROR CONDITION
*
         LR    R15,R8              PUT THE RACF RC BACK TO RETURN WITH
         B     DONE                PROCESSING COMPLETE... GO EXIT
*
***********************************************************************
* FREE STORAGE, WITH EXIT RETURN CODE = ZERO                          *
***********************************************************************
*
ALLOW    DS    0H                  COMMAND AUTHORIZED
*
         LA    R10,CCMLNTH         PRIME R10 WITH BUFFER LENGTH
         LR    R5,R3               PUT ADDRESS OF STORAGE IN R5
         BAL R7,FREEBUFF           GO AND FREE A BUFFER
         LTR R15,R15               DID WE FREE IT ?
         BNZ ERROROUT              NO, ERROR CONDITION
*
         L     R15,ACCESS          ALLOW REQUEST
         B     DONE                PROCESSING COMPLETE... GO EXIT
*
***********************************************************************
* FREE STORAGE, WITH EXIT RETURN CODE = 08 - DENY ACCESS               *
***********************************************************************
*
DENY     DS    0H                  COMMAND DENIED
*
         LA    R10,CCMLNTH         PRIME R10 WITH BUFFER LENGTH
         LR    R5,R3               PUT ADDRESS OF STORAGE IN R5
         BAL R7,FREEBUFF           GO AND FREE A BUFFER
         LTR R15,R15               DID WE FREE IT ?
         BNZ ERROROUT              NO, ERROR CONDITION
*
         L     R15,NOACCESS        DENY REQUEST
         B     DONE                PROCESSING COMPLETE... GO EXIT
*
***********************************************************************
* FREE STORAGE, WITH EXIT RETURN CODE = 10 - ERROR CONDITION          *
***********************************************************************
*
ERRORRET DS    0H                  COMMAND DENIED WITH ERROR CONDITION
*
         LA    R10,CCMLNTH         PRIME R10 WITH BUFFER LENGTH
         LR    R5,R3               PUT ADDRESS OF STORAGE IN R5
         BAL R7,FREEBUFF           GO AND FREE A BUFFER
         LTR R15,R15               DID WE FREE IT ?
         BNZ ERROROUT              NO, ERROR CONDITION
*
         L     R15,ERROR           ERROR OUT
         B     DONE                PROCESSING COMPLETE... GO EXIT
*


                                        Appendix A. IMS Security Exits Examples   225
                                 EJECT
                        ***********************************************************************
                        * RETURN AND ALLOW COMMAND, NO FREE MAIN NECESSARY, WAS WTOR          *
                        ***********************************************************************
                        *
                        ALLOWTOR EQU *
                        *
                                 L     R15,ACCESS          ALLOW REQUEST
                                 B     DONE                GET OUT
                        *
                        ***********************************************************************
                        * SET RETURN CODE TO DENY ACCESS, NO FREE MAIN NECESSARY              *
                        ***********************************************************************
                        *
                        REJECT EQU     *
                        *
                                 L     R15,NOACCESS        DENY REQUEST
                                 B     DONE                GET OUT
                        *
                        ***********************************************************************
                        * SET RETURN CODE TO AN ERROR CONDITION, NO FREEMAIN NECESSARY        *
                        ***********************************************************************
                        *
                        ERROROUT EQU *
                        *
                                 L     R15,ERROR           ERROR OUT
                                 B     DONE                GET OUT
                        *
                        ***********************************************************************
                        * GETOUT
                        ***********************************************************************
                        *
                        DONE     EQU *
                        *
                                 L      R13,4(,R13)        GET PREVIOUS SAVE LEVEL
                                 RETURN (14,12),,RC=(15) RETURN WITH RETURN CODE IN R15
                        *
                                 EJECT
                        ***********************************************************************
                        * GETACEE - USERID AVAILABLE IN CCMDUSER, ACEE PUT INTO R10           *
                        ***********************************************************************
                        *
                        GETACEE EQU *
                        *
                                 ST    R14,SAVER14        STORE RETURN ADDRESS FOR LATER
                        *
                                 MVC WRKRACRP,WRKRC       INIT RACROUTE PARMLIST FOR CREATE
                        *
                                 ST    R13,WRKSAVE1       SAVE ADDRESS OF SAVEAREA
                                 LA    R13,WRKRACRS       GET ADDRESS OF RACF SAVEAREA
                        *
                        ***********************************************************************
                        * GET LENGTH OF USERID, AND PUT IN FRONT OF USERID, FOR RACROUTE CALL *
                        * TELSTRA RULES HAVE USERIDS A MINIMUM OF 7 CHARACTERS, SO ONLY HAVE *
                        * TO CHECK IF IT IS SEVEN OR EIGHT.                                   *
                        ***********************************************************************
                                 L     R7,CCMDUSER        GET ADDRESS OF USERID




226   IMS V6 Security Guide
         MVC WRKUSERN(8),0(R7) MOVE USERID INTO WORKAREA
*
CHECK8TH CLI WRKUSERN+7,X′40′     IS THE 8TH CHARACTER A BLANK ?
         BE    CHECK7TH           YES, CHECK AGAIN
         LH    R1,EIGHT           NO, LENGTH = 8
         B     GOTLEN
*
CHECK7TH CLI WRKUSERN+6,X′40′     IS THE 7TH CHARACTER A BLANK ?         07702500
         BE    INVALUSR           YES, USERID TOO SHORT
         LH    R1,SEVEN           NO, LENGTH = 7
         B     GOTLEN
*
INVALUSR DS    0H
         L     R14,SAVER14        RESTORE RETURN ADDRESS FOR LATER
         B     ERRORRET           GETOUT WITH ERROR
*
GOTLEN DS      0H
         STC R1,WRKUSERL          SET L(USER ID) INTO WORK AREA
*
***********************************************************************
* ISSUE RACROUTE CALL TO GET ACEE                                     *
***********************************************************************
*
         RACROUTE REQUEST=VERIFY,ACEE=WRKACEE,ENVIR=CREATE,            X
               WORKA=WRKRACRW,PASSCHK=NO,USERID=WRKUSER,               X
               MF=(E,WRKRACRP),RELEASE=2.1
*
         LTR R15,R15              DID WE GET THE ACEE
         BZ    VEROK              YES, OK
*                                 NO, HANDLE ERROR CONDITION
         L     R14,SAVER14        RESTORE RETURN ADDRESS FOR LATER
         B     ERRORRET           GET OUT WITH ERROR
*
VEROK    DS    0H
*
         L     R13,WRKSAVE1       RESTORE ADDRESS OF SAVEAREA
         L     R10,WRKACEE        GET ADDRESS OF ACEE
*
         L     R14,SAVER14        RESTORE RETURN ADDRESS FOR LATER
*
         BR    R14
*
         EJECT
*********************************************************************** 14330070
*                                                                     * 14330100
* THIS ROUTINE WAS BASED ON SUBROUTINE SCANKTAB IN DFSICL30           * 14330100
*                                                                     * 14330100
* -------                                                             * 14330200
* SCANKWDT - SUBROUTINE TO SCAN THE KEYWORD TABLE TO CHECK IF         * 14330280
* -------     THE CURRENT TOKEN IS A KEYWORD.                         * 14330300
*                                                                     * 14330400
*      INPUT:                                                         * 14330490
*                                                                     * 14330500
*         R7 - RETURN ADDRESS                                         * 14330600
*         CALNAME - CONTAINS THE CURRENT TOKEN                        * 14330650
*                                                                     * 14330700
*      OUTPUT:                                                        * 14330780
*                                                                     * 14330800
*         CALFND - BIT CALKFND IS SET TO INDICATE KEYWORD FOUND       * 14330900


                                        Appendix A. IMS Security Exits Examples   227
                        *         CALKADDR - ADDR OF LAST KEYWORD FOUND                       *   14330990
                        *         CALTOKEN - SET TO INDICATE CURRENT TOKEN IS KWD OR NULL KWD *   14330993
                        *         CALKABBR - INTERNAL ABBREVIATION OF KEYWORD                 *   14330996
                        *                                                                     *   14331000
                        *      REGISTERS DESTROYED : R8,R9                                    *   14331100
                        *                                                                     *   14331200
                        ***********************************************************************   14331270
                        SCANKWDT DS    0H                                                         14331300
                                 L     R11,CCMDSCD         A(SCD)
                                 USING SCD,R11
                                 L     R8,SCDCKWD0         GET PTR TO KEYWORD TABLE               14331400
                                 DROP R11                  NO LONGER NEED SCD
                        SCANK100 DS    0H                                                         14331490
                                 LA    R9,KWDHDRL          GET HEADER LENGTH                      14331500
                                 AR    R9,R8               POINT TO FIRST KEYWORD      @BIP6EAV   14331600
                        SCANK200 DS    0H                                              @BIP6EAV   14331700
                                 CLC 0(2,R9),=X′ FEFE′     IS IT POINT TO HEADER       @BIP6EAV   14331770
                                 BE    SCANK300              YES, END OF SYNONYMS      @BIP6EAV   14331800
                                 CLC 0(3,R9),=X′ FFFFFF′ IS IT END OF TABLE ?          @BIP6EAV   14331900
                                 BE    SCANK500            YES, GO OUT                 @BIP6EAV   14331980
                                 USING KWDNTRY,R9                                      @BIP6EAV   14332000
                                 CLC CALNAME,KWDNAME       IS TOKEN SAME AS KEYWORD    @BIP6EAV   14332100
                                 BE    SCANK400            YES, SET BITS & EXIT LOOP @BIP6EAV     14332200
                                 LA    R0,KWDNTRYL         NO, GET LENGTH OF KWD ENTRY @BIP6EAV   14332270
                                 AR    R9,R0               UPDATE TO NEXT SYN          @BIP6EAV   14332300
                                 B     SCANK200             GO CHECK IF SYN            @BIP6EAV   14332400
                        SCANK300 DS    0H                                              @BIP6EAV   14332480
                                 LR    R8,R9               UPDATE TO NEXT KEYWORD      @BIP6EAV   14332500
                                 B     SCANK100            CHECK NEXT KEYWORD          @BIP6EAV   14332600
                        SCANK400 DS    0H                                              @BIP6EAV   14332690
                                 ST    R8,CALKADDR         YES, SAVE KEYWORD POINTER @BIP6EAV     14332700
                                 MVC CALKABBR,KWDABBR                                  @BIP6EAV   14332800
                                 OI    CALFND,CALKFND      SET KEYWORD FOUND FLAG      @BIP6EAV   14332900
                                 OI    CALFND,CALLKFND     SET LAST KWD FOUND FLAG     @BIP6EAV   14332980
                                 OI    CALTOKEN,CALKEY     INDICATE CURR TOKEN IS KWD @BIP6EAV    14333000
                        SCANK500 DS    0H                                              @BIP6EAV   14333100
                                 BR    R7                                              @BIP6EAV   14333190
                                 DROP R9                                               @BIP6EAV   14333200
                                 EJECT                                                 @BIP6EAV   14333300
                        ***********************************************************************
                        *                                                                     *
                        *    SUBROUTINE TO INVOKE IMS CALLABLE SERVICES TO GET STORAGE        *
                        *                                                                     *
                        *    ENTRY                                                            *
                        *        R7 -- RETURN ADDRESS                                         *
                        *        R8 -- LENGTH                                                 *
                        *                                                                     *
                        *    EXIT                                                             *
                        *        R3 -- ADDRESS OF OBTAINED STORAGE                            *
                        *        R15 -- RETURN CODE                                           *
                        *                  00 ---- SUCCESSFULLY GOT STORAGE                   *
                        *                  OTHERWISE, UNABLE TO GET STORAGE                   *
                        *                                                                     *
                        *        R0, R1, R2 & R4 ARE DESTROYED                                *
                        *                                                                     *
                        ***********************************************************************
                        GETBUFF DS     0H
                                 SPACE 2
                        ***********************************************************************


228   IMS V6 Security Guide
*        GET CALLABLE SERVICE INTERFACE TOKEN                         *
***********************************************************************
         L     R1,CCMDECB          LOAD A(ECB)
         CALL DFSCSII0            CSI INIT ENTRY
         SPACE 2
         LTR R15,R15              INIT SUCCESSFUL ?
         BNZ GETBUFFE             NO, GO RETURN
         SPACE 2
*                                 R1 -- PARM LIST
         L     R2,0(,R1)          R2 -- CALLABLE SERVICE TOKE
         LA    R3,CSICLLEN(,R1) R3 -- CALLABLE SERVICE PARM
         LA    R4,CSPLPLEN(,R3) R4 -- STORAGE PARM LIST
         SPACE 2
***********************************************************************
*        INITIALIZE CALLABLE SERVICE PARAMETER LIST                   *
***********************************************************************
         USING CSPARMS,R3
         XC    CSPARMS(CSPLPLEN),CSPARMS    CLEAR CS LIST
         LA    R0,CSPLSTRG        STORAGE SERVICE
         ST    R0,CSPLSERV        SET SERVICE CODE
         ST    R2,CSPLTOKN        SET CS TOKEN
         SPACE 3
***********************************************************************
*        INITIALIZE STORAGE SERVICE PARAMETER LIST                    *
*        TO OBTAIN 31-BIT, PRIVATE STORAGE IN SUBPOOL 0               *
*        ON A DOUBLEWORD BOUNDARY                                     *
***********************************************************************
         USING CSSTRG,4
         XC    CSSTRG(CSGTPLEN),CSSTRG      CLEAR STORAGE LIST
         LA    R0,CSSTGET         FUNCTION CODE = GET STORAGE
         ST    R0,CSSTFUNC        SET FUNCTION CODE
         SPACE 2
         ST    R8,CSGTLEN         SET STORAGE LENGTH
         SPACE 2
***********************************************************************
*        INVOKE CALLABLE SERVICE TO OBTAIN STORAGE                    *
***********************************************************************
         CALL DFSCSIF0,((R3),(R4)),MF=(E,(R1))
         SPACE 2
         LTR R15,R15              STORAGE OBTAINED ?
         BNZ GETBUFFF             NO, GO RETURN
         SPACE 2
*
***********************************************************************
* GETBUFF COMMON EXIT POINT                                           *
***********************************************************************
         L     R3,CSGTADDR        STORAGE ADDRESS
         DROP R3
         DROP R4
         BR    R7                 RETURN TO CALLER
         SPACE 2
***********************************************************************
* GETBUFF ERROR EXIT POINT                                            *
***********************************************************************
GETBUFFE DS    0H
         B     ERROROUT           RETURN TO CALLER
***********************************************************************
* GETBUFF ERROR EXIT POINT                                            *



                                        Appendix A. IMS Security Exits Examples   229
                        ***********************************************************************
                        GETBUFFF DS    0H
                                 B     ERROROUT           RETURN TO CALLER
                                 EJECT
                        ***********************************************************************
                        *
                        *    SUBROUTINE TO INVOKE IMS CALLABLE SERVICES TO FREE STORAGE
                        *
                        *    ENTRY
                        *        R5 -- ADDR(STORAGE)
                        *        R7 -- RETURN ADDRESS
                        *        R10 -- LENGTH OF STORAGE
                        *
                        *    EXIT
                        *        R15 -- RETURN CODE
                        *                  00 ---- SUCCESSFULLY FREED STORAGE
                        *                  OTHERWISE, UNABLE TO FREE STORAGE
                        *
                        *        R0, R1, R2, R3 & R4 ARE DESTROYED
                        *
                        ***********************************************************************
                        FREEBUFF DS    0H
                                 SPACE 2
                        ***********************************************************************
                        *        GET CALLABLE SERVICE INTERFACE TOKEN                         *
                        ***********************************************************************
                                 L     R1,CCMDECB          LOAD A(ECB)
                                 CALL DFSCSII0            CSI INIT ENTRY
                                 SPACE 2
                                 LTR R15,R15              INIT SUCCESSFUL ?
                                 BNZ FREEBUFE             NO, GO RETURN
                                 SPACE 2
                        *                                 R1 -- PARM LIST
                                 L     R2,0(,R1)          R2 -- CALLABLE SERVICE TOKE
                                 LA    R3,CSICLLEN(,R1) R3 -- CALLABLE SERVICE PARM
                                 LA    R4,CSPLPLEN(,R3) R4 -- STORAGE PARM LIST
                                 SPACE 2
                        ***********************************************************************
                        *        INITIALIZE CALLABLE SERVICE PARAMETER LIST                   *
                        ***********************************************************************
                                 USING CSPARMS,R3
                                 XC    CSPARMS(CSPLPLEN),CSPARMS    CLEAR CS LIST
                                 LA    R0,CSPLSTRG        STORAGE SERVICE
                                 ST    R0,CSPLSERV        SET SERVICE CODE
                                 ST    R2,CSPLTOKN        SET CS TOKEN
                                 SPACE 4
                        ***********************************************************************
                        *        INITIALIZE STORAGE SERVICE PARAMETER LIST                    *
                        *        TO FREE PRIVATE STORAGE IN SUBPOOL 0                         *
                        ***********************************************************************
                                 USING CSSTRG,R4
                                 XC    CSSTRG(CSGTPLEN),CSSTRG      CLEAR STORAGE LIST
                                 LA    R0,CSSTFREE        FUNCTION CODE = FREE STORAGE
                                 ST    R0,CSSTFUNC        SET FUNCTION CODE
                                 SPACE 2
                                 ST    R5,CSFRSTAD        SET STORAGE ADDRESS
                                 SPACE 2
                                 ST    R10,CSFRLEN        SET STORAGE LENGTH



230   IMS V6 Security Guide
         SPACE 2
***********************************************************************
*        INVOKE CALLABLE SERVICE TO FREE STORAGE                         *
***********************************************************************
         CALL DFSCSIF0,((R3),(R4)),MF=(E,(R1))
         SPACE 2
         LTR R15,R15                  STORAGE FREED ?
         BNZ FREEBUFE                 NO, GO RETURN
         SPACE 2
***********************************************************************
* FREEBUFF COMMON EXIT POINT                                             *
***********************************************************************
         DROP R3
         DROP R4
         BR    R7                     RETURN TO CALLER
         SPACE 2
***********************************************************************
* FREEBUFF ERROR EXIT POINT                                              *
***********************************************************************
FREEBUFE DS    0H
         B     ERROROUT               RETURN TO CALLER
         EJECT
         LTORG ,
***********************************************************************
* EXECUTE STATEMENTS                                                     *
***********************************************************************
*
EXSRCH TRT 0(0,R5),TRTALPHA EXECUTE STMT TO SEARCH TABLE
EXCONV TR      0(0,R5),LWRUPPR        CONVERT TO UPPER CASE
*
***********************************************************************
* LOCAL EQUATES AND DATA AREAS                                           *
***********************************************************************
*
ONE      DC    H′ 1 ′
FOUR     DC    H′ 4 ′
SEVEN    DC    H′ 7 ′
EIGHT    DC    H′ 8 ′
DOLLAR DC      CL1′ $′                $ - FIRST CHARACTER OF PROFILE
BLANK1 DC      CL1′ ′                 1 CHARACTERS OF BLANKS
BLANK3 DC      CL3′       ′           3 CHARACTERS OF BLANKS
BLANK13 DC     CL13′                 ′ 13 CHARACTERS OF BLANKS
NRE      DC    CL3′ NRE′              INDICATING AN NRE
ERE      DC    CL3′ ERE′              INDICATING AN ERE
NUL      DC    CL3′ NUL′              ″NUL″ RETURN FROM DFSCKWD0
*
***********************************************************************
* VALUE INDICATING NO PRIOR SECURITY CHECK FOR COMMAND                   *
***********************************************************************
*
ACCESS DC      0F′ 0 ′ , X′00000000′ COMMAND WAS PREVIOUSLY AUTHORIZED
NOACCESS DC    0F′ 0 ′ , X′00000008′ COMMAND WAS PREVIOUSLY UNAUTHORIZED
ERROR    DC    0F′ 0 ′ , X′00000010′ GETMAIN/FREEMAIN FAILURE
NOSECURE DC    0F′ 0 ′ , X′80000000′ NO PRIOR RACF OR SMU CHECKING
*
***********************************************************************
* VALUE INDICATING THE FIRST DIGIT OF THE RACF CLASS NAME                *
***********************************************************************
*


                                         Appendix A. IMS Security Exits Examples   231
                        CMDCLAS DC     CL1′ C′             C - BEGINNING OF THE RACF CLASS NAME
                        *
                                       EJECT
                        ***********************************************************************
                        * ALPHANUMERIC TRANSLATE AND TEST TABLE, COPIED FROM PRINCIPAL OF         *
                        *                                                 OPERATIONS MANUAL       *
                        *                                                                         *
                        * THE OFFSET MATCHES THE EBCDIC CODE FOR CHARACTERS (IE. C1 IS ′ A′ ) *
                        *                                                                         *
                        * ALL LETTERS ARE MAPPED TO ′ 0 0 ′ , SO TRT COMMAND IGNORES THEM.        *
                        *                                                                         *
                        * SPACES ARE THE ONLY CHARACTERS THAT REQUIRE SPECIAL ATTENTION,          *
                        * AND ARE MAPPED TO ′ 0 4 ′ , SO TRT CAN HANDLE THEM PROPERLY.            *
                        *                                                                         *
                        * ALL NUMBERS ARE MAPPED TO ′ 0 8 ′ , SO TRT HANDLES THEM AS AN ERROR     *
                        * EVERYTHING ELSE IS MAPPED TO ′ 0 8 ′ , SO TRT HANDLES THEM AS AN ERROR. *
                        *                                                                         *
                        ***********************************************************************
                        *
                        TRTALPHA DC    256X′ 0 8 ′
                                 ORG TRTALPHA+C′ ′
                                 DC    X′ 0 4 ′
                                 ORG TRTALPHA+C′ , ′
                                 DC    X′ 0 4 ′
                                 ORG TRTALPHA+C′ = ′
                                 DC    X′ 0 4 ′
                                 ORG TRTALPHA+C′ A′
                                 DC    X′ 0 0 ′
                                 ORG TRTALPHA+C′ B′
                                 DC    X′ 0 0 ′
                                 ORG TRTALPHA+C′ C′
                                 DC    X′ 0 0 ′
                                 ORG TRTALPHA+C′ D′
                                 DC    X′ 0 0 ′
                                 ORG TRTALPHA+C′ E′
                                 DC    X′ 0 0 ′
                                 ORG TRTALPHA+C′ F′
                                 DC    X′ 0 0 ′
                                 ORG TRTALPHA+C′ G′
                                 DC    X′ 0 0 ′
                                 ORG TRTALPHA+C′ H′
                                 DC    X′ 0 0 ′
                                 ORG TRTALPHA+C′ I′
                                 DC    X′ 0 0 ′
                                 ORG TRTALPHA+C′ J′
                                 DC    X′ 0 0 ′
                                 ORG TRTALPHA+C′ K′
                                 DC    X′ 0 0 ′
                                 ORG TRTALPHA+C′ L′
                                 DC    X′ 0 0 ′
                                 ORG TRTALPHA+C′ M′
                                 DC    X′ 0 0 ′
                                 ORG TRTALPHA+C′ N′
                                 DC    X′ 0 0 ′
                                 ORG TRTALPHA+C′ O′
                                 DC    X′ 0 0 ′
                                 ORG TRTALPHA+C′ P′
                                 DC    X′ 0 0 ′
                                 ORG TRTALPHA+C′ Q′


232   IMS V6 Security Guide
         DC    X′ 0 0 ′
         ORG   TRTALPHA+C′ R′
         DC    X′ 0 0 ′
         ORG   TRTALPHA+C′ S′
         DC    X′ 0 0 ′
         ORG   TRTALPHA+C′ T′
         DC    X′ 0 0 ′
         ORG   TRTALPHA+C′ U′
         DC    X′ 0 0 ′
         ORG   TRTALPHA+C′ V′
         DC    X′ 0 0 ′
         ORG   TRTALPHA+C′ W′
         DC    X′ 0 0 ′
         ORG   TRTALPHA+C′ X′
         DC    X′ 0 0 ′
         ORG   TRTALPHA+C′ Y′
         DC    X′ 0 0 ′
         ORG   TRTALPHA+C′ Z′
         DC    X′ 0 0 ′
*        ORG   TRTALPHA+C′ ( ′
*        DC    X′ 0 0 ′
*        ORG   TRTALPHA+C′ ) ′
*        DC    X′ 0 0 ′
*
***********************************************************************
* TRANSLATE TABLE TO CONVERT LOWER CASE TO UPPER CASE                 *
*                                                                     *
* THE OFFSET MATCHES THE EBCDIC CODE FOR CHARACTERS (IE. C1 IS ′ A′ ) *
*                                                                     *
* EVERYTHING IS MAPPED TO BLANKS, EXCEPT THE LOWER CASE LETTERS, WHICH*
* ARE MAPPED TO THEIR UPPER CASE EQUIVALENT.                          *
*                                                                     *
* THE EQUALS, COMMA AND QUOTE CHARACTERS ARE ALSO NOT ALTERED AS THEY *
* ARE ALSO VALID COMMAND INPUT / DELIMITERS                           *
*                                                                     *
* ACCORDING TO DFSICL30, THE FOLLOWING CHARACTERS ARE ALSO VALID AS *
* INPUT, AND HENCE LEFT AS IS :                                       *
*       (,),*,%,#,@,$,.                                               *
*                                                                     *
***********************************************************************
*
LWRUPPR DC     CL256′ ′
         ORG LWRUPPR+X′ 8 1 ′      TRANSLATE LOWER CASE TO UPPER
         DC    C′ ABCDEFGHI′
         ORG LWRUPPR+X′ 9 1 ′      ...
         DC    C′ JKLMNOPQR′
         ORG LWRUPPR+X′ A2′        ...
         DC    C′ STUVWXYZ ′
         ORG LWRUPPR+X′ C1′        KEEP UPPER CASE AS IS
         DC    C′ ABCDEFGHI′
         ORG LWRUPPR+X′ D1′        ...
         DC    C′ JKLMNOPQR′
         ORG LWRUPPR+X′ E2′        ...
         DC    C′ STUVWXYZ′
         ORG LWRUPPR+X′ F0′        KEEP NUMERICS AS IS
         DC    C′0123456789′
         ORG LWRUPPR+C′ , ′        KEEP ′ , ′ AS IS
         DC    C′ , ′
         ORG LWRUPPR+X′ 7D′        KEEP QUOTE AS IS


                                        Appendix A. IMS Security Exits Examples   233
                                 DC    X′ 7D′
                                 ORG   LWRUPPR+C′ = ′     KEEP ′=′ AS IS
                                 DC    C′ = ′
                                 ORG   LWRUPPR+C′ ( ′     KEEP ′ ( ′ AS IS
                                 DC    C′ ( ′
                                 ORG   LWRUPPR+C′ ) ′     KEEP ′ ) ′ AS IS
                                 DC    C′ ) ′
                                 ORG   LWRUPPR+C′ *′      KEEP ′ *′ AS IS
                                 DC    C′ *′
                                 ORG   LWRUPPR+C′%′       KEEP ′%′ AS IS
                                 DC    C′%′
                                 ORG   LWRUPPR+C′ # ′     KEEP ′ # ′ AS IS
                                 DC    C′ # ′
                                 ORG   LWRUPPR+C′ @′      KEEP ′ @′ AS IS
                                 DC    C′ @′
                                 ORG   LWRUPPR+C′ $′      KEEP ′ $′ AS IS
                                 DC    C′ $′
                                 ORG   LWRUPPR+C′ . ′     KEEP ′ . ′ AS IS
                                 DC    C′ . ′
                                 ORG
                        *
                                 EJECT
                        ***********************************************************************
                        * PARMLIST FOR RACROUTE FASTAUTH    FUNCTION CALL                     *
                        ***********************************************************************
                        *
                        CCMDCHKS RACROUTE REQUEST=FASTAUTH,MF=L,RELEASE=2.1
                        CCMDCKSL EQU *-CCMDCHKS
                        ***********************************************************************
                        * PARMLIST FOR RACROUTE CREATE ACEE FUNCTION CALL                     *
                        ***********************************************************************
                        *
                        WRKRC    RACROUTE REQUEST=VERIFY,ENVIR=CREATE,MF=L,RELEASE=2.1
                        WRKRCLNG EQU *-WRKRC
                        *
                        ***********************************************************************
                        * PARMLIST FOR RACROUTE DELETE ACEE FUNCTION CALL                     *
                        ***********************************************************************
                        *
                        WRKRD    RACROUTE REQUEST=VERIFY,ENVIR=DELETE,MF=L,RELEASE=2.1
                        WRKRDLNG EQU *-WRKRD
                        *
                                 EJECT
                        *
                        ***********************************************************************
                        * DSECT TO MAP THE DFSCCMD0 SPECIFIC PARMLIST                         *
                        * AS DEFINED IN THE IMS CUSTOMIZATION GUIDE                           *
                        ***********************************************************************
                        *
                        DFSCCMD DSECT
                        CCMDECB DC     A(0)                POINTER TO CLB OR PST
                        CCMDSCD DC     A(0)                POINTER TO SCD
                        CCMDUSTB DC    A(0)                POINTER TO USER TABLE
                        CCMDUSER DC    A(0)                POINTER TO USER ID
                        CCMDCVB DC     A(0)                POINTER TO CVB
                        CCMDRETC DC    A(0)                SECURITY RETURN CODE ON ENTRY
                        CCMDCTB DC     A(0)                POINTER TO CTB
                        CCMDCMD DC     A(0)                POINTER TO COMMAND INPUT



234   IMS V6 Security Guide
         DS    CL2                 RESERVED FOR FUTURE USE
CCMDRR DS      CL1                 RACROUTE CALL ALREADY MADE
CCMDTYPE DS    CL1                 REQUEST TYPE
CCMDICMD DC    A(0)                POINTER TO ICMD CALL INFO
DFSCCMDL EQU *-DFSCCMD             LENGTH OF DSECT
*
***********************************************************************
* DSECT TO MAP THE STORAGE USED BY RACF CHECKING                       *
***********************************************************************
*
CCMD0    DSECT
CCMDCLS DS     0CL8                CLASS FOR RACF
CCMDC    DC    CL1′ ′              THE FIRST CHARACTER
CCMDACID DC    CL4′      ′         THE IMSID
CCMDCLSF DC    CL3′    ′           THE LAST 3 CHARACTERS, ALWAYS BLANKS
         SPACE
CCMDCMDP DS    0CL8                CMD/PARAMETER FOR RACF VALIDATION
COMMAND$ DC    CL1′ $′             FIRST CHAR, ALWAYS ′ $′ TO BE UNIQUE
COMMAND DC     CL3′    ′           FIRST 3 CHARS OF CMD
COMMANDP DC    CL3′    ′           FIRST 3 CHARS OF CMD PARAMETER
COMMANDF DC    CL1′ ′              LAST 1 CHARACTERS, ALWAYS BLANKS
         SPACE
CCMDCHKL RACROUTE REQUEST=FASTAUTH,CLASS=CCMDCLS,MF=L,RELEASE=2.1
         SPACE
FAWORK DS      CL64
SAFWORK DS     CL512
SAFSAVE DS     18F                 SAVE AREA FOR SAF
SAVER14 DC     A(0)                STORAGE TO SAVE R14 INTO
*
***********************************************************************
* PART OF DSECT TO MAP THE STORAGE USED BY RACF BUILD/DELETE ACEE      *
***********************************************************************
*
WRKUSER DS     0CL9                USERID
WRKUSERL DS    X                   USERID LENGTH
WRKUSERN DS    CL8                 USERID VALUE
WRKACEE DS     F                   ADDRESS OF ACEE
WRKSAVE1 DS    F                   SAVEAREA FOR R13 RET ADDRESS
WRKSAVE2 DS    F                   TEMPORARY SAVEAREA
WRKRACRW DS    512X                RACROUTE WORKAREA
WRKRACRS DS    18F                 RACROUTE SAVEAREA
WRKRACRP DS    XL(WRKRCLNG)        RACROUTE PARMLIST
*
***********************************************************************
* PART OF DSECT TO MAP THE COMMAND KEYWORD TABLE USAGE                 *
***********************************************************************
*
CALNAME DS     CL13                WORKAREA FOR CALNAME
CALKADDR DS    F                   ADDRESS OF LAST KEYWORD FND
CALFND DS      C                   KEYWORD FOUND INDIATOR
CALKFND EQU X′ 8 0 ′               KEYWORD FOUND
CALLKFND EQU X′ 4 0 ′              LAST KEYWORD FOUND
CALTOKEN DS    C                   CURRENT TOKEN FLAG
CALKEY EQU X′ 8 0 ′                CURRENT TOKEN IS KEYWORD
CALPARM EQU X′ 4 0 ′               CURRENT TOKEN IS PARAMETER
CALKABBR DS    CL3                 CURRENT KEYWORD ABBREVIATION
*
CCMLNTH EQU *-CCMD0                LENGTH OF DSECT
*


                                        Appendix A. IMS Security Exits Examples   235
                        ***********************************************************************
                        * DSECT TO MAP THE COMMAND STRING                                     *
                        ***********************************************************************
                        *
                        CMDBUFF DSECT
                        CMDLL    DS    H                   LENGTH FIELD
                        CMDZZ    DS    H                   RESERVED
                        CMDDATA DS     0CL1                BEGINNING OF COMMAND DATA
                        *
                        ***********************************************************************
                        * DSECT TO MAP THE COMMAND KEYWORD                                    *
                        ***********************************************************************
                        *
                        CMDKEYWD DSECT
                                 DS    0CL1                BEGINNING OF COMMAND DATA
                        *
                        ***********************************************************************
                        * REGISTER EQUATES                                                    *
                        ***********************************************************************
                        *
                        CCMDTRM EQU 1                      REQUEST TYPE=TERMINAL (NOT LU6.2)
                        CCMDLU6 EQU 2                      REQUEST TYPE=LU6.2 TERMINAL
                        CCMDIUSR EQU 3                     REQUEST TYPE=ICMD FOR USERID
                        CCMDIPRG EQU 4                     REQUEST TYPE=ICMD FOR PROGRAM
                        CCMDMCS EQU 6                      REQUEST TYPE=MCS ENTERED CMD
                        *
                                 EJECT
                        *
                                 PRINT NOGEN
                                 REQUATE E=NO
                                 PRINT GEN
                        *
                        ***********************************************************************
                        * CONTROL BLOCK DSECTS                                                *
                        ***********************************************************************
                        *
                                 GBLC &SUBPARM(20)
                        *
                                 PRINT NOGEN
                                 DFSCSIPL
                                 DFSCMDVB
                                 DFSCMDKW
                                 ICLI CTBBASE=0,CTTBASE=0,CLBBASE=0
                                 ISCD
                                 IPST
                                 END




236   IMS V6 Security Guide
A.3 Security Reverification Exit (DFSCTSE0)
                DFSCTSE0 is the final decision maker to authorize or take authorization away
                from a transaction.



                         TITLE ′ SECURITY REVERIFICATION′                                     01470100
                ***********************************************************************       01470300
                *                                                                      *      01470500
                * MODULE NAME: DFSCTSE0                                                *      01470700
                *                                                                      *      01470900
                * DESCRIPTIVE NAME: SECURITY REVERIFICATION EXIT                       *      01471000
                *                                                                      *      01471300
                * COPYRIGHT: REFER TO MODULE DFSAADC0                                  *      01471500
                *                                                                      *      01471700
                * STATUS: VERSION 1.3                                                  *      01471900
                *                                                                      *      01472000
                * FUNCTION:                                                            *      01472300
                *                                                                      *      01472500
                *    THIS EXIT ROUTINE IS CALLED BY DFSCAUT0 OR DFSDAUT0 EITHER WITH A*       01472700
                *    A RACF PRODUCT OR WHEN, WITH RACF, THE TRANSACTION AUTHORIZATION *       01472750
                *    FAILED. DFSCTSE0 WILL ALLOW USER TO REEVALUATE THEIR              *      01472800
                *    TRANSATION AUTHORIZATION CHECKING ON A DLI CHANGE CALL, @PL30138         01472850
                *    OR DLI AUTH CALL TO REEVALUATE IF A USER HAS ACCESS TO     @PL30138      01472860
                *    A SET OF APPLICATION DEFINED RESOURCES.                    @PL30138      01472870
                *                                                                      *      01472900
                * NOTES:                                                               *      01473000
                * FOR AUTH CALL, IF SMF LOGGING IS REQUESTED, AND THIS EXIT @PL30138          01473007
                * IS CALLED, THE USER EXIT IS RESPONSIBLE FOR SMF LOGGING OF @PL30138         01473014
                * THE SECURITY ERROR IF THE SOURCE TERMINAL IS NOT PRESENT. @PL30138          01473021
                * THE RETURN CODE FROM THE PRIOR FUNCTION IS PROVIDED TO        @PL30138      01473028
                * THIS EXIT IN REG3 AT ENTRY. THE PRESERVATION OF THIS          @PL30138      01473035
                * RETURN CODE IS THE RESPONSIBILITY OF DFSCTSE0. IF             @PL30138      01473042
                * DFSCTSE0 DOES NOT PROVIDE A UNIQUE RETURN CODE, IT IS THE @PL30138          01473049
                * RESPONSIBILITY OF DFSCTSE0 TO PROPAGATE THE RETURN CODE OF @PL30138         01473056
                * THE PRIOR FUNCTION IN REG15 UPON RETURN TO DFSCAUT0 OR                      01473063
                * DFSDAUT0.                                                                   01473067
                *                                                               @PL30138      01473070
                *AFTER COMPLETION OF EXIT PROCESSING, THE RETURN CODE PROVIDED @PL30138       01473077
                *BY THE LAST EXIT ENTERED IS STORED IN THE EXITRC FIELD OF THE @PL30138       01473084
                *I/O AREA. AFTER COMPLETION OF THE EXITS, DFSCAUT0/DAUT0 WILL          *      01473091
                *CONTINUE TO PROCESS THE AUTH CALL. IF EITHER OF THE EXITS      @PL30138      01473098
                *PROVIDE EXIT USERDATA, IT WILL BE PROVIDED IN THE I/O AREA     @PL30138      01473105
                *EVEN IF NOT REQUESTED. THE STATUS FIELD IS UPDATED TO          @PL30138      01473112
                *INDICATE THE PRESENCE OF THE USERDATA. IF THE EXITS DO NOT @PL30138          01473119
                *PROVIDE USERDATA, THE PARM LIST WILL BE EXAMINED TO DETERMINE @PL30138       01473126
                *IF USERDATA HAS BEEN REQUESTED. IF IT WAS REQUESTED, AND THE          *      01473133
                *CALLER WAS DFSDAUT0, THE RACF ACEE WILL BE AVAILABLE. IF THE          *      01473137
                *CALLER WAS DFSCAUT0, A CHECK WILL BE MADE TO SEE IF THE CURRENT       *      01473140
                *TABLE IS MARKED AS ″SIGNED ON″. IF SIGNED ON THEN THE USERID          *      01473147
                *IN THE CTB IS COMPARED WITH THE USERID IN THE TRANSACTION.            *      01473154
                *IF TERMINAL IS NOT ON OR ID′ S DO NOT MATCH, THE STATUS IN THE        *      01473161
                *WORK AREA IS UPDATED TO INDICATE THIS. IF THE CURRENT USER            *      01473168
                *IS SIGNED ON, THEN THE RACF ACEE WILL BE AVAILABLE. THE               *      01473172
                *RACF ACEE IS CHECKED IF INSTALLATION DATA IS PRESENT IN AN ACEE       *      01473175
                *FOR THE USER. IF PRESENT, IT WILL BE MOVED TO THE WORK AREA @PL30138         01473182
                *AND THE STATUS FIELD UPDATED IF NOT, THE STATUS FIELD WILL @PL30138          01473189
                *INDICATE NO INSTALLATION DATA PRESENT. THIS ENDS DFSCAUT0             *      01473196


                                                        Appendix A. IMS Security Exits Examples   237
                        *OR DFSDAUT0, AND RETURN IS MADE TO DFSDLA30 WITH THE PROPER          *   01473203
                        *RETURN CODE.                                                         *   01473207
                        *                                                              @PL30138   01473210
                        * TO IMPLEMENT:                                                @PL30138   01473217
                        *        USERS OF RACF WILL HAVE TO ADD NEW CLASSES TO THE     @PL30138   01473224
                        *RACF CLASS DESCRIPTOR TABLES. IN ADDITION, RACF EXITS         @PL30138   01473231
                        *DFSCTRN0 AND DFSCTSE0 WILL HAVE TO BE MODIFIED TO UNDERSTAND @PL30138    01473238
                        *THE NEW ENTRY VECTORS AND PROCESS ACCORDINGLY. OEM SECURITY @PL30138     01473245
                        *MUST ALSO BE AWARE OF THIS NEW ENTRY CODE. NO IMS GENERATION @PL30138    01473252
                        *IS NECESSARY. IMS TRANS AUTHORIZATION PROCESSING MUST BE      @PL30138   01473259
                        *ACTIVE.                                                       @PL30138   01473266
                        *                                                              @PL30138   01473273
                        *                                                              @PL30138   01473280
                        *    DEPENDENCIES:                                                    *   01473300
                        *                                                                     *   01473500
                        *    THIS ROUTINE WILL ONLY BE CALLED WHEN DFSCTSE0 IS LINK EDITED. *     01473700
                        *                                                                     *   01473900
                        * INPUT:                                                              *   01474000
                        *        R0 POINTER TO USERID FROM THE PST (PSTUSID) OR ZERO @PL30138     01474300
                        *        R1    POINTER TO PASSWORD OR ZERO                            *   01474500
                        *              FOR AUTH CALL POINTER TO GENERIC CLASS          @PL70514   01474504
                        *              TRAN = USE TRAN CLASS                           @PL70514   01474506
                        *              FIELD = USE FIELD CLASS                         @PL70514   01474508
                        *              DATABASE = USE DB CLASS                         @PL70514   01474510
                        *              OTHER = USE OTHER CLASS                         @PL70514   01474512
                        *              SEGMENT = USE SEGMENT CLASS                     @PL70514   01474514
                        *        R2    CALLING ROUTINE NUMBER, AS FOLLOWS                     *   01474520
                        *              0C -- DFSDLA30 CHANGE CALL                      @PL30138   01474540
                        *              20 -- DFSDLA30 FOR AUTH CALL                    @PL30138   01474570
                        *        R3    RACF OR DFSCTRN0 RETURN CODE                           *   01474600
                        *        R4    POINTER TO STORAGE AREA WITH FOLLOWING FORMAT          *   01474610
                        *               REFER TO DSECT CTSEPARM AT THE END OF EXIT:           *   01474620
                        *                 BYTE         CONTENT                                *   01474630
                        *                 1            FLAG BYTE                              *   01474640
                        *                    X′ 8 0 ′      ACEE FROM CTB USED                 *   01474650
                        *                    X′ 4 0 ′      DYNAMIC ACEE IN CTL USED           *   01474660
                        *                    X′ 2 0 ′      DYNAMIC ACEE IN DEP USED           *   01474670
                        *                    X′ 1 0 ′      ACEE COULD NOT BE CREATED          *   01474680
                        *                    X′ 0 8 ′      RESERVED FOR FUTURE USE            *   01474690
                        *                    X′ 0 4 ′      RESERVED FOR FUTURE USE            *   01474700
                        *                    X′ 0 2 ′      RESERVED FOR FUTURE USE            *   01474710
                        *                    X′ 0 1 ′      RESERVED FOR FUTURE USE            *   01474720
                        *                 2-4          RESERVED                               *   01474730
                        *        R7    SOURCE CTB POINTER IF TERMINAL AVAILABLE AND    @PQ02392   01474750
                        *              VALID, OTHERWISE ZERO.                          @PL30138   01474760
                        *        R9    POINTER TO THE PST.                             @PL30138   01474820
                        *        R10 POINTER TO TRANSACTION CODE OR RESOURCE NAME      @PL30138   01474900
                        *        R11 ADDRESS OF SCD                                           *   01475000
                        *        R13-R15 STANDARD OS CALLING SEQUENCE                         *   01475200
                        *              THE STANDARD REGISTER SAVE AREA FIRST THREE WORDS      *   01475400
                        *              MUST NOT BE MODIFIED.                                  *   01475600
                        *                                                                     *   01475800
                        * OUTPUT:                                                             *   01476000
                        *                                                                     *   01476200
                        *        UPON RETURN THE FOLLOWING RETURN CODES WILL BE USED IN R15: *    01476400
                        *                                                                     *   01476600
                        *        RC= 0, ACCEPT THE TRANSACTION                                *   01476800
                        *        RC= 4, RESOURCE NOT PROTECTED                         @PL30138   01476860
                        *        RC= 8, USER NOT AUTHORIZED                            @PL30138   01476920


238   IMS V6 Security Guide
*        RC= POSITIVE, MEANS REJECT THE TRANSACTION.           @PL30138       01477000
*        RC= NEGATIVE, USER IS AUTHORIZED, THE NEGATIVE VALUE @PL30138        01477050
*             IS THE COMPLEMENTED ADDRESS THAT POINTS TO USER @PL30138        01477100
*             DATA PROVIDED BY RACF. (AUTH CALL)               @PL30138       01477150
***********************************************************************       01477200
         EJECT                                                                01477400
         DS 0D                     ENSURE DOUBLE ALINGMENT     @PL13683       01477600
DFSCTSE0 CSECT                                                 @PL13683       01477800
         SAVE (14,12),,CTSE086                                 @PL13683       01478000
         LR    R12,R15             SET R12 AS BASE REGISTER    @PL13683       01478200
         USING DFSCTSE0,R12                                    @PL13683       01478400
         USING CTB,R7                                          @PL13683       01478600
         USING SCD,R11                                         @PL13683       01478800
         LR    R15,R3              SET RACF/DFSCTRN0 RET CODE @PL13683        01479000
*        NOP                                                   @PL13683       01479200
RETSE    EQU *                     RETURN POINT                @PL13683       01479400
         L     R14,12(,R13)        RESTORE R14                 @PL13683       01479500
         LM    R0,R12,20(R13)      RESTORE REGISTERS           @PL13683       01479600
         BR    R14                 RETURN                      @PL13683       01479800
USERTBL DSECT                                                                 01480000
USRENTRY DS    CL8                 USERID                      @BM00028       01490000
         DS    CL8                 PASSWORD                    @BM00028       01500000
         DS    CL4                 ACCOUNTING INFORMATION      @BM00028       01510000
         DS    AL4                 ADDRESS OF TRANSACTION LIST @BM00028       01520000
CTRNPARM DSECT                                                 @BM00145       01520700
CTRNFLG1 DS    CL1                 FLAG BYTE                   @BM00145       01521000
CTRNFTRM EQU X′ 0 1 ′              SMU LTERM SECURITY IN EFFECT@BM00145       01522000
CTRNFPSW EQU X′ 0 2 ′              SMU PASSW SECURITY IN EFFECT@BM00145       01522800
*        EQU X′ 0 4 ′              RESERVED                    @BM00145       01523000
*        EQU X′ 0 8 ′              RESERVED                    @BM00145       01524000
*        EQU X′ 1 0 ′              RESERVED                    @BM00145       01524900
*        EQU X′ 2 0 ′              RESERVED                    @BM00145       01525000
*        EQU X′ 4 0 ′              RESERVED                    @BM00145       01526000
*        EQU X′ 8 0 ′              RESERVED                    @BM00145       01527000
         DS    CL3                 RESERVED                    @BM00145       01527800
CTRNRFRC DS    F                   RACF RETURN CODE            @BM00145       01527900
CTRNTPIP DS    0A                  ADDR(TPIPE)--OTMA                          01527950
CTRNPLUN DS    A                   ADDR(PARTNER LU NAME)--(LU6.2)             01528000
CTRNTMEM DS    A                   ADDR(MEMBER NAME)--OTMA                    01528500
CTRNUTKN DS    AL4                 ADDRESS OF RACF UTOKEN      @BM00145       01529000
CTRN62ID DS    A                   ADDR(PARTNER USERID)--(LU6.2)              01529250
CTRNPLEN EQU *-CTRNPARM                                        @BM00145       01529500
CTSEPARM DSECT                                                 @PQ02392       01529600
CTSEFLG1 DS    CL1                 FLAG BYTE                   @PQ02392       01529620
CTSEACEC EQU X′ 8 0 ′              ACEE FROM CTB USED          @PQ02392       01529640
CTSEACDC EQU X′ 4 0 ′              DYNAMIC ACEE IN CTL USED    @PQ02392       01529660
CTSEACDD EQU X′ 2 0 ′              DYNAMIC ACEE IN DEP USED    @PQ02392       01529680
CTSEACEN EQU X′ 1 0 ′              ACEE COULD NOT BE CREATED @PQ02392         01529700
         DS    CL3                 RESERVED                    @PQ02392       01529800
CTSEPLEN EQU *-CTSEPARM                                        @PQ02392       01529900
         PRINT NOGEN                                                          01530000
         REQUATE                                                              01540000
         ISCD SCDBASE=0                                        @BM00028       01550000
         ICLI CTBBASE=0,CNTBASE=0                              @BM00028       01560000
         END                                                                  01580000




                                        Appendix A. IMS Security Exits Examples   239
240   IMS V6 Security Guide
Appendix B. Security Maintenance Utility (DFSISMP0)

                         For security beyond that provided by default terminal security, you can use the
                         various security options specified with the security maintenance utility (SMU).
                         The utility is executed offline after completion of Stage 2 processing for system
                         definition. Its output is a set of secured resource tables placed on the
                         IMS.MATRIX data set. The tables are loaded at system initialization time, and,
                         for certain options, work with exit routines and/or the resource access control
                         facility (RACF) program product during online execution to provide resource
                         protection.

                         The security maintenance utility provides five security options:
                         LTERM security
                           Defines the commands and transactions that can be used from a given
                           physical or logical terminal
                         Password security
                           Limits the use of a specified IMS resource to someone who supplies the
                           correct password
                         Resource access security
                           Limits the set of IMS resources that can be used by dependent regions that
                           are authorized to access a specific application group
                         Transaction command security
                           Lets an application program issue a subset of IMS operator commands (using
                           the DL/I CMD call)
                         Sign-on verification security
                           Identifies a particular user to IMS to determine if each transaction entered by
                           that user is authorized to the user ID currently logged on

                         MVS users can also use the RACF program product if desired. See B.3.5,
                         “Sign-on Verification Security” on page 244.

                         Although IMS system definition creates most resident control blocks for the IMS
                         control program, it supplies only basic terminal security which prohibits the entry
                         of certain commands from any terminal other than the master terminal. If no
                         security options are specified by system definition, the generated IMS system
                         protects the commands shown in Figure 39 from non-master terminal use:


                               /ASSIGN       /DEQUEUE      /MSASSIGN     /RMxxxxxx •••
                               /CHANGE       /DISPLAY      /MSVERIFY     /RSTART
                               /CHECKPOINT   /ERESTART     /NRESTART     /SMCOPY
                               /CLSDST       /IDLE         /OPNDST       /SSR
                               /COMPT        /LOOPTEST     /PSTOP        /START
                               /DBDUMP       /MODIFY       /PURGE        /STOP
                               /DBRECOVERY   /MONITOR      /QUIESCE      /TRACE
                               /DELETE

                             Note: ••• RMLIST is not protected from non-master terminal use.

                         Figure 39. Protected Commands




© Copyright IBM Corp. 1999                                                                              241
                        The basic level of security is called default terminal security. It exists whether
                        the security maintenance utility is used to implement the added security features
                        of IMS.



B.1 Input and Output Flow
                        Figure 40 on page 243 shows the flow of input to and output from the security
                        maintenance utility. Refer to this figure as you read the remaining sections of
                        this Appendix.



B.2 Restrictions
                          •   If you do not use RACF, two of the options, sign-on verification and IMS
                              Resource Access Security, require user exit routines that you must provide.
                              IMS does not supply exit code except for sample user exits.
                          •   The security maintenance utility does not provide LTERM, password,
                              resource, transaction command, or sign-on verification security for terminals
                              defined with the Extended Terminal Option (ETO) or for LU 6.2 devices. If
                              your system uses ETO or LU 6.2 terminals, use RACF or an equivalent
                              security product to provide terminal security functions.
                          •   SMU cannot be used for transaction command security for DL/I ICMD or
                              RCMD calls.



B.3 Security Options
                        This section provides a brief explanation of each of the five security options for
                        the security maintenance utility.


B.3.1 LTERM Security
                        This security option allows you to define a set of commands and transactions
                        that are authorized for use by specified logical terminals. You can define a
                        maximum of 32,767 different patterns for these sets of commands and
                        transactions, a pattern being a unique set of commands issued by one or more
                        terminals. For example: two terminals issuing the same set of commands
                        constitutes one pattern; two terminals issuing different sets of commands
                        constitutes two patterns.

                        For multiple IMS systems, you can also specify a set of authorized transactions
                        that can be passed to an IMS system using a logical data link. Terminal security
                        requires no external user exit routines.


B.3.2 Password Security
                        This option specifies the use of a password with terminal input. Resources
                        cannot be used unless a correct password is supplied. Password security can
                        be used for:
                              Transactions
                              Commands

                        When an operator enters the /LOCK or /UNLOCK command to control the use of
                        online resources, the use of several keywords can be protected by requiring a
                        password. The resources that can be protected are:


242   IMS V6 Security Guide
Figure 40. Security Maintenance Utility Data Set Requirements

                           PTERM
                           LTERM
                           Application programs
                           Databases


B.3.3 Transaction Command Security
                       You must use a security option to authorize an online application program to
                       issue IMS commands using the DL/I CMD and GCMD calls. You make the
                       authorization by associating the transaction that invokes the program with a list
                       of commands that the program is designed to use. In the case of an automated
                       operator program, you need to specify all the commands the program is
                       designed to use. The list of commands that programs can issue is given in
                       IMS/ESA Operations Guide , SC26-8741. Transaction command security requires
                       no user exit routines.


B.3.4 IMS Resource Access Security
                       Resource access security prevents an IMS resource from being used by a
                       dependent message region unless that resource has been authorized for use by
                       the dependent region. It also prevents an unauthorized dependent message
                       region from starting.




                                                         Appendix B. Security Maintenance Utility (DFSISMP0)   243
                        You specify, in the SECURITY macro during system definition, whether resource
                        access security will be included and whether RACF or a user exit routine will be
                        used for the authorization validation.

                        You define, through security maintenance, a list of IMS resources and assign a
                        unique application group name (AGN) to the list. security maintenance places
                        this AGN in a table the IMS system recognizes. IMS prevents the use of
                        resources by a dependent message region unless that resource is listed in the
                        AGN table.

                        You must either provide a user exit routine or use RACF to authorize the start of
                        a dependent message region.


B.3.5 Sign-on Verification Security
                        You can prevent an unauthorized user from accessing the IMS system from a
                        local or remote terminal by defining a list of terminals that require sign-on
                        verification. Sign-on verification security identifies a user to IMS as being
                        present from the /SIGN ON command entry until a /SIGN OFF command is
                        entered.

                        You can define a maximum of 32,767 terminals to require sign-on verification.

                        You can also restrict those authorized users (user IDs) to specific transactions.
                        You do this by specifying, along with sign-on verification security, transaction
                        authorization. As each transaction is entered from a terminal, either RACF or a
                        user exit routine, or both, validate it for the user ID signed on. If the terminal
                        from which the transaction is entered does not require sign-on verification, the
                        transaction code is still checked by RACF or by the user exit routine.



B.4 Resource Access Control Facility (RACF)
                        RACF is an independent facility that runs under MVS operating systems. RACF
                        and security maintenance provide the same functions as user exit routines and
                        Security Maintenance: sign-on verification and resource access security.

                        Two RACF security variations, not supplied by user exit routines and security
                        maintenance, are terminal-user security and resource class security (provided
                        by the RACF APPL resource class). RACF terminal-user security prevents an
                        online user from using a physical terminal unless the appropriate user ID is
                        specified under a user profile for that terminal. (RACF terminal-user security
                        and password security are somewhat different from the same functions provided
                        by security maintenance and user exit routines.) Through the RACF keyword
                        APPL, resource class security lets you define any resource in the IMS system,
                        including the system itself, as a resource to protect.



B.5 Command Authorization Exit Routine
                        You can supply an exit routine to restrict the commands a user can issue from a
                        terminal or from an AO application that uses the ICMD call. See Chapter 10,
                        “IMS Security Exits” on page 181 for more information. If the command
                        authorization user exit is included in the IMS system, IMS calls the exit to check
                        whether a user ID is eligible to issue a command. If the value coded for the IMS
                        execution parameter keyword AOIS is either A or C, DFSCCMD0 is called to



244   IMS V6 Security Guide
                check whether the AO application is eligible to use the ICMD call to issue the
                command.



B.6 IMS Application Resource Access Security
                Application resource access security permits online programs to determine the
                access authority of the user requesting the transaction. This level of security is
                available by issuing an Authorization (AUTH) call in conjunction with RACF.

                You define (to RACF) the resources whose access will be restricted within the
                application program. These resources include terminals, spool readers, and
                data sets.

                You can use the normal IMS security exit routines (such as the /SIGN ON exit
                routine and the Transaction Authorization exit routine) for additional control of
                the authorization process. Chapter 10, “IMS Security Exits” on page 181 has
                more information on the exit.



B.7 SECURITY Procedure
                The SECURITY procedure is created as a part of system generation and is
                placed into the IMS.PROCLIB procedure library by Stage 2 of IMS system
                definition.

                To run the security maintenance program, you must have previously defined an
                IMS control program using the value ALL, ON-LINE, NUCLEUS, CTLBLKS, or
                MODBLKS as the second sublist entry of the SYSTEM operand of the IMSCTRL
                macro instruction. Two of the modules created during Stage 2 of IMS system
                definition are a directory of communication resources and a directory of
                database resources of the defined system. They are placed in the IMS.RESLIB
                and IMS.MODBLKS data sets, respectively. These directories and the security
                maintenance control statements are the required input for the security
                maintenance utility.

                The security maintenance program runs as a three-step job. The first step (Step
                S) accepts the input control and data statements and checks them against the
                IMS system being maintained to ensure correct format and validity. If there are
                no errors in the first step, the second step (Step C), an operating system
                assembly, is performed. The third step (Step L) is a link-edit that takes the
                assembly output from Step C and creates the following:
                    Password table
                    Password matrix
                    Password matrix relative pointer lists
                    Terminal matrix
                    Terminal matrix relative pointer lists
                    Transaction command matrix
                    Transaction command matrix relative pointer list
                    Sign-on relative terminal list
                    Application Group Name table

                Depending on the input presented, there are a variable number of output load
                modules created. The maximum size of any generated matrix is:
                   M=(IxR)/8


                                                Appendix B. Security Maintenance Utility (DFSISMP0)   245
                        where:

                        I     is the number of securing resources. These are shown below for each
                              matrix:

                              Matrix                      Securing Resource
                              Password                    Passwords
                              Terminal                    Logical terminals and link names
                              Transaction Command         Transactions

                              Note: In order to produce a valid terminal matrix, the number of LTERMs
                              specified at system generation cannot exceed 65535.

                        R     is the number of secured resources. If more than one secured resource is
                              secured to the same set of securing resources, then only one secured
                              resource is counted in order to calculate the size of the matrix. For
                              example, if one or more transactions and/or commands can be entered by
                              the identical subset of LTERMs, then these transactions and/or commands
                              are counted as a single secured resource. These are shown below for each
                              matrix:

                              Matrix                      Secured Resource
                              Password                    Commands, databases, LTERMs, programs,
                                                          PTERMs, transactions
                              Terminal                    Transactions, commands
                              Transaction Command         Commands

                        M     is the total virtual storage requirement in bytes.

                        As mentioned. the security procedure is created by the Stage 2 processing and
                        is placed at standard IMS.PROCLIB. Refer IMS/ESA Installation Volume I:
                        Installation and Verification , GC26-8736 for JCL statements, parameter
                        description and procedure usage.



B.8 Utility Control Statements
                        Input to the security maintenance utility consists of control and data statements.
                        A control statement indicates to the utility that security is being established for
                        the system resource named by that statement. Control statements are identified
                        by close and open parentheses characters in combination, )(, in character
                        positions 1 and 2 of the input statement, followed by a blank in character position
                        3. A control statement remains in effect until another control statement or end of
                        input data is encountered.

                        Data statements describe the security to be established for the system resource
                        defined by the preceding control statement. All data statements following a
                        control statement are associated with that control statement. Data statements
                        are identified by a blank in character position 1 of the input statement. Each
                        statement, control or data, has only one operand, separated from the operation
                        by a blank. Any number of valid data statements can be used in conjunction
                        with a given control statement.

                        Input data must be entered in columns 1 through 71 of the input statements;
                        columns 72 through 80 are ignored.




246   IMS V6 Security Guide
Comments can be included following the parameter specifications on control and
data statements. Comment-only statements can be specified by an asterisk in
column 1.

Use Table 34 to determine which input statements can be used as control
statements, data statements, or both.

 Table 34. Security Maintenance Utility Input Statements
 Input Statement                    Control Statement                Data Statement
 AGN                                         X
 SIGN                                        X
 AGLTERM                                                                    X
 AGPSB                                                                      X
 AGTRAN                                                                     X
 STERM                                                                      X
 COMMAND                                     X                              X
 CTRANS                                      X                              X
 DATABASE                                    X                              X
 PASSWORD                                    X                              X
 PROGRAM                                     X                              X
 PTERM                                       X                              X
 TCOMMAND                                    X                              X
 TERMINAL                                    X                              X
 TRANSACT                                    X                              X


The operands that can be used with the above statements are:
Password
  A password is any combination of 1 to 8 alphanumeric characters. The
  longest password encountered on a PASSWORD statement in the input stream
  governs the maximum length of input passwords that will be accepted by your
  IMS system.
  To define additional passwords, a PASSWORD control statement is used with
  no following data statements:


        )( PASSWORD ABCD
        )( PASSWORD EFGH

Logical terminal name or     link name
  A valid logical terminal   name or link name is 1 to 8 characters in length. It
  must be defined in the     IMS system being maintained or it is invalid. Any
  invalid terminal names     or link names are rejected by security maintenance.
Transaction code
  A valid transaction code is 1 to 8 characters in length. It must be defined in
  the IMS system being maintained. If it is not defined, it is treated as invalid by
  the utility.




                                   Appendix B. Security Maintenance Utility (DFSISMP0)   247
                        Command language verb
                          Valid command language verbs are obtained from the Stage 2 output of the
                          IMS system definition. The command verb, without the leading slash, can be
                          abbreviated to the first three characters.
                        Name
                          Name is a valid database name, program name, VTAM node name, application
                          group name, or BTAM physical terminal number as obtained from the output
                          of the IMS system definition.
                        Note:
                          1. Only the first three characters of the operation code are required to identify
                             control or data statements.
                          2. Physical terminal numbers are found in the Stage 1 listing and in the
                             assembly of DFSISDB0 in Stage 2 of the IMS system definition.



B.9 Statement Syntax
                        The following commands show the valid syntax or combinations of control
                        statements and data statements that security maintenance accepts and gives
                        examples:

                                AGN Command
                                 ──AGN──<agn_name>───────────────────────────────────────────────────
                               Part Two:
                               ├──┬─AGLTERM──┬─<lterm>─┬──────┬───────────────────────────────────────┤
                                  │          └─ALL─────┘      │
                                  ├─AGPSB──┬─<psb>─┬──────────┤
                                  │        └─ALL───┘          │
                                  └─AGTRAN──┬─<transaction>─┬─┘
                                            └─ALL───────────┘
                               Note:
                               1
                                 The Part Two line may be repeated as many times as necessary.



                        The following are programs, transactions, and logical terminals whose access is
                        restricted to the region associated with the AGN name:
                              )( AGN         TEST005
                                 AGPSB       DDLTBP01
                                 AGTRAN      TRAN13C0
                                 AGLTERM     DD3270L4

                              )( AGN         TEST003
                                 AGPSB       ALL
                                 AGTRAN      ALL
                                 AGLTERM     ALL

                              )( AGN         TEST004
                                 AGPSB       APOL1
                                 AGPSB       A3270
                                 AGTRAN      ADDINV
                                 AGTRAN      APOL15
                                 AGLTERM     TERM0001
                                 AGLTERM     TERM0002


248   IMS V6 Security Guide
 )( AGN          TEST002
    AGPSB        A3270
    AGTRAN       ADDINV

 )( AGN          TEST002
    AGPSB        INTCON

    COMMAND Command
    ──COMMAND──<command>────────────────────────────────────────────────
   Part Two:
   ├──┬─PASSWORD──<password>─┬────────────────────────────────────────────┤
      └─TERMINAL──<lterm>────┘


The following are passwords assigned to commands:
 )( COMMAND     CHANGE
    PASSWORD    PSWD1

 )( COMMAND     PURGE
    PASSWORD    PSWD2
    TERMINAL    TERM0001

 )( COMMAND     STOP
    TERMINAL    TERM0002

    CTRANS Command
    ──CTRANS──<trnname>─────────────────────────────────────────────────
   Part Two:
   ├──TCOMMAND──┬─<command>─┬─────────────────────────────────────────────┤
                └─*─────────┘


These following illustratse the relationship of AO transactions to commands.
When an asterisk (*) is used in the TCOMMAND data statement, all commands in
the command table DFSSMUL0 are used. The asterisk (*) in the first example
indicates that the automated operator program ADDPART is allowed to use all
the IMS commands that can be issued from an AO application. The APOL13 AO
transaction can use only the COMPT command.
 )( CTRANS       ADDPART
    TCOMMAND     *

 )( CTRANS       APOL13
    TCOMMAND     COMPT

    DATABASE Command
    ──DATABASE──<dbname>────────────────────────────────────────────────
   Part Two:
   ├──┬─PASSWORD──<password1>────┬────────────────────────────────────────┤
      ├─)( PASSWORD──<password2>─┤
      └─)( PASSWORD──<passwordn>─┘




                              Appendix B. Security Maintenance Utility (DFSISMP0)   249
                        The following are passwords assigned to each database. To define additional
                        passwords, a PASSWORD control statement is used with no following data
                        statements.
                              )( DATABASE    ACCTLOG
                                  PASSWORD   LOG
                              )( PASSWORD    ABCD
                              )( PASSWORD    EFGH

                              )( DATABASE    ACCTREC
                                  PASSWORD   REC

                              )( DATABASE    ACTIVITY
                                  PASSWORD   ACTIVE

                                PASSWORD Command
                                 ──PASSWORD──<password>──────────────────────────────────────────────
                               Part Two:
                               ├──┬─COMMAND──<command>──────┬─────────────────────────────────────────┤
                                  ├─DATABASE──<database>────┤
                                  ├─PROGRAM──<program>──────┤
                                  ├─PTERM──<node>───────────┤
                                  ├─TERMINAL──<lterm>───────┤
                                  └─TRANSACT──<transaction>─┘


                        The following are passwords assigned to each of the specified resource types:
                              )( PASSWORD    PSWD1
                                 COMMAND     START

                              )( PASSWORD    PSWD2
                                 DATABASE    DB1

                              )( PASSWORD    PSWD3
                                 PROGRAM     PSB109

                              )( PASSWORD    PSWD4
                                 PTERM       NODE871

                              )( PASSWORD    PSWD5
                                 TERMINAL    LTERM001

                              )( PASSWORD    PSWD6
                                 TRANSACT    PAYTRAN

                                PROGRAM Command
                                 ──PROGRAM──<psbname>────────────────────────────────────────────────
                               Part Two:
                               ├──PASSWORD──<password>────────────────────────────────────────────────┤


                        The following are passwords assigned to each program.




250   IMS V6 Security Guide
  )( PROGRAM      ACCT
      PASSWORD    DOLLAR

  )( PROGRAM      ENG560
      PASSWORD    PARTNO

     PTERM Command
     ──PTERM──<nodename>─────────────────────────────────────────────────
   Part Two:
   ├──PASSWORD──<password>────────────────────────────────────────────────┤


The following illustrates assigning a password to a static terminal:
  )( PTERM        NODE561
      PASSWORD    CLMARW

     SIGN Command
     ──SIGN──────────────────────────────────────────────────────────────
   Part Two:
   ├──STERM──┬─ALL───────────────────────────────────┬────────────────────┤
             ├─LINE──<btamline#>──TERMINAL──<pterm#>─┤
             └─<vtamnode>────────────────────────────┘


The examples on the next page illustrate terminals that must enter a sign-on
command to gain access to IMS.

Line numbers and terminal numbers are assigned by the position of the LINE
and TERMINAL macros in Stage 1 input. Stage 2 output shows the line number
that has been assigned to each line and the terminal number that has been
assigned to each terminal.
 1. In the first example, all terminals are required to sign on.
 2. The second example shows that sign-on will be required for the fourth
    PTERM on the third LINE macro in the system definition macros. This
    example also shows that sign-on will be required for the second PTERM on
    the fifth LINE macro in the system definition macros.
 3. The third example shows that sign-on will be required for the following
    terminals:
    a. The BTAM or VTAM terminal represented by the fourth TERMINAL macro
       in the system definition macros.
    b. During system definition, a terminal number is assigned to each
       terminal, which is defined by a TERMINAL macro. The numbers assigned
       are consecutive and represent the numerical position of a TERMINAL
       macro among all the TERMINAL macros supplied in system definition
       macros.
     c. The BTAM or VTAM terminal represented by the ninth TERMINAL macro
        in the system definition macros.
    d. The BTAM or VTAM terminal represented by the one hundred fifth
       TERMINAL macro in the system definition macros.
    e. The VTAM terminal with a node name of NODE12

                                 Appendix B. Security Maintenance Utility (DFSISMP0)   251
                                 f. The VTAM terminal with a node name of V3270
                              )( SIGN
                                 STERM            ALL

                              )( SIGN
                                 STERM LINE 3 TERMINAL 4
                                 STERM LINE 5 TERMINAL 2

                              )( SIGN
                                 STERM   4
                                 STERM   09
                                 STERM   105
                                 STERM   NODE12
                                 STERM   V3270

                                TCOMMAND Command
                                 ──TCOMMAND──<command>───────────────────────────────────────────────
                               Part Two:
                               ├──CTRANS──<transaction>───────────────────────────────────────────────┤


                        The following is an example of transaction command security for certain
                        commands. The STOP command can be used by AO transactions ADDINV,
                        APOL11, and APOL12.
                              )( TCOMMAND         STOP
                                 CTRANS           ADDINV
                                 CTRANS           APOL11
                                 CTRANS           APOL12

                                TERMINAL Command
                                 ──TERMINAL──<lterm>─────────────────────────────────────────────────
                               Part Two:
                               ├──┬─COMMAND──<command>──────┬─────────────────────────────────────────┤
                                  ├─PASSWORD──<password>────┤
                                  └─TRANSACT──<transaction>─┘


                        The following shows that LTERM854 terminal can enter a subset of IMS terminal
                        commands and transaction codes defined by the system definition example in
                        this book. If a password is assigned to the LTERM, such as password AB432I,
                        the password must be supplied when the LOCK or UNLOCK command is used to
                        lock/unlock the LTERM.
                              )( TERMINAL      LTERM854
                                 PASSWORD     AB432I
                                 TRANSACT     ACCTCHG
                                 TRANSACT     ACTY
                                     :
                                     :
                                 COMMAND      BROADCAST
                                 COMMAND      START
                                     :
                                     :
                                 COMMAND      DISPLAY



252   IMS V6 Security Guide
                   TRANSACT Command
                   ──TRANSACT──<transaction>───────────────────────────────────────────
                 Part Two:
                 ├──┬─PASSWORD──<password>─┬────────────────────────────────────────────┤
                    └─TERMINAL──<lterm>────┘


              The following are passwords assigned to transaction codes and terminals that
              can use each transaction code. With the list of terminals is the required
              password that must be supplied with the transaction entry. A transaction may
              be secured by assigning a password, restricting transaction entry to specific
              LTERMS, or both.
                )( TRANSACT    ACCTCHG
                    PASSWORD   CHARGE
                    TERMINAL   A875111
                    TERMINAL   C8751112
                       :
                       :

                )( TRANSACT    ACTY
                    PASSWORD   GO
                    TERMINAL   A8751111
                       :
                    TERMINAL   MASTER
                    TERMINAL   ALTMAST


B.10 Output
              Output from the security maintenance utility consists of up to eight sequential
              members that are placed in IMS.MATRIX. These members cannot be
              reprocessed using the linkage editor.

              The contents and names of the six members are:

              Contents                                   Name
              Communication Password Table/Matrix        DFSISPBx
              Terminal Offset List                       DFSISTLx
              Transaction Command Matrix                 DFSISTCx
              Transaction Offset List and Table          DFSISTTx
              Sign-on Table                              DFSISSOx
              Application Group Name Table               DFSAGTOx


              The utility also provides a listing of the maintenance tables created. Each run of
              the utility replaces previously created members. A set of security maintenance
              tables can be maintained for each IMS online control program nucleus. It is
              identified by the last character of the IMS nucleus name.




                                              Appendix B. Security Maintenance Utility (DFSISMP0)   253
B.11 Security Status Reports
                        Each execution of the utility produces a printed analysis of the IMS system for
                        which security is being maintained. If errors are encountered in processing the
                        input control statements, no security block update functions are performed.
                        Instead, diagnostic error messages are produced for the entire input stream.

                        You can also request an execution of the security maintenance utility with no
                        updates, to produce a printed analysis of your IMS system security
                        specifications.




254   IMS V6 Security Guide
Appendix C. IMS/ESA DBRC Security Tool (5697-D87)

                         IBM recently announced a database tool to protect the RECON data sets. As of
                         IMS Version 6, the use of the DBRC security tool is mandatory. All databases
                         must be registered with DBRC. Therefore, RECON data sets contain critical
                         information about IMS databases, as well as IMS system information. If
                         information stored in RECON data sets is lost or corrupted, IMS will stop its
                         operation until the data is restored.

                         Currently, everyone who has control access is able to update entire RECON data
                         sets even he or she may need to access only a few records. This has the
                         potential to corrupt, accidentally or intentionally, the RECON data sets.

                         The DBRC security tool allows you to protect the RECON data sets by:
                             •   Blocking any unauthorized access to read or update RECON using the DBRC
                                 utility DSPURX00.
                             •   Protecting any RECON data sets access by an MVS utility, IDCAMS for
                                 example, or user-written programs.
                             •   Creating additional SMF records to record every command executed by the
                                 DSPURX00 utility. This is for auditing purposes.

                         The DBRC utility establishes an environment where only very few IDs and
                         Trusted Agents are allowed to open RECON data sets in Control mode. A Proxy
                         user is also allowed to access RECON but only when the data sets are opened.
                         In summary, this utility provides a finer granularity to protect RECON. For
                         detailed information, refer to IMS/ESA Database Recovery Control Security Tool
                         User ′ s Guide , SC26-9456.




© Copyright IBM Corp. 1999                                                                             255
256   IMS V6 Security Guide
Appendix D. Special Notices

                         This publication is intended to help technical professionals understand many
                         security functions of IMS/ESA and how to set up the environment to protect
                         IMS/ESA resources. The information in this publication is not intended as the
                         specification of any programming interfaces that are provided by IMS/ESA
                         Version 6. See the PUBLICATIONS section of the IBM Programming
                         Announcement for IMS/ESA Version 6 Release 1 for information about what
                         publications are considered to be product documentation.

                         References in this publication to IBM products, programs or services do not
                         imply that IBM intends to make these available in all countries in which IBM
                         operates. Any reference to an IBM product, program, or service is not intended
                         to state or imply that only IBM′s product, program, or service may be used. Any
                         functionally equivalent program that does not infringe any of IBM′s intellectual
                         property rights may be used instead of the IBM product, program or service.

                         Information in this book was developed in conjunction with use of the equipment
                         specified, and is limited in application to those specific hardware and software
                         products and levels.

                         IBM may have     patents or pending patent applications covering subject matter in
                         this document.    The furnishing of this document does not give you any license to
                         these patents.   You can send license inquiries, in writing, to the IBM Director of
                         Licensing, IBM   Corporation, North Castle Drive, Armonk, NY 10504-1785.

                         Licensees of this program who wish to have information about it for the purpose
                         of enabling: (i) the exchange of information between independently created
                         programs and other programs (including this one) and (ii) the mutual use of the
                         information which has been exchanged, should contact IBM Corporation, Dept.
                         600A, Mail Drop 1329, Somers, NY 10589 USA.

                         Such information may be available, subject to appropriate terms and conditions,
                         including in some cases, payment of a fee.

                         The information contained in this document has not been submitted to any
                         formal IBM test and is distributed AS IS. The information about non-IBM
                         (″vendor″) products in this manual has been supplied by the vendor and IBM
                         assumes no responsibility for its accuracy or completeness. The use of this
                         information or the implementation of any of these techniques is a customer
                         responsibility and depends on the customer′s ability to evaluate and integrate
                         them into the customer′s operational environment. While each item may have
                         been reviewed by IBM for accuracy in a specific situation, there is no guarantee
                         that the same or similar results will be obtained elsewhere. Customers
                         attempting to adapt these techniques to their own environments do so at their
                         own risk.

                         Any pointers in this publication to external Web sites are provided for
                         convenience only and do not in any manner serve as an endorsement of these
                         Web sites.

                         Any performance data contained in this document was determined in a
                         controlled environment, and therefore, the results that may be obtained in other




© Copyright IBM Corp. 1999                                                                               257
                        operating environments may vary significantly. Users of this document should
                        verify the applicable data for their specific environment.

                        Reference to PTF numbers that have not been released through the normal
                        distribution process does not imply general availability. The purpose of
                        including these reference numbers is to alert IBM customers to specific
                        information relative to the implementation of the PTF when it becomes available
                        to each customer according to the normal IBM PTF distribution process.

                        The following terms are trademarks of the International Business Machines
                        Corporation in the United States and/or other countries:

                        ACF/VTAM                                   Aptiva
                        AS/400                                     AT
                        CICS                                       CICS/MVS
                        DB2                                        IBM
                        IMS                                        IMS/ESA
                        MQSeries                                   MVS/ESA
                        OS/2                                       OS/390
                        RACF                                       RS/6000
                        SP                                         System/390
                        VM/ESA                                     VTAM
                        400

                        The following terms are trademarks of other companies:

                        C-bus is a trademark of Corollary, Inc. in the United States and/or
                        other countries.

                        Java and all Java-based trademarks and logos are trademarks or registered
                        trademarks of Sun Micorsystems, Inc. in the United States and/or other countries.

                        Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
                        Microsoft Corporation in the United States and/or other countries.

                        PC Direct is a trademark of Ziff Communications Company in the United States
                        and is used by IBM Corporation under license.

                        ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel
                        Corporation in the United States and/or other countries.

                        UNIX is a registered trademark in the United States and/or other
                        countries licensed exclusively through X/Open Company Limited.

                        SET and the SET logo are trademarks owned by SET Secure Electronic
                        Transaction LLC.

                        Other company, product, and service names may be trademarks or
                        service marks of others.




258   IMS V6 Security Guide
Appendix E. Related Publications

                         The publications listed in this section are considered particularly suitable for a
                         more detailed discussion of the topics covered in this redbook.



E.1 International Technical Support Organization Publications
                         For information on ordering these ITSO publications see “How to Get ITSO
                         Redbooks” on page 261.
                             •   Interoperability Between VSE DL/I and OS/390 IMS DBCTL , SG24-5249
                             •   Connecting IMS to the World Wide Web: A Practical Guide to IMS
                                 Connectivity , SG24-2220



E.2 Redbooks on CD-ROMs
                         Redbooks are also available on the following CD-ROMs. Click the CD-ROMs
                         button at http://www.redbooks.ibm.com/ for information about all the CD-ROMs
                         offered, updates and formats.

                         CD-ROM Title                                                             Collection Kit
                                                                                                  Number
                         System/390 Redbooks Collection                                           SK2T-2177
                         Networking and Systems Management Redbooks Collection                    SK2T-6022
                         Transaction Processing and Data Management Redbooks Collection           SK2T-8038
                         Lotus Redbooks Collection                                                SK2T-8039
                         Tivoli Redbooks Collection                                               SK2T-8044
                         AS/400 Redbooks Collection                                               SK2T-2849
                         Netfinity Hardware and Software Redbooks Collection                      SK2T-8046
                         RS/6000 Redbooks Collection (BkMgr Format)                               SK2T-8040
                         RS/6000 Redbooks Collection (PDF Format)                                 SK2T-8043
                         Application Development Redbooks Collection                              SK2T-8037




E.3 Other Publications
                         These publications are also relevant as further information sources:
                             •   IMS/ESA Administration Guide: System , SC26-8730
                             •   IMS/ESA Utilities Reference: System , SC26-8770
                             •   IMS/ESA Customization Guide , SC26-8732
                             •   IMS/ESA Operations Guide , SC26-8741
                             •   IMS/ESA Operator ′ s Reference , SC26-8742
                             •   IMS/ESA Installation Volume I: Installation and Verification , GC26-8736
                             •   IMS/ESA Database Recovery Control Security Tool User ′ s Guide , SC26-9456


                             •   OS/390 Security Server (RACF) Security Administrator ′ s Guide , SC28-1915


                             •   CICS Transaction Server for OS/390 CICS IMS Database Control Guide ,
                                 SC33-1700
                             •   CICS Transaction Server for OS/390 CICS RACF Security Guide , SC33-1701



© Copyright IBM Corp. 1999                                                                                         259
                          •   OS/390 MVS/ESA Planning: APPC/MVS Management , GC28-1807
                          •   OS/390 MVS/ESA Programming: Sysplex Service Guide , GC28-1771


                          •   APPC System Definitions in MVS/ESA and OS/2 , GG66-3224




260   IMS V6 Security Guide
How to Get ITSO Redbooks
This section explains how both customers and IBM employees can find out about ITSO redbooks, redpieces, and
CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided.
 •   Redbooks Web Site http://www.redbooks.ibm.com/
     Search for, view, download, or order hardcopy/CD-ROMs redbooks from the redbooks Web site. Also read
     redpieces and download additional materials (code samples or diskette/CD-ROM images) from this redbooks
     site.
     Redpieces are redbooks in progress; not all redbooks become redpieces and sometimes just a few chapters
     will be published this way. The intent is to get the information out much quicker than the formal publishing
     process allows.
 •   E-mail Orders
     Send orders by e-mail including information from the redbook fax order form to:

     In United States:                      e-mail address: usib6fpl@ibmmail.com
     Outside North America:                 Contact information is in the ″How to Order″ section at this site:
                                            http://www.elink.ibmlink.ibm.com/pbl/pbl/

 •   Telephone Orders

     United States (toll free)             1-800-879-2755
     Canada (toll free)                    1-800-IBM-4YOU
     Outside North America                 Country coordinator phone number is in the ″How to Order″ section at this site:
                                           http://www.elink.ibmlink.ibm.com/pbl/pbl/

 •   Fax Orders

     United States (toll free)              1-800-445-9269
     Canada                                 1-403-267-4455
     Outside North America                  Fax phone number is in the ″How to Order″ section at this site:
                                            http://www.elink.ibmlink.ibm.com/pbl/pbl/

This information was current at the time of publication, but is continually subject to change. The latest information
may be found at the redbooks Web site.

      IBM Intranet for Employees
  IBM employees may register for information on workshops, residencies, and redbooks by accessing the IBM
  Intranet Web site at http://w3.itso.ibm.com/ and clicking the ITSO Mailing List button. Look in the Materials
  repository for workshops, presentations, papers, and Web pages developed and written by the ITSO technical
  professionals; click the Additional Materials button. Employees may access MyNews at http://w3.ibm.com/ for
  redbook, residency, and workshop announcements.




© Copyright IBM Corp. 1999                                                                                             261
IBM Redbook Fax Order Form
Please send me the following:

Title                                                      Order Number                      Quantity




First name                               Last name


Company


Address


City                                     Postal code              Country


Telephone number                         Telefax number               VAT number

•   Invoice to customer number


•   Credit card number




Credit card expiration date               Card issued to                  Signature

We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not
available in all countries. Signature mandatory for credit card payment.




262     IMS V6 Security Guide
Glossary
abend.   Abnormal end of task                            which is temporarily recorded on DASD, to the system
                                                         log data set, which is stored on DASD, tape, or mass
access method. A technique for moving data               storage.
between main storage and input/output devices, for
example, VSAM, VTAM.                                     archive process. The process of archiving the
                                                         IMS/ESA OLDS to a system log data set (SLDS) on
access method control block (ACB). A control block       either tape or DASD.
that links an application program (for example, a CICS
system) to an access method (for example, VSAM or        area. A subset of a DEDB that is defined as a VSAM
VTAM). In communication with DL/I, an ACB is used        ESDS data set. Each area in a DEDB consists of a
only when the underlying access method is VSAM.          root-addressable part, an independent-overflow part,
                                                         and a sequence-dependent part. Area contains the
access method services (AMS). A utility program for      entire logical structure for a set of root segments and
the definition and management of VSAM data sets.         their dependent segment.

active IRLM. The IRLM supporting the active IMS          area data set. A data set that contains a DEDB area.
subsystem in an XRF complex.                             IMS can maintain up to seven copies of this data set.

active libraries. The libraries from which IMS draws     Automated Operator. An application program that
its execution information when online change is used.    can allows a subset of IMS operator commands and
                                                         receive status information on the execution of the
address space. A range of up to 2 GBs of contiguous      commands.
virtual storage addresses that the system creates for
the user. Unlike a data space, an address space          backout. The process of removing all the database
contains user data and programs, as well as system       transaction and manages data
data and programs, some of which are common to all
address spaces. Instructions execute in an address       batch checkpoint/restart. The facility that enables
space, not a data space.                                 batch processing programs to synchronize
                                                         checkpoints and to be restarted at a user-specified
APPC/IMS. A part of IMS TM that uses the CPI             checkpoint.
communication interface to talk to application
programs.                                                batch image copy. A copy of a database or area that
                                                         reflects the state of the data at a time when no
application control blocks (ACB). The control blocks     updates were being made. The Database Image Copy
created from the output of DBDGEN and PSBGEN and         utility (DFSUDMP0) produces batch image copies,
placed in the ACB library for use during online and      which IMS utilities use when recovering from failures.
DBB region type execution of IMS.
                                                         batch message processing (BMP) program. An IMS
application identifier (VTAM applid). The name by        batch processing program that has access to online
which a logical unit known in a VTAM network. The        databases and message queues. BMPs run online but
CICS applid is specified in the APPLID system            like programs in a batch environment, they are
initialization parameter.                                started with job control language (JCL).

application load balancing. An optional facility that    batch processing. (1) Type of data processing in
enables an application program to be scheduled into      which a number of input items are grouped for
more than one message or batch message region at         processing serially with a minimum of operator
the same time.                                           intervention and no end-user interaction. (2) Serial
                                                         processing of computer programs. (3) Pertaining to
Application Group Name. A name that represents a         the technique of executing a set of computer
defined set of IMS resources (PSBs, transaction          programs so that each is completed before the next
names, and logical terminal names).                      program of the set is started.

APPLID name. The name of which VTAM knows an             batch processing program. An application program
IMS system for establishing sessions. The name is        that has access to databases and MVS data
specified in a VTAM APPL definition statement and in     management facilities but does not have access to
the APPLID keyword of the IMS COMM system                the IMS control region or its message queues.
definition macro.
                                                         buffer invalidation. A technique for preventing the
archiving logs. The process of copying records or        use of invalid data in an IMS Sysplex data sharing
logs of IMS activity from the online log data set,


© Copyright IBM Corp. 1999                                                                                  263
environment. The technique involves marking all            database recovery. The process of restoring a
copies of data in IMS buffers invalid once a sharing       physically damaged DBDS by merging an image copy
IMS subsystem has updated that data.                       and logs or change accumulations.

checkpoint. In IMS, the point at which an application      Database Recovery Control (DBRC). A feature of the
program commits that the changes it has made to a          IMS Database Manager that facilitates easier
database are consistent and complete, and releases         recovery of IMS databases. DBRC maintains
database segments for use by other programs. You           information required for database recoveries,
can request checkpoints at appropriate points in a         generates recovery control statements, verifies
program to provide places from which you can restart       recovery input, maintains a separate change log for
that program if it, or the system, fails.                  database data sets, and supports the sharing of IMS
                                                           databases and areas by multiple IMS subsystems.
For an IMS system, a point in time from which the
system can start again if a failure makes recovery
                                                           DEDB. A direct-access database that consists of one
necessary. The checkpoint is performed by IMS itself.
                                                           or more areas, with each area containing both root
                                                           segments and dependent segments. DEDBs use a
cold start. The starting of IMS when it is initialized
                                                           data structure that allows them to be used for both
for the first time or when some error condition
                                                           hierarchic processing and journaling. The database is
prevents a warm or emergency restart.
                                                           accessed by using VSAM′s Media Manager.
command. A request from a terminal or AO
                                                           DL/I address space. An address space used by the
(automated operator) to perform a specific IMS
                                                           online IMS control program to contain most of the
service, such as altering system resource status or
                                                           DL/I code and control blocks. This option can be
displaying specific system information.
                                                           selected for the online IMS environment to provide an
commit. To make changes permanent for a resource           alternative virtual storage configuration.
in order to establish a new consistent status.
                                                           dynamic allocation/deallocation. A function that
control region. The MVS main storage region that           removes the requirement to allocate IMS databases,
contains the IMS control program                           area data sets, and certain system data sets through
                                                           job control language. A data set is allocated during
Data Language/I (DL/I). The IMS data manipulation          IMS initialization or when it is first used and is
language, a common high-level interface between a          deallocated when it is no longer used (that is, closed
user application and IMS. DL/I calls are invoked from      or stopped).
application programs written in languages such as
PL/I, COBOL, VS Pascal, C, and Ada. It can also be         Fast Path. IMS functions for applications that require
invoked from assembler language application                good response characteristics and that may have
programs by subroutine calls. IMS lets the user            large transaction volumes. Programs have rapid
define data structures, relate structures to the           access to main-storage databases (to the field level),
application, load structures, and reorganize               and to direct-access data entry databases. Message
structures.                                                processing is grouped for load balancing and
                                                           synchronized for database integrity and recovery.
data sharing. The concurrent access of databases by
two or more IMS subsystems. The IMS subsystems             IFP. IMS Fast Path program, a type of program
can be in one processor or in separate processors.         designed to operate with expedited message handling
They can share data at two levels: the database level      (EMH) in a Fast Path region.
and the block level.
                                                           IMS subsystem. An individual batch or online IMS
database control (DBCTL). An environment allowing          control program executing in an MVS address space.
full-function database and DEDBs to be accessed from
                                                           IMS system log. Logically, a single log made up of
one or more transaction management subsystems.
                                                           online data sets (OLDSs) and write-ahead data sets
database data set (DBDS).      A data set containing all   (WADSs).
or part of a database.
                                                           Intersystem Communication (ISC). An extension of
database description (DBD). The collection of macro        IMS Multiple Systems Coupling that permits the
parameter statements that define the characteristics       connection of IMS to another IMS subsystem, to
of a database, such as the database′s organization         CICS/MVS, or to a user-written subsystem, provided
and access method, the segments and fields in a            both subsystems use ISC.
database record, and the relationship between types
                                                           IRLM. An IMS component that provides lock
of segments.
                                                           management for use by IMS subsystems that share
                                                           data in an MVS environment.




264    IMS V6 Security Guide
lock management. The reservation of a segment by          RSR. IMS Remote Site Recovery, which provides
a program. Other programs are kept from using the         remote recovery for IMS DB full function databases,
segment until the program using it is done.               IMS DB Fast Path databases, IMS TM Message
                                                          Queues, and the IMS TM telecommunications network.
MPR. An IMS/ESA online message processing
region.                                                   system log data set (SLDS). The system log data set,
                                                          which is normally the tape data set that contains the
Not-IWAIT time. Elapsed time minus IWAIT time for         archived OLDS.
an event. Approximately equals to CPU time if there
is no interference.                                       transaction. A message from a terminal or an
                                                          application program that causes the application
online. Applicable in the IMS DB/DC, DBCTL, and           program logic to be executed.
DCCTL environments, unless otherwise indicated.
                                                          transaction command security. The use of system
online change. The process of adding, deleting, or        definition macros and security maintenance utility
replacing various IM resources without stopping the       control statements to permit specific application
system to redefine them.                                  programs to issue some of the IMS operator
                                                          commands.
online image copy. The process of creating an image
copy while the DBDS is online. Also, the image copy       two-phase commit. A two-step process by which
created by the process.                                   recoverable resources in an IMS system and an
                                                          external subsystem are committed. During the first
OLDS. The IMS/ESA online log data set that contains       the subsystems are polled to ensure that they are
the log records of all IMS/ESA activity.                  ready to commit. If all subsystems respond
                                                          positively, they are then told to execute commit
program specification block (PSB). The control block      processing.
that describes databases and logical message
destinations used by an application program. A PSB        unit of recovery. Work done on a protected resource
consists of one or more PCBs.                             between one sync point and the next.

recovery control (RECON) data sets. Data sets in          unit of work. A distinct unit of processing that can be
which Data Base Recovery Control stores information       released by the application program for use by other
about logging activity and events that might affect the   programs in the system.
recovery of databases.
                                                          XRF. A software function designed to minimize the
                                                          impact of various failures of IMS users.




                                                                                                  Glossary   265
266   IMS V6 Security Guide
List of Abbreviations
ACB            access control block in VSAM.             DNS       Domain Name System
               Application control block in IMS.
                                                         DM        database manager
ACF/VTAM       advanced communication
                                                         DL/I      data language I
               function/virtual telecommunications
               access method                             DLS       DL/I separate address space

AGN            application group name                    DLISAS    DL/I separate address space

AIB            application interface block               DRA       database resource adapter

AMS            access method services                    EMCS      extended multiple console support

AO             automatic operation                       EMH       expedited message handler

API            application programming interface         EMHB      expedited message handler buffer
                                                                   (terminal buffer)
APF            authorized program facility
                                                         ESA       enterprise systems architecture
APPC           advanced program-to-program
               communication; also advanced              ETO       Extended Terminal Option
               peer-to-peer communication                FDBR      fast database recovery
APPLID         VTAM application ID                       FIFO      first in, first out
ARM            automatic restart manager                 HD        hierarchic direct
BMP            batch message processing (IMS region)     HDAM      hierarchic direct access method
BTAM           basic telecommunications access           HIDAM     hierarchic indexed direct access
               method                                              method
CA             control area                              I/O PCB   input/output program communication
CI             control interval                                    block, also called TPPCB

CICS           Customer Information Control System       IBM       International Business Machines
                                                                   Corporation
CPIC           common programming interface for
               communications                            IFP       IMS Fast Path (IMS region)

CPU            central processing unit                   IMS       information management system

CQS            common queue service                      IPL       initial program load

DASD           direct access storage device              IRLM      IMS resource lock manager

DBCTL          database control                          ISC       intersystem communication

DBD            database description                      ISPF      interactive system productivity facility

DBDGEN         database description generation           ITOC      IMS TCP/IP OTMA connector

DBDS           database data set                         ITSO      International Technical Support
                                                                   Organization
DBRC           IMS/VS Database recovery control
                                                         JCL       job control language
DB2            DATABASE 2
                                                         LTERM     logical terminal
DC             database communication
                                                         MCS       multiple console support
DCB            data set control block
                                                         MPP       message processing program
DD             data set definition
                                                         MPR       message processing region (region in
DEADQ          dead letter queue
                                                                   which MPPs are run)
DEDB           data entry database
                                                         MSC       multiple systems coupling
DFSnnnnz       IMS message where nnnn are four
                                                         MTO       master terminal operator
               numerics and the suffix z indicates the
               user action I = information, A =          MVS       multiple virtual storage
               action, W = warning                       NAK       Network Acknowledge
DFSxxxxx       IMS module, control block, table, or      OLDS      online log data set
               PROCLIB member



© Copyright IBM Corp. 1999                                                                              267
OSAM           overflow sequential access method      SMP      system modification program
OTMA           Open Transaction Manager Access        SMU      security maintenance utility
PARMLIB        MVS parameter library data set         SNA      systems network architecture
PDS            partitioned data set                   SPA      scratchpad area
PROCLIB        procedure library data set; IMS        TCB      task control block
               procedures are in IMSESA.PROCLIB
                                                      TCP/IP   transmission control protocol/Internet
               and MVS procedures are in
                                                               protocol
               SYS1.PROCLIB
                                                      TM       transaction manager
PSB            program specification block, made up
               of PCBs, both I/O and database         TSO      time sharing option

PTF            physical twin forward, also program    UOW      unit of work
               temporary fix                          VSAM     virtual storage access method
RAA            root addressable area                  VSO      virtual storage option
RACF           resource access control facility       VTAM     virtual telecommunications access
RECON          recovery control                                method

RSR            remote site recovery                   WLM      work load manager

SAF            system access facility or system       XCF      extended control facility
               authorization facility                 XRF      extended recovery facility
SLUP           secondary logical unit parameter       Y2000    Year 2000
SLUTYPEP       secondary logical type parameter




268    IMS V6 Security Guide
Index

A                                                    D
abbreviations 267                                    database resource adapter (DRA) 166
Accessor environment element (ACEE) 156              DB/DC 18, 50
ACEE 156                                             DB2 1, 18, 121, 134
acronyms 267                                         DBCTL 18, 50, 89, 90, 95, 127, 161, 162, 165, 166
advanced program-to-program communications           DEDB 18
 (APPC) 147                                             DEDB databases 50
AGN 20, 52, 143, 191                                 DFHDBMP 168
AIB 193                                              DFS2180I 119
Allocate program specification block (APSB) 191      DFS2467 120
AO 28, 29, 40, 51, 87, 88, 168                       DFS2469W 107
   application program 88                            DFS286I 120
AO program 118, 172, 174, 182                        DFS3432 195
APPC 1, 49, 92, 121, 147, 154, 187                   DFS3649 120
APPC/IMS 150, 151, 182, 183                          DFS3649A 188
APPC/MVS 147, 148, 150, 154, 187                     DFS3656A 188
   ACCESS keyword 148                                DFS3662 120
   SECURITY keyword 147                              DFSBSEX0 123, 184, 187, 205
application group name (AGN) 140                     DFSCCMD0 15, 50, 51, 66, 71, 77, 84, 85, 87, 88, 89,
application interface block (AIB) 193                 90, 93, 94, 112, 113, 119, 127, 147, 150, 151, 168, 172,
APSB 145, 151                                         173, 182, 184, 200, 211
autologoff 55, 191, 202                              DFSCMPR0 184
Automated Operator 13, 15, 166                       DFSCSGN0 41, 66, 71, 183, 186, 188
autosignoff 55, 191, 202                             DFSCTRN0 16, 17, 41, 50, 66, 71, 97, 98, 99, 122, 134,
                                                      147, 150, 151, 174, 183, 184, 185, 186
                                                     DFSCTSE0 122, 134, 135, 154, 183, 184, 237
B                                                    DFSGMSG0 188
bibliography 259                                     DFSIINB0 119
BMP 9, 20, 134, 161, 162                             DFSINTX0 187
BTAM 2, 29                                           DFSISIS0 19, 20, 52, 141, 143, 144, 145, 162, 186
Build Security Environment exit (DFSBSEX0)   187,    DFSISMP0 241
 205                                                 DFSISPBx 115
                                                     DFSISTCx 115, 116
                                                     DFSISTLx 115
C                                                    DFSISTTx 115
CDBM 89, 95, 166, 168
                                                     DFSSGNX0 66, 67, 68, 69, 185, 188
CICS 1, 89, 94, 95, 147, 161
                                                     DFSXLIC0 119
   ISC 95
                                                     DRA 95, 165, 166
   SEND/RECEIVE interface 95
cold start 100
COMM macro 2, 32                                     E
   PASSWD parameter 32                               E-MCS console 9, 13, 90, 113, 173, 183, 191, 199
Command Authorization exit routine                   Emergency restart 100
 (DFSCCMD0) 15, 77, 84, 86, 92, 95, 113, 119, 182,      COLDSYS keyword 100
 211, 244                                            ETO terminals 11, 12, 16, 65, 86, 191
Common programming interface                         Extended Terminal Option (ETO) 242
 communications 191
Common queue server (CQS) 171
CONTROL PROGRAM/REGION 52                            F
CPI-C 20, 124, 145, 148, 151, 191                    Fast Path 87
CQS 171                                              finance device   68




© Copyright IBM Corp. 1999                                                                                269
                                                      IMS (continued)
G                                                       autologoff 55, 70, 186
generation data groups (GDGs)    140                    autologon printers 68
Glossary 263                                            Automated Operator 87
GU 32                                                   autosignoff 55, 70, 186
                                                        BMP 9, 120, 121
                                                        BMPUSID keyword 196
I                                                       CHNG call 112, 121, 122, 152, 184, 187, 197
IBMBATCH procedure 145
                                                        CMD call 112, 119, 168, 174, 184
ICHRFR01 35
                                                        CMDMCS parameter 90
ICHRRCDE 35
                                                        cold start 99, 103
IMS 1, 151
                                                        COMM macro 2, 3, 23, 24, 33, 77
   /BROADCAST command 92, 182
                                                        Common queue structures (CQS) 200
   /CHAnge command 14
                                                        conversational program 123
   /CHEckpoint command 66
                                                        CTB control block 106
   /DISPLAY APPC command 93
                                                        data sets 135
   /DISPLAY command 95, 112, 155
                                                        DB/DC environment 198
   /ERE COLDSYS 101
                                                        DBCTL 147, 161
   /ERE command 25, 38, 46, 100, 168
                                                        DCCTL environment 198
   /EXIT command 83
                                                        default terminal security 7, 13, 77
   /FORMAT command 95
                                                        Dependent regions 19
   /IAM command 12, 70
                                                        DFSISMP0 241
   /LOCK command 12, 18, 51, 70, 112, 127
                                                        DFSPBxxx member 79, 90, 95, 98, 103
   /LOG command 182
                                                        DL/I allocate PSB 191
   /MODIFY command 36, 195
                                                        DL/I AUTH call 19
   /MODIFY COMMIT 84, 99
                                                        DL/I CMD call 15
   /MODIFY PREPARE RACF 84, 99
                                                        DL/I ICMD call 79
   /NRE command 13, 25, 38, 46, 62, 100, 168
                                                        DLISAS address space 131
   /OPNDST command 188
                                                        DRA 162, 166
   /RCLSDST command 86
                                                        ETO terminals 55, 61, 66, 77, 86, 185
   /RDISPLAY command 92, 95, 182
                                                        Fast Path 87
   /RELEASE command 112
                                                        Field sensitivity 19
   /RMLIST command 92
                                                        GCMD call 184
   /SECURE APPC command 93, 151
                                                        GU call 32
   /SECURE APPC FULL command 192
                                                        I/O PCB 120
   /SECURE command 46, 49, 150, 155, 158
                                                        ICMD call 13, 32, 89, 112, 118, 119, 121, 168, 182,
   /SECURE OTMA command 94
                                                          184
   /SET command 112
                                                        IMS TCP/IP 154
   /SIGN command 86, 151, 188
                                                        IMS.ACBLIBx 21
   /SIGN ON command 12, 38, 55, 63, 140
                                                        IMS.MATRIXx 21, 61
   /STOp command 15, 83, 169
                                                        IMS.MODBLKSx 21
   /TEST command 95
                                                        IMSCTRL macro 140
   /UNLOCK command 12, 18, 51, 70, 112, 127
                                                        IMSGEN macro 2, 23, 24, 33, 77
   ACEE control block 105
                                                        INIT call 127
   AGN 19, 161, 162
                                                        initialization 58
   AGN function 141
                                                        installations 1
   AGN parameter 19
                                                        ISC 1
   ALOT parameter 202
                                                        ISIS parameter 98, 99
   AO program 112
                                                        ISRT call 112
   AOIS parameter 15, 99, 113, 118, 168
                                                        ITOC 1, 147
   APPC 1, 49
                                                        KEYWD macro 81
   APPC/IMS 147
                                                        log records 64
   APPCSE parameter 99
                                                        LTERM security 13, 70
   APPLCTN macro 163
                                                        LU 6.2 device 79
   application program 52
                                                        Master terminal 13
   APSB call 124, 191
                                                        MATRIX data sets 41
   APSB security 9
                                                        MPP region 120
   ASOT parameter 55, 202
                                                        MSC 1, 147, 151, 185
   AUTH call 112, 123, 131, 133, 135, 184, 187, 197




270   IMS V6 Security Guide
IMS (continued)
    MTO 1, 25, 41, 100                                   M
    Multiple systems coupling (MSC) 151                  MCS console 9, 13, 90, 113, 173, 183, 191, 199
    OLDS log data set 107                                Message Queuing Series (see MQSeries) 158
    Online change 161                                    MPP 134
    OTMA 1, 49, 93, 147, 154                             MQSeries 147, 158, 161
    physical terminal 55                                   IMS bridge 159
    printers 68                                            SecurityScope field 158
    program-to-program switch 120, 122, 196              MSC 1
    PSB 20, 161, 192                                     MSC program routing exit (DFSCMPR0) 184
    PSBGEN 19, 127                                       MVS 151
    PTERM 81
    RACROUTE REQUEST=LIST 58
    RCF parameter 62, 65, 97, 99
                                                         O
                                                         OLDS log 116
    RCFTCB parameter 105
                                                         OSAM 18, 50
    RCMD call 184
                                                         OTHER SYSTEMS security option 52
    resources 1
                                                         OTMA 1, 49, 93, 154, 187
    SCD control block 106
                                                            /DISPLAY OTMA command 93
    Security 11
                                                            Callable interface 156
    SECURITY macro 3, 4, 7, 8, 13, 15, 23, 24, 25, 33,
                                                            Client bid 156
      34, 60, 62, 65, 71, 77, 100, 140, 165, 168, 192
                                                            client bid command 155
    Segment sensitivity 19
                                                            ITOC 154
    SGN parameter 65, 67
                                                            OTMA client 122
    shared queues 1, 172, 183, 187, 191
                                                            OTMA Connection 154
    sign-off process 105
                                                         OTMA Prerouting and Destination Resolution
    sign-on process 105
                                                          exit 122
    sign-on security 37
                                                         OTMA transaction 122
    SMU 2
                                                         output-only devices 68
    SPA 122
    Stage 1 34, 57
    startup parameters 43                                P
    Static terminals 55, 77, 85                          Participant Adapter Parameter List (PAPL)     95, 165
    SYSDEF macro 25, 56                                  password security
    system definition 1                                     /LOCK and /UNLOCK command 242
    TCO 13                                               Physical terminals 11
    TRANAUTH keyword 101                                 procedures, IMS
    TRANSACT macro 16, 172                                  Security 245
    TRN parameter 97, 99, 104                            Programs DL/I CMD call 15
    TYPE keyword 41                                      Programs DL/I ICMD call security 15
    XRF environment 187                                  PSB 9, 20
IMS terminals 57                                         PSBGEN 19, 128
IMSXCF 94                                                   Field level sensitivity 128, 129
Initialization exit (DFSINTX0) 187                          Key sensitivity 128, 129
ISC 1, 68, 94                                               PROCOPT keyword 128
ITOC 1                                                      Segment sensitivity 128
    security 156

                                                         R
J                                                        RACF 2, 3, 9, 12, 15, 20, 23, 24, 50, 52, 56, 63, 77, 82,
JCL 131                                                   97, 98, 99, 127, 134, 141, 150, 151, 152, 172, 173, 174,
  USER parameter      131                                 182, 183, 184
                                                           ACEE control block 121, 158
                                                           ADDSD command 136, 139
L                                                          ADDUSER command 63, 64, 144
Logical terminals 11
                                                           AIMS class 144, 145, 151, 192
LTERM 14, 16, 25, 65, 68, 116, 120
                                                           APPCTP class 151
LU 6.2 147, 148, 151, 182, 191, 242
                                                           APPL class 21, 140, 145
                                                           CIMS class 150, 156, 169




                                                                                                      Index   271
RACF (continued)                                    RCLASS 35
  CIMS/DIMS classes 15, 66, 70, 82, 118, 194, 200   recovery log data sets (RLDSs) 140
  CIMS/DIMS profiles 83                             resource access control facility (RACF)
  CLASS class 148                                   Resource Access exit routine (DFSISIS0)     19, 20, 186
  class descriptor table 194                        resource access security 61, 243
  Class descriptor table (ICHRRCDE) 35              Router table (ICHFR01) 35
  CLASS keyword 191                                 RSR 33
  data space option 36, 191, 194
  database class 130, 135
  DATASET class 21, 130, 139, 145                   S
  DIMS class 169                                    SAF 1
  EXITRC field 135                                  SECLVL 37
  FACILITY class 9, 35, 155, 159, 191               Secondary Log Data Sets (SLDSs) 140
  FEEDBACK area 135                                 Security 1
  FIELD class 135                                      security parameters 2
  FIMS/HIMS classes 19                                 security tables 2
  generic profiles 82                                  Sysplex 9
  GTERMINL class 56, 57                             Security macro 3, 8, 97, 100, 103, 113, 141, 183, 244
  ICHRFRTB macro 35                                    AGNEXIT parameter 186
  IMSPROG profile 83                                   ISIS parameter 141
  MQADMIN class 159                                    PASSWD=FORCE parameter 80
  OIMS class 19, 134                                   PASSWD=YES parameter 80
  OTHER class 134, 135                                 RCLASS parameter 98, 192
  passticket 161                                       resource access security 244
  PERMIT command 18, 21, 65, 118, 144, 146             SECCNT= keyword 115
  PIMS/QIMS classes 18, 50                             SECLVL parameter 186
  RACF TCB 105                                         SECLVL=FORCTRAN,FORCSIGN 97
  RACINIT command 156                                  SECLVL=TRANAUTH,SIGNON 97
  RACROUTE command 194                                 TERMNL=FORCE parameter 80
  RACROUTE macro 117, 121                              TERMNL=YES parameter 80
  RCLASS 34                                            TRANCMD keyword 113, 116
  RDEFINE command 59, 202                              TYPE keyword 97, 141, 186
  report writer 63                                     TYPE=AGNEXIT 98
  RESLEVEL profile 160, 161                            TYPE=TRANEXIT keyword 183
  REVERIFY command 9, 17, 117, 191, 202             security maintenance utility (DFSISMP0)
  RVARY command 195                                    Command Authorization exit routine 244
  RVFY parameter 201                                   description 241, 246
  SAF interface 123                                    execution 246
  security parameters 147                              IMS resource access security 243
  security profile 36, 37                              input statement operands 246
  SEGMENT class 135                                    LTERM security 242
  SETROPTS command 35, 58, 97, 99, 136, 146, 160,      output 253
    194                                                password security 242
  sign-on 121                                          resource access control facility (RACF) 244
  SIMS/UIMS classes 19                                 sign-on verification 244
  STARTED class 21                                     transaction command security 243
  STATUS field 134, 135                             SECURITY procedure, process 245
  SYSPROG profile 83                                Security reverification exit 135
  TERMINAL class 12, 56, 57                         Security reverification exit (DFSCTSE0) 183, 184, 237
  TERMINAL/GTERMINL classes 58, 64                  shared queues 1, 171
  TERMINAL/GTERMINL profiles 59                     sign-on exit (DFSSGNX0) 66
  TIMS class 150, 156                               Sign-on verification 12, 244
  TIMS/GIMS classes 17, 66, 106, 117, 194              /SIGN command 244
  TRANAUTH keyword 106                              Sign-On/Off Security exit (DFSCSGN0) 183, 186
  USERDATA field 134                                SLU-P 68
  uses with security maintenance utility 244        SMF Type 80 record 63
  WIMS class 19                                     SMU 2, 12, 14, 15, 16, 20, 23, 24, 40, 50, 51, 60, 77,
                                                      79, 88, 97, 98, 99, 112, 127, 141, 151, 162, 164, 172,
                                                      174, 182, 191, 202




272   IMS V6 Security Guide
SMU (continued)
   Access control 182
   CTRAN statement 88, 114
   Input statement 80
   PASSWD parameter 98
   Password security 182
   SMU GEN 127
   TCOMMAND statement 88, 114
   TERMNL parameter 98
   Transaction command security 182
   utility 80
Stage 1 168
Static terminals 11, 12, 16
sysplex 195
Sysplex security 9
System Authorization Facility (SAF) 147, 151


T
TCP/IP 1
TRANCMD keyword 40
Transaction authorization 101
Transaction authorization exit (DFSCTRN0)   16, 17,
  183
transaction command security 243


U
utilities
    security maintenance   241


V
VSAM 18, 50
VTAM 2, 29, 151
  ACB 33
  APPLID 21


X
XCF 157, 159, 195
  JOIN 156
XRF 33, 202




                                                      Index   273
274   IMS V6 Security Guide
ITSO Redbook Evaluation
IMS V6 Security Guide
SG24-5363-00

Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete this
questionnaire and return it using one of the following methods:
 •   Use the online evaluation form found at http://www.redbooks.ibm.com/
 •   Fax this form to: USA International Access Code + 1 914 432 8264
 •   Send your comments in an Internet note to redbook@us.ibm.com

Which of the following best describes you?
__Customer       __Business Partner     __Solution Developer       __IBM employee
__None of the above

Please rate your overall satisfaction with this book using the scale:
(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)
Overall Satisfaction      ____________

Please answer the following questions:

Was this redbook published in time for your needs?          Yes____ No____

If no, please explain:
_____________________________________________________________________________________________________

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________



What other redbooks would you like to see published?
_____________________________________________________________________________________________________

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________



Comments/Suggestions:     (THANK YOU FOR YOUR FEEDBACK!)
_____________________________________________________________________________________________________

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________




© Copyright IBM Corp. 1999                                                                               275
                        IMS V6 Security Guide
SG24-5363-00
Printed in the U.S.A.




                        SG24-5363-00




IBML

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:71
posted:10/10/2011
language:English
pages:290