 |
» |
|
|
|
User tracing records intrinsic calls and data for a single
transaction program, including all conversations in which the transaction
program is engaged. Tracing can be turned on using the TraceOn parameter of the TPStarted intrinsic. Once the trace has been turned on,
it remains on until TPEnded is called. Entries are written to the trace file
at the completion of each intrinsic call. See Chapter 5 “ Intrinsic Descriptions” for
descriptions of the TPStarted and TPEnded intrinsics. User tracing should be enabled during program development
so that the trace will always be available for debugging. It is
common practice to disable user tracing after a program has been
debugged. However, if a problem arises after the program is in use,
enabling tracing again may help to diagnose the problem. You can enable or disable user tracing without recompiling
the program by creating a control file that passes the desired tracing
value to the TPStarted intrinsic, or by coding your program to accept
an info string from the MPE RUN command that contains the TraceOn value. Collecting the User Trace | |
The user trace file is created in the group and account from
which the TP is run. The default name is PSTRACnn, where nn is a number from 00 through 49 that increments each
time a new file is opened. After 25 user trace files are created, the system purges one
trace file each time a new one is opened. Trace files are created
and numbered as follows: Trace files PSTRAC00 through PSTRAC24 are created. PSTRAC25 is created and file PSTRAC00 is purged. The next trace file created is PSTRAC26. When PSTRAC26 is created, PSTRAC01 is purged. When PSTRAC27 is created, PSTRAC02 is purged, and so on. After trace file PSTRAC49 is created, the numbering wraps and the next file
created is PSTRAC00.
There are never more than twenty-five trace files in the group
and account where the TP is running, because, after the twenty-fifth
file is created, an old file is purged for each new one created.
Because the numbering wraps to 00 after it reaches 49, the youngest
trace file could be numbered either low or high. The key to finding
the youngest file is determining whether the file numbers have wrapped. If the file numbers have not wrapped, the numbering will be contiguous;
that is, no gaps will exist between numbers. In the following example,
PSTRAC00 to PSTRAC21 have been purged, and PSTRAC47 to PSTRAC49
do not exist. Therefore, the files have not wrapped, and the file
with the highest number is the youngest. :listf pstrac@.testpgms.api,2
<F100P12>ACCOUNT= API GROUP= TESTPGMS
FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----
SIZE TYP EOF LIMIT R/B SECTORS #X MX
PSTRAC22 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC23 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC24 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC25 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC26 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC27 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC28 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC29 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC30 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC31 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC32 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC33 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC34 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC35 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC36 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC37 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC38 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC39 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC40 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC41 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC42 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC43 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC44 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC45 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC46 NTRAC 128W FB 1000 1000 8 1008 16 16
: |
The youngest trace file is PSTRACE46, because the file numbers
are contiguous, and 46 is the highest number. If the file numbers have wrapped, the file with the highest
number is not the youngest. In the following example, notice that
the numbering jumps from PSTRAC02 to PSTRAC28. There is a gap of
26 file numbers after PSTRAC02. The youngest file will always be
at the lower end of the gap. In this example, the youngest file
is PSTRAC02. The files PSTRAC03 through PSTRAC27 have been purged,
and the numbering has wrapped. :listf pstrac@.testpgms.api,2
<F100P12>ACCOUNT= TESTPGMS GROUP= API
FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----
SIZE TYP EOF LIMIT R/B SECTORS #X MX
PSTRAC00 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC01 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC02 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC28 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC29 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC30 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC31 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC32 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC33 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC34 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC35 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC36 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC37 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC38 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC39 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC40 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC41 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC42 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC43 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC44 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC45 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC46 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC47 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC48 NTRAC 128W FB 1000 1000 8 1008 16 16
PSTRAC49 NTRAC 128W FB 1000 1000 8 1008 16 16
: |
| | | |  | NOTE: When you delete some of the trace files from a group,
you no longer have a complete set, and finding the youngest file
becomes difficult. If you must clean up trace files, copy the files
that you need to another group and purge all the trace files at
once. | | | | |
Formatting the User Trace | |
The trace file must be formatted before you can read it. On
MPE V, use the utility APPCDUMP.APPC.SYS to format the user trace. APPCDUMP requires that
you specify an input file and an output file. The syntax for running
APPCDUMP is as follows: :FILE TRACEIN = trace file name
:FILE TRACEOUT = { $STDLIST } (terminal)
{ *LP } (printer)
{ file designator }
:RUN APPCDUMP.APPC.SYS |
On MPE XL, use the NMS utility NMDUMP.PUB.SYS to format the user trace. To run NMDUMP, type
the following command at the MPE colon prompt: :RUN NMDUMP.PUB.SYS NMDUMP will respond with a menu. You use the menu to indicate
the type of file you want to format and which subsystem generated
the file. NMDUMP will prompt you for an input file and an output
file. The default output file is $STDLIST. You can use a file equation
to back-reference the name of an input or output file. For more information
on NMDUMP, see Using the Node Management Services (NMS)
Utilities. Reading the User Trace | |
The user trace records information for each intrinsic the
local TP calls. This section explains how to read the information
in the user trace. Figure 7-1 “User Trace of a Two-Way Conversation” is an example trace of a two-way
conversation. Figure 7-1 User Trace of a Two-Way Conversation Figure 7-1 “User Trace of a Two-Way Conversation” is an example of a trace of a
two-way conversation. This section explains the meaning of each
field in the user trace. - Intrinsic
name
The name of each LU 6.2 API intrinsic the local
TP calls appears on the left side of the display. - RetCode
(Return Code) This is the status info value returned
in the Status parameter of the intrinsic. The status info is the
most useful piece of diagnostic information in the user trace. It
directs you to areas of investigation that help you identify problems
with your TP. Chapter 5 “ Intrinsic Descriptions” lists the values that
each intrinsic can return, and Appendix A “Status Info” lists
the causes and recommended actions for all status info values. - Rsrc
(Resource ID) This is the conversation identifier returned
by MCAllocate or MCGetAllocate. It identifies the conversation for which each
intrinsic was called. In the example, only one conversation (with Resource
ID of 15) was allocated, so all intrinsics were called for that
conversation. If more than one conversation had been allocated (that
is, if MCAllocate had been called more than once by the TP), the different
Resource IDs would tell you which intrinsic calls belonged to which
conversations. - ConvState
This is the conversation state of the local TP after
the intrinsic has executed. - Intrinsic parameters
The rest of the fields in the trace are the parameters specific
to each intrinsic. Different parameters are traced for different
intrinsics. The parameters are listed here by intrinsic. See Chapter 5 “ Intrinsic Descriptions” for more information on intrinsics and their
parameters. - TPStarted:
- TPID
Transaction program identifier - TPName
Name of transaction program - TraceSize
Trace file size in records - TraceFile
Name of trace file for user tracing
- TPEnded:
- TPID
Transaction program identifier
- MCAllocate:
- TPID
Transaction program identifier - SessionType
Configured session type used by the conversation - SyncLevel
Synchronization level for the conversation (CONFIRM
or NONE) - ReturnControl
When control is returned to your program if no session
is available (IMMEDIATE or WHEN_SESSION_ALLOCATED) - Timer
How long your program will wait on an intrinsic
call for data or confirmation from the remote TP before control
is returned to your program - NameLength
Length (in bytes) of remote TP name - RemoteTPName
Name of remote TP (in hex) - PIPxx
PIP data (xx = 1 through 16). On the left, the PIP
data is displayed in hexadecimal. On the right, it is displayed
in EBCDIC.
- MCGetAllocate:
- TPID
Transaction program identifier - SessionType
Configured session type used by the conversation - SyncLevel
Synchronization level for the conversation (CONFIRM
or NONE) - Timer
How long your program will wait on an intrinsic
call for data or confirmation from the remote TP before control
is returned to your program - TPName
Name of local transaction program - PIPxx
PIP data (xx = 1 through 16). On the left, the PIP
data is displayed in hexadecimal. On the right, it is displayed
in EBCDIC.
- MCConfirm:
- RTS
Request to send received
- MCDeallocate:
- DeallocateType
Type of deallocation for the conversation (CONVERSATION_SYNC_LEVEL, FLUSH,
ABEND, LOCAL, or CONFIRM)
- MCPostOnRcpt:
- Length
Length of data to be received before local TP is
notified - Offset
Stack offset of data to be posted (This value is
in decimal on MPE V and hexadecimal on MPE XL.)
- MCPrepToRcv:
- Locks
Lock specifying when control is returned to the
conversation - Type
Type of PrepToRcv (FLUSH, CONFIRM or CONVERSATION_SYNC_LEVEL)
- MCRcvAndWait, MCRcvNoWait:
- RTS
Request to send received
- Length
Length of data received
- Offset
Stack offset of data received (This value is in
decimal on MPE V and hexadecimal on MPE XL.)
- WhatRcvd
What was received (data or control information)
- Data
Data received. On the left, the data is displayed
in hexadecimal. On the right, it is displayed in EBCDIC.
- MCSendData:
- RTS
Request to send received - Length
Length of data sent
- Offset
Stack offset of data sent (This value is in decimal
on MPE V and hexadecimal on MPE XL.)
- Data
Data sent. On the left, the data is displayed in
hexadecimal. On the right, it is displayed in EBCDIC.
- MCSendError:
- RTS
Request to send received
- MCTest:
- PostedType
Type of information posted (DATA or NOT_DATA) - Test
Condition being tested (POSTED or REQUEST_TO_SEND_RECEIVED)
- MCWait:
- PostedType
Type of information posted (DATA or NOT_DATA) - ResourcePosted
Resource ID of the conversation being posted.
|
