This section discusses the following topics:
Initially, a set-up contains one database machine which is called SQLMACH. As your installation grows, you can add more database machines. The primary reason for doing so would be to permit multiple user mode access to more than one database at the same time, or multiple database operation.
Consider, for example, an installation having one database machine (SQLMACH) and three databases (SQLDBA, DATA1, and DATA2). A database machine can access only one database at a time. Thus, as Figure 78 shows, while the database machine is accessing one database in multiple user mode, the other databases are inactive.
Figure 78. One Database Machine Accessing One Database
|
Users could access the remaining databases (DATA1 and DATA2) in single user mode if their machines were set up to do so; however, it is not recommended that the database manager be used this way.
If you define two more database machines, multiple user access to all three databases is now possible at the same time. Figure 79 shows a multiple database configuration. In this case, two more database machines are defined (SQLMFB and SQLJDS). Each machine "owns" one database (that is, has the MDISK entries in its directory for the database minidisks), and operates independently of the others.
Figure 79. Multiple Users Accessing Multiple Databases
Although database machines operate independently of each other, users are not restricted to a particular one.
Suppose user CINDY in Figure 79 has CONNECT authority on all three databases. With this configuration, she can move between databases by using the SQLINIT EXEC or the SQL CONNECT statement.
For example, CINDY could issue SQLINIT DBNAME(SQLDBA) to prepare her virtual machine for accessing the SQLDBA database, and then use ISQL to access that database. To access any of the other databases, she could leave ISQL, reissue the SQLINIT EXEC (specifying another database), and then access that database using ISQL. She could issue the SQL CONNECT statement to switch databases without leaving ISQL. (The SQL CONNECT statement is described in the DB2 Server for VSE & VM Database Administration manual.)
Processors can be part of either a TSAF collection or an SNA network.
The TSAF collection is composed of a group of processors with the TSAF virtual machine component installed, running and connected. A distributed relational database network is a group of interconnected processors supporting relational databases that can be accessed locally or remotely through either the SQLDS protocol or the DRDA protocol. Each processor gains access to the SNA network through its communications subsystem. On the database manager, the communications subsystem consists of the CMS communications directory, APPC/VM, TSAF, AVS, and the VTAM product.
All databases generated on these processor must be identified as either LOCAL or GLOBAL resources. A LOCAL database can be accessed only by users located on the same processor as the database. A GLOBAL database can be accessed by users located on other processors as well, as long as the processor on which the database resides is physically connected to those processors or is in a TSAF collection.
A DB2 Server for VM application server can receive communications from other relational database products when the PROTOCOL=AUTO parameter of the SQLSTART EXEC is specified.
A DB2 Server for VM application requester can communicate with other relational database products when either DRDA or AUTO is specified for the PROTOCOL parameter of the SQLINIT EXEC.
If the application requester uses DRDA protocol to communicate with a like application server, the overhead increases due to the protocol conversion between the two. The use of DRDA protocol between like machines is usually only for problem determination or modelling.
In Figure 80, application servers SQLA and SQLB are on two processors connected in a TSAF collection. One of the processors has access to the SNA network through AVS. The application requester USER1 is on the other processor. It is assumed that the application server SQLB supports DRDA protocol.
Figure 80. Accessing Application Servers in a Network
Application server SQLA is LOCAL; thus it can be accessed only by application requesters that are on the same processor, such as USER1. Application server SQLB is GLOBAL, so it can be accessed by application requesters such as USER1 located anywhere in the TSAF collection or SNA network. Because application server SQLB supports the DRDA protocol, it can also be accessed by unlike application requesters that support the DRDA protocol in the SNA network.
Application requester USER1 can access DB2 Server for VM application servers in both the TSAF collection and the SNA network, as well as unlike application servers that support the DRDA protocol in the SNA network.
Users do not have to know the location of the application servers: all they need to know is the server name (server_name). For example, in Figure 80, a user can establish a default application server for implied connection by entering one of the following SQLINIT EXEC commands:
SQLINIT DBNAME(SQLA) SQLINIT DBNAME(SQLB) SQLINIT DBNAME(SQLC)
The user then can access the default application server through ISQL, the DBS utility, or an application program, or can issue the SQL CONNECT statement to switch to another application server. For example, if USER1 accesses the SQLA application server through ISQL, he or she can later switch to the SQLC application server, without having to exit ISQL, by entering CONNECT TO SQLC. For more information on the SQL CONNECT statement, see the DB2 Server for VSE & VM Database Administration manual.
When an application requester uses AVS to communicate with a remote application server, a connection is initiated. If this connection causes the established session limit to be exceeded, AVS puts the connection in a pending state. This state is maintained indefinitely until another session becomes available, which happens when an existing connection is disconnected or terminated. AVS then allocates the connection on this session, and control is returned to the user application.
Attention: To avoid this situation, it is recommended to plan for peak usage. The calculated session limit should be increased to allow for some additional connections.
If users do not have a database machine installed on their processors, they can still access database machines on other processors if a service machine has been installed. In a TSAF collection a service machine gives users access to a production minidisk that contains DB2 Server for VM files, such as SQLINIT EXEC and ISQL EXEC, necessary for users to access the databases.
Figure 81 shows an example of a user accessing an application server located on another processor in a TSAF collection.
Figure 81. A Processor with a Service Machine Installed
In Figure 81, user FRED is accessing a database machine located on another processor. FRED is located on a processor that does not have a database machine but does have a service machine installed.
Most error and informational messages are issued from the user machine, but messages and output for operator commands (SHOW and COUNTER), and HELP text are issued from the database machine. Thus if your organization has the database manager on different processors in a collection, you should support the same national languages on the database machine as are supported on the user machines that can access it. For example, if you support French HELP text and messages on a user machine, and a user accesses a database that does not have French HELP text and messages, that user will receive error and informational messages in French, but the HELP text for those messages will be in English. Figure 82 shows an example of such a set-up.
Figure 82. National Language Support for Remote Access Users
 |
