10. MODIFICATION › 10.3 Program Modifications to the Assembler Routines › 10.3.3 Apportionment Algorithm Modifications
10.3.3 Apportionment Algorithm Modifications
The BMC MAINVIEW for IMS Online Event Collector produces
transaction records that contain resource time measures for
all the resources used by each IMS transaction.
Beginning with IMS Version 10.1, and the introduction of the
Transaction Level Statistics (TLS) log record, CPU time and
other resource measurements can be captured at the
transaction level. If TLS record generation is active, then
the following discussion regarding CPU time and other
resource apportionment is not longer applicable.
Without either BMC MAINVIEW for IMS Online or the presence of
the TLS log records beginning with IMS Version 10.1, resource
usage information is not presented by individual transaction.
Rather, resource use statistics are contained in the type 07
log record. The type 07 log record is only produced by IMS
at the end of a schedule, during which one or many
transactions may have been processed.
Consider the following diagram, showing two transactions
being processed in a schedule.
Residency time,
transaction A
(ISURESTM)
|<---------------->|
| |
Input queue | | Input queue | Residency
time, tran A| | time, tran B| time, tran B
(ISUTMQIN) | | (ISUTMQIN) | (ISURESTM)
|<---------->| |<----------->|<------------>|
| | | | |
-------------------------------------------------time->
01 35S 08 31D 01 35S 03 31D 03 07
A: 01.35S.......31D..........03....31D
B: ..................01.35S........31D....03......07
The input message for transaction A arrives first in the
diagram. It enqueues on the transaction's SMB (35S, or a
type 35 SMB enqueue record). IMS schedules the transaction
(type 08 record) and processing begins.
Transaction A's input message is read by the application
program (type 31D, Get Unique (GU) from the message queue by
DLI). Meanwhile, transaction B's input message arrives (01)
and enqueues on the same SMB (35S). Transaction A produces
an output message (03), and finishes executing.
When the application program is ready to process the next
transaction, it issues another GU from the IMS message queue
(the second 31D record), getting transaction B's input. The
program processes transaction B, produces an output message
(the second type 03 record), and finishes.
The application program then performs another GU from the
message queue. This time, there are no input messages
waiting, so IMS terminates the application. After the
application is terminated and the message processing region
is quiesced, IMS writes the application accounting record
(type 07).
The resource data in the type 07 log record represents
resources used over the entire schedule. There is one
measure of CPU time in this example: the sum of CPU time used
by transactions A and B.
The CA MICS IMS Analyzer apportions the resources in a type
07 log record by the ratios of residency times of the
transactions that executed in a schedule as illustrated
below.
o Residency time for transaction A is 2 seconds.
o Residency time for transaction B is 4 seconds.
o Thus, the total residency time for both transactions was
6 seconds.
o The type 07 log record indicates that 3 seconds of CPU
time were used by the application program during the
schedule.
o Transaction A is given its "share" of the CPU time, which
is 3 CPU seconds times 2 residency seconds divided by 6
residency seconds, or
3 CPU sec * (2 res sec / 6 res sec) = 1 CPU second
o Transaction B is given its "share" of the CPU time, which
is 3 CPU seconds times 4 residency seconds divided by 6
residency seconds, or
3 CPU sec * (4 res sec / 6 res sec) = 2 CPU seconds
The theory behind this apportionment algorithm is that
transactions that took longer to execute must have used more
resources than their faster companions.
This method worked well when first introduced because IMS
transaction residency times were larger due to the slower
computers of the day. However, with the faster hardware and
improved performance of later versions of IMS software,
residency time apportionment is less meaningful. The theory
is just as valid, but in practice there is a flaw in the
method.
Residency time is calculated from the differences between two
timestamps. For transaction A in the example, residency time
is the difference between the timestamp on the first type 31D
record and the timestamp on the second 31D. For transaction
B, residency is the difference between the timestamps on the
second type 31D record and the type 07 log record.
IMS presents all these timestamps in .1 second precision.
Modern IMS systems can process many transactions in the same
tenth of a second. Thus, many transactions processed by the
IMS Analyzer are observed to have ZERO residency time.
There is an alternate method available for performing
resource apportionment. This method uses the transaction
count as the basis for apportionment. If n number of
transactions executed during the schedule, then each
transaction gets 1/n amount of the resource.
To use the alternate apportionment algorithm in the Log Data
Reduction (LDR) program(s) (listed in section 10.3), find the
SETC statement that defines the macro variable APPORTN. This
variable may take only two values:
o The first value performs apportionment by the ratios of
residency time, as follows:
&APPORTN SETC 'TRANRESP'
o The second value performs apportionment by the number of
transactions executed, as follows:
&APPORTN SETC 'TRANBMPC'
Before making modifications, follow these steps:
1. Make a complete record of your modifications.
2. Copy the program code from sharedprefix.MICS.ASM to
sharedprefix.MICS.LOCALMOD.CNTL to save an original copy
of the logic.
3. Review any further CA MICS IMS maintenance for changes to
the LDR program(s) that might interfere with your planned
modifications. Resolve any line collision issues with
help from CA Technical Support.
After modifying the LDR program(s), reassemble using the
CA MICS IMSASM job.
Copyright © 2014 CA.
All rights reserved.
|
|