Avoiding contention for IMS resources (excluding buffer pools)

The interleaved processing of concurrent regions is a major area of contention for IMS resources. A set of regions processing a mix of transactions can overlap processing and use the advantage of multitasking over serially ordered execution.

The following list identifies several areas concerned with the pattern of scheduling and region efficiency:

• Using class scheduling in DB/DC and DCCTL environments

  The following points affect your decisions about using class scheduling:

  • Use classes to separate low-priority and long-running transactions from high-priority work.
  • Arrange your class structure so that any high-priority class work has the opportunity of being scheduled in more than one region, unless doing so is undesirable for some special reasons, such as program isolation conflicts. Multi-server systems generally produce lower waiting times than single-server systems.
  • To prevent message regions from being idle while transactions are waiting on the input queue, assign additional (lower-priority) classes to a message region below the primary class or classes assigned to the region. Avoid regions that only service one class, unless you are sure that work of that class will always be waiting to be processed.
  • For very high-volume transactions, dedicate a message region and classify the program as a wait-for-input program to reduce input queuing time and to eliminate scheduling and program load.
• Processing limit counts in DB/DC and DCCTL environments

  Review your transaction class and priority scheme. Set the PROCLIM parameter on the TRANSACT macro to ensure that no transaction type can monopolize a message region if other transactions are waiting and are eligible for processing in that region. Only use a PROCLIM value higher than 5 if the response times of contending transactions are unimportant. In that case, set PROCLIM=1 for the lower-priority transactions. With wait-for-input transactions, set PROCLIM to a suitably high (or maximum) value so that you avoid rescheduling the application program. Use pseudo WFI and quick reschedule to eliminate processing overhead. By going through quick reschedule, a region can process more messages per schedule than the processing limit, thereby eliminating unnecessary rescheduling and reloading of application programs.

  Note: A region scheduled against a transaction whose processing limit count is 0 cannot go through quick reschedule or become a pseudo WFI.
• Parallel scheduling in DB/DC and DCCTL environments

  Do not use parallel scheduling for low-volume transactions that can be scheduled sequentially. Using message regions for parallel processing can reduce the efficiency of regions in which multiple transactions are processed for each scheduling of a program. Parallel scheduling should be reserved for those transactions where temporary peaks in the arrival rate might cause excessive queuing to develop due to flooding of a single message processing region. In these situations use a PARLIM level geared to the average service time and response time objective for the transaction type.

• IMS message processing regions in DB/DC and DCCTL environments

  Operating your IMS system with too few or too many message processing regions can affect performance and transaction response times. In an environment with many different transaction types, regions with a very high occupancy level must be carefully monitored to ensure that they are not causing queues to build up on the IMS message queues.

  In environments with only a few transaction types, high levels of occupancy can usually be sustained, because the application programs can often remain in the region processing multiple transactions for each schedule.

  The meaning of high occupancy depends on the transaction mix, transaction characteristics, class scheduling scheme, and response-time objectives. For some transactions, a large queuing delay might be acceptable. For others, a much smaller queuing delay must be achieved in order to satisfy the user.

  In contrast, having many low-occupancy concurrent message processing regions can unnecessarily increase the contention among regions for buffer pool space, real storage, IMS system data sets, and database records (because of program isolation enqueuing).

  You can eliminate some of the processing overhead by specifying pseudo wait-for-input (PWFI) on the MPP region startup procedure. A PWFI message processing region remains scheduled when no more messages need to be processed, instead of terminating the application program. This eliminates unnecessary termination and rescheduling.

  Adjust the number of message processing regions to the minimum possible consistent with achieving your response-time objectives. Increase the number of regions only when an increasing workload cannot be serviced within the objectives, and when changes to the message class structure, quick reschedule, PWFI, and region control parameters (including PARLIM, PROCLIM, and WFI) do not effectively contain the response-time increases. Although you can specify up to 999 dependent regions, always try to contain the response time demands with a minimum number.

  The number of required regions, excluding wait-for-input regions, can be estimated as shown in the following example.

  number of regions =
           ((arrival rate)*(time in region))/(desired region percentage occupancy)

  arrival rate is the total number of transactions received in an interval divided by that interval in seconds. time in region is defined as the sum of the mean times for: scheduling and termination, schedule-to-first DL/I call, and elapsed execution, taken from the IMS Monitor Region Summary report.

  Do not include regions dedicated to wait-for-input processing in this calculation, because their region occupancy is 100%.

  In addition to establishing the number of message processing regions, you control which transactions can be scheduled into those regions by:

  • The choice of class and priority structure
  • The PROCLIM and PARLIM parameters on the TRANSACT macro
• CCTL regions in DB/DC and DBCTL environments

  CCTL application program performance can be affected by contention for database resource adapter (DRA) resources. Specifically, if the maximum number of DRA threads allowed is less than the number of CCTL application programs making PSB schedule requests, some of those requests wait until a DRA thread becomes available.

• Save area sets in DB/DC and DCCTL environments

  When you consider the number of regions and their occupancy for a given transaction rate, check that the input data transmission is not delayed. One factor causing delay might be the limiting number of concurrent terminal I/Os. You can adjust this limiting number using the SAV parameter in the online EXEC statement (up to a maximum of 999 concurrent I/Os). This parameter is termed the number of dynamic save area sets for the terminal I/O, because one of these areas controls each active terminal I/O.

• Database contention in DB/DC and DBCTL environments

  Avoid databases with a small number of roots or root anchor points. If the databases are accessed by more than one transaction concurrently, program isolation (PI) contention is probable. The use of control records in databases or of records that keep running totals also causes PI enqueuing.

  If you cannot avoid databases with a small number of roots, use class scheduling to allocate all such contending transactions to a single region, thus forcing them to process sequentially.