
MXCS Architecture Overview
SQL/MX Connectivity Service Administrative Command Reference—526350-005
1-5
Software Installation
Error messages describe the problem and, where possible, suggest a recovery
action.
Software Installation
MXCS administrative commands are installed as part of MXCI. No special installation
process is needed to install software for these commands.
Starting, Leaving, and Ending MXCI
The MXCI command has many options. One of them enables you to specify the name
of a command file. For start-up information, see MXCI Mode Command on page 2-12.
For examples, see Example Commands and Objects on page A-1
Complex System Configuration
This subsection describes a complex MXCS configuration on one system, showing the
objects that MXCS administrative commands manage: service, server, DS, and EVAR.
In Figure 1-2 on page 1-6, a system is shown with three of its CPUs represented and
MXCS objects distributed across these CPUs. The service object is a logical entity
consisting of two processes, one or more DS instances, a table of all servers it has
started and owns, and memory-resident copies of EVARS owned by each DS instance.
Data sources exist in three places in three forms:
A copy on the disk that has no state except existence or not
A copy in the service, the DS instance, that has a state (stopped is default state)
A partial copy kept in each server
The configuration server in each service reads all DS instances at service start-up and
keeps them current. However, states for DS instances can be different in different
services. The association server starts each server and passes its DS attributes at
server start-up and also when certain attributes change. However, when an EVAR for a
DS instance is added, deleted, or changes value, it is not passed to connected servers
because this action changes the environment during transactions. EVARs pass from a
DS instance to a server only when that server starts or goes idle. Some DS attributes
are never passed to the servers. For example, only the association server uses the
maximum number of servers permitted.
In this configuration, two services are running: Service A on CPU 5 and Service B on
CPU 9. The SQL/MX database engine contains the configuration database for the
permanent ODBC configuration information (DS and EVAR definitions). Note that CPU
11 has no MXCS service running on it, but it does have a server object. Also, one
instance of MXCI is running on one of the CPUs, which is not specified as it does not
matter for this discussion.
On CPU 5, Service A is a logical entity consisting of an association server and a
configuration server. All three DS definitions are read from the disk and kept current in
Komentáře k této Příručce