Processing of connection requests

Db2 completes the following steps to process a connection request:

1. Db2 obtains the initial primary authorization ID. As shown in the following table, the source of the ID depends on the type of address space from which the connection was made.

   Table 1. Sources of initial primary authorization IDs

   Source	Initial primary authorization ID
   TSO	TSO logon ID.
   BATCH	USER parameter on JOB statement.
   IMS control region or CICS®	USER parameter on JOB statement.
   IMS or CICS started task	Entries in the started task control table.
   Remote access requests	Depends on the security mechanism used.

2. RACF® is called through the z/OS® system authorization facility (SAF) to check whether the ID that is associated with the address space is authorized to use the following resources:
   • The Db2 resource class (CLASS=DSNR)
   • The Db2 subsystem (SUBSYS=ssnm)
   • The requested connection type
   The SAF return code (RC) from the invocation determines the next step, as follows:

   • If RC > 4, RACF determined that the RACF user ID is not valid or does not have the necessary authorization to access the resource name. Db2 rejects the request for a connection.
   • If RC = 4, the RACF return code is checked.
     • If RACF return code value is equal to 4, the resource name is not defined to RACF and Db2 rejects the request with reason code X'00F30013'.
     • If RACF return code value is not equal to 4, RACF is not active. Db2 continues with the next step, but the connection request and the user are not verified.
   • If RC = 0, RACF is active and has verified the RACF user ID; Db2 continues with the next step.
3. If RACF is active and has verified the RACF user ID, Db2 runs the connection exit routine. To use Db2 secondary IDs, you must replace the exit routine.
   If you do not want to use secondary IDs, do nothing. The IBM®-supplied default connection exit routine continues the connection processing. The process has the following effects:

   • The Db2 primary authorization ID is set based on the following rules:
     • If a value for the initial primary authorization ID exists, the value becomes the Db2 primary ID.
     • If no value exists (the value is blank), the primary ID is set by default, as shown in the following table.

       Table 2. Sources of default authorization identifiers

       Source	Default primary authorization ID
       TSO	TSO logon ID
       BATCH	USER parameter on JOB statement
       Started task, or batch job with no USER parameter	Default authorization ID set when Db2 was installed (UNKNOWN AUTHID on installation panel DSNTIPP)
       Remote request	None. The user ID is required and is provided by the DRDA requester.

   • The SQL ID is set equal to the primary ID.
   • No secondary IDs exist.
4. Db2 determines if TSO and BATCH connections that use DSN, RRSAF, and Utilities are trusted.

   For a TSO and BATCH connection that uses DSN, RRSAF, and Utilities, Db2 checks to see if a matching trusted context is defined for the primary authorization ID and the job name. If a matching trusted context is found, the connection is established as trusted.