When a set-up includes multiple databases, the following terms are used:
LINK SQLMACH 195 195 RR
which makes the SQLMACH machine's production minidisk available to this secondary database machine. For more information, see Adding a Secondary Database Machine.
These definitions are illustrated in Figure 83
Figure 83. Types of Database Machines
 |
Here, the SQLMACH machine owns the primary production minidisk through an MDISK control statement. The DBMACH1 machine is a secondary database machine, with a LINK directory control statement to the primary production minidisk. The DBMACH2 machine is another primary database machine because it owns a copy of the original production minidisk. This DBMACH2 machine also has a LINK entry for the SQLMACH machine's service minidisk. The service minidisk contains all IBM-supplied files, including those that are necessary for a production minidisk. This link is necessary to prepare the secondary production minidisk by copying all appropriate IBM-supplied files from the service minidisk to it. The ARISPDFC EXEC is supplied for use in copying these files. For information on using this EXEC, see Appendix G, Service and Maintenance Execs.
The product-supplied files must be the same on all production minidisks at your installation. If you apply service to one production minidisk, you must apply the service to all. (The DB2 Server for VM Program Directory describes how to apply service.) When you create a secondary production minidisk, you create a new environment, with its own application server and its own users. You should keep the environments as independent as possible: that is, users should not be allowed to communicate with database machines using different production minidisks. (In the VM/ESA operating system, users can access any production minidisk.)
In VM/ESA operating system, there is no dependency between the database machine's production disk and the database being accessed since the connection by APPC/VM is to a resource identifier rather than a virtual machine. You do not have to copy the virtual machine name to the bootstrap before the resource adapter can communicate with the database.
The resource is identified when SQLSTART is issued. For this reason, resource identifiers must be unique within a TSAF collection or an AVS gateway. The server name (server_name) does not have to be the same as the resource identifier (resid); however, it should be unique within the SNA network.
In this environment, a user must have a link to a valid production disk. The user can then access any of the application servers in the same collection or network.