A number of separate SESAM/SQL applications can execute concurrently on a single computer; a separate DBH and its associated application programs are involved in the execution of each of these applications.
In distributed processing in which application programs work with more than one DBH, different DBHs, application programs and distribution components (SESDCNs) can be involved in the applications (see section “Distributed processing with SESAM/SQL DCN”).
In order to avoid conflicts, system administrators can combine applications that belong together in configurations, thereby isolating them from other configurations. For example, it is possible to combine test applications and production applications in separate configurations so that they can work completely independently of one another.
A configuration can contain the following components:
In non-distributed processing, one or more DBHs with the relevant databases and one or more application programs
In distributed processing, all the DBHs that belong together (each with the relevant databases), plus application programs and SESDCNs
In addition, SESAM/SQL defines a pool to accommodate the administrative data used in communication and in distributed processing for each configuration with at least one transaction application, and for each configuration engaged in distributed processing.
All the components that are to be combined in a single configuration must be located on the same computer. Each DBH and each application program and, in distributed processing, each SESDCN, too, must be assigned to just one configuration at execution time.
Configuration name
The configuration name is used to assign the individual components to their respective configurations. The application program obtains the configuration name via a connection module parameter in the configuration file; the DBH and SESDCN obtain the configuration name via a DBH or DCN option.
The configuration name must be unique on the computer. Configurations located on different computers can use the same names. However, it is better to use configuration names that are unique across all systems in order to make it possible to perform an SESDCN recovery on a computer other than the one on which SESDCN was cold-started (see the “Database Operation” manual).
Communication between configurations
The individual configurations operate fully independently of one another. Without the distribution component SESDCN, an application program can only communicate with one DBH, namely with the one whose name was assigned as a connection module parameter and which belongs to the same configuration as the application program. With SESDCN, the configurations work independently of one another, but application programs can send requests to DBHs that do not belong to their own configuration, even if they are located on a different computer.
The figure 27 on the next page shows two computers, each with two configurations:
Configuration M on computer 1 consists of application programs, SESDCNA, DBH 1, DBH2 and the pool. It works independently of configuration Z on the same computer, but it can communicate with configuration J and configuration Y on the other computer.
Configuration Z on computer 1 consists of application programs and DBH3. It communicates with no other configurations.
Configuration J on computer 2 consists of application programs, SESDCNX, DBH6 and the pool. It communicates with configuration Y on the same computer, and with configuration M on computer 1.
Configuration Y on computer 2 consists of application programs, SESDCNB, DBH7, DBH8 and the pool. It communicates with configuration J on the same computer, and with configuration M on computer 1.
Figure 27: Example of communication between different configurations
Communication with virtual hosts
When operating a SESAM configuration you can also use a virtual host. In this case, SESAM/SQL uses the virtual host rather than the real host as its communication partner.
As a result, you can make the distribution rules and SQL system accesses independent of real host names.
To enable SESAM/SQL to use a virtual host, you must enter a corresponding statement for the application SES091cnf in the file $TSOS.SYSDAT.BCAM.APPLICATIONS (cnf is the configuration name).
Example
Entry with cnf = P in the $TSOS.SYSDAT.BCAM.APPLICATIONS file:
NEA SES091P VIRHOST
After this SESAM/SQL will use the virtual host name as the host name in the user identification (<user-identification>). Without this assignment the user identification will continue to be via the real host name.
In TIAM and DCAM applications the virtual host is used automatically.
In UTM applications, the parameter HOST NAME in the MAX option must be supplied with the name of the virtual host during UTM generation. As a result, the UTM applications can also use the virtual host and communicate with the SESAM configuration. This is absolutely necessary because, just like in the situation with real hosts, all the partners in a configuration must use the same host.
The virtual host must not be deactivated while a SESAM configuration is operating on it. If this does occur, this will be identified as a failure of the communication partners even if the real host is still active.