IMS internal resource usage
There are several summary reports that you can use to examine the level of internal contention for resources.
The following list provides a brief description of these reports.
- Pool space failure report
- The Pool Space Failure Summary report gives the number of times
(in each region) a given amount of storage was unavailable. It shows
the number of bytes, the identification of the pool, and the number
of occurrences when storage was unavailable. You can use this summary
to determine if you need to increase the buffer pool allocation, either
by a system definition change or by overriding the number of buffers
in the EXEC statements in the JCL.
The format of the report is shown in the following example.
POOL SPACE FAILURE SUMMARY POOL ID BYTES REQ. OCCURRENCES DLMP 8888 1 DLDP 7777 1 TOTAL 2 - Programs experiencing deadlock report
- The Deadlock Event Summary report records each time a pair of
programs reaches a deadlock over ownership of a segment in a given
database data set. Each line in the report shows the two PSBs involved
and indicates which is given processing right-of-way (REQ-ING PSB)
and which has to reprocess after dynamic backout has occurred (LOSING
PSB). The deadlock event summary report is illustrated in the following
example.
DEADLOCK EVENT SUMMARY REQ-ING PSB LOSING PSB DMBNAME OCCURRENCES PSBNAME1 TPPSBRE3 DBASEBAL 1 TOTAL 1 - IMS latch conflict report
- The basic serialization of the task processing in IMS is controlled by ownership of an IMS latch. When different programs are executing,
they compete for the ownership. If they wait for the resource, the
one possessing the latch has to post the other ITASK waiting for it.
Use the Latch Conflict Statistics report to judge the level of contention
for a resource.
The different types of latches and the counters that exhibit the level of contention are given in the Latch Conflict Statistics report. The following example shows a sample latch conflict statistics report. The entries are organized according to the latch names.
When a system checkpoint is taken during the time the monitor is active, latch conflict statistics are reset to zero, thus corrupting the values presented in this report. If this situation exists, the following message will be inserted at the top of the report:
**** A CHECKPOINT OCCURRED DURING MONITOR RUN **** **** LATCH CONFLICT STATISTICS ARE INVALID **** **** SEE UTILITIES REFERENCE MANUAL ****However, if the master terminal operator issues the /CHECKPOINT command with the STATISTICS keyword parameter, latch conflict statistics are reset to zero, but the IMS monitor is not notified. Therefore, DFSUTR20 cannot detect that the statistics have been corrupted and will not issue this message.
Recommendation: Do not issue statistics checkpoints while the monitor is running.IMS MONITOR ** GENERAL REPORTS ** TRACE START 1993 209... LATCH CONFLICT STATISTICS LATCH COUNT AT AT NAMES FIELD START END DIFF. LOGL CONTENTIONS 0 0 0 SMGT CONTENTIONS 0 0 0 XCNQ CONTENTIONS 0 0 0 ACTL CONTENTIONS 0 0 0 CBTS CONTENTIONS 0 0 0 DBLK CONTENTIONS 0 0 0