View figure.This section describes the Control Center product architecture. It is intended primarily for those people involved in the installation, maintenance, or administration of Control Center, and users of the product.
This section is prerequisite reading for the material presented in Chapter 3, Installation and Migration Overview, and Chapter 8, Managing the Environment.
The product architecture has been designed to allow you to install a Control Center configuration that is tailored to meet your specific database support requirements. It is easily customized because of a modular design and externalized control parameters that allow you to be very specific in identifying how you want your databases managed. For example, tape management processes are often quite unique to specific VM installations, requiring that the management (for instance, mounting or cataloging) be handled in a particular manner. When installing, you can instruct the product how to manage tapes and tape-related information required by your installation. In addition to tape management, Control Center can be customized in other ways to help you handle your database environment.
In Control Center configuration, there are five basic types of virtual machines: service machines, database machines, support machines, user machines, and Control Center owner machines.
Figure 3 shows a basic Control Center configuration with a service machine (MSTRSRV), two support machines (MSTRSUP1, MSTRSUP2), two database machines (SQLMACH1, SQLMACH2), two user machines (MSTRUSR1, MSTRUSR2), and a single owner machine (MSTROWN).
Figure 3. Control Center Machine Types
| View figure. |
This is a machine that runs in disconnected mode (no physical console or keyboard attached) and is responsible for the automated operations of the database environment. This is the central machine that processes your requests as a user of Control Center, as well as manages the activities of support machines and database machines.
The MSTRSUP1 and MSTRSUP2 machines in the figure are support machines. These machines are controlled and managed by a service machine (MSTRSRV) while running in a disconnected mode (no physical console or keyboard attached). The service machine will send these machines long-running work activities that require dedicated processing. These long-running activities are often referred to as multiple user mode (MUM) applications, because these applications connect to a database that is running in a multiple user mode (SYSMODE=M).
The SQLMACH1 and SQLMACH2 machines in Figure 3 are database virtual machines. These machines are your database application servers that take requests for data or data updates from other virtual machines. These machines own the minidisks that your database data is stored on.
The MSTRUSR1 and MSTRUSR2 machines are user machines, each with a physical console and keyboard attached. This is the type of machine that you use to interface with the Control Center and DB2 for VM Server products. These machines must be authorized to Control Center, as well as to the database itself.
As an authorized user, you can connect to a database and run MUM activities, as can a support machine. You can, however, prefer to have your longer-running MUM activities processed on a support machine so as to keep your virtual machine free for other processing activities.
These machines are owners of particular service and support machines. These machines are specified during the installation of a service machine or support machine. The MSTROWN machine shown represents an owner virtual machine for the MSTRSRV service machine and the MSTRSUP1 and MSTRSUP2 support machines.
The owner machines are given Control Center Administrator level authorization. These machines will be sent Control Center machine consoles, if the Control Center machine is spooling a console, each time a service machine or support machine is cycled (stopped and restarted, IPLed, or Control Center midnight processing). They are designated as owner machines in the Control Center PROFILE file.
As covered in Control Center Tools Overview, the product is comprised of three types of tools: System Administration, Database Administration, and Control Center Administration tools.
The virtual machines outlined above each use a specific type of Control Center tool. It is important, therefore, that you review and understand the Control Center Tools Overview section of this manual before proceeding any further in this section.
The System Administration tools are used to manage the operations of your database virtual machine consoles. In other words, these tools automate all the activities that would normally be performed by a database console operator logged directly onto the database's virtual machine.
It is the purpose of the service machine to invoke, run, and manage the System Administration tools, automating console operations for one or more databases.
How the System Administration Tools Work On the Service Machine
The service machine runs the System Administration tools in a disconnected mode, meaning that there is no physical console or keyboard attached to these machines while they are running. These machines are in a sleep (trivial CPU usage) mode until a message or file is sent to them, causing an interrupt of their sleep state. Upon interruption, the service machine "wakes up" and runs System Administration tools to review the message or file to determine what, if any, action should be taken.
Scheduled Processing
The System Administration tools are not just reactive to interrupts, but can be scheduled by you for specific invocation. For example, you can schedule (the scheduler is a Control Center Administration tool) a database archive activity to occur at a later scheduled time. At the specified time, the archive System Administration tool will be invoked and the archive activity will be started. As the archive is processed, the database's console will then generate many messages that may require responses, and it is the job of the System Administration tools to provide the database's console with any required information.
Asynchronous Processing
A single service machine running the System Administration tools can support one or more database machines simultaneously. This means that multiple database console activities can be processed by Control Center at the same time. For example, MSTRSRV could start a full database archive for the SQLMACH1 database and at the same time start an add dbextent process on the SQLMACH2 database machine. MSTRSRV will respond to each database console message as it occurs and does not become locked into the processing of one specific database's console messages. Both activities can proceed simultaneously on each database machine.
Simultaneous Support of Multiple Database Versions
The System Administration tools running on the service machine support the simultaneous running of different versions of DB2 Server for VM therefore, you will not have to reinstall or reconfigure your service machine when you move to new versions.
As described in Database Administration Tools, the Database Administration tools are very different from the System Administration tools. These tools require a dedicated virtual machine console while running, which means that multiple Database Administration tools cannot run on the same virtual machine at the same time.
These tools require a dedicated console because they are database application programs. These tools work through the database to manipulate actual database data, compared to the System Administration tools, which do not perform database connects. They are often referred to as multiple user mode (MUM) applications, because they connect to a database that is running in multiple user mode (SYSMODE=M).
Why Support Machines?
Use support machines to invoke and process Database Administration jobs that run for long periods of time (usually anything greater than a few minutes). Support machines run in disconnected mode and can be instructed to invoke and execute Database Administration tools. Install one support machine per database machine. This gives you the capability to run simultaneous Database Administration tools against one or more databases. For example, you could instruct the MSTRSRV machine to have the MSTRSUP1 machine run a reorganization of a DBSPACE in the SQLMACH1 database, and at the same time start another reorganization on the MSTRSUP2 machine for the SQLMACH2 database.
Managing Support Machines
The service machine will manage the support machines. When initiating or scheduling Database Administration tools to run on support machines, you interface with the service machine and give it instructions that drive the tools' execution on the support machine.
The service machine processing of an activity on a support machine from invocation to completion. It is the responsibility of the service machine to track the activity of each of its support machines, as well as to maintain a status of each of the activities performed.
Why Not on Service Machines?
When executing, Database Administration tools require a dedicated virtual machine. This means that the virtual machine on which these tools are running is unavailable until execution is completed. When a service machine runs a Database Administration tool, it is unavailable to meet its primary responsibility of servicing database consoles. Furthermore, a potential deadlock situation could be created (refer to the "Control Center Tools Overview").
As described in the Control Center Administration Tools, these tools provide the service machines and support machines with some basic operational capabilities. For example, the Job Scheduling tool provides service machines with the ability to manage the processing of either service machine jobs (archives, recovers, add dbextents), or support machine jobs (DBSPACE reorganizations, table reorganizations).
These tools do not require their own virtual machines, but rather are invoked and run by the service machines and support machines as required. Code for these tools is located on the Control Center product code disk, that both the service machine and support machine must have read access to (refer to the code disk discussion later in this section).
The Control Center tools run on various types of virtual machines. Each of these machines contributes to the processing of the database environment, and therefore must be able to communicate with each other. This section will cover basic types of communications relating to the five types of Control Center machines previously discussed.
Three Types of Communications
There are three different types of communications relating to your configuration:
Figure 4 is a diagram of Control Center related virtual machines and the communication connections used between them.
The service machine communicates with database machines through the Single Console Image Facility (SCIF).
In Figure 4, the MSTRSRV machine is connected using SCIF with SQLMACH1 and SQLMACH2 database machines. There is no limit to the number of SCIF connections a service machine can have, but each database can have only one.
| Important: |
|---|
|
You must not identify another machine as a secondary console for a service machine. If you have database machines SCIFed to your service machine and your service machine SCIFed to a third machine, then any database console messages will, in effect, be SCIFed directly to the third machine, bypassing the service machine entirely. |
SCIF is a standard component of VM that enables the service machine to act as the virtual console and virtual keyboard for each database machine it is connected to, as if the service machine were actually logged onto the database virtual machine(s). The service machine, through the SCIF connection, can issue commands directly to the database, as well as view all database console messages that are displayed on the database's console.
Breaking the SCIF Connection
Figure 4. Control Center Communication Connections
 View figure. |
The SCIF relationship will exist while the database and service machine are running in disconnected (no physical console or keyboard attached) mode. If you log onto the database machine, the SCIF connection to the service machine will be broken. Any messages produced on the database console while you are logged on will not be forwarded by SCIF to your service machine.
Logging onto the service machine will not break the SCIF connection (messages will still be forwarded and stacked for processing) but you will not be able to communicate with the service machine using the interfaces provided (SQM command mode or panel interface).
Number of Service Machines Required
It is necessary to have at least one service machine per CPU, because the SCIF facility cannot communicate across CPUs. There is no limit on the number of database virtual machines connected via SCIF to your service machine. You are not, however, limited to installing just one service machine per CPU. You can install as many service machines as are necessary to meet your specific requirements. Additional machines, for example, can be required to segregate different platforms (production, development, test) from each other, or to provide more responsive database console management.
If you have a database console environment that is very active (many console messages from archives, operator commands), and your service machine seems to be performing sluggishly, then you can install additional service machines to distribute the console processing activity across multiple machines. This can be especially true if you decide to run several database monitors (refer to Chapter 27, Database Monitoring Tools) with very small frequency (1 to 5 minute) intervals.
This is because each monitor will cause the generation of additional database console messages that your service machine will have to analyze and react to.
As Figure 4 shows, the service machine uses messages and files to communicate back and forth with user machines and support machines. Interfaces running on the machines receive and interpret the messages and files to determine what action or what information is to be displayed.
If the MSTRUSR machine in the diagram requests information about a database (the SHOW commands), the request is transmitted to the MSTRSRV1 machine in the form of a message and the response is sent back to MSTRUSR in the form of a file. The file sent back to MSTRUSR will appear in the MSTRUSR's reader. The Control Center interface will PEEK the file, displaying it to MSTRUSR. After MSTRUSR exits the file display, the file will be purged from the reader. If MSTRUSR wants to save or print a copy of the information, a SAVE or FILE command while in PEEK (placing the file onto MSTRUSR's 191 A-disk) can be issued.
Waiting for Requested Information
When a request for information is sent to Control Center through the SQM interface, the user will be placed in a WAIT state (using WAKEUP) until the information is returned to the user's reader. There is a predefined length of time that the SQM interface will wait for the reader file. After this amount of time, SQM will return control to the user and indicate that the expected file did not arrive. This problem will usually indicate that Control Center failed or that a network connection from the user to the Control Center machine is not available.
There are four basic modes of communication with Control Center. Any of these modes can be used by any virtual machine attempting to communicate with Control Center:
Communicating with the Control Center facility via the panel interface is done through the SQM EXEC. SQM is invoked in panel mode by entering SQM without any parameters.
The SQM interface can be invoked in command mode to issue single-line commands to a service machine. This mode can be very useful when it is required to communicate with a service machine in a single-line mode format, such as issuing communications from a program (EXEC) or server machine.
Files can be sent directly to service machines. If the sender is authorized, the file will be received by the service machine onto either its 191 A-disk or the code disk, depending on the type of file sent.
Communications to a remote CPU service machine are done through the Remote Spooling Communications Support (RSCS) network product. If you have multiple CPUs, then communications to a service machine on another CPU will only be possible if the remote CPU has been identified to RSCS. When communicating with the remote service machine, all messages and files are routed through RSCS directly to the remote service machine; the local CPU service machine is not involved in the communications.
The support machine (MSTRSUP) and user machine (MSTRUSR) run the Database Administration tools. These tools will perform a database connect to a specified database (SQLMACH1 or SQLMACH2) by running the database-provided SQLINIT utility. This utility is available with all versions of DB2 Server for VM and provides applications with the ability to establish communications with a database.
To successfully connect to a database, support machines and user machines must have database DBA connect authorization. This authorization is maintained by DB2 Server for VM for each database machine. In Figure 4 the MSTRUSR machine must be granted specific connect authorization to each database that the machine will be accessing.
| Important: |
|---|
|
The connect authorizations are maintained by the database and are completely separate and distinct from the Control Center product authorizations. |
During Control Center installation you will be prompted for the virtual device addresses of the Control Center code disk and tape management code disk. This information will be used by Control Center when establishing your virtual machine environments in preparation for activities to be performed.
The Control Center code disk shown in Figure 5 contains only Control Center product code (this includes the DBINIT CONTROL and SQLMSTR DIRECTRY files). Each of the machines shown has read access to the code disk, with the service machine (MSTRSRV) having read and write access. Since MSTRSRV has write access to the code disk, this machine is referred to as the code disk owner.
Each of the virtual machines has its own read/write 191 A-disk. The service machines and support machines store various control files which are updated and stored on their A-disks. Information used by the database machines during startup and termination is kept on each database machine's A-disk. The user machine (MSTRUSR) A-disks will be updated with certain control information that will be used by the Control Center panel and command mode interfaces, as well as by any Database Administration tools that the user machine invokes.
Communications Code: The Control Center code disk contains all code needed for invoking, using, and communicating with the Control Center tools. In addition, information detailing your local and remote CPUs is stored on this disk (refer to "SQLMSTR DIRECTRY and DBINIT CONTROL Files" below).
Automatic Code Disk Reaccessing and Shared Code Disks: The service machine and support machines should use a common (shared) code disk. Since only one of the machines (must be a service machine) can own (read/write) access, then the other machines will only have shared (read) access.
In support of Control Center shared code disk access, when the code disk is updated by the owning service machine, the service machine will automatically instruct other service machines and support machines to reaccess the changed code disk. In addition, any users that are currently linked to the disk will be notified that the code disk has been changed and should be reaccessed.
The service machines and support machines will reaccess the disk automatically, provided that the owner service machine has been authorized as a Control Center Administrator to each of these machines. This feature is especially important in regard to the SQLMSTR DIRECTRY and DBINIT CONTROL files, which contain common control information that is used during Control Center communications.
SQLMSTR DIRECTRY and DBINIT CONTROL Files: These files provide basic communications control information that must be made available to all virtual machines (service machine, support machine, database machines, and user machines) that will use the Control Center tools. These files contain specific communications control information particular to your installation (Chapter 8, Managing the Environment). Since the information must be made available to all users of the Control Center product, these files are stored on the Control Center code disk.
When updating files that normally reside on the Control Center code disk, you can be instructed to send a copy of the files to the service machine that has write access to the Control Center code disk. If you are authorized (Control Center Administrator authority) to update the Control Center code disk, then you can update the disk by sending code files (includes SQLMSTR DIRECTRY and DBINIT CONTROL) to the service machine that owns the code disk. The service machine will automatically receive any code files to the code disk.
This disk contains the database product code. In order to communicate and use a database, the user and support machine must have read access to this disk. This disk must also be available to the database machine, which must have the ability to access this disk in write mode.
Figure 5. Control Center Code Disk
 View figure. |
The Tape Management code disk, or any disk with code necessary for the management of tapes on your system, must be linked and accessed by your database virtual machines. Control Center will manage the linking and accessing of these disks automatically based on information supplied during installation. As shown in Figure 5, the database machine (SQLMACH) has read access to a tape management code disk.
The tape code disk virtual address and owner ID (user ID) are maintained in the SQLMSTR CONTROL file kept on the service machine's 191 A-disk. This file can be changed (taking care to maintain upper and lower case characters) and will take effect the next time Control Center is restarted.
Tape Management Interfaces
Control Center does not require a tape management product, but does support the following tape management software.
In the absence of a tape manager, tape support is handled by sending tape mount request messages directly to a system operator ID. The product can also be adapted to work with other tape managers, with some customization.
Control Center allows the database archive and recovery functions to be automated with or without the availability of a tape management product. Physical mounting of tapes by a tape operator or automated hardware tape component (tape loader, tape hopper) is required. Ordinarily, a specific VM user ID is designated to receive tape mount requests from users on the system. The tape mount requests are usually sent as messages which include information concerning the tape to be mounted, what virtual machine requires the tape drive, what virtual address should be used for attaching the tape drive to the requesting user, whether the tape should be write-enabled, and other tape characteristics (labeled, scratch, density).
The SQMOUNT EXEC will be executed whenever a tape mount is required by any database. This exec will receive all parameters associated with the specific tape mount (which database, which virtual address, write-enabled). There are four different routines in SQMOUNT which are used to submit the appropriate tape mount request:
One of the four routines will be executed, depending on information supplied during the installation process. If VMTAPE, or a routine that is not mentioned above is used, the SQMOUNT EXEC can need to be locally customized with appropriate density information. See the DB2 Server for VM Control Center Program Directory.
Control Center is designed to handle multivolume |archive (ARIARCH) tapes using the CMS FILEDEF and LABELDEF commands. When a database starts, Control Center will issue FILEDEF and LABELDEF commands for the ARIARCH ddname used by the database for archiving. When multiple labeled tapes are required for the archive, each one will be provided to CMS using the LABELDEF command. |Log archives are restricted to single tape volumes so multivolume |tape processing is not performed for ARILARC.
Multivolume tape handling is automatically processed, depending on whether the database is using the generic CMS handling of End-Of-Volume, or one of the supported EOV exits has been installed (DMSTVS or DMSTVI). When each database starts, Control Center will determine whether the database has access to either the DMSTVS or DMSTVI module exit. When a subsequent End-Of-Volume is reached, Control Center will then perform the appropriate action based on which exit is available (if any).
The DMSTVI exit of CMS is supported. This allows tape management products to easily handle tape mounts and multivolume tape processing. |If available, DMSTVI is automatically invoked when the database performs an OS OPEN(TM) on a tape dataset during an archive. It is also invoked when End-Of-Volume (EOV) is reached on a tape within a multivolume tape set. Control Center will pass the specified parameter values to a tape management product through DMSTVI using the CMS FILEDEF and LABELDEF commands. The new LOGTAPE-PREMOUNT option also provides flexibility to support various implementations of the DMSTVI exit. Below are some highlights of tape processing. (DBSTART is the exec that Control Center uses to start up databases controlled by a service machine). |Presently, VMTAPE is the only supported tape manager that uses |DMSTVI.
| Note: | Please note that CA-DYNAM/T does NOT support multivolume tape processing. Therefore, this version of Control Center will only support single tape handling. |
Control Center is designed to automate the database archiving and recovery processes. Ordinarily, a tape operator will mount a physical tape and attach the tape drive to the database machine. To reduce or eliminate manual interface, an automated tape handler or tape stacker can be used.
Control Center must rely on information (messages) within the VM/CMS operating system to provide full automation without intervention by the DBA during the archive and recovery processes. The primary area within the archive and recovery process where minimal system messages are available is during the tape mount function. Under VM/CMS, no automatic system message is provided to the requester when a tape is inserted into a tape drive and readied for use. This makes it very difficult for Control Center to determine when the tape is available, so that the product can instruct the database to begin reading or writing to the tape.
Because of the limited number of VM/CMS tape system messages, Control Center has been designed to rely on the CP TAPE nnnn ATTACHED message which is generated when the system operator attaches the tape drive to the database virtual machine.
| Note: | This places a requirement on the tape operator to attach the tape drive to the database only after the tape has been inserted into the tape drive and readied for use. This will be required for every tape mounted, even multiple tape volumes defined for a single archive activity. Control Center will automatically detach the tape drive between each mount when the End-Of-Volume is reached. |
Control Center currently supports:
For systems with VMTAPE, or other tape management products, the SQMOUNT EXEC can need to be modified to issue the appropriate MOUNT command syntax for that product. See the DB2 Server for VM Control Center Program Directory.
Scratch tape pools are supported when VMTAPE is used. This option allows separate tape pools to be defined for each database. When the scratch tape option is used, the tapes will be allocated from the scratch tape pool defined for the database.
Users are authorized to access the product as either a Control Center Administrator, a Database Administrator, a Database Operator, or a Database User. The Control Center Administrator has the highest level of authority, which enables a user to perform any function available within a specific Control Center machine, including all DBA functions for all databases controlled by that machine. The Database Administrator can perform any Control Center function against one or more specified databases. The Database Operator can perform a subset of functions (such as archiving and database startup) for one or more specified databases. The Database User can only execute display functions for a specified database through the corresponding service machine, and perform the DATA only options of the Table Reorganization and Redefinition tool.
There is an additional level of authorization, that of database. This is for internal usage to allow communications between the database and the service machine.
The scheme below indicates the scope of authority for each level.
The five levels of authorization are discussed in more detail here.
The Control Center Administrator is responsible for the operational aspects of the service machine (there can be more than one administrator). An Administrator is allowed to perform any function that is available within Control Center, including all DBA functions for all databases under a service machine's control.
Each Administrator user ID which is known by the service machine will receive many files and messages during Control Center operation. Many of these have to do with database activities and others with Control Center operation itself. Administrators are the main players in the setup of the Control Center system.
At installation time one owner ID (discussed earlier in this section) will become the default administrator. Through the Control Center panel interface, this ID can also promote other users to be administrator. This user will also receive the SQLMSTR CONSOLE files that are closed and transferred from the service machine each day at midnight.
The database is assigned a level of authorization during the initialization process. This is needed to allow for communications between the database and the Service machine. This authorization is internal and transparent to the users of the product. It is noted here only for completeness' sake.
A Control Center Database Administrator is responsible for all operational aspects of a specific database. The DBA is allowed to perform all available operational functions within Control Center for that specific database. Every time a database is identified to the Service machine, specific information about the database must be given to it. One step in this identification process is to specify the user IDs which will be regarded as Control Center Database Administrators for that database. One user could be a Control Center DBA of many databases, but this must explicitly be told to the system in the identification step for every database which is new for a given Service machine. The Control Center Administrator will automatically acquire Control Center DBA authority over all databases controlled by a given Service machine. There can be more than one ID identified as a Control Center database administrator.
Control Center Database Operators will typically have the authority to execute a subset of the commands available to the Database Administrator. For example, an operator may be able to initiate database archives and start the database, but may not be authorized to add dbextents.
Control Center Database Users have the lowest level of authorization. They are only allowed to issue SHOW commands against a database, but they are not allowed to change anything in the database configuration or to perform hazardous actions against any database.
Notes: