In a distributed relational database using an Systems Network Architecture (SNA) network, communications jobs and interactive jobs are the main types of work an administrator must plan to manage on each server.
Servers in the network start communications jobs to handle requests from an application requester (AR); an AR's communications requests to other servers normally originate from interactive or batch jobs on the local system.
Setting up an efficient work management environment for the distributed relational database network servers can enhance your overall network performance by allocating system resources to the specific needs of each application server (AS) and AR in the network.
When the i5/OS™ licensed program is first installed, QBASE is the default controlling subsystem. As the controlling subsystem, QBASE allocates system resources between the two subsystems QBASE and QSPL. Interactive jobs, communications jobs, batch jobs, and so on, allocate resources within the QBASE subsystem. Only spooled jobs are managed under a different subsystem, QSPL. This means you have less control of system resources for handling communications jobs versus interactive jobs than you would using the QCTL controlling subsystem.
Using the QCTL subsystem configuration, you have control of four additional subsystems for which the system has allocated storage pools and other system resources. Changing the QCTL subsystems, or creating your own subsystems gives you even more flexibility and control of your processing resources.
Different system requirements for some of the systems in the Spiffy Corporation distributed relational database network might require different work management environments for best network efficiency. The following discussions show how the distributed relational database administrator can plan a work management subsystem to meet the needs of each iSeries™ server in the Spiffy distributed relational database network.
In the Spiffy Corporation system organization, a small dealership might be satisfied with a QBASE level of control for the various jobs its users have on the server. For example, requests to a small dealership's relational database from the regional AR (to update dealer inventory levels for a shipment) are handled as communications jobs. Requests from a dealership user to the regional AS, to request a part not currently in stock locally, is handled as an interactive job on the dealership server. Both activities are relatively small jobs because the dealership is smaller and handles fewer service orders, parts sales and so on. The coordination of resources in the QBASE subsystem provides the level of control this enterprise requires for their interactive and communications needs.
A large dealership, on the other hand, probably manages its work through the QCTL subsystem, because of the different work loads associated with the different types of jobs.
The number of service orders booked each day can be high, requiring a query to the local relational database for parts or to the regional center AS for parts not in stock at the dealership. This type of activity starts interactive jobs on their system. The dealership also starts a number of interactive jobs that are not distributed relational database related jobs, such as enterprise personnel record keeping, marketing and sales planning and reporting, and so on. Requests to this dealership from the regional center for performance information or to update inventory or work plans are communications jobs that the dealership wants to manage in a separate environment. The large dealership can also receive a request from another dealership for a part that is out of stock at the regional center.
For a large dealership, the QCTL configuration with separate subsystem management for QINTER and QCMN provides more flexibility and control for managing its server work environment. In this example, interactive and communications jobs at the dealership server can be allocated more of the server resources than other types of jobs. Additionally, if communications jobs are typically fewer than interactive jobs for this system, resources can be targeted toward interactive jobs, by changing the subsystem descriptions for both QINTER and QCMN.
A work management environment tailored to a Spiffy Corporation regional center perspective is also important. In the Spiffy network, the regional center is an AR to each dealership when it updates the dealership inventory table with periodic parts shipment data, or updates the service plan table with new or updated service plans for specific repair jobs. Some of these jobs can be run as interactive jobs (on the regional system) in early morning or late afternoon when system usage is typically less, or run as batch jobs (on the regional server) after regular business hours. The administrator can tailor the QINTER and QBATCH subsystems to accommodate specific processing times and resource needs.
The regional center is also an AS for each dealership when a dealership needs to query the regional relational database for a part not in stock at the dealership, a service plan for a specific service job (such as rebuilding a steering rack), or for technical bulletins or recall notifications since the last update to the dealership relational database. These communications jobs can all be managed in QCMN.
However, a closer examination of some specific aspects of distributed relational database network use by the KC000 (Kansas City) regional center and the dealerships it serves suggests other alternatives to the distributed relational database administrator at Kansas City.
The KC000 server serves several very large dealerships that handle hundreds of service orders daily, and a few small dealerships that handle fewer than 20 service orders each day. The remaining medium-sized dealerships each handle about 100 service orders daily. One problem that presents itself to the distributed relational database administrator is how to fairly handle all the communications requests to the KC000 server from other systems. A large dealership could control QCMN resources with its requests so that response times and costs to other systems in the network are unsatisfactory.
The distributed relational database administrator can create additional communications subsystems so each class of dealerships (small, medium, or large) can request support from the AS and generally receive better response. By tailoring the subsystem attributes, prestart job entries, communications work entries, and routing entries for each subsystem description, the administrator controls how many jobs can be active on a subsystem and how jobs are processed in the subsystem.
The administrator can add a routing entry to change the class (and therefore the priority) of a DRDA/DDM job by specifying the class that controls the priority of the job and by specifying QCNTEDDM on the CMPVAL parameter, as in the following example:
ADDRTGE SBSD(QCMN) SEQNBR(280) CLS(QINTER) CMPVAL('QCNTEDDM' 37)
The administrator can also add a prestarted job for DRDA/DDM job by specifying QCNTEDDM as the prestarted job, as in the following example:
ADDPJE SBSD(QCMN) PGM(QCNTEDDM)