You can access multiple application servers from within an application program, but only one application server can be accessed at a time. DB2 Server for VM application servers can reside on the same processor as the user, or on another processor (in the TSAF collection or the SNA network). VSE application servers must reside on the same processor as the user, if DRDA protocol is not being used. If the VSE application server does not reside on the same processor as the CICS/VSE online user, the VSE application server must be accessed during the DRDA protocol. This VSE server must be defined as a remote DRDA server to the DB2 Server for VSE Online Resource Adapter. VM application servers, accessed through VSE guest sharing or using the DRDA protocol, may reside on the same processor as the user, or on another processor (in the TSAF collection or the SNA network). If a program is written to access multiple application servers, its package must exist on all of them.
This section discusses these authorities in more detail, and explains how to switch application servers from your application program. For a detailed discussion on establishing communication links between application requesters and application servers, refer to the DB2 Server for VM System Administration or the DB2 Server for VSE System Administration manual.
Use the CONNECT statement to switch among application servers if you want application programs to connect to different application servers while running. For more information on the CONNECT statement, see the DB2 Server for VSE & VM SQL Reference manual.
Figure 97 and Figure 99 show how an application program, indicated by PGM, accesses three application servers with and without switching application servers in the program. The application servers can reside on the same processor as the program or on a different processor.
The application server specified by the SQLINIT EXEC is the default application server. In Figure 99 the default application server is DB01.
If you are not switching application servers in the program, to access another application server you must terminate the program, reissue the SQLINIT EXEC, and run the program again. In Figure 97, for example, to switch from application server DB01 to application server DB02, you must terminate the program PGM, reissue SQLINIT, and run the program again.
Figure 96. Switching Application Servers NOT Implemented within the Program
|
When you are switching application servers in the program, an application program can switch to a new application server during execution with the CONNECT statement. Like the SQLINIT method, a package for the program must exist on all application servers it accesses, and each logical unit of work must end before you switch to a different application server. See Parameters for SQLPREP EXEC for Single and Multiple User Modes for the options used to preprocess the program on multiple application servers.
Figure 97. Switching Application Servers Implemented
 |
Figure 98 shows how an application program, indicated by PGM, accesses three application servers by switching application servers in the program. The application servers can reside on the same processor as the program or on a different processor. When you are switching application servers in the program, an application program can switch to a new application server during execution with the CONNECT statement. A package for the program must exist on all application servers it accesses, and each logical unit of work must end before you switch to a different application server. See Preprocessing the Program on Multiple Application Servers for more details.
Figure 98. Switching Application Servers Implemented - DB2 Server for VSE
 |
An DB2 Server for VM application accesses the application server established by the SQLINIT command when:
An DB2 Server for VSE application accesses the default application server when:
| DB2 Server for VSE |
|---|
|
For more information about the defaults that determine the application server that is accessed, refer to the DB2 Server for VSE System Administration manual. |
The application accesses a new application server after executing: An application accesses a specific application server after executing:
| DB2 Server for VSE |
|---|
|
You must enter a CONNECT statement from a batch application after a COMMIT RELEASE statement or ROLLBACK RELEASE statement to reestablish the user ID and target application server. Otherwise subsequent SQL statements are not successful (SQLCODE -563). A null CONNECT statement is not sufficient. |
For DB2 Server for VM to query the user ID and the identity of the application server to which you are currently connected, as well as the relational database management system (RDBMS) running the application server, do one of the following from within an application program. For DB2 Server for VSE to query the user ID and the identity of the application server to which you are currently connected, enter one of the following from within an application program.
For DB2 Server for VSE if a null CONNECT is issued as the first SQL statement in a batch application, blanks are returned in the SQLCA for the user ID and application server name and the execution of subsequent SQL statements are not successful (SQLCODE -563).
If you are using DB2 Server for VM, from your terminal, enter:
Figure 99 shows how an application can take advantage of switching application servers.
Figure 99. Pseudocode Illustrating How to Switch Application Servers
In the above example, the application connects to three application servers (DB01, DB02, and DB03), and performs a series of operations when accessing each one. When accessing DB01, the program retrieves information from the application server (with the FETCH statement) and processes the information.
Next, it accesses DB02, and some rows are deleted from a table; then accesses DB03, and rows are inserted into a table.
An application program that allows access to multiple application servers with the CONNECT statement must exist on every application server that the program is to access.
The DB2 Server for VSE preprocessors provide the DBNAME parameter to preprocess a program on different application servers. In addition, the CBND transaction provides the DBLIST parameter to create a package on different application servers.
The DB2 Server for VM SQLPREP EXEC provides the option to preprocess a program on multiple application servers with the DBFile or DBList parameter. However, an application using either of these parameters is preprocessed on one application server at a time. Each of the application servers provided in the DBFile or DBList parameter preprocesses the program separately and consecutively, and generates a source listing. These source listings are concatenated.
When an application that accesses different application servers is being preprocessed, certain warnings may be issued by the preprocessor. For example, if TABLE1 exists in DB01, but your application program is preprocessed against DB02 or DB03, you will receive warning messages that the table does not exist in those application servers. If your program does not access TABLE1 in DB02 or DB03, these messages can be ignored; however, if TABLE1 will be accessed in either DB02 or DB03, you must create TABLE1 in the accessed application server.
You should repreprocess the program on the application servers that you updated before executing the program. If you are using the preprocessing option CTOKEN=NO, you only need to preprocess the application program on one application server. If you specify CTOKEN=YES, you must repreprocess on all application servers that the program accesses to get the same timestamp.
During execution, the table being referenced in an SQL statement may reside in the currently accessed application server or in another application server. In fact, a table of the same name, but with different attributes, may be in the application server. The database manager issues a warning message that there are inconsistencies, but preprocessing will continue. The statement causing the warning remains in the package, and will only cause an application failure if it is referenced at run time. Conditions that will generate a warning and the corresponding SQLCODE include:
For more information on preprocessing against unlike DB2 Server for VM application servers, refer to Preprocessing the Program.