To preprocess or run a DB2 Server for VM application program in multiple user mode, you must associate your user ID with the application server that you want your program to access. To do this, specify the application server in the SQLINIT EXEC.
You need only do this once, as long as you continue to operate on the same application server or are using the CONNECT statement to switch application servers. Even if you log off and log back on to your virtual machine, you retain your association with the application server that was established by the SQLINIT EXEC (the association is recorded on your A-disk).
If you want to switch to a different application server and cannot use the CONNECT statement to do so, you must end your application program and invoke the SQLINIT EXEC again, specifying the new application server.
For information on the SQLINIT EXEC, refer to the DB2 Server for VSE & VM Database Administration manual.
In the VM environment, an explicit CONNECT statement is not required. Instead, the database manager accepts the password verification of the VM virtual machine and uses the VM user ID as the DB2 Server for VM user ID. This support is called "implicit connect." Implicit connect is possible if either the special user ID ALLUSERS or the individual users have been granted CONNECT authority.
For example, assume the following GRANT statement:
GRANT CONNECT TO A, B, C, ALLUSERS
After this statement, any VM user may be implicitly connected to the system. However, if the following statement is used, only users A, B, C can be implicitly connected to the system:
REVOKE CONNECT FROM ALLUSERS
Thus, the special user ID "ALLUSERS" can be used to selectively turn the implicit connect capability on or off for the total user set, while individual users can retain implicit connect authority.
If no explicit CONNECT is performed, an implicit connect occurs when the database manager receives a request to execute the first executable SQL statement. If the implicit connect is processed successfully, the statement is executed. As a result, the SQLCA contains information on the status of the execution of that statement. Information regarding warning conditions encountered while the connection was processed is lost. If the connection fails, the SQLCA contains information on the status of the connection.