Dump Overview Notes

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.

08/04/23

AN OVERVIEW OF TPFPRINCIPAL FUNCTIONS AND FEATURES

OVERVIEW OF CORE LAYOUT OF A TPF SYSTEM

08/04/23

OVERVIEW OF THE CPU LOOP

Check the Ready List

Check the Input List

Check the Deferred List

Process Ready List

Process Input List

Process Deferred List

Process Cross ListCheck theCross List

Wait to be flagged

New work arrived

08/04/23

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.

08/04/23

PATH TAKEN BY AN AGENT ENTRY THROUGH THE TPF SYSTEM

08/04/23

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 forcedSoftware forced

1. Hardware (micro-code) forcedWhen 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-I000001This is a catastrophic program error detected whilst running in SVM.

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

CTL-I000002This 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-I000004This 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 state1 = problem state

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

08/04/23

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.

08/04/23

TPF4.1 DUMP EXAMPLEPRINCIPAL AREAS

SERRC DUMP FORMAT

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

Appended Console MessageAny 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 OptionsThe ZASER options in force at the time of the dump are listed.

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

System Traces ActiveThere 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 SVMThis is the amount of virtual storage defined for the main I/Stream.

08/04/23

BLK CHECK MODEIf 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 AreaThis 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 InThis 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 ProgramThe 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 KeysSVA 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 DisplayInformation about the I/Stream in error is listed first. For an OPR dump with ZASER SHORT, this is the only I/Stream status provided.

08/04/23

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 151 = Problem state (usual setting for applications)

BITS 16-17 Address space control00 = EVM (primary address space in POPS)11 = SVM (home address space in POPS)

BIT 32 Address mode1 = 31 bit mode0 = 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.

08/04/23

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.

08/04/23

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 ErrorThis is the object code located 2K before and 2K after the PSW NSI address (bits 33-63).

Area Referenced by RegisterThis 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 EntriesEach 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 PageThere 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.

08/04/23

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 InformationFor 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.

08/04/23

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 use0011 - 127 byte block attached0021 - 381 byte block attached0031 - 1055 byte block attached0051 - 4095 byte block attached

08/04/23

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 Error40 = ID Check20 = Record Code Check Error10 = Short Record08 = Long Record04 = End of file (tape only)02 = Invalid file address/Software error88 = 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 1GLY - 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.

08/04/23

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.

08/04/23

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 AV1CE2AVL2 1055 free block chain 4 bytes dump tag AV2CE2AVL4 4k free block chain 4 bytes dump tag AV4CE2SVA SVA of the ECB 4 bytes dump tag SVACE2EVA EVA of the ECB 4 bytes dump tag EVACE2FLAG Block check mode for ECB

- Bit 0 ON if blk check on 1 byte Page 2 displacement

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:

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.

08/04/23

Program Nesting Levels

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

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:

0 4 8 10

18 20 21 22

EVA of next

DBT entry

EVA of

previous

DBT entryCBRW FARW

FARX Ind user

ind

level

index

Where : Ind 00 - not in-use user ind 80 - TPFDF detac80 - 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.

08/04/23

Data BlocksCore 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.

08/04/23

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.

CZ1SEDumps 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.

08/04/23

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)

08/04/23

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.

08/04/23

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 SAREnter either the date in day/month/year, or a number.

0 = yesterday1 – day before yesterday. ( logs are kept for 60 days)

the rest of the parameters are optional,Start time End timeGTID of agent to be viewedAgency code

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

08/04/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 LogMake 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 secondsnn is the I/Stream on which the error occurredvvvvvv is the dump tape volserxxxx 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

originatedpppp is the program in which the error occurredaaa. 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.

08/04/23

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 secondsx is the CPU idnn is the I/Stream on which the error occurredvvvvvv is the dump tape volseryyyy..yyyy.. is the PSW at the time of the SNAPCpppp is the program taking the SNAPCussssssss is the prefix (u) and senum (ssssssss) of the SNAPCllllll is the lniata from which the processing in error

originatedREGISTER 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.

08/04/23

Obtaining a Dump ListingUse 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

08/04/23

Dump Overview Notes

Documents

Transcript of Dump Overview Notes