TPF41 DUMP ANALYSIS OVERVIEW FOR THE PAT GROUP

COURSE NOTES
DEFINITION OF A TPF 4.1 SYSTEM DUMP

A SYSTEM DUMP, or CORE DUMP, or DUMP, on a TPF system,

is a snapshot of selected areas of core, taken immediately an error is detected.

Other activities are immediately suspended and selected areas of core are written to
the Dump device. This can be printed off with a Post Processor and used with other
information to help find the cause of the error

System error processing is always initiated through a program interruption for

software errors, or a machine check for hardware errors. (Core parity failure, channel
failures, processor chip exploding etc.) We shall leave the hardware errors to the
engineers!

The Dump process is automatically initiated by the Interrupt system when the error is
detected, different areas of core may be dumped for different types of error in an
attempt to provide enough information to find the problem.

WHY WE DUMP

To provide information to solve the problem:

To minimise the effects of the error:

In some cases the system will immediately stop the entry that caused the error
and exit it from the system. In other cases, control may be returned to the
entry so that it can clean up - data records can be reset, and so on.

26/09/09 Page 1
 AN OVERVIEW OF TPF
PRINCIPAL FUNCTIONS AND FEATURES
OVERVIEW OF CORE LAYOUT OF A TPF SYSTEM

CP Records and Tables

Core Resident pgms

CP Records and Tables

Fixed Storage
Globals

CP Records and Tables

VFA
VFA

CP Records and Tables

Fixed Storage

IOBs
SWBs

ECBs
Working Storage

4K Frames

4K Common frames

Core Resident pgms

CP Records and Tables
Fixed Storage
Globals

Control Program

Main Storage

26/09/09 Page 2
 OVERVIEW OF THE CPU LOOP

Check the
Cross List Process Cross List

Check the
Ready List Process Ready List

Check the
Input List Process Input List

Check the
Deferred List Process Deferred List

Wait to be flagged
New work arrived

26/09/09 Page 3
 INPUT MESSAGES AND TRANSACTION

Messages

A user enters a message (e.g. what is the availability on flight ‘x’?). Once the user
presses the input key the message is ready to be sent to the system.
Each user’s ‘address’ is identified by a Galileo Terminal Identifier or GTID (used to
be called a Line Number Interchange Address Terminal Address or LNIATA). The
GTID is stored when the message arrives in the system so that the response (output
message) goes to the correct user.
Since input messages are the basic unit of work for a TPF system, its performance is
often measured by the number of (input) messages it processes per second.
TPF is designed to be capable of processing over 2,000 messages per second.

Transactions

A transaction consists of one or more user entries which together represent something
of importance to the business (e.g. several user entries are required to book a seat on
an aircraft)
The computer needs to keep track of the progress of a transaction to ensure that the
results of the separate but related entries from the same user are combined
To achieve this, each GTID has a record on DASD to keep track of transactions
(related entries from the same user). This record is called the AAA (Agents
Assembly Area)

Entry Control Block

The Entry Control Block (ECB) is a special area of memory, assigned by the Control
Program to keep track of an input message that arrives in the system.
It is ‘active’ for the life of a message and is used as an ‘anchor’ for the information
required to process the input message. It therefore contains some very important
fields like the user’s GTID.
Areas within it are used by application programs and other areas are used by the
Control Program.

26/09/09 Page 4
 PATH TAKEN BY AN AGENT ENTRY THROUGH THE TPF SYSTEM

26/09/09 Page 5
 CAUSES OF DUMPS
There are three broad categories of errors that will result in a dump:
- Hardware errors,
- Software Errors where the processor cannot continue the program execution
- Database Corruption where the program recognises the data is invalid in some way.

TYPES OF DUMPS
Program interrupts can be caused by one of two things:

Hardware forced
Software forced

1. Hardware (micro-code) forced

When the micro-code in the CPU hardware detects that an 'illegal' action is being requested.
For example, an application program, with a PSW protection key of 1 attempts to write to an
area in core with a protection key of F.
A program interruption occurs which activates system error processing. One of the following
system error numbers is then associated with the error:

CTL-I000001
This is a catastrophic program error detected whilst running in SVM.

CTL-I000003
This is a non-catastrophic program error detected whilst running in EVM.

CTL-I000002
This is a catastrophic address space violation error detected whilst running in
SVM or if running if EVM in supervisor state if the bad address is a branch
address (instead of just a bad data address).

CTL-I000004
This is a non-catastrophic address space violation error detected whilst
running in EVM.

Bit 15 of the PSW tell you if a program is running in problem or supervisor state.
0 = supervisor state
1 = problem state

Bits 16-17 of the PSW tell you whether EVM or SVM has control.
00 = EVM
11 = SVM

26/09/09 Page 6
Program interrupts (continued)

2. Software forced

This is caused by the active program executing a SNAPC or SERRC macro when an error is
detected by the program itself.
.
Both result in an invalid op-code being generated, which cause a program interrupt when
encountered.

The Control program CSECT CCCPSE, checks the type of error and failing instruction Op.
Code to see if it should process a SNAPC or SERRC macro, or whether a ‘micro-code’
forced error has been encountered.

26/09/09 Page 7
 TPF4.1 DUMP EXAMPLE
PRINCIPAL AREAS
SERRC DUMP FORMAT

System Error Number

The prefix and ‘senum’. The ‘senum’ identifies the type of error (used by SELOG41).

Appended Console Message

Any text string pointed to by R0 at the time of the SERRC.

For CTL-I000001/I000002/I000003/I000004 the appended message is always the general

registers and PSW at the time of the dump.

System Error Options

The ZASER options in force at the time of the dump are listed.

Dump Keywords
These are the keywords associated with the CTL dump error number (from the SMDT)

System Traces Active

There are six trace tools available. For those relating to ECBs, page 3 of the ECB is used to
hold the information:

MACRO Traces all SVCs. The information is stored in ECB Page 3.

ENTER Traces all core, file and VFA ENTERs and BACKs. The information is
stored in ECB Page 3.
SYSLOG Traces non-ECB transfers such as CXFRC, SWISC etc.

I/O This is not normally of relevance to application programmers.

BRANCH Traces certain branch instructions (BAS, BASR, BALR).

REGISTER Save register contents as part of the MACRO or ENTER trace
information.

ZSTRC is a functional entry that will display which options are active online.

Size of SVM
This is the amount of virtual storage defined for the main I/Stream.

26/09/09 Page 8
 BLK CHECK MODE
If YES, the block check mode test tool is active on the system. Check ECB Page 2 field as
well though, as block check can be deactivated for a single ECB if it approaches its 1Mb
private address range ceiling.

With Block check mode on:

1. Each private core block request results in a new 4K frame being obtained
2. The 4K frame from which a private core block was allocated is returned to the system and
removed from the EVM at RELCC or FILE time.

Block check mode tries to trap ECBs which walk off the end of private core blocks and refer
to private core blocks after release.

ECB Private Area

This gives the address range that will be used for the 24 bit EPA. Everything within that
range is not necessarily addressable by the ECB. The segment and page tables will
determine which addresses within that range can be accessed by the ECB.

Error Occurred In
This gives the address space in control at the time of the dump. Application dumps should be
in EVM unless the error occurred whilst the CP was performing some service on behalf of the
ECB which required it to switch address spaces to SVM.

Failing Program
The program name and version in which the error occurred are given together with the
displacement of the instruction in error and the loadset name in which the program was
loaded (default is BASE).

If you are looking at a 4.1 listing, the instruction displacement will be as given in the listing.
If you are looking at a 3.1 listing, add X'18' to the instruction displacement given to obtain
the correct displacement in the listing.

Storage Protection Keys

SVA ranges and their associated protect keys are listed. Note that the start of the EPA
represents the end of the common frame area so you should be able to identify the common
storage address range.

I/Stream Status Display

Information about the I/Stream in error is listed first. For an OPR dump with ZASER
SHORT, this is the only I/Stream status provided.

26/09/09 Page 9
General Registers

Addresses in these registers are likely to be EVAs (ECB Virtual Addresses) in EVM dumps.
R8 will contain the EVA of the program block, R9 will contain the EVA of the ECB).

Control Registers

Not used by applications, but for information, CR1 has the real address of the segment table
used by the EVM in control. CR13 always contains the real address of the SVM segment
table.

Current PSW at Time of Dump

The PSW is described on page 22 of the salmon (or new blue ESA/370) card.

Areas of particular interest are:

BIT 5 DAT control bit
1 = DAT on (usual setting)
BITS 8-11 current protect key
BIT 15
1 = Problem state (usual setting for applications)
BITS 16-17 Address space control
00 = EVM (primary address space in POPS)
11 = SVM (home address space in POPS)
BIT 32 Address mode
1 = 31 bit mode
0 = 24 bit mode
BITS 33-63 NSI address

The instruction address given in bits 33-63 is that of the bad instruction in a CTL-
I000004(2) where the 3rd and 4th bytes of the program interrupt code (see below) are either
0010 or 0011.

In all other dumps, it is the address of the next instruction. To obtain the bad instruction
address you therefore have to subtract the instruction length given in the 1st and 2nd bytes of
the program interrupt code (see below)

The displacement given on the first page under 'Failing Program' is always that of the bad
instruction.

26/09/09 Page 10
PSWS - Old, New, Intrpt Code

When an interrupt occurs, the current PSW is stored in the OLD PSW field in the prefix page
for the given interrupt type and the NEW PSW of the given interrupt type is loaded.

The OLD PSW fields therefore contain the PSW at the time of the last interrupt of that type
and the NEW PSW fields contain the PSW that is executed when an interrupt of that type
occurs. The instruction address portion of the NEW PSW (bits 33-63) is the address of the
routine to process each type of interrupt.

Restart New PSW is used for an IPL or restart (manual dump).

External New PSW is generally used by system timers.

SVC New PSW is loaded when a '0A' Op-code is encountered. It points to the macro
decoder within the Control Program.

Program New PSW is loaded when system error processing is required. It points to
CCCPSE which is the system error CSECT within the Control Program.

Machine New PSW is loaded when a hardware error is detected.

I/O New PSW is loaded when an interrupt is received from an I/O device. It points to
Centralised I/O (CIO).

The Interrupt Code provides more information about the interrupt. Of most interest to
application programmers are the SVC and PROGRAM interrupt codes.

The 1st and 2nd bytes of the SVC interrupt code are the length and are always 0002.
The 3rd and 4th bytes are the SVC number.

The 1st and 2nd bytes of the PROGRAM interrupt code give the length of the previous
instruction. The 3rd and 4th bytes give the program interrupt type code.
These are listed on page 23 of the salmon (or new blue ESA/370) card.

Trans Exec ID

Translation Exception Identification. This is only applicable for a CTL-4 dump since it
gives the virtual address that DAT could not translate within 4K. Therefore it may not be the
exact address but helps ensure that you are looking at roughly the right area.

26/09/09 Page 11
Prefix Register

Contains the absolute address of the prefix page for this I/Stream.

Last 10 Branch Table Entries

The last 10 branch entries will always be within the control program since it controls dump
processing. See ‘Branch Trace Table’ description below for more details.

Area of Program in Error

This is the object code located 2K before and 2K after the PSW NSI address (bits 33-63).

Area Referenced by Register

This information will not appear in an OPR dump with ZASER SHORT specified. 4K of
storage is displayed, 2K before and 2K after the address contained in each of the general
registers as long as the addresses are within the address space. R8, R9, R11 and R12 are
ignored as long as R8 points to the program block R9 to the ECB, R11 contains X’1000’ and
R12 contains X’2000’.

Collated ECB Macro Trace Entries

Each ECB maintains its own macro trace within page 3 of the ECB. However, an I/Stream
wide collated macro trace is also provided in the dump. The most recent macro is located at
the top of the collated trace table.

The ECB address given in the collated macro trace is an SVA. The offending ECB is
identified by '*' alongside the ECB address. R9 will contain a different address (EVA) to that
in the collated macro trace (SVA) in an EVM dump.

Prefix Page
There is one prefix page per I/Stream. Each one is a 4k core block in high memory which
contains all the core pointers and PSWs etc. the I/Stream needs to function properly.

Within assembler code, the prefix page is referenced as the first 4k of core although this is
not its absolute address. The absolute address of an I/Stream's prefix page is contained in the
prefix register which is a hardware feature. When assembler code refers to the first 4k of
core, therefore, the absolute address of the field referenced is resolved using the prefix
register at run time.

26/09/09 Page 12
 Branch Trace Table

A 4K area per I/Stream is used to record branches ‘traced’ with BRANCH trace. ‘LAST’
identifies the most recent entry.

It is of little use for application problem resolution because, since only the second word of the
PSW is recorded, you cannot determine whether the branch address is an EVA (ECB Virtual
Address) or an SVA (System Virtual Address).

Additional I/Stream Information

For systems running with more than one I/Stream, information about the non-offending
I/Streams are dumped except for OPR dumps with ZASER SHORT specified.

26/09/09 Page 13
 ECB (Entry Control Block)
The ECB consists of three consecutive 4K frames, or Pages of core in its own private area.

Useful ECB Page 1 Fields

ECB Page 1 is unprotected, addressed by R9 and defined by the DSECT EB0EB. The
application areas used will be specific to the function in which the error occurs. However, in
addition, the following Page 1 fields are useful in dump solving:

File Address Reference Words (FARW)

There are sixteen, 8 byte FARWs for application use and one for the program level. These 8
byte fields are consecutive within the ECB and start at dump tag FA0:

Each 8 byte item has the format:

| | | | | | |
record id | rcc | spare | file address
| | | | | | |

A File Address Reference Word needs to be set up before a FIND type macro is issued. If the
Record ID and RCC are zeroed on a FIND, no check is made for a match with the retrieved
record. These fields must match that of the data record, however, on a FILE macro.

Core Block Reference Words (CBRW)

There are sixteen, 8 byte CBRW for application use and one for the program block. These 8
byte fields are consecutive within the ECB and begin at dump tag CR0.

Each 8 byte item has the format:

| | | | | | |
| |
core block EVA | block | useable
| type | blk size
| | | | | | |

The block type can be :

0001 - Level not in use

0011 - 127 byte block attached
0021 - 381 byte block attached
0031 - 1055 byte block attached
0051 - 4095 byte block attached

26/09/09 Page 14
SUD Bytes - Detailed Data Level Indicators

There are 16 consecutive SUD bytes, one for each data level beginning at dump tag SUD.
The appropriate SUD byte is set up when an error occurs retrieving a record from DASD.

The byte settings and error descriptions are as follows:

80 = Hardware Error
40 = ID Check
20 = Record Code Check Error
10 = Short Record
08 = Long Record
04 = End of file (tape only)
02 = Invalid file address/Software error
88 = Device not operational

SUP Byte - Detailed Program Level Indicator

This is the error byte used when retrieving a program from DASD. It is at dump tag SUP.
The error codes are the same as for the SUD bytes.

SUG Byte - Gross Error Indicator

This byte contains a value which is obtained by 'OR'ing all the SUD and SUP bytes together.
Thus a non-zero SUG byte indicates a retrieval error on some level or for some program and
the SUD and SUP bytes can be interrogated.

The SUG byte immediately follows the SUP byte in the ECB.

GLA/GLY - Global Area Addresses

These fields are both 4 bytes in length. They are consecutive within the ECB and have the
dump tags GLA and GLY.

GLA - contains the EVA of global area 1

GLY - contains the EVA of global area 3

CE1CPNL/CE1FPNL - Program Nesting Level Pointers

CE1CPNL contains the EVA of the last used Program Nesting Entry and has the dump tag
CPL. CE1FPNL contains the EVA of the first Program Nesting Entry in ECB Page 3 and has
the dump tag FPL.

If CE1CPNL contains the EVA of the CE1FPNL field (i.e. the address of the field 4 bytes
beyond it), then there are no nested programs.

26/09/09 Page 15
DET - Detached Block Counters

Dump tag DET holds the address of the current DBT (Detached Block Table) entry, and
following this address are 16 single byte fields holding counts of the number detached blocks
(detached by the TPF DETAC function) from each data level. Immediately following these
16 bytes is a single byte holding the count of the number of TPFDF DETAC'd blocks for this
ECB.

PSW - Program Status Word

At dump tag PSW is an 8 byte field containing the last stored PSW for this ECB. The PSW is
saved here when an SVC is issued. This allows the control program to know which
instruction it should return to in the application once it has serviced the request.

IOC - I/O Counter

At dump tag CTL is a halfword containing the number of outstanding I/Os for this ECB.

Every time an I/O request to DASD is issued by this ECB, this field is incremented. When
the I/O request completes it is decremented.

If a macro is issued with an implied or explicit wait (e.g. FIWHC, WAITC etc.), processing
will not be allowed to continue until this counter is zero. Macros with implied or explicit
waits are used to ensure all I/O operations pending completion do so before processing
continues.

HLD - Hold Counter

Immediately following the IOC halfword is a single byte containing the number of records
being HELD by the ECB.

A FIWHC macro will increment this count on completion and an UNFRC will decrement it.

If this field contains a value of more than 1 it could be a pointer to a deadly embrace problem.
Good coding practice is to ensure that only one record is held at a time.

26/09/09 Page 16
Useful ECB Page 2 Fields

DSECT IEQCE2 describes this page of the ECB. It is key protected. Applications should not
need to access information contained in this page during processing but some of the fields are
of interest to application programmers when debugging:

CE2AVL1 128/381 free block chain 4 bytes dump tag AV1

CE2AVL2 1055 free block chain 4 bytes dump tag AV2
CE2AVL4 4k free block chain 4 bytes dump tag AV4
CE2SVA SVA of the ECB 4 bytes dump tag SVA
CE2EVA EVA of the ECB 4 bytes dump tag EVA
CE2FLAG Block check mode for ECB 1 byte Page 2 displacement
- Bit 0 ON if blk check on X’34’
CE2ACN ECB activation number 4 bytes Page 2 displacement
X’68’

The free block chain fields contain pointers to in-core tables if there are available blocks of
the appropriate size.

The SVA of the ECB corresponds to '*' denoted ECB address in the collated macro trace
table. The EVA of the ECB corresponds to the address in R9 in an EVM dump.

The ECB activation number supports the E-loader. Each program loaded to the system is
associated with an activation number. The activation number in the ECB determines which
version of a program that ECB will use.

ECB Page 3 Fields

DSECT IEQCE3 describes this key protected page of the ECB. It contains the macro trace
table, the program nesting level entries and the detac block table for the ECB.
Macro Trace

The macro trace table starts at displacement 0 of page 3 of the ECB and consists of a 24 byte
header followed by up to 70 trace table entries.

The macro trace table header is identified by dump tag MTH and has the format:

EVA of next size of EVA of first EVA of last SVA of first SVA of last
trace slot trace slot trace slot trace slot trace slot trace slot

0 4 8 C 10 14

The standard trace entry item is 40 bytes long. If registers are also saved the item is
increased by 16 fullwords for R0-R15. The macro trace table is a wraparound table. To find
the last macro, use the address of the next slot to be used (from the trace table header) to
locate the last actually used and work backwards.

26/09/09 Page 17
 Program Nesting Levels

The nesting level information begins at dump tag L0. Each item is 24 bytes long and has
the format :

EVA of next EVA of base EVA EVA of nested prog's PBI original
PNL entry previous of nested instruction PAT entry PBI
PNL entry program to return to address

0 4 8 C 10 14 16
There are 35 nesting items within the ECB. If more are required, a 4K private frame is
attached as an overflow block to hold further nested items. If the last nesting level 'EVA of
next PNL entry' is not zero this is the address of the overflow block.

As long as no overflow block has been used, if CE1CPNL does not contain the address of
CE1FPNL, the number of nested programs can be calculated as follows:

(CE1CPNL-CE1FPNL)/X'18' + 1

Detached Block Table

The first Detac item is identified by dump tag DBT. Each Detac item is 36 bytes in length
and has the format:

EVA of
EVA of next
previous CBRW FARW
DBT entry
DBT entry
0 4 8 10

FARX Ind user level

ind index

18 20 21 22

Where : Ind 00 - not in-use user ind 80 - TPFDF detac

80 - detached block held

Level Index level number * 8

10 Detac table items are available within the ECB. If more are required, a 4K private frame
can be attached to the ECB as overflow. If the last DBT item 'EVA of next DBT entry' is not
zero, this is the address of the overflow block.

26/09/09 Page 18
 Data Blocks
Core blocks in use by the ECB appear after the ECB in the dump. Attached core blocks are
dumped first followed by detached core blocks. The Detac Block Table Entry (from ECB
Page 3 or any obtained overflow) relating to the detached block is dumped prior to the
detached block itself. The type of block (msg, VFA etc) and level is identified. The block
size can be found by looking at the displacement column.

26/09/09 Page 19
 USEFUL TOOLS TO HELP DUMP SOLVING

SELOG41 System Error Log Exec for TPF4.1

The ‘SELOG41’ exec provides descriptions for TPF 4.1 dump numbers.

To obtain the description enter: SELOG41 n

where n is the ‘system error number’ – ‘SENUM’ (up to 6 significant digits)

New SERRC and SNAPCs coded in application programs should be given unique ‘senum’
dump numbers and entries added to the SELOG41 dataset.

Note:
Dump numbers for programs under development will not be found until the development
programmer has sent the new SERRC and SNAPC dump numbers to MVS to be added to
SELOG41.

CZ1SE
Dumps coded in application programs generally have the error number hardcoded in the
SERRC/SNAPC macro. Within systems code however, equate names are often used in place
of a hard coded number. The value assigned to these equates are contained in macro CZ1SE.

Application programs should NOT code SERRC numbers using equates.

26/09/09 Page 20
 SYSTEM MONITORING

Analysis of production environment dumps should occur in a planned and organised manner,
with coverage being the central point of control. This does not mean that all areas of
development should not be monitoring the system for errors, only that a central control
should be in place to oversee the smooth operation of the production systems.

Coverage monitor the production systems on an ongoing basis. Tools they use to help them
do this include UDARS, the console logs and OLDF.

The tools that coverage use to monitor the production systems can also be of use to the
second level support groups when working on resolving a dump. UDARs, the console logs
and OLDF can be helpful in identifying trends as well as providing a background to the
system state at the time of a specific dump.

UDARs (Upars Daily System Activity Report)

UDARs is a report that is generated on a daily basis that contains statistical information about
each of the production systems. It has several sections, those used here are:

• Sequential System Error Listing

• Alter Core/Alter File Summary
• System Error Recap Analysis
• System Error Dump and NoDump Summary (15 day)

How to Look at the UDARs Report

• 'AD TPFINFRA'
• 'VMENU 9.M.U'
• The filename of the UDARs report is the Julian Date (e.g. 96101)
• The filetype is the system name +UDAR(S)

26/09/09 Page 21
 CONSOLE LOGS
When analysing a dump, the console log is often invaluable in helping to understand what
was happening on the system around the time of the dump.

How to Look at the Console Logs

1) For Production and Copy Systems

• 'AD TPFCONS'
• The filename of the console logs is the date (e.g. 13JAN94)
• The filetype is the system name

2) For Test Systems

The current log:

• From your VM1 session 'VMSPOOL SPOOLIST VPxxxxx' (where xxxxx is the
system whose console log you want to see)
• Move your cursor to the file that is open (OPN) and press PF11 to view

Previous logs of the Test Systems that Test Systems Coverage control :
• 'AD HELPTSC'
• The filename of the console log is the system name
• The filetype is LOG_xxx (where xxx is the week day of the console log you wish to
see)

One week's worth of console logs are kept on this disk for each test system controlled by
Test Systems Coverage.

Online Dump Facility (OLDF)

OLDF is an online package that allows users to monitor the dump activity of a TPF system.
It also allows for the online display of a dump (as a mini dump) to aid in the resolution of a
dump. This saves the time and resources that are necessary to process a dump in MVS to
produce a listing. Only non-catastrophic dumps with an associated ECB are candidates for an
OLDF mini dump to be taken.

See the OLDF User Guide for the OLDF entries available or use the ZUODF HELP online
help function.

26/09/09 Page 22
 TRANSLOG - Transaction Log by Agency or agent

The TRANSLOG exec provides a means to submit an MVS job to scan the
PRE Transaction Logs which contain all the agent entries made on the PRE system..

You can select an agency, or a specific agent’s GTID and specify the time period if required.

The current day cannot be scanned.

Enter ‘TRANSLOG’ on VM and enter parameters on the screen display.

Enter a unique name to identify the report on SAR
Enter either the date in day/month/year, or a number.
0 = yesterday
1 – day before yesterday. ( logs are kept for 60 days)

the rest of the parameters are optional,

Start time
End time
GTID of agent to be viewed
Agency code

Note the Job numbers, and enter SAR to view the report.

26/09/09 Page 23
 OBTAINING DUMP INFORMATION

Having identified a dump to be investigated and used the utilities listed in the previous
section of these notes, you may decide that you need to obtain a listing of the dump from the
dump tape.

Reading the Dump Message from the Console Log

Make sure that you look at the console log for the correct processor for a loosely coupled
complex as each processor has its own dump tape!!

The dump message for a SERRC has the format:

CPSE0052E hh:mm:ss ...

IS-nn RTL-vvvvvv UASU SE-xxxx ttt-ssssss llllll pppp
aaaaaaaaaaaaa...

Where:
hh:mm:ss is the time in hours, minutes and seconds
nn is the I/Stream on which the error occurred
vvvvvv is the dump tape volser
xxxx is the sequence error number
ttt is the dump type (CTL or OPR)
ssssss is the dump number (use SELOG41 to decode)
llllll is the lniata from which the processing in error
originated
pppp is the program in which the error occurred
aaa. is any appended error message
N.B. for CTL-I000001/I000002/I000003/I000004, the
appended message always gives the PSW and general
register contents at the time of the dump for the
I/Stream in error.

You will need the dump tape volser and the sequence error number to post process a
SERRC dump.

26/09/09 Page 24
DUMP MESSAGES contd.

The dump message for a SNAPC has the format:

SNAP0001I hh.mm.ss CPU-x SS-BSS SSU-UASU IS-nn RTL-vvvvvv

PSW-yyyyyyyy yyyyyyyy PGM-pppp CODE-ussssssss TERM-llllllll
<optional register display/appended message if coded on SNAPC>
END OF SNAPC CONSOLE DISPLAY¬

Where:
hh:mm:ss is the time in hours, minutes and seconds
x is the CPU id
nn is the I/Stream on which the error occurred
vvvvvv is the dump tape volser
yyyy..yyyy.. is the PSW at the time of the SNAPC
pppp is the program taking the SNAPC
ussssssss is the prefix (u) and senum (ssssssss) of the SNAPC
llllll is the lniata from which the processing in error
originated
REGISTER contents or an appended message may optionally be
included depending upon what was coded on the SNAPC

You can post process SNAPCs by specifying the senum, prefix or time range required. You
will always need the dump tape volser.

26/09/09 Page 25
 Obtaining a Dump Listing
Use the STPP41 exec.

**STPP41** System Dump Processing

Current Post Processor-> Y Online or Test System-> (O/T)

System Name-> Sub System-> Req'd for VSS

Valid System Names: APO VSS PRE CRE TR1 PGR CGR TGR

RTL Number(s)-> -> Processor ID-> A (ABCDEFGH)

Dump Numbers-> -> -> -> ->

-------------------------------------------------------------------------------
SNAP Dump Request Prefix:
Dumps->
Time-> - - - - -
-------------------------------------------------------------------------------
Output: Virtual Reader-> MVS Printer-> SAR Name->
-------------------------------------------------------------------------------
MVS Job Control Information: Priority -> Output Class -> (A,H,Q,S,W,4)
-------------------------------------------------------------------------------

PF01/13 for Help PF02/14 to Execute PF03/15 to Exit PF04/16 to Clear

1. Enter the appropriate system name

2. Enter the RTL number
3. Enter the Processor ID
4. For a SERRC, enter the dump sequence error number(s) (SE-). Note if you require a full
dump, enter the SE number followed by F (e.g. 10 gives mini dump, 10F gives full dump
for SE-10).
5. For a SNAPC, enter the PREFIX OR the senum (in DUMPS field) OR a time range for
SNAPCs of interest.
6. The test systems should have virtual tapes mounted, so enter the test system name in
Owner’s Logon ID field and enter Y alongside Run on VM
7. To send the output to your VM reader, enter Y alongside Output: Virtual Reader. To send
the dump to SAR enter a name that you want associated with the dump in the SAR Name
field.
8. PF2 to execute

26/09/09 Page 26