invoked, displays a menu screen from which the user can choose a specific
application. It is then possible to run all the elements of the application under the
common menu transaction ID. This is very effective from the application users point
of view, because they do not have to use a large number transaction IDs to run an
application. However, this is not helpful from a performance monitoring point of
view, because all the data is identified with a single transaction ID, and using
standard CICS performance class data, it is not possible to distinguish the various
elements of a large application. Having completed a long and possibly complex
transaction selected from the menu, on returning to the menu the user could select
an entirely different application that then runs under the same menu transaction ID.
Thus, the use of menu transactions and similar design techniques can make it
difficult to monitor the performance of individual parts (or tasks) of an application.
You could also have the opposite of the menu transaction, where an application
runs under many different transaction IDs, and you want some means of identifying
or relating all these apparently disparate items of work to the same application.
Another factor to consider when trying to collect data in the way you want is the
effect of invoking an EMP. Each time you invoke an EMP with an EXEC CICS
MONITOR command, all the performance data collected by the system EMPs, and
the data collected by the user EMPs, is cleared from the transaction's monitoring
area. This makes it difficult for application designers using ordinary user-defined
EMPs to control the gathering of performance class data.
To exercise greater control over the identification and collection of performance
data, you can use the application naming event monitoring points that are
generated for you automatically when you specify APPLNAME=YES in the
DFHMCT TYPE=INITIAL macro. There are two APPLNAME EMPs generated when
you assemble an MCT with APPLNAME=YES, DFHAPPL.1 and DFHAPPL.2, which
perform the following default operations when invoked:
DFHAPPL.1
Moves 4 characters from offset 0 of the address specified on the DATA1
option of the EXEC CICS MONITOR command.
DFHAPPL.2
Moves 8 characters from offset 4 of the address specified on the DATA1
option of the EXEC CICS MONITOR command.
Unlike EMPs that you define explicitly with your own empids, data moved by
invoking the APPLNAME EMPs is not reset by CICS, but you can set different
values by invoking the APPLNAME EMPs again.
Examples of invoking application naming EMPs
Figure 102 on page 746 shows an assembler example of how to move a CICS
transaction ID to the transaction monitoring area.
Chapter 28. CICS monitoring 745