This chapter describes some of the ways in which MTO-enabled enterprise servers can be used, the information needed to control enterprise server processing and how to create and configure MTO-enabled enterprise servers.
An MTO-enabled enterprise server equates to a CICS region. On a mainframe, CICS regions are used for a variety of purposes, such as separating departmental applications or projects, and isolating the impact of failures by separating resources into terminal-owning regions, application-owning regions and file-owning regions. MTO-enabled enterprise servers can be used in similar ways.
You do not need to define services, request handlers or implementation packages in order to run migrated CICS applications in an MTO-enabled enterprise server. However, you should not delete the system services and request handlers that are automatically associated with an enterprise server when you create it.
You can, if you wish, run non-CICS applications such as Web services alongside CICS applications in an MTO-enabled enterprise server.
Configuring an MTO-enabled enterprise server is very like configuring any enterprise server, as described in section Enterprise Servers in the chapter Configuration in your Enterprise Server Configuration and Administration Guide. The differences are listed and explained below.
Because an MTO-enabled enterprise server contains more types of object than a non-MTO enabled enterprise server, there are more objects to take into account when you are deciding how much space to allocate to the shared memory area. For these extra objects perform the calculations in the table below and add the total to the total in the table in the section Enterprise Servers in the chapter Configuration in your Enterprise Server Configuration and Administration Guide.
Item | Calculation | Result |
---|---|---|
Remote systems |
|
|
PCT | Number of entries x 48 | |
FCT | Number of entries x 88 + (4 x number of split key components used) | |
DCT | Number of entries x 48 | |
PPT | Number of entries x 48 | |
Programs (load hold)1 | Number active x (average length + 8) | |
TST | Number of entries x 32 | |
PLT | Number of entries x (56 + (8 x average number of items in list)) | |
JCT | Number of entries x 48 | |
ICE2 | Number active x 64 | |
AID3 | Number active x 64 | |
Getmain SHARED4 | Number active x (average length + 8) | |
ENQ5 |
|
|
CICS client requests6 | (3270 data stream length + COMMAREA + TEUA + 64) x number of servers |
Footnotes:
Programs loaded as data with EXEC CICS LOAD
Interval Control Elements. Tasks scheduled for a particular time.
Automatic Initiate Descriptor. Tasks awaiting a free service execution process for execution.
Areas of memory allocated with EXEC CICS GETMAIN SHARED.
User controllable synchronization locks allocated with EXEC CICS ENQ.
The buffers calculation is a rule of thumb. Use the average data stream, COMMAREA, and TEUA sizes for the computation. This only works if your system is set up to incur a minimum amount of SEP queueing. The buffers calculation must exceed the maximum size of a single buffer; that is, one that contains maximum data, COMMAREA, and TEUA sizes.
Buffers are short lived and stay in shared storage only if no SEP is available to service the request. Once a SEP is dispatched, the buffer is immediately moved to local process storage and the shared storage is released. Outbound buffers also stay in shared storage for a very short period of time. Outbound, the only delay is for processor dispatch to the supporting terminal process. Once the terminal process is dispatched, the buffer contents are moved to local process storage and the shared storage buffer is released.
The System Initialization Table (SIT) specifies how an MTO-enabled enterprise server is to be initialized when it starts up. It determines such things as, but is not limited to:
Some of the properties of a SIT are shared with the enterprise server definition, for example, the size of shared memory and settings for traces and dumps.
A SIT is defined and stored in a resource definition file (RDF). An RDF can hold any number of SITs. Facilities for defining SITs are described in the chapter Resource Definitions. MTO supplies several pre-configured SITs. These can be used as defaults or used as a basis for customizing your own.
The startup list names the resource groups that are to be installed at system initialization. In this way, you can specify which resources are associated with a SIT and therefore which resources are installed when an MTO-enabled enterprise server is started. You can share resources across multiple enterprise servers or you can restrict some resources to a specific enterprise server. No matter what resources are defined in an RDF, a resource is not installed for a enterprise server unless the group that the resource belongs to is specified in the startup list associated with the SIT used to start the enterprise server. (You can, however, use the supplied transaction CINS to install further resource groups once the server is running.)
Assume, for example, that the RDF defines the resources shown in Figure 4-1:
Figure 4-1: Example of resources defined in the RDF
Starting a enterprise server with the SIT SAMPSIT1 specified will initialize that enterprise server with the two groups SAMPGRP1 and SAMPGRP2. This is because SAMPSIT1 specifies a startup list SAMPLST1 which has only those two groups listed.
Additional groups can be installed to that enterprise server when it is running, without having to stop the server, by using the supplied transaction CINS.
Assuming you have the authority (sign-on security privilege) to run the transaction, enter:
CINS SAMPGRP3
Then the SAMPLIST3 group is installed and made available to enterprise server users.
You can control whether to load all PCT entries at startup or to defer the loading of some or all PCT entries until the corresponding transaction ID is entered.
The advantages of loading all PCT entries at startup are:
These advantages are particularly important in a production environment, where you need fast response times and stable region definition. The disadvantage is that if there are many PCT entries to load, the startup time is increased and the shared memory usage will be high.
You can control the loading of PCT entries with the Defer Install field on the CICS SIT page of ESMAC.
If you defer loading PCT entries, when you enter a transaction ID that is not currently loaded into memory, MTO searches the groups specified in the original startup list in reverse order. If a PCT entry for the transaction ID is found, it is dynamically loaded into memory for subsequent use. If the transaction ID is not found, a TRANSIDERR occurs as normal.
Note: If a group specified as deferred is empty at startup, it will not be searched subsequently for PCT entries.
The following examples assume that resources are defined as shown.
Example 4-1:
Assume the RDF defines the resources shown in Figure 4-2.
Figure 4-2: Resource Definition File for Example 4-1
Using DEFSIT1, the following entries are loaded into memory at startup (in addition to the DFH group entries):
The entry for (TRN1,PROG5) from DEFGRP2 is used instead of the entry for TRN1 in DEFGRP1. This is because DEFGRP2 occurs later than DEFGRP1 in the startup list.
Example 4-2:
Assume the RDF defines the resources shown in Figure 4-3.
Figure 4-3: Resource Definition File for Example 4-2
Starting the region with DEFSIT2, deferred PCT loading is enabled for all groups in the startup list. No PCT entries are loaded into memory at startup. When the is running, if the transaction ID TRN3, for example, is entered from a client, the system will:
Subsequent uses of the transaction ID TRN3 will find the PCT entry in memory, so no searching of the resource definition file takes place. Similarly, if the transaction ID TRN1 is entered from aclient, the system searches for and finds the definition in DEFGRP2.
This will find the same definition for TRN1 as Example 4-1.
Example 4-3:
Assume the RDF defines the resources shown in Figure 4-4.
Figure 4-4: Resource Definition File for Example 4-3
The third type of deferred PCT load allows you to specify the number of groups that will have the loading of their PCT definitions deferred. In this case, the deferred group count is set to 1, so the loading of PCT definitions from DEFGRP2 is deferred.
The number of groups to defer is counted back from the end of the startup list.
In this case, at system startup, the following PCT definitions are loaded into memory:
The definition for transaction ID TRN1 is now taken from DEFGRP1 and not from DEFGRP2, as in Example 4-1 and Example 4-2.
Copyright © 2006 Micro Focus (IP) Ltd. All rights reserved.