Managing connection requests from local applications

Different local processes enter the access control procedure at different points, depending on the environment in which they originate.

The following processes go through connection processing only:

Requests originating in TSO foreground and background (including online utilities and requests through the call attachment facility)
JES-initiated batch jobs
Requests through started task control address spaces (from the z/OS® START command)

The following processes go through connection processing and can later go through the sign-on processing:

The IMS™ control region.
The CICS® recovery coordination task.
DL/I batch.
Applications that connect using the Resource Recovery Services attachment facility (RRSAF).

The following processes go through sign-on processing:

Requests from IMS dependent regions (including MPP, BMP, and Fast Path)
CICS transaction subtasks

IMS, CICS, RRSAF, and DDF-to-DDF connections can send a sign-on request, typically to execute an application plan. That request must provide a primary ID, and can also provide secondary IDs. After a plan is allocated, it need not be deallocated until a new plan is required. A different transaction can use the same plan by issuing a new sign-on request with a new primary ID.

Processing of connection requests
A connection request makes a new connection to DB2; it does not reuse an application plan that is already allocated. Therefore, an essential step in processing the request is to check that the ID is authorized to use DB2 resources.
Using secondary IDs for connection requests
If you want to use DB2 secondary authorization IDs, you must replace the default connection exit routine. If you want to use RACF® group names as DB2 secondary IDs, the easiest method is to use the IBM®-supplied sample routine.
Processing of sign-on requests
Requests can come from IMS-dependent regions, CICS transaction subtasks, or RRS connections. For each of these types of requests, the initial primary ID is obtained immediately before a plan for the transaction is allocated. A new sign-on request can run the same plan without de-allocating and reallocating the plan.
Using secondary IDs for sign-on requests
If you want the primary authorization ID to be associated with DB2 secondary authorization IDs, you must replace the default sign-on exit routine.
Using sample connection and sign-on exit routines for CICS transactions
For a CICS transaction to use the sample connection or sign-on exit routines, the external security system, such as RACF, must be defined to CICS.

Parent topic: Managing access through RACF