DB2 Server for VSE & VM: Application Programming

How DB2 Establishes User IDs for CICS/VSE Transactions

Online DB2 Server for VSE transactions need not issue an SQL CONNECT to establish the user id within the database manager. When a transaction does not issue a CONNECT statement with the "userid IDENTIFIED BY password" clause, DB2 Server for VSE online support attempts to establish the user ID for the transaction.

This implicit CONNECT capability is useful if your installation requires its terminal users to sign-on using the CESN transaction. For many DB2 Server for VSE transactions, your installation might consider the sign-on verification sufficient. It may also be useful if your installation has just installed the system, and finds it convenient to have all users identified by one name (for example, TESTUSER).

DB2 Server for VSE online support establishes a user ID for CICS/VSE transactions as follows:

  1. If the transaction issues an SQL CONNECT statement with the "userid IDENTIFIED BY password" clause, the user ID is established explicitly for the application.
  2. If the transaction does not issue such a CONNECT statement, the online support attempts to establish the user ID implicitly as follows:
    1. If the transaction had a user ID established for a previous logical unit of work, and the previous logical unit of work did not specify the RELEASE option for COMMIT WORK or ROLLBACK WORK, that user ID is used. (Remember that the connection to the application server is dropped every time a logical unit of work ends with release; thus, the user ID has to be re-established if the transaction has more than one logical unit of work ending with release.) Otherwise...
    2. If the user has signed on using the CESN transaction and the transaction is associated with a terminal, the sign-on user ID is used for the user ID. Otherwise...
    3. The user ID that was specified as an input parameter to the transaction that enabled the DB2 Server for VSE online support to a particular server becomes the user ID. This transaction could be either CIRB or CIRA. The person that invoked CIRB or CIRA will know what the user ID is. However...
    4. A user ID need not be specified when CIRB or CIRA is invoked. It is an optional parameter. If no user ID was specified, and none of the previous cases applied, the user ID established for your transaction is CICSUSER.

Once the user ID is determined as described above, one more requirement must be met in order to successfully complete the connection to the application server. Either the specific user ID must have been granted CONNECT authority or "ALLUSERS" must have been granted CONNECT authority. "ALLUSERS" is a special user ID that permits any user ID to be implicitly connected without having been specifically granted CONNECT authority. "ALLUSERS" can be used by the DBA to turn on or off the implicit connect capability.

Earlier in this book, it was recommended that you always explicitly connect to the application server to avoid confusion. However, it is recognized that many installations have terminal operators that need not be aware of DB2 Server for VSE user ID or authorization capabilities. In these cases, the DB2 Server for VSE implicit CONNECT support can be very useful. For more details on the CICS transaction environment, see the DB2 Server for VSE & VM Database Administration manual.

User IDs for Remote CICS/VSE Transactions

For online DB2 Server for VSE transactions which are accessing a remote server and which issued an SQL CONNECT statement with the "userid IDENTIFIED BY password" clause to establish the user ID within the database manager, the user ID is established explicitly for the transaction.

For online DB2 Server for VSE transactions which are accessing a remote server and which did not issue an SQL CONNECT statement with the "userid IDENTIFIED BY password" clause to establish the user id within the database manager, the Online Resource Adapter will attempt to establish the user ID for the transaction implicitly as follows:

  1. If the transaction had a user ID established for a previous remote logical unit of work, and the previous logical unit of work did not specify the RELEASE option for COMMIT WORK or ROLLBACK WORK, and the transaction did not switch to another application server, that user ID and its corresponding password are used. (Remember that every time a logical unit of work ends with RELEASE or the transaction switched to another application server, and you enter another SQL statement, you are implicitly connected as the CICS signon userid. Therefore, the user ID has to be re-established if the transaction has more than one logical unit of work ending with RELEASE or if the transaction is switching application servers.)
  2. The user ID returned by the CICS ASSIGN command is used for the user ID.

|Using Batch for Remote CICS/VSE Transactions

|Application programs running in batch can connect to |remote application servers, process some work, and then CONNECT to |another application server (local or remote) and do more processing. | | |VSE Batch application programs which are accessing a remote server |and use the SQL CONNECT statement, can manipulate and access remote data |managed by application servers. The CONNECT statement must be the first |SQL statement issued by the Batch application. The VSE Batch |application only accesses one remote database per unit of work.

|The current unit of work must be completed by using the COMMIT or ROLLBACK |statements before the CONNECT statement can be used to switch to another |userid or application server.

|Before a batch application program can access a remote application server, |the following tasks must be completed: |

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]