APAR status
Closed as canceled.
Error description
This APAR documents changes to the DB2 Administration Guide Volume 1 SC26488800 which did not make Version 3 GA pubs. This information is continued from II07478 & II07866. This Info. APAR is continued in II08225 & II08603. 5740xyr00 R310 =============================================================== Version 3 Book Title: DB2 Admin. Guide, Vol. 1 Pages: 2-312 Change Description: Replace the section 'Coordinating DB2 and CICS Security' with the following: COORDINATING DB2 AND CICS SECURITY The following mechanisms coordinate DB2 and CICS Security: o THE AUTH OPTION SPECIFIED IN THE RCT: The CICS attachment facility uses the AUTH specification to select authorization IDs to pass to DB2 for a particular transaction. You specify the AUTH option in macro DSNCRCT TYPE=COMD TYPE=ENTRY, and TYPE=POOL. See "DSNCRCT TYPE=ENTRY" on page 2-324 for instructions. o DB2 PRIVILEGES AND AUTHORITIES: You control access within DB2 by granting, not granting, or revoking privileges and authorities. See "Explicit Privileges and Authorities" on page 5-14. o THE RACF ROUTER TABLE: If RACF is installed, you need to define the CICS-to-DB2 connection to RACF. For information on how to do this, see "Add Entries to the RACF Router Table" on page 5-77. o STANDARD CICS SECURITY MECHANISMS: You can control users' ability to enter DB2 and attachment facility commands from CICS terminals through CICS security mechanisms. See "Chapter 6-2. Monitoring and Controlling DB2 and Its Connections" on page 6-25 for information on the DB2 commands that can be issued in the CICS environment. HOW PRIMARY AND SECONDARY AUTHORIZATION WORK To set up security definitions for the CICS attachment facility, you should understand how DB2, CICS, and RACF work together to coordinate security. The simple scenarios in this section show how these systems use primary and secondary authorization to permit access to a DB2 plan from a CICS terminal. Primary Authorization To use primary authorization, you can specify an explicit character string or one or more of the subparameters TERM, TXID, USER, or USER ID on the AUTH option. Figure 1 shows how DB2 and CICS coordinate security with a primary authorization ID. +----------------------------------------------------------+ | | | 1. Assume these definitions are set up: | | | | CICS: In the RCT, TRN1 is defined as having | | AUTH=USERID and plan T1PLAN. | | | | DB2: USER1 has execute authority on T1PLAN. | | | | 2. A user logs on to CICS as USER1 and issues | | transaction TRN1. | | | | 3. The CICS attachment facility performs a DB2 sign-on | | and sends DB2 the primary authorization ID, USER1.* | | DB2 recognizes that USER1 has execute authority on | | T1PLAN and permits access. | | | | * Note that CICS signs on only if it is not reusing a | | thread with the same TXID and sign-on ID. | | | +----------------------------------------------------------+ Figure 1. CICS Attachment Facility: Primary Authorization Secondary Authorization To use secondary authorization, specify AUTH=GROUP as described under the GROUP subparameter in "DSNCRCT TYPE=ENTRY" on page 2-324. Although it is possible to specify AUTH=(grpname), we do not recommend that you do so; using a group name as a primary authorization ID is not a good security technique. Figure 2 shows how DB2, CICS and RACF coordinate security with secondary authorization IDs. +----------------------------------------------------------+ | | | 1. Assume these definitions are set up: | | | | CICS: In the RCT, TRN1 is defined as having | | AUTH=GROUP and plan T1PLAN. | | | | | | DB2: G33 has execute authority on T1PLAN. | | | | RACF: USER1 is defined as belonging to 3 groups:| | SPIFFY, ACCT, and G33. SPIFFY is USER1's default| | secondary authorization ID. The list-of-groups | | option is on. | | | | 2. A user logs on as USER1 and issues transaction TRN1. | | | | 3. The attachment facility performs a DB2 sign-on and | | sends DB2 the primary authorization ID, USER1, and | | the default secondary authorization ID, SPIFFY.* | | | | 4. DB2 calls the DB2 sign-on exit, DSN3SSGN, which | | calls RACF. RACF sends all of the secondary | | authorization IDs for USER1 to DB2. DB2 recognizes | | that G33 has execute authority on T1PLAN and permits | | access. | | | | * Note that CICS signs on only if it is not reusing a | | thread with the same TXID and sign-on ID. | | | +----------------------------------------------------------+ Figure 2. CICS Attachment Facility: Secondary Authorization When the RACF list-of-groups option is on, the sample sign-on exit denies access to authorization IDs that are not defined to RACF. You can change the sample sign-on exit to bypass RACF checking for transactions which do not use AUTH=GROUP. For instructions, see "Sample Exit Routines" on page X-60. HOW THE ATTACHMENT FACILITY SELECTS AUTHORIZATION IDS When a CICS transaction issues its first SQL call, the attachment facility determines which primary and secondary authorization IDs to send to DB2 based on the subparameters specified for the AUTH option. See "DSNCRCT TYPE=ENTRY" on page 2-324 for detailed information about these subparameters. The authorization ID CICS sends to DB2 can be any one of the following. o The VTAM application name for the CICS system; use AUTH=SIGNID. o A character string of 1-8 characters; use AUTH=(string). o The CICS terminal ID; use AUTH=TERM. o The CICS transaction ID (TXID); use AUTH=TXID. o The CICS group ID (GROUP); use AUTH=GROUP. o The user-defined ID (SIGNID) in macro DSNCRCT TYPE=INIT. You can specify three subparameters to indicate the order that the attachment facility selects from transaction- related information to form an authorization ID. The attachment facility uses the first valid authorization value in the supplied list. Figure 3 shows how this works. +----------------------------------------------------------+ | | | 1. AUTH=(USERID,TERM,TXID) is specified for transaction | | TRN1. | | | | 2. The attachment facility determines if USERID is valid| | by checking to see if a signed-on user ID is | | associated with TRN1. | | | | 3. If USERID is not a valid value, the attachment | | facility determines if TERM is valid by checking to | | see if a terminal associated with TRN1. | | | | 4. If TERM is not a valid value, the attachment facility| | selects TXID (the transaction ID). | | | +----------------------------------------------------------+ Figure 3. CICS Attachment Facility: Selecting an Authorization ID If you are using CICS Version 4, note that a signed-on user ID is associated with all transactions; AUTH=(USERID,TXID) is equivalent to AUTH=(USERID). ================================================================ Version 3 Book Title: DB2 Admin. Guide, Vol. 1 Pages: 2-325 Change Description: Replace the bulleted list with the following: To use the GROUP option, you must set up definitions as follows: o Activate the RACF list-of-groups option. o Define your CICS system initialization table (SIT) to have EXTSEC=YES (or SEC=YES for CICS Version 4). If you are using the multiple region option (MRO), define the SIT for all CICS systems as EXTSEC=YES or SEC=YES. o Define the userid in the CICS sign-on table (SNT) to have EXTSEC=YES. (This does not apply to CICS Version 4, because CICS Version 4 does not use a sign-on table.) o Define a DB2 sign-on exit which will check authorization using the secondary ID. The default sign-on exit (DSN3@SGN), shipped in the DB2 load library (SDSNLOAD), does not work for AUTH=GROUP. Instead, you can run installation job DSNTIJEX to assemble the sample sign-on exit, which checks the secondary authorization IDs to see if they have valid access to a plan. o When the user signs on to a CICS terminal-owning region (TOR), the TOR must propagate the authorization ID to the CICS application-owning region (AOR). For more information on that propagation, see the description of ATTACHSEC in the applicable version of the CICS Intercommunication Guide. o For releases earlier than CICS Version 4, the user must be signed on to a terminal for the AUTH=GROUP option to apply. For example, if a transaction is started without a terminal, then AUTH=GROUP does not apply. ================================================================ Version 3 Book Title: DB2 Admin. Guide, Vol. 1 Pages: 2-327 Change Description: Remove the following inaccurate sentence the description of 'DPMODE=': 'Specifies a default for the DPMODE parameter in other TYPES of this macro.' The DPMODI parameter, described on page 2-315, specifies a default for the DPMODE parameter in other TYPES of the macro. ================================================================ Version 3 Book Title: DB2 Admin. Guide, Vol. 1 Pages: 3-32 Change Description: Replace the bulleted list under 'Updating CDB Values' with: o Changes to SYSLUMODES take effect the next time DDF is started. o Changes to SYSLUNAMES and SYSLOCATIONS take effect as follows: -- If DDF has not yet tried to communicate with a particular remote location, rows added to SYSLUNAMES and SYSLOCATIONS take effect when DDF attempts to communicate with that location. -- If DDF has already attempted communication with a particular location, rows added to SYSLUNAMES and SYSLOCATIONS take effect the next time DDF is started. o Changes to SYSUSERNAMES and SYSMODESELECT take effect at the next thread access. ================================================================ Version 3 Book Title: DB2 Admin. Guide, Vol. 1 Pages: 3-36 Change Description: Replace the second paragraph and bulleted list under 'Interpreting CNOS Messages' as follows: 'CNOS processing always takes place, but you can control when it happens for a specific LU name and mode name combination. You do this with the AUTO column in the SYSLUMODES table of the CDB. Specify AUTO=NO so that CNOS takes place at the time of the first needed reference to that MODENAME-LUNAME combination. If you specify AUTO=YES, CNOS takes place at the time DDF is started, if the other system is available.' ================================================================ Version 3 Book Title: DB2 Admin. Guide, Vol. 1 Pages: 3-55 Change Description: Replace the 3'rd through 6'th paragraphs under 'Tune GRS for DB2' with this: 'You must exclude from sharing the bootstrap data set, the DB2 catalog and directory, and all user data sets that are not shared resources. For information on managing MVS catalogs with shared read-only data, see the appropriate version of 'DFSMS/MVS: Managing Catalogs'.' ================================================================ This Info. APAR is continued in II08225.
Local fix
Problem summary
Problem conclusion
Temporary fix
Comments
close for INTERNET viewing
APAR Information
APAR number
II08170
Reported component name
PB LIB INFO ITE
Reported component ID
INFOPBLIB
Reported release
001
Status
CLOSED CAN
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
1994-09-01
Closed date
1997-10-31
Last modified date
1997-10-31
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Applicable component levels
[{"Business Unit":{"code":null,"label":null},"Product":{"code":"SG19O","label":"APARs - MVS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEPEK","label":"Db2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]
Document Information
Modified date:
14 December 2020