Figure 4-1: Example of resources defined in the RDF
This chapter describes some of the ways in which regions can be used, the information needed to control region processing and how to create and configure regions.
On a mainframe, 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.
Similarly, on a PC, the use of CICS Option regions varies widely, for example:
The System Initialization Table (SIT) specifies how a region is to be initialized when it starts up. It determines such things as, but is not limited to:
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 CICS Resource Definitions in the Administrator's Guide. CICS Option supplies several pre-configured SITs. These can be used as defaults or used as a basis for customizing your own.
Whan you create a new project, you can define the region name, RDF, and SIT that the project is to use. After the project has been created, you can change the region name, RDF, SIT, and startup list with the CICS System Properties dialog box. The changes that you make on the Overrides page of the CICS System Properties dialog box are stored in the project file, not in the RDF.
You set the number of shared pages for a region in the Shared Pages field of the SIT.
The shared pages is the shared memory resource used by a CICS Option region; each server and terminal emulator also requires its own memory which is allocated dynamically.
Use the calculation described in this section to estimate the number of shared pages to allocate to a CICS Option region. The calculation is based on the number of servers, resource definitions, and memory allocation the region requires.
Actual requirements vary according to the nature of the workload, but you are advised to over-allocate the shared memory resource. CICS Option optimizes the use of the shared memory resource by minimizing the number of physical pages used at lower than maximum processing volumes.
Perform the calculations in the middle column of the table below and enter the result of each calculation in the right-hand column. The sum of these answers is the minimum number of bytes required for the shared memory. Divide this number by 4096 and round up to get a figure for the number of shared pages needed.
| Item |
Calculation |
Result |
|---|---|---|
| CICS Option overhead | Fixed size | = 4096 |
| Shared storage management | Shared storage size / 4096 | = |
| Trace | Number entries x 24 | = |
| Server | Number servers x 64 | = |
| Terminals | Number requesters x 64 | = |
| Remote systems | Number sysids x 96 Number sessions x 32 |
= = |
| PCT | Number entries x 48 | = |
| FCT | Number entries x 88 + (4 x Number split key components used) | = |
| DCT | Number entries x 48 | = |
| PPT | Number entries x 48 | = |
| Programs (load hold)1 | Number active x (average length + 8) | = |
| TST | Number entries x 32 | = |
| PLT | Number entries x (56 + (8 x avg items in list)) | = |
| JCT | Number entries x 48 | = |
| ICE2 | Number active x 64 | = |
| AID3 | Number active x 64 | = |
| Getmain SHARED4 | Number active x (average length + 8) | = |
| ENQ5 | Number active x (24 + average arg length)
Number processes waiting on ENQ x 16 |
= = |
| Buffers6 | (3270 data stream length + COMMAREA + TEUA + 64) x number servers | = |
Notes:
Buffers are short lived and stay in shared storage only if no server is available to service the request. Once a server 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 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 a region is started. You can share resources across multiple regions or you can restrict some resources to a specific region. No matter what resources are defined in an RDF, a resource is not installed for a region unless the group that the resource belongs to is specified in the startup list associated with the SIT used to start the region. (You can, however, use the supplied transaction CINS to install further resource groups once the region is running.)
When you create a project, CICS Option reads the startup list associated with the SIT that you specify from the RDF and stores it in the project file. Any changes that you make to the startup list are not written back to the RDF.
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 region with the System Initialization Table SAMPSIT1 specified will initialize that region 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 region when it is running, without having to terminate the region, 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 region users.
This section describes some recommended approaches to the setting up of resources to facilitate:
Your system administrator would perform some of the tasks described, while you, as a CICS developer, would perform others.
For group working, your system adminstrator should perform the following tasks:
For further information on these tasks see the chapter CICS Resource Definitions in the Administrator's Guide
Then, to set up a project that uses this shared resource definition file:
Mainframe Express now performs the following actions:
You can now make changes to the SIT and startup list on your PC without affecting other developers who are using the shared RDF. You can view and change the SIT settings by right-clicking CICS System in the CICS View and clicking Properties. You can make changes to the startup list by right-clicking CICS System in the CICS View and clicking Startup List. You can also add a new resource to the project on your PC without affecting other users. When you add a new resource using the IDE, Mainframe Express by default creates a new resource group with the same name as the project, and adds it to the project's startup list.
When your CICS region is initialized, it obtains the location of the shared RDF from the project file. It reads the SIT specifed in the project file from the RDF, then applies the overrides stored in the project file. It then reads the startup list specifed in the project, not the startup list stored in the shared RDF.
Notes:
You can set up an RDF for stand-alone working on your own PC as follows:
Mainframe Express now performs the following actions:
You can make changes to the SIT and the startup list using the IDE.
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 PCT load field on the Development page of the SIT properties dialog box.
If you defer loading PCT entries, when you enter a transaction ID that is not currently loaded into memory, Mainframe Express 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.
Assume the RDF defines the resources shown in Figure 4-2.
Figure 4-2: Resource Definition File for Example 1
Using DEFSIT1, the following entries are loaded into memory at region startup (in addition to the DFH group entries):
(TRN2,PROG2) from DEFGRP1
(TRN3,PROG3) from DEFGRP1
(TRN4,PROG4) from DEFGRP2
(TRN1,PROG5) from DEFGRP2
Note: 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.
Assume the RDF defines the resources shown in Figure 4-3.
Figure 4-3: Resource Definition File for Example 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 region startup. When the region is running, if the transaction ID TRN3, for example, is entered from a 3270 terminal, the system will:
Search DEFGRP2 for a PCT entry=TRN3. Result: Not found
Search DEFGRP1 for a PCT entry=TRN3. Result: Found. Load the
definition into memory
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 a 3270 terminal, the system searches for and finds the definition in DEFGRP2.
Note: This will find the same definition for TRN1 as Example 1.
Assume the RDF defines the resources shown in Figure 4-4.
Figure 4-4: Resource Definition File for Example 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.
Note: 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:
(TRN1,PROG1) from DEFGRP1
(TRN2,PROG2) from DEFGRP1
(TRN3,PROG3) from DEFGRP1
Note: The definition for transaction ID TRN1 is now taken from DEFGRP1 and not from DEFGRP2, as in Examples 1 and 2.
Copyright © 2001 Micro Focus International Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.