SY28 1133 02_MVS_Diagnostic_Techniques_Dec85 02 MVS Diagnostic Techniques Dec85

User Manual: SY28-1133-02_MVS_Diagnostic_Techniques_Dec85

Open the PDF directly: View PDF PDF.
Page Count: 746

DownloadSY28-1133-02_MVS_Diagnostic_Techniques_Dec85 SY28-1133-02 MVS Diagnostic Techniques Dec85
Open PDF In BrowserView PDF
SY28-1133-2
File No. S370-37

Program Product

MVS Diagnostic
Techniques

MVS/System Product
J ES3 5740-XYN
MVS/System Product
J ES2 5740-XYS

--..-----

--

- . ------------."

TNL SN28-5095 (December'27, 1985) to SY28-1133-2

Third Edition (July, 1985)
This is a major revision of, and obsoletes, SY28-1133-1 and Technical Newsletter
SN28-0875. See the Summary of Amendments following the Contents for a summary of
the changes made to this manual. Technical changes or additions to the text and
illustrations are indicated by a vertical line to the left of the change.
This edition with Technical Newsletter SN28-5095 applies to Version 1 Release 3.6 of
MVS/System Product 5740-XYN or 5740-XYS and to all subsequent releases until
otherwise indicated in new editions or Technical Newsletters. Changes are made
periodically to the information herein; before using this publication in connection with
the operation of IBM systems, consult the latest IBM Systemj370 Bibliography,
GC20-0001, for the editions that are applicable and current.
References in this publication to IBM products, programs, or services do not imply that
IB.M intends to make these available in all countries in which IBM operates. Any
reference to an IBM program product in this publication is not intended to state or imply
that only IBM's program product may be used. Any functionally equivalent program
may be used instead.
Publications are not stocked at the address given below; requests for IBM publications
should be made to your IBM representative or the IBM branch office serving your
locality.
A form for reader's comments is provided at the back of this publication. If the form has
been removed, comments may be addressed to IBM Corporation, Information
Development, Department D58, Building 921-2, PO Box 390, Poughkeepsie, NY 12602.
IBM may use or distribute wh~tever information you supply in any way it believes
appropriate without incurring any obligation to jou.
© Copyright International Business Machines Corporation 1981, 1985

Guide for Using This Publication
The following is a list of guidelines for using this publication.
•

This publication contains information from OS/VS2 System Programming
Library: MVS Diagnostic Techniques, GC28-0725-2. It also includes all
information from the Newsletters and Supplements issued for GC28-0725-2
through September 15, 1981.

•

This publication contains information for OSjVS2 MVS Release 3.8 plus the
following:

-

OSjVS2 MVS Processor Support 2
OSjVS2 MVS/System Product Release
OSjVS2 .MVS/System Product Release
OSjVS2 MVS/System Product Release
OSjVS2 MVS/System Product Release
OSjVS2 MVS/System Product Release
OSjVS2 MVS/System Product Release
OSjVS2 MVS/System Product Release
OSjVS2 MVS/System Product Release

I
I Enhancements
2
3
3.2 (TNL, SN28-5014)
3.3
3.4 (TNL,SN28-0875)
3.5

•

Do not use this publication unless you have installed MVS/System Product
Version I Release 3.5.

•

The implied date of this publication, for the purpose of inserting new
Newsletters and Supplements, is July 1, 1985. When you are adding pages
from different Newsletters and Supplements, always use the page with the
latest date (shown at the top of the page).

Guide for Using This Publication

iii

IV

MVS Diagnostic Techniques

Preface
This publication describes diagnostic techniques and guidelines for isolating.
problems on MVS systems. It is intended for the use of system programmers and
analysts who understand MVS intemallogic and who are involved in resolving
MVS system problems.
This publication is intended for use only in debugging. None of the information
contained herein should be construed as defining a programming interface.

Note:· For JES3 diagnostic information, refer to JES3 SPL: Diagnosis.

Organization and Contents
This publication stresses a three-step debugging approach:
1.

Identifying the external symptom of the problem.

2.

Gathering relevant data from system data areas in order to isolate the
problem to the component level.

3.

Analyzing the component to determine the cause of the problem.

In support of this approach, the publication has been reorganized into three basic
parts consisting of five sections and three appendixes as follows:
Part 1
"Section 1. General Introduction" describes the debugging approach that is used
and defines the external symptoms that are used to identify a system problem.
"Section 2. Important Considerations Unique to MVS" describes concepts and
functions that should be understood prior to undertaking system diagnosis.
Inchlded are: global system analysis, system execution modes and status saving,
locking, use of recovery work areas, effects of MP, trace analysis, debugging
hints, and general data gathering techniques.
"Section 3. Diagnostic Materials Approach" provides guidelines for obtaining and
analyzing storage dumps of data areas affected by the problem.

Preface

V

Part 2
"Section 4. Symptom Analysis Approach" describes how to identify an external
symptom (loop, wait state, TP problem, performance degradation, or incorrect
output), and provides an analysis procedure for what kind of problem is causing
the symptom.
"Section 5. Component Analysis" describes the operating characteristics and
recovery procedures of selected system components and provides debugging
techniques for determining the cause of a problem that has been isolated to a
particular component.

Part 3
Appendixes

A-

describes the flow of various MVS processes.

B-

provides a step-by-step approach to analyzing a stand-alone dump.

C-

provides diagnostic information for SVC dump titles.

D - contains definitions of abbreviations used throughout the publication.

Referenced Publications

The following publications either are referenced in this pUblication or provide
related reading:
System/370 Principles of Operation
Synchronous Data Link Control General Information
MVS Interactive Problem Control System (IPCS)
User's Guide and Reference
Environmental Record Editing and Printing (EREP) Program
User's Guide and Reference
OS/VS2 System Programming Library:
Initialization and Tuning Guide
Supervisor
Job Management
Service Aids
SYS1.LOGREC Error Recording
Debugging Handbook (5 volumes)
LC28-1385 through
JES3 System Programming Library: Diagnosis
OS/VS2 TCAM System Programmer's Guide, TCAM Level 10
OS/VS2 TCAM Debugging Guide, TCAM Level 10
OS/ VS2 MVS VTAM Debugging Guide
ACF/VTAM Diagnosis Guide
ACF/VTAM Diagnosis Reference
Operator's Library:
OS/VS2 MVS System Commands
OS/VS2 MVS JES2 Commands
VTAM Network Operating Procedures
A CF/ VTAM Operation
OS/VS TCAM Level 10
JES/3 Operator's Library

VI

MVS Diagnostic Techniques

GA22-7000
GA27-3093
GC28-1183
GC28-1378
GC28-I029
GC28-I046
GC28-1303
GC28-0674
GC28-0677
LC28-1389
SC23-0043
GC30-205I
GC30-3040
GC27-OO23
SC27-0615
SC27,.()621
GC28-I031
SC23-0048
GC27-6997
SC27-0612
GC30-3037
SC23-0045

TNL SN28-5095 (December 27, 1985) to SY28-1133-2

MVS/370 Message Library:
JES2 Messages
GC38-1374,
System Messages (2 volumes)
System Codes
OS/VS2 System Logic Library (11 volumes) - Volume 1
OS/VS2 I/O Supervisor Logic
OS/VS2 System Initialization Logic
OS/VS2 MVS Service Aids Logic
OS/VS2 MVS Global Resource Serialization Logic
JES2 Logic
OS/VS2 MVS JES3 Logic
Resource Access Control Facility (RACF): Program Logic Manual
OS/VS2 MVS Programmed Cryptographic Facility: Program Logic Manual
OS/VS2 MVS Resource Measurement Facility (RMF)
Version 2 Program Logic Manual
MVS Input/Output Configuration Program Logic
OS/VS2 VTAM Data Areas
ACF/VTAM Data Areas
OS/VS2 VTAM Logic
A CF/ VTAM Logic
OS/VS2 VSAM Logic
OS/VS2 Catalog Management Logic
OS/VS2 Access Method Services Logic
OS/VS2 MVS Mass Storage System Communication (MSSC) Logic
OS/VS2 SAM Logic
OS/VS2 BDAM Logic
OS/VS2 MVS VTIOC and TCAS Logic
OS/VS2 TSO Command Processor Logic, Volume IV
OS/VS2 Open/ClosejEOV Logic
OS/VS2 CVOL Processor Logic
OS/ VS2 VIO Logic
OS/VS2 TCAM Level 10 Logic
IBM 3704 and 3705 Communications Controllers NCP/VS Logic
3704/3705 Communications Controllers Principles of Operation
IBM 3704/3705 Communications Controllers Emulation Program
Generation and Utilities Guide and Reference Manual
IBM 3704/3705 Communications Controller NCP/VS
Generation and Utilities Guide and Reference Manual

GC28-1354
GC28-1375
GC38-1008
SY28-0713
SY26-3823
LY28-1050
SY28-0643
LY2S-1059
LY24-6006
LY24-6005
LY28-0730
LY28-0958
LY2S-0923
LY2S-1033
SY27-7267
LY38-3054
SY2S-0621
LY27-S034
SY26-3825
SY26-3826
SY35-0010
SY35-0013
SY26-3832
SY26-3831
SY27-7269
SY2S-0652
SY26-3827
SY35-0011
SY26-3834
SY30-3032
SY30-3013
GC30-3004
GC30-300S
GC30-3007

Preface

Vll

December 27, 1985

viii

MVS Diagnostic Techniques

Contents
Section 1. General Introduction
1-1
Basic MVS Problem Analysis Techniques
1-1
IPCS - Interactive Problem Control System
1-4
Section 2. Important Considerations Unique to MVS 2-1
Global System Analysis 2-2
Global Indicators that Determine the Current System State 2-2
Work Queues, TCBs and Address Space Analysis
2-5
TCB Summary 2-5
SRB Dispatching Queues 2-5
Address Space Analysis 2-6
Task Analysis 2-7
Summary 2-9
System Execution Modes and Status Saving 2-10
System Execution Modes 2-10
Task Mode
2-10
SRB Mode 2-11
Physically Disabled Mode 2-12
Locked Mode 2-13
Determining Execution Mode From a Stand-alone Dump 2-13
LCCA Indicators 2-13
PSA Indicators 2-13
ASCB Indicators 2-14
Locating Status Information in a Storage Dump 2-15
Task and SRB Mode Interruptions 2-15
Locally Locked Task Suspension 2-17
SRB Suspension 2-17
SMF Suspension 2-19
Locking 2-21
Categories of Locks 2-21
Types of Locks 2-22
Locking Hierarchy 2-23
Determining Which Locks Are Held On a Processor 2-24
Content of Lockwords 2-25
Global Spin Lockword 2-25
Global Suspend Lockword (Cross Memory Services Locks) 2-25
Local Suspend Lockword (Local Lock) 2-25
How To Find Lockwords 2-26
Results of Requests For Unavailable Locks 2-26
Global Spin Locks 2-26
Local Locks 2-27
Cross Memory, Services Locks 2-28
Intersect 2-31

Contents

IX

Determining if Intersects are Held on a 'Processor 2-31
Requesting the Intersect 2-32
Use of Recovery Work Areas For Problem Analysis 2-33
SYSl.LOGREC Analysis 2-34
Listing the SYS1.LOGREC Data Set 2-34
SDWAVRA Key-Length-Data Format 2-35
Important Considerations About SYSl.LOGREC Records 2-36
SYSl.LOGREC Recording Control Buffer 2-38
Formatting the LOGREC Buffer 2-38
Finding the LOG REC Recording Control Buffer 2-38
Format of the LOGREC Recording Control Buffer 2-38
FRR Stacks 2-40
Extended Error Descriptor (EED) 2-41
RTM2 Work Area (RTM2WA) 2-41
Formatted RTM Control Blocks 2-42
System Diagnostic Work Area (SDWA) Use in RTM2 2-42
Effects of Multiprocessing On Problem Analysis 2-43
Features of an MP Environment 2-43
MP Dump Analysis 2-45
Data Areas Associated With the MP Environment 2-45
Parallelism 2-46
General Hints For MP Dump Analysis 2-48
Inter-Processor Communication 2-49
Direct Services 2-50
Remote Pendable Services 2-51
Remote Immediate Services 2-52
MP Debugging Hints 2-58
MVS Trace Analysis 2-61
Trace Entries 2-61
Trace Entry for Service Processor Call SVC 2-64
Trace Examples 2-64
Notes For Traces 2-66
Tracing Procedure 2-66
Bypassing GTF Lost Events 2-68
Cautionary Notes 2-69
Master Trace 2-71
Master Trace Table 2-72
The Message Processing Facility Table (MPFT) 2-74
Miscellaneous Debugging Hints 2-75
Alternate CPU Recovery (ACR) Problem Analysis 2-75
Pattern Recognition 2-77
Low Storage Overlays 2-78
Common Bad Addresses 2-80
OPEN/CLOSE/EOV ABENDs 2-80
Debugging Machine Checks 2-81
Debugging Problem Program Abend Dumps 2-86
Debugging From Summary SVC Dumps 2-89
SUMDUMP Output For SVC-Entry SDUMP 2-90
SUMDUMP Output For Branch-Entry SDUMP 2-91
Started Task Control ABEND and Reason Codes 2-93
SWA Manager Reason Codes 2-94
Additional Data Gathering Techniques 2-95
Using the CHNGDUMP, DISPLAY DUMP and DUMP Operator
Commands 2-95

X

MVS Diagnostic Techniques

How to Print Dumps
2-97
How to Automatically Establish System Options For SVC Dump
How to Copy PRDMP Tapes
2-99
How to Rebuild SYSl.UADS
2-100
How to Print SYSl.DUMPxx
2-101
How to Clear SYSl.DUMPxx Without Printing
2-102
How to Print the SYSl.COMWRITE Data Set
2-103
How to Print an LMOD Map of a Module
2-103
How to Re-Create SYS1.STGINDEX· 2-103
Software LOGREC Recording
2-104
Using the PSA as a Patch Area
2-104
Using the SLIP Command
2-105
SLIP Event Qualifier Keywords
2-105
Using the ACTION Keyword
2-112
Dump Tailoring
2-117
2-118
Examples of Using the SLIP Command
Example of SLIP Command From TSO Terminal
2-124
2-125
Designing an Effective SLIP Trap
Controlling SLIP Traps
2-125
Placement of PER Traps
2-127
SLIP Command Keyword Summary
2-129
System Stop Routine
2-133
How to Expand the Trace Table
2-133

2-99

3-1
Section 3. Diagnostic Materials Approach
3-2
Stand-alone Dumps
SVC Dumps
3-4
How to Change the Contents of an SVC Dump Issued by an Individual
Recovery Routine
3-5
SDUMP Parameter List
3-5
SYSABENDs, SYSMDUMPs, and SYSUDUMPs
3-7
3-7
Software-Detected Errors
Hardware-Detected Errors
3-8
Section 4. Symptom Analysis Approach
4-1
Waits
4-2
4-2
Characteristics of Disabled Waits
4-3
Analysis Approach For Disabled Waits
4-4
Characteristics of Enabled Waits
4-5
Analysis Approach For Enabled Waits
Stage 1: Preliminary Global System Analysis
Stage 2: Key Subsystem Analysis
4-8
Stage 3: System Analysis
4-14
Loops
4~15
Common Loop Situations
4-15
Analysis Procedure' 4-16
TP Problems
4-20:
Message Flow Through the System
4-20
Types of Traces
4-21
GTF Traces
4-21
ACF /VTAM Traces
4~22
ACF/TCAM Traces
4-22
NCP and EP Traces
4-22
Performance Degradation
4-23

4-6

Contents

Xl

Operator Commands 4-23
Dump Analysis Areas 4-24
Incorrect Output 4-29
Initial Analysis Steps 4-29
Isolating the Component 4-29
Analyzing System Functions 4-30
Summary 4-31
5-1
Supervisor Control 5.. 2
Dispatcher 5-2
Important Dispatcher Entry Points 5-2
Dispatchable Units and Sequence of Dispatching 5-4
Dispatchability Tests 5-13
Miscellaneous Notes About the Dispatcher 5-14
Dispatcher Recovery Considerations 5-15
Dispatcher Error Conditions 5-16
SRB/SSRB Pool Manager 5-17
SRB/SSRB Pool Manager Entry Points 5-17
SRB/SSRB P()ol Manager Recovery Considerations 5-18
SRB/SSRB Pool Manager Error Conditions 5-19
Stop/Reset Services 5-19
Stop/Reset Entry Points 5-19
Stop/Reset Recovery Considerations 5-20
Stop/Reset Error Conditions 5-21
SUSPEND/RESUME/TCTL Services 5-22
SUSPEND/RESUME/TCTL Entry Points 5-22
RESUME/TCTL Recovery Considerations 5-23
SUSPEND/RESUME/TCTL Error Conditions 5-24
lOS 5-25
Front-End Processing 5-25
Back-End Processing 5-25
lOS Problem Analysis 5-25
lOS ABEND Codes 5-28
Loops 5-28
lOS WAIT States 5-29
General Hints For lOS Problem Analysis 5-30
lOS Diagnostic Aids 5-32
Table of EXCP Abend Codes 5-32
EXCP Debugging Area (XDBA) 5-33
SDWA Variable Recording Area 5-34
Output of lOS Recovery Procedures 5-34
Informative IOSB Fields 5-43
Table of lOS Messages 5-46
lOS Wait State Codes 5-47
Table of lOS Return Codes 5.;.47
Error Recovery Procedures (ERPs) 5-48
lOS and ERP Processing 5-48
Identifying ERP Module Names 5-49
How ERP Transfers Control 5-49
Abnormal End Appendages 5-49
Retry/Restart the Channel Program 5-50
Error Interpreter 5-50
ERP Messages and Logging 5-51

Section S. Component Analysis

XU

MVS Diagnostic Techniques

Intercept Conditions 5-51
Unit Check on Sense Command 5-52
Compound Errors 5-52.
Diagnostic Approach 5-52
Program Manager 5-55
Functional Description 5-55
Program Manager Organization 5-55
Program Manager Control Blocks 5-55
Program Manager Queues 5-55
Queue Validation 5-58
System Initialization 5-58
Basic Functional Flow 5-60
LINK 5-60
ATTACH 5-61
XCTL 5-61
LOAD 5-64
DELETE 5-64
Exit Resource Manager 5-64
SYNCH 5-65
IDENTIFY 5-65
ABEND Resource Manager 5-66
806 Abend 5-66
APF Authorization 5-70
Module Subpools 5-71
FETCH/Program Manager Work Area (FETWK) 5-72
RB Extended Save Ar~a (RBEXSAVE) 5-72
CDE Pool Control 5-72
Virtual Fetch 5-74
Functional Description 5-74
Module Organization 5-74
Functional Flow 5-75
Control Blocks 5-78
Recovery Processing 5-79
Error During Initialization Processing 5-79
Errors During Build, Find, and Get Processing 5-79
Debugging Hints 5-80
VSM 5-82
Address Space Initialization 5-84
Step Initialization/Termination (lEAVPRTO GETPART /FREEPART) 5-86
Virtual Storage Allocation (GETMAIN/FREEMAIN) 5-87
GETMAIN's Functional Recovery Routine - lEAVGFRR 5-90
VSM Cell Pool Management 5-92
Miscellaneous Debugging Hints 5-92
Real Storage Manager (RSM) 5-97
Major RSM Control Blocks 5-97
PCB (page Control Block) 5-99
SPCT (Swap Control Table) 5-100
PFTE (page Frame Table Entry) 5-101
Page Stealing 5-101
Reclaim 5-102
Relate 5-103
RSM Recovery 5-104
Real Storage Management ABEND Reason Codes 5-105
Contents

XUl

RSM Debugging Tips 5-107
Converting a Virtual Address to a Real Address 5-108
Example: Converting a Virtual Address to a Real Address
PCB Trace Facility 5-111
Auxiliary Storage Manager (ASM) 5-112
Component Functional Flow 5-113
Saving an LG 5-113
Requesting I/O 5-114
Requesting Swap I/O 5-115
Component Operating Characteristics 5-117
System Mode 5-117
Address Space, Task, and SRB Structure 5-117
Storage Considerations 5-117
Interfaces With Other Components 5-118
Register Conventions 5-118
Footprints and Traces 5-118
General Debugging Approach 5-119
Paging Interlocks 5-119
Incorrect Pages 5-120
Unusable Paging Data Sets 5-125
Page/Swap Data Set Errors 5-127
Error Analysis Suggestions 5-127
Validity Checking 5-128
ASM Serialization 5-129
Recovery Considerations 5-131
Recovery Traces 5-132
Recovery Structure 5-132
Recovery As a Debugging Tool 5-133
Recovery Footprints 5-133
ASM Diagnostic Aids 5-134
COD ABEND Meanings for ASM 5-134
ASM Recovery Control Blocks 5-135
Additional ASM Data Areas 5-139
System Resources Manager (SRM) 5-141
SRM Objectives 5-141
Address Space States 5-142
SRM Indicators 5-143
System Indicators 5-143
Individual User Indicators 5-147
Other Indicators 5-148
SRM Error Recovery 5-148
SRM SDWA Data 5-149
Module Entry Point Summaries 5-149
VTAM 5-150
Note to Readers 5-150
VSAM 5-151
Record Management 5-151
RPL 5-151
PLH 5-152
BUFC 5-152
Record Management Debugging Aids 5-153
Open/Close/End-Of-Volume 5-155
O/C/EOV Debugging Aids 5-155
I/O Manager 5-157

xiv

MVS Diagnostic Techniques

5-110

I/O Manager Debugging 5-157
Catalog Management 5-158
Major Registers and Control Blocks 5-158
How to Find Registers 5-158
Major Registers 5-159
Major Control Blocks 5-159
Module Structure 5-164
VSAM Catalog Recovery Logic 5-165
Establishing/Releasing a Recovery Environment 5-165
Maintaining a Pushdown List End Mark 5-166
Tracking GETMAIN/FREEMAIN Activity 5-166
CMS Function Gate 5-167
Recovery Routine Functions 5-167
Diagnostic Output (Function 4) 5-167
Backout (Function 7) 5-168
Drop Catalog Orientation (Function 9) 5-168
Storage Freeup (Function 10) 5-168
DEFINE/DELETE Backout (Function 12) 5-169
Debugging Aids 5-170
Allocation/Unallocation 5-172
Functional Description 5-172
Allocation 5-172
Unallocation 5-173
Batch Initialization and Control 5-173
Dynamic Initialization and Control 5-173
JFCB Housekeeping 5-174
Common Allocation 5-174
Common Unallocation 5-175
Volume Mount .and Verify 5-176
General Debugging Aids 5-176
Allocation Module Naming Conventions 5-176
Registers and Save Areas 5-177
Common Allocation Control Block Processing 5-177
EST AE Processing 5-180
Unit Allocation Status Recording 5-180
ALLOCAS Recovery Considerations 5-183
ALLOCAS Debugging Hints 5-183
Debugging Hints 5-192
Allocation Serialization 5-192
Subsystem Allocation Serialization 5-193
Device Selection Problems (Non-Abend) 5-193
Address Space Termination 5-194
OBO Abend 5-194
OC4 Abend in IEFAB4FC 5-195
Volume Mount and Verify (VM&V) Waiting Mechanism 5-195
Allocation/Unallocation Reason Codes 5-197
Common and Batch Allocation and JFCB Housekeeping Reason
Codes 5-197
Common and Batch Unallocation Reason Codes 5-200
Dynamic Allocation Reason Codes 5-200
JES2 5-201
Note to Readers 5-201
Subsystem Interface (SSI) 5-202
System Initialization Processing 5-202
Contents

XV

Subsystem Interface Major Control Blocks 5-203
Requesting Subsystem Services 5-206
Invoking the Subsystem Interface 5-206
Logic' Flow Examples 5-208
Notifying a Single Subsystem 5-208
Notifying All Active Subsystems 5-210
Debugging Hints 5-211
Event Notification Facility (ENF) 5-212
Requests for ENF Services 5-212
Listen and Signal Exit Routines 5-214
ENF Control Blocks 5-215
ENF Initialization 5-216
ENF Processing 5-217
ENF Return Codes 5-217
ENF Logic Flow Examples 5-217
ENF Recovery Routines 5-220
Recovery Teinrination Manager (RTM) 5-221
Functional Description 5-221
Work Areas 5-221
Major RTM Modules 5-221
Process Flow 5-222
Hardware Error Processing 5-222
Normal Task Termination 5-224
Abnormal Task Termination 5-225
Retry 5-226
Cancel 5-227
Address-Space Termination 5-229
PER Activation/Deactivation 5-230
Error ID 5-232
SVC Dump Debugging Aids 5-233
Important SVC Dump Entry Points 5-233
SVC Dump Error Conditions 5-234
SYS1.LOGREC Entries Produced for SVC Dump Errors 5-234
Control Blocks Used to Debug SVC Dump Errors 5-237
Resource Cleanup for SVC Dump 5-238
SLIP Processor Debugging Aids 5-238
SLIP Command Processor Recovery 5-239
SLIP Processor Recovery 5-239
PER Activation/Deactivation Recovery 5-240
Control Blocks Used by SLIP 5-242
Communications Task 5-244
Functional Description 5-244
Communications Task Control Blocks 5-246
Debugging Hints 5-248
Console Not Responding to Attention 5-248
Enabled Wait State 5;.248
Disabled Wait State 5-249
Messages or Replies Lost 5-249
No Messages on One Console 5-250
Messages Routed to Wrong Console 5-250
Truncated Messages 5-250
Console Switching 5-251
Action Message Retention Facility Debugging Aids 5-251
DIDOCS Trace Table 5-252
XVI

MVS Diagnostic Techniques

DIDOCS-In-Operation Inaicator 5-252
DIDOCS Locking
5-252
K Q Command Debugging Aids
5-253
Master Trace Debugging Aids
5-254
5-256
Recovery Management Support (RMS)
MCH Diagnostic Aids
5-256
MCH Return Codes
5-256
Processor Work Area (PWA) 5-257
PWF Diagnostic Aids
5-257
PWF Return Codes 5-257
PWF pata Areas
5-257
Dump Footprint Table 5-265
5-265
Appendage (lCFBDFOO) Footprint Table
LOGREC Recording
5-266
CCH Diagnostic Aids
5-266
5-266
Message IGF002I
PCCA Fields Showing CCH Footprints 5-267
DDR Diagnostic Aids
5-268
DDR Tasks 5-268
DDR Communication Table (DDRCOM)
5-268
DDR Error Recovery Parameter List (DERPLIST) 5-269
DDR Return Codes 5-272
Software Recording
5-272
DDR Storage Dumps 5-272
MIH Diagnostic Aids
5-273
MIll Process
5-273
MIll Work Area
5-273
Software Recording
5-276
MIll Storage Dumps 5-276
Service Processor Call SVC and MSSFCALL DIAGNOSE Instruction 5-277
Service Processor Call SVC (SVC 122) Used With the MSSF
5-277
MSSFCALL Data Block 5-278
SVC Abend and Return Codes With the MSSF
5-279
SVC Processing and Control Blocks With the MSSF
5-279
SVC Control Blocks Used with the MSSF
5-280
MSSFCALL DIAGNOSE Instruction 5-281
MSSFCALL DIAGNOSE Instruction Condition Codes 5-282
Service Processor Call SVC and SERVICE CALL Instruction 5-283
Service Processor Call SVC (SVC 122) Used With theService Processor
Architecture 5-283
Service Call Control Block (SCCB)
5-284
SVC Abend and Return Codes With the Service Processor
Architecture
5-284
SVC. Processing Withthe Service Processor Architecture
5-285
SVC Control Blocks Used With the Service Processor Architecture 5-286
SERVICE CALL Instruction 5-287
SERVICE CALL Instruction Condition Codes 5-287
Cross Memory Services 5-288
PC/AUTH Services 5-288
Module Structure
5-289
Process Flow 5-290
Control Block Structure
5-291
Control Block Formats 5-293
Recovery Considerations 5-296
Contents

XVll

Debugging Hints 5-299
SLIP Traps
5-301
PCLINK Services 5-302
STKE Control Block 5-302
Module Structure 5-304
Debugging Hints 5-304
Global Resource Serialization 5-305
Functional Overview 5-306
Ring Processing 5-306
Command Processing 5-306
Dump Support 5-307
Resource Request Processing (Mainline and Fast Path) 5-307
CTC Processing 5-307
WTO/WTOR Message Processing 5-307
Initialization 5-307
Queue Scanning Services 5-308
Storage Management 5-308
Control Blocks 5-308
Control Block Overviews 5-310
Module Flow Diagrams 5-320
Diagnostic Aids
5-343
Check on Enabled Wait During IPL 5-343
System Indicators 5-343
Probe Points 5-344
CTC Processing Debugging Hints 5-344
Ring Processing Debugging Hints 5-345
ENQ/DEQ/RESERVE Processing Debugging Hints 5-345
Storage Management Debugging Hints 5-348
Serialization 5-350
Recovery Routines 5-351
SYSl.LOGREC Recording
5-351
Appendix A. Process Flows A-I
RSM Processing for Page Faults A-2
lEAVPIX Tests A-2
lEAVGFA Tests A-2
lEAVPIOP Tests A-3
lEAVIOCP Tests A-6
Swapping A-7
Swap-In Process A-7
Swap-Out Process A-9
EXCP/IOS A-I2
GETMAIN/FREEMAIN A-I5
GETMAIN Processing A-I5
FREEMAIN Processing A-I6
VTAM Process A-18
TSO A-2I
Time Sharing Initialization A-2I
LOGON Processing A-24
LOGON Scheduling Diagnostic Aids A-32
TSO Line Drop Processing A-34
TMP and Command Processor Interface A-37
TSO Command Processor Recovery A-4I
TSO Terminal I/O Overview A-42

XVlll

MVS Diagnostic Techniques

Terminal Output Flow A-43
Terminal Input Flow A-44
TSO/TIOC Terminal I/O Diagnostic Techniques
TSO Attention Processing A-46
Appendix B. Stand-Alone Dump Analysis
Overview B-1
Analysis Procedure B-6

A-45

B-1

Appendix C. SVC DUMP Title Directory
C-l
System-Defined SVC Dump Titles C-2
Operator- and Caller-Defined SVC Dump Titles C-82
SVC Dumps Without Titles C-83
Module to SVC Dump Title Cross-Reference C-85
Appendix D. Abbreviations
Index

D-l

X-I

Contents

XIX

XX

MVS Diagnostic Techniques

Figures
2-l. Definition and Hierarchy of MVS Locks 2-22
2-2. Bit Map to Show Locks Held on a Processor 2-24
2-3. Classification and Location of Locks 2-26
2-4. Cross Memory Services Lock Suspend Queues 2-30
2-5. Example of SDWAVRA in Key-Length-Data Format 2-35
2-6. Format of the LOGREC Recording Control Buffer 2-39
2-7. Format of Records Within the LOGREC Recording Control
Buffer 2-39
2-8. SIGP Return Codes 2-50
2-9. External Call (XC) Process Flow 2-54
2-10. Emergency Signal (EMS) Process Flow 2-56
2-11. How to Locate the Trace Table 2-62
2-12. Types of Trace Entries 2-63
2-13. MVS Trace of a Page Fault Without I/O (Formatted by SNAP in
SYSUDUMP/SYSABEND) 2-65
2-14. MVS Trace of a Page Fault With I/O (Unformatted) 2-65
2-15. GTF Trace of a Page Fault Without I/O 2-66
2-16. GTF Trace of a Page Fault With I/O 2-66
2-17. SLIP Command Summary 2-130
4-1. JES2 Commands for Status Information 4-24
4-2. System Use of Hardware Components 4-26
5-1. SRB Queue Structure and Control Block Relationships 5-6
5-2. Local SRB Queue Structure and Control Block Relationships 5-7
5-3. Dispatcher Processing Overview 5-10
5-4. I/O Processing Overview 5-26
5-5. Major lOS and EXCP Control Block Relationships 5-27
5-6. Program Manager Modules 5-56
5-7. Program Manager Control Blocks and Work Areas 5-57
5-8. Program Manager Queues 5-57
5-9. lEAVNP05 Initialization 5-59
5-10. New PRB Initialization - LINK 5-61
5-11. New RB Initialization - XCTL 5-62
5-12. XCTL RB Manipulation 5-63
5-13. CDE Initialization by IDENTIFY 5-66
5-14. Module Search Sequence for LINK, ATTACH, XCTL and
LOAD 5-68
5.. 15. Module Search Sequence of Private Libraries 5-69
5-16. CDE Allocation 5-70
5-17. Virtual Fetch Modules 5-75
5-18. Virtual Fetch Control Blocks 5-78
5-19. Virtual Storage Management's View of MVS Storage 5-83
5-20. Virtual Storage Management's Control Block Usage 5-85
5-21. Virtual Storage Management's Global Data Area (GOA) ?-89
5-22. SOWAVRA Error Indicators 5-91
Figures

XXI

5-23.
5-24.
5-25.
5-26.
5-27.
5-28.
5-29.
5-30.
5-31.
5-32.
5-33.
5-34.
5-35.
5-36.
5-37.
5-38.
5-39.
5-40.
5-41.
5-42.
5-43.
5-44.
5-45.
5-46.
5-47.
5-48.
5-49.
5-50.
5-51.
5-52.
5-53.
5-54.
5-55.
5-56.

5-57.
5-58.
5-59.
5-60.
5-61.
5-62.
5-63.
5-64.
5-65.
5-66.
5-67.
5-68.

XXll

MVS Diagnostic Techniques

VSM Cell Pool Management 5-93
Major RSM Control Blocks and Their Functions 5-97
Relationship of Critical RSM Control Blocks 5-98
Page Stealing Process Flow 5-102
Converting Virtual Addresses to Real Addresses 5-109
Relationship of Important ASM Control Blocks 5-116
Locating An LSID From An LPID
5-122
Relating the Virtual Address to the PART and PAT 5-124
Page/Swap Data Set Error Action Matrix
5-127
SRM Control Block Overview 5-145
Relationship of the Six Major Functions of
Allocation/Unallocation 5-172
Common Allocation Input 5-178
Common Allocation Control Blocks After Construction of Volunit Table
and EDLs 5-179
ALLOCAS Control Block Structure 5-182
ALLOCAS Dump 5-187
VM&V Control Block Structure 5-196
Subsystem Interface Control Block Usage 5-205
Control Block Usage With Synonyms 5-206
Control Block Structure for Invoking Subsystem Interface 5-207
Finding the SSIB for a Job When SSOB Pointer is Zero 5-208
ENF Event Parameter List (ENFPM) 5-213
ENF Control Block Summary 5-215
ENF Control Block Structure 5-216
Sequence of Communications Task Processing 5-245
Communications Task Control Block Structure 5-247
Typical DDRCOM Chains 5-269
DDR Error Recovery Parameter List 5-270
MIH Work Area 5-275
Overview of SVC Processing With the MSSF 5-280
SVC Control Block Structure With the MSSF 5-281
Overview of SVC Processing With the Service Processor
Architecture 5-286
SVC Control Block Structure With the Service Processor
Architecture 5-287
PCIAUTH Control Block Structure
5-292
PC/AUTH Recovery Areas
5-297
PCLINK Control Block Structure 5-303
TCBs in the Global Resource Serialization Address Space 5-311
CTC Processing - Control Block Overview 5-312
Ring Processing - Control Block Overview 5-313
Command Processing - Control Block Overview 5-314
ENQjDEQ Processing - Local Resources - Control Block
Overview 5-314
ENQjDEQ Processing - Global Resources - Control Block
Overview 5-315
Queue Scanning Services - Local Resources - Control Block
Overview 5-316
Queue Scanning Services - Global Resources - Control Block
Overview 5-317
Storage Management - Control Block Overview 5-318
WTOjWTOR Message Processing - Control Block Overview 5-319
Module Flow Overview and Directory 5-321

5-69.
5-70.
5-71.
5-72.
5-73.
5-74.
5-75.
5-76.
5-77.
5-78.
5-79.
5-80.
5-81.
5-82.
5-83.
5-84.
5-85.
5-86.
5-87.
5-88.
5-89.
5-90.
5-91.
5-92.
A-I.
A-2.
A-3.
A-4.
A-5.
A-6.
A-7.
A-8.
A-9.
A-IO.
A-II.
A-I2.
A-I3.
B-1.

Module Flow for CTC Processing - Handle Arrival of
Immediate-CCW
5-322
Module Flow for CTC Processing - Handle Arrival of RSA or
RSAIRCD
5-322
Module Flow for CTC Processing - Send a RSA or RSAIRCD
5-323
Module Flow for Ring Processing - Send/Receive a RSA
5-324
Module Flow for Ring Processing - Send a RSAIRCD or
5-325
Immediate-CCW (Requested by ISGBCI)
Module Flow for Ring Processing - Send a RSAIRCD (Requested by
ISGBTC) 5-326
Module Flow for Ring Processing - Handle Arrival of RSAIRCD (Not
Requested by This System) 5-327
Module Flow for Ring Processing - SNAPSHOT Function 5-328
Module Flow for Ring Processing - SENDCMD (RSCRADDS)
Function 5-329
Module Flow for Ring Processing - SENDCMD (RSCRSNAD)
Function 5-330
Module Flow for Command Initialization and Cleanup 5-331
Module Flow for DISPLAY GRS 5-332
Module Flow for VARY GRS(x), PURGE 5-332
Module Flow for VARY GRS(x), QUIESCE to Another System 5-333
Module Flow for VARY GRS(x), QUIESCE by a System to Quiesce
Itself 5-334
Module Flow for VARY GRS(x), RESTART to Restart Another
System 5-335
Module Flow for VARY GRS(ALL), REST ART to Restart All
Systems 5-336
Module Flow for VARY GRS(x), RESTART by a System Not in the
Main Ring 5-337
Module Flow for Join Processing at Initialization Time
5-338
Module Flow for ENQ/DEQ Mainline - Local Resource
Request 5-339
Module Flow for ENQ/DEQ Mainline - Global Resource
Request 5-340
Module Flow for the Termination Resource Manager 5-341
Module Flow for Queue Scanning Services 5-342
Module Flow for Dump Support - SVC Dump
5-342
Page Fault Process Flow A-4
Swap-In Process Flow A-8
Swap-out Process Flow A-IO
IOSjEXCP Process Flow A-13
VTAM SEND Process Flow A-19
Overview of Logon Processing A-22
TCAM Organization After a TSO Logon A-26
Logon Work Area A-28
LOGON Work Area Bits That Indicate the Currently Executing
Module A-32
LOGON Scheduling Post Codes A-33
Overview of TSO Line Drop Process A-35
Summary of Command Processor Recovery Activity
A-42
TSO Attention Flow A-47
Stand-alone Dump A:nalysis Flowchart B-5

Figures

XXlll

XXIV

MVS Diagnostic Techniques

TNL SN28-5095 (December 27, 1985) to SY28-1133-2

Summary of Amendments
Summary of Amendments
for SY28-1133-2
as Updated December 27, 1985
by Technical Newsletter SN28-5095

This Technical Newsletter, which supports Version 1 Release 3.6 of MVS/System
Product, includes HASPRAS as the issuing module of a $SDUMP macro
instruction for JES2.
Additionally, several technical corrections were made.

Summary of Amendments
for SY28-1133-2
MVS/System Product Version 1 Release 3.5

This major revision consists of maintenance changes and changes to support
MVS/System Product 1.3.5.
The changes include:
•

The Service Processor Call SVC (SVC 122), which provides MVS support for:
Processor complexes with the Service Processor Architecture. For these
processors, MVS issues the SERVICE CALL instruction to communicate
wi th the service processor.
Processor complexes with the monitoring and system support facility
(MSSF). (The Service Processor Call SVC was formerly called the
MSSFCALL SVC.) For these processors, MVS issues the MSSFCALL
DIAGNOSE instruction to communicate with the MSSF.

•

Bit 19 in the machine check interruption code (MCIC).

•

SVC dump titles for the scheduler, master scheduler, and TSO.

•

Minor technical and editorial changes throughout.

Summary of Amendments

XXV

TNL SN28-5095 (December 27, 1985) to SY28':'1133-2

•

Information in "Section 5. Component Analysis" for the following
components is deleted from this book because the information is obsolete or
duplicated in other books.
JES2 - see the JES2 Logic book for diagnostic information.
VTAM - see the ACFjVTAM Diagnosis Guide and ACFjVTAM Diagnosis
Reference for diagnostic information.

Summary of Amendments
for SY28-1133-1
as Updated December 30, 1983
by Technical Newsletter SN28-0875

This Technical Newsletter, which supports Version 1 Release 3.4 of MVSjSystem
Product, contains information for the functional subsystem interface (FSI).
Also, changes have been made throughout this publication to reflect maintenance
changes.

XXVI

MVS Diagnostic Techniques

Section 1. General Introduction
This section introduces basic MVS problem analysis and provides an overview of
the interactive problem control system (IpeS).

Basic MVS Problem Analysis Techniques
Problem isolation and determination are significantly more complex in MVS than
in previous operating systems because of:
•

Enabled System Design which has made the internal and environmental
status-saving functions more extensive than those of previous systems.

•

Multiprocessing (MP) which potentially allows the execution of code in
sequences not encountered in a uniprocessing (UP) environment. MP can.
also cause contention for serially reusable resources. (In this manual, MP
refers to mUltiprocessing on both multiprocessors and attached processors.)

•

Locking Mechanism which facilitates enabled system design and
multiprocessing functions and maintains data integrity.

•

Subsystems which are responsible for processing work requested from the
system. They maintain their own work queues, control block structures and
dispatching mechanisms - all of which must be understood in order to
effectively pursue problems in the MVS operating system.

•

Software Recovery which attempts to keep the system available despite errors.

•

The number of components which provide new functions and whose internal
logic must be understood for effective problem determination.

As a result of this complexity, MVS problem solvers have made two adjustments
in their diagnostic outlook:
•

Rather than learning the system logic at an instruction or module level, they
have learned the system in terms of component interactions at the interface
level.

•

They have learned that the most effective problem ·analysis at a system level is
obtained from a disciplined, almost formal, diagnostic approach.

Section 1. General Introduction

1-1

This publication contains those debugging techniques and guidelines that have
proven the most useful to problem solvers with several years experience in
analyzing MVS system problems. These techniques are presented in terms of a
debugging "approach" that can be summarized in three steps:
1.

Identifying the external symptom of the problem.

2.

Gathering relevant data from system data areas in order to isolate the
problem to a component.

3.

Analyzing the component to determine the cause of the problem.

The most important step in this approach is often the first - correctly identifying
the external symptom of a problem. To do this, it is best to get a description of
the problem as it was perceived by an eyewitness. You will want a description
that provides a context from which to start, such as:
"System is looping; can't get in from console."
"Job abended with 213."
"I/O error on 251."
"Console locked out."
"Terminal hung, keyboard locked."
"System in wait, nothing running."
"Bad output."
"Job won't cancel."
"System degrading. Very slow."
"System died."
"OC4 in component abc."
The list is endless, of course. Your objective is to fit one (or more) of these
descriptions to one of the following external symptoms.
•

Enabled wait - The system is not executing any work and when it takes
interrupts, nothing happens. Something appears to be stuck.

•

Disabled wait - The system freezes with a disabled PSW that has the wait bit
on. This can be either an explicit and intentional disabled wait or a situation
that occurs because the PSW area has been overlaid.

•

Disabled Loop - This is normally a small (fewer than 50 instructions) loop in

disabled code.
•

Enabled loop - This is normally a large loop in enabled code (and may include
disabled portions - loops as a result of interrupts).

•

Program check - The program is automatically cancelled by the system,

usually because of improper specification or incorrect use of instructions or
data in the program. If a SYSABEND, SYSMDUMP, orSYSUDUMP DD
statement was included in the JCL for the job, a dump of the problem
program will be taken.
•

1-2

ABEND - The system issues an SVC 13 with a specific code from 1 to 4095 to
indicate an abnormal situation.

MVS Diagnostic Techniques

•

Incorrect output - The system is not producing expected output. Incorrect
output can be categorized as: missing records, duplicate records or invalid
data that has sequence errors, incorrect values, format errors. or meaningless
data. If a program has apparently executed successfully, incorrect results will
not be detected until the data is used at some future time.

•

Performance degradation - A bottleneck or system failure (hardware or
software) has severely degraded job execution and throughput.

•

TP problem - A problem, usually detected by the operator or terminal user,
that indicates malfunctions are affecting one or more terminals, lines, etc.

The chapters in Section 4 (Symptom Analysis Approach) will help you identify
these symptoms. The main rule at this stage of your analysis is to proceed
carefully. When first screening a problem, do not assume too much. Don't even
assume that the original eye witness description was correct. Keep all initial
information about the problem as a reference for your later analysis.
In the course of identifying the correct external symptom, you will begin gathering
data that will lead you to other sections of the pUblication. Specific data
gathering techniques are contained in Sections 2 and 3. Section 2 describes the
major MVS debugging areas such as LOGREC records and recovery work areas.
Section 3 describes how to use a storage dump effectively as your main source of
diagnostic material.
Eventually you should have gathered enough data to isolate the problem to a
particular component or process. Section 5 and Appendix A provide techniques
for analyzing system components and processes so that you can determine the
cause of the problem. Appendix B contains a step-by-step procedure that can be
used as a guide for analyzing a stand-alone dump.
Note: Before you begin using this publication for problem analysis, scan through
it to find out where the various types of information are located. Depending on
your current debugging sk.illievel, various sections will be more important than
others.

Always keep in mind that trouble-shooting a system of the internal complexity of
MVS is not always an "If A, then B" procedure. The guidelines and techniques
presented in this publication define "generally" what the analyst will discover.
The nature of the debugging process is such that the problem solver does not
perform ,the same analysis for every problem.

Section 1. General Introduction

1-3

IPCS - Interactive Problem Control System
The Interactive Problem Control System (IPCS) provides MVS installations with
expanded capabilities for diagnosing software failures and facilities for managing
problem information and status.
IPCS includes facilities for:
•

Online examination of storage dumps.

•

Analysis of key MVS system components and control blocks.

•

Online management of a directory of software problems that have occurred in
the user's system.

•

Online management of a directory of problem-related data, such as dumps or
the output of service aids.

IPCS runs as a command processor under TSO, allowing the user to make use of
existing TSO facilities from IPCS, including the ability to create and execute
command procedures (CLISTs) containing the IPCS command and its
subcommands.
IPCS supports three forms of MVS storage dumps:
•

High-speed stand-alone dumps produced by AMDSADMP.

•

Virtual dumps produced by MVS SDUMP on SYSl.DUMP data sets.

•

Virtual dumps produced by MVS SDUMP on data sets specified by the
SYSMDUMP DD statement.

Dumps on data sets specified by the SYSABEND or SYSUDUMP DD
statements cannot be analyzed using the IPCS facilities.
For information about IPCS, refer to the MVS Interactive Problem Control
System (IPCS) User's Guide and Reference.

1-4

MVS Diagnostic Techniques

Section 2. Important Considerations Unique to MVS
This section describes concepts and functions that are unique to the MVS
environment and useful to problem analysis. It also contains miscellaneous
debugging hints and general data gathering techniques.
The chapters in this section are:
•
•
•
•
•
•
•
•

Global System Analysis
System Execution Modes and Status Saving
Locking
Use of Recovery Work Areas in Problem Analysis
Effects of Multiprocessing on Problem Analysis
MVS Trace Analysis
Miscellaneous Debugging Hints
Additional Data Gathering Techniques

Section 2. Important Considerations Unique to MVS

2-1

Global System Analysis
In trying to isolate a problem to an internal symptom, a global system analysis
often uncovers enough data to provide a starting point for the actual problem
isolation and debugging. This chapter discusses the main considerations the
analyst should be aware of when analyzing a stand-alone dump, including:
•

The system areas that should be inspected to understand the current system
state at the time of a dump

•

The system areas that should be examined to understand the current state of
the work in the system and the current disposition of storage and tasks

Global Indicators that Determine the Current System State
The following areas should be examined to help determine the current state of the
system:
1. PSA - occupies the first 4K bytes of real storage for each processor. Note
that absolute 0 is not used during normal system operation on a 'machine with
the MP feature - this is true whether the system is operating in MP or UP.
(The one exception is a control program that is system generated with
ACRCODE = NO.) During NIP processing the PSA(s) for the processor(s)
are initialized and the prefix register(s) are initialized to point to them.
Special Notes About Stand-alone Dumps:

•

If you IPL the stand-alone dump program from the system control (SC)
frame on the 3033 or the CC012 frame of the 3081, it is not necessary to
perform the STORE STATUS operation as noted in the following
paragraphs. Status is automatically stored when stand-alone dump is
invoked from either of these frames and automatic store status is on.

•

Before taking a stand-alone dump, it is necessary to perform a STORE
STATUS operation. This hardware facility does not use prefixing; instead
it stores values such as the current PSW, registers, CPU timer, and clock
comparator in the unprefixed PSA (the one used before NIP initialized
the prefix register) at absolute address 100. The dump program
subsequently saves these values and, in an MP environment, issues a
SIGP instruction to other processors requesting a STORE STATUS
operation. As a result, these values in the unprefixed PSA are overlaid by
another processor's values.
Therefore, in an MP environment the status in the unprefixed PSA is
always that of a non-IPLed processor, not the one on which the
stand-alone dump was IPLed.

•

2-2 MVS Diagnostic Techniques

In a machine not equipped with the MP feature and therefore without
prefixing, the IPLing of the stand-alone dump program causes low
storage (0-X'18') to be overlaid with CCWs. You should be aware of this
and not consider it as a low storage overlay.

2.

•

In an MP environment, the STORE STATUS operation must be
performed only from the processor to be IPLed for the stand-alone dump
program.

•

IPLing the stand-alone dump program twice causes the storage dump to
contain a dump of the dump program itself because it was read in for the
first IPL. This causes the dump program to overlay a certain portion of
the nucleus (generally starting at X'7000') and the general purpose
registers to contain values associated with the stand-alone dump program
and not MVS.

•

If the operator does not issue the STORE STATUS instruction before
IPLing a stand-alone dump, the message "ONLY GENERAL PURPOSE
REGS VALID" might appear on the formatted dump. The PSW, control
registers, etc., are not included. This greatly hampers the debugger's task.

Registers and PSW - The print dump program formats the current PSW and
the general, floating point, and control registers associated with each
processor. From these, you can determine the program executing on each
processor.
If the current PSW is 070EOOOO 00000000 and the GPRs are all 0, you are in
the no-work wait condition, which indicates no ready work is available for
this processor to execute.
If there is or should be work remaining, an invalid wait condition results.
(Refer to the chapter on "Waits" in Section 4.)
If the registers are not equal to zero and the PSW does not contain the wait
bit (X'OO02'), there is an active program. If the wait task is dispatched, the
system is in the no-work wait condition.

3.

ILC/CC - location X'S4' for external interrupts; location X'S8' for SVC
interrupts; location X'SC' for program interrupts. These fields indicate the
last type of interrupt associated with each interrupt class for each processor.
The work active when each interrupt occurs is represented by the old PSWs at
locations: X'lS' (external); X'20' (SVC); X'2S' (program). Common contents
of these fields are:
X'84'

00001004 clock comparator
00001005 CPU timer
OOOxl201 SIGP-emergency signal
000x1202 SIGP-external call
Where x indicates the processor issuing the SIGP instruction.

X'8S'

000200xx where xx is the SVC number. This field should be inspected for unusual SVCs
such as:
1 - WAIT:
D-ABEND:
F-ERREXCP:
10 - PURGE:
38 - ENQ:
4F - STATUS:

X'8C'

can indicate an enabled wait situation
can indicate program error processing
can indicate a problem in I/O error processing
can indicate a problem in the swap process
can indicate a resource contention problem
can indicate a non-dispatchability problem

OOOXOOll indicates a page fault interrupt. Anything other than a code of 11 is highly
suspect and must be inspected further. Also with a code of 11, the program check old
PSW (location X'2S') must be enabled (mask = X'07') because disabled page faults are
not allowed in MVS and it is an error if one occurs.

Section 2. Important Considerations Unique to MVS

2-3

4.

PSA + X'204' (CPU ID)

5.

PSA + X'20S' (address of PCCA - 1 per processor) - The PCCA contains
information about the physical facilities of each processor.

6.

PSA + X'210' (address of LCCA - 1 per processor) - The LCCA contains many
of the status-saving areas that were located in low storage in previous
systems. It is used for software environment saving and indications. The
registers associated with each of the interrupts you find in the PSA are saved
in this area. In addition, the system mode indicators for each processor are
maintained in the LCCA.

7.

PSA +X'224' (PSAAOLD) - This is the address of the ASCB of the work last
dispatched on each processor. This field indicates the address space that is
currently executing.

8.

PSA + X'21C' (PSATOLD) - This is the address of the TCB of the work last
dispatched on each processor. This field in conjunction with PSAAOLD
isolates to a task within an address space. Note: PSATOLD=O when SRBs
are dispatched.

9.

PSA + X'22S' (PSASUPER) - This is a field of bits that represent various
supervisory functions in the system. If a loop is suspected, these bits should
be checked in an attempt to isolate the looping process.
Note: Because of SRM timer processing in MVS, the external first level
interrupt handler bit (X'20') or the dispatcher bit (X'04') may be set in this
field even in the enabled wait situation.

10. PSA + X'2FS' (PSACLHS) - This field indicates the current locks held on
each processor. Knowing which locks are held helps isolate the problem,
especially in a loop situation. By determining the lock holders you can isolate
the current process. (See the chapter on "Locking" later in this section.)
11. PSA + X'3S0' (PSACSTK) - This is the address of the active recovery stack
which contains the address of the recovery routines to be routed control in
case of an error. If the address is other than X'COO' (normal stack), the type
of stack (for example, program check FLIH or restart FLIH) is meaningful,
especially in the loop situation.
By searching the normal stack (X'COO') and associating the recovery routine
to active mainline routines you may get an idea of the current process. This
is true only if the pointer to the current entry is not X'CEO,' which would
indicate an empty recovery stack.
Note: If a loop is suspected, the first word following each routine address in
the current stack should be scanned. A X'80' indicates that routine is in
control. A X'40' indicates that routine is in control and that it is a nested
recovery routine.

If X'28' into the stack is non-zero, also check for an SDWA address at X'5C'
into the active stack. This block is mapped by the SDW A DSECT and is
described in the Debugging Handbook (RTCA and SDWA are different names
for the same control block). If an SDWA address is present, an error has

2-4

MVS Diagnostic Techniques

occurred and it can be related to the problem you are analyzing. If trapping
via RTM's SLIP facility, the registers at entry to RTM are contained in this
area.
12. PSA + X'414' (PSACSID) - This is the ID of the channel set that is currently
connected to this processor.

Work Queues, TCBs and Address Space Analysis
Examine the following areas to help determine the current state of work in the
system.
TCB Summary
The TCB summary report, produced by AMDPRDMP (print dump program),
contains a summary of the address spaces and their associated tasks. A quick
scan of the completion (CMP) field for each task reveals any abnormal
terminations that have occurred. Discovery of an error completion code warrants
further investigation as to the cause. Remember, however, that these codes are
residual and the job or task might have recovered from the problem.
Also investigate multiple abnormal completion codes which all relate to the same
area of the system, or many tasks that all have the same completion code. These
completion codes can all relate to one area of the system and perhaps to the
problem you are investigating. Again, LOGREC should provide further
documentation in an error situation such as this.
SRB Dispatching Queues

The print dump program formats the SRB dispatching queues. Elements on any
of these queues should be investigated, especially in cases where no work appears
to be progressing through the system.
Elements on the global, SVT, or address space local services management queues
(SVTGSMQ, SVTLSMQ, or ASCBLSMQ) can indicate that the dispatcher has
not received control since these SRBs were scheduled. This is an unusual
condition that should be investigated to determine why the SRBs have not been
dispatched.
Elements on the global/local service priority lists (GSPLs/LSPLs) should be
explained. It is possible the dump was taken before the SRB routines were able
to execute. But it more likely indicates some other system problem such as an
enabled wait or disabled loop. If there are SRBs on an LSMQ/LSPL, you should
determine if the associated address space is swapped into storage and if it is not,
why not. (possible causes are real frame shortage or a problem in the
paging/swapping mechanism.) Again this is an indication of a potential system
problem. The chapter on "Waits" in Section 4 and the chapter on "Dispatcher"
in Section 5 contain additional information on the dispatching queues.

If, at this point, you can isolate the problem to a component, refer to the
"Component Analysis" for that component in Section 5. The chapter on "Waits"
in Section 4 should prove helpful if you have isolated to a problem in the system.

Section 2. Important Considerations Unique to MVS

2-5

Address Space Analysis

If you have isolated the error to a given address space or want to determine the
state of a given address space, analyze the ASCB.
Important indicators in the ASCB are:
•

ASCBLOCK (ASCB + X'80') - to determine the specific state of the local
lock. If it contains 7FFFFFFF, FFFFFFFF, or 4FFFFFFF (the lock
suspendjinterruptjready-to-run IDs), refer to the chapter on "Locking" later
in this section for an explanation.
Note: When holding a suspend lock, a routine can only be suspended
because it attempts to obtain an unavailable cross memory services lock or
because of a page fault, synchronous page fix, or if the SMF buffers are full
when SMF is entered, or the routine specifies SUSPEND = YES on the
SDUMP macro. To find the reason for the suspension, refer to the discussion
of Task Analysis later in this chapter and to the chapter on "'Locking" later in
this section.

2-6

•

ASCBEWST (ASCB + X'48') - to determine the TOD clock value when the
address space last executed. This field helps you determine how long an
address space has been swapped-out. By subtracting this field (bytes 3-6
which repeat approximately every 15 minutes) from the last timer value in the
MVS trace table and converting to seconds, you can discover the approximate
swap-out time. (See the chapter "MVS Trace Analysis" later in this section.)

•

ASCBTNEW (ASCB + X'lC') - identifies highest-priority TCB that is
dispatchable. Explicit wait sets a non-dispatchability flag
(TCBFLGS4 = X'04').

•

ASCBCPUS (ASCB + X'20') - number of processors running tasks in this
address space.

•

ASCBSEQN (ASCB + X'26') - indicates the address space's position on the
dispatching queue. If its value is X'7FFF' the ASCB is not on the
dispatching queue.

•

ASCBRCTF (ASCB + X'66'), ASCBFLG 1 (ASCB + X'67') - current status of
the address space.

•

ASCBASXB (ASCB + X'6C') - pointer to the ASXB that anchors the TCBs.

•

ASCBDSPI (ASCB + X'72') - address space non-dispatching flags.

•

ASCBSRBS (ASCB + X'76') - number of SRBs currently suspended in the
address space.

•

ASCBOUCB (ASCB + X'90') - pointer to the OUCB, which is helpful when
determining why an address space is swapped-out.

•

ASCBFMCT (ASCB + X'98') - number of real frames currently occupied by
the address space.

MVS Diagnostic Techniques

•

ASCBTCBS (ASCB + X'D8') - number of ready TCBs not requiring the local
lock.

•

ASCBTCBL (ASCB + X'DC') - number of ready TCBs requiring the local
loc~.

•

ASCBLOCI (ASCB + X'E8') - contains either the ASCB address of the
address space holding this ASCB's local lock as a CML lock, or zero.

•

ASCBCMLH (ASCB + X'EC') - contains either the address of the suspended
TCB or SSRB holding this ASCB's local lock, or zero. The high-order bit on
in field ASCBCMLH indicates an SSRB.

Task Analysis

Once you understand the ASCB you should analyze the associated task structure.
Once again, scan the TCBs associated with your address space and look for an
abnormal completion field. While doing so, check the RB structure for each task.
Remember that the region control task, dump task, and STC/LOGON are
represented by the first three TCBs. "Normally" they will be waiting during task
execution. If one of them is not, you should determine why.
Assuming the first three TCBs are not obvious problem areas, continue inspecting
the remaining TCBs. You are trying to explain each RB. Starting with the last
RB created (the first RB, pointed to by the TCB + 0), determine what work is
represented. If work is waiting, find out why.
Note: The master scheduler address space has system task TCBs that differ from
other address spaces. Refer to the diagrams for Master Scheduler Initialization,
Start Initiator, and Job Execution in the topic "General System Flow" in the
Debugging Handbook, Volume I for details of the TCB structures.

The RBOPSW indicates the issuer of an explicit WAIT. TCBFLGS4 indicates an
explicit WAIT. If it is not an explicit WAIT, consider the following suspension
possibilities and their associated key indicators:
1.

If ASCBLOCK = X'7FFFFFFF', X'FFFFFFFF', or X'4FFFFFFF', the
status (registers and PSW) of the suspended, interrupted, or ready-to-run task
is saved in the IHSA of the locally locked address space (ASCB + X'6C'
points to ASXB; ASXB + X'20' points to IHSA). The IHSA is serialized by
the address space's local lock. The reason for suspension is important. If it is
for a lock, find out what address space or task owns that lock and what the
o/wners' state is. (The chapter on "Locking" later in this section shows how
to determine lock owners.) If it is for a page fault or synchronous page fix,
determine the state of that page fault or synchronous page fix. If it is for an
SMF suspension, the field at SMCA + X'8C' points to an SMF suspend block
(SSB). (For additional information on SMF suspension, see the topic "SMF
Suspension" later in this section.) Note also that while the RBTRANS field
points to the page fault causing address, the RBWCF is O.
Note: If a task owned the local lock at the time of the suspension or
interruption, TCBACTIV is left on. If no TCB in the task structure has an
active indicator set, you can assume an SRB owned the lock. If no SRBs are

Section 2. Important Considerations Unique to MVS

2-7

on either of the cross memory services lock suspend queue, the suspension is
probably the result of a page fault or a synchronous page fix.
An SRB can be suspended requesting an unavailable suspend lock (local or
cross memory services), or because of a page fault or a page fix. Once an
executing SRB is suspended for any of the above reasons, an SSRB (see the
Debugging Handbook) is constructed. Also, anSRB can be delayed by the
dispatcher if the local lock is unavailable and the SRB is to receive control
with the local lock held. No status is saved for a delayed SRB; instead the
SRB is placed on the local lock suspend queue. If suspended for page fault
processing, the SSRB is pointed to by the corresponding PCB + X'IC'
(PCBSRB). PCBs are generally chained together and anchored in two
locations: (1) the RSMHDR for local address space page faults; (2) the PVT
for page faults caused by referencing commonly addressable storage. Note
that if real frames were not available when the page fault occurred, even local
page faults are queued from the PVT on the defer queue (PVTGFADF,
PVT + X'7S4').
For a cross memory services lock request, the SSRB is on the requested cross
memory services lock's suspend queue. See the chapter on "Waits" in Section
4 for details on how to locate the SSRB. For Local lock suspensions, the
·SRBs and SSRBs are chained together onaqueue anchored in the ASCB
field ASCBLSQH (ASCB + X'84').
A locked TCB can be suspended for the same reasons as an SRB. The save
area is the IHSA of the locally locked address space (described in the
Debugging Handbook). The IHSA is valid during a page fault if the
corresponding PCB -+ X'08' flag is on, indicating t1;te lock was held at the time
of the page fault. Also, the TCBLLH (TCB + X'1l4') is set to X'OI' if tlte
task was locally locked at the time of the page fault.
The IHSA is valid for a cross memory services lock suspension if the ASCB is
on the cross memory services lock's suspend queue. The CMSSMF lock
suspend queue header is at label CMSFRSQH, the ENQ/DEQ cross memory
services lock suspend queue is at label CMSEDLK + X'4', and the general
cross memory services lock suspend queue is at label CMSSQH in CSECT
lEAVESLA. If there is a page fault, the TCB could be suspended while
holding both the local lock and at least one cross memory services lock. An·
indication of this is that the flag for cross memory services locks
(ASCB + X'2A') is turned on, and the ASCB address is in at least one of the
cross memory services locks. The cross memory services lockword contains
the ASCB address of the locally locked address space. The requester of the
cross memory services lock can own a cross memory 10cal(CML) lock.
Note: The local and cross memory services lock bits in ASCBHLHI are set
at suspend and are never reset.

2.

If ASCBLOCK == X'OOOOOOOO' and the memory jtask is waiting, the status is
saved in the RBjTCB. (See the chapter on "System Execution Modes and
Status Saving" later in this section.)
A task can issue the SUSPEND macro to cause the wait count of an· RB to
be non-zero. The RBOPSW indicates the issuer ora SUSPEND
RB = CURRENT request. However, an RB can also issue SUSPEND

2-8

MVS Diagnostic Techniques

RB = PREVIOUS. In this case, the only clue to the issuer is the interrupt
code in the RB. If the interrupt code indicates a type 2, 3, or 4 SVC, then
this SVC routine could have issued the suspend for this RB; but it is also
possible that some IRB had executed on behalf of the task and issued a
suspend for its previous RB.
If the RBOPSW does not indicate the issuer of a WAIT or SUSPEND, and
the RB is not in either page fault wait or page fix wait, then a SUSPEND
RB = PREVIOUS might have been issued.
Note: The explicit wait flag in the TCB (in TCBFLGS4) will not be on for a
suspended RB.

3.

Suspended SRBs can cause bottlenecks. The chapter on "System Execution
Modes and Status Saving" can aid in locating any suspended SRBs that relate
to the address space. Note: Do not spend time looking for them unless other
facts about the problem indicate a potential problem in this area.

By far the most important consideration in task analysis is the RB structure of
each task. Generally if you have isolated the problem to an address space, RB
analysis shows a potential problem in the way of:
•
•
•
•
•
•

Long RB chains
Contention caused by an ENQ (SVC 38) request
SMF suspension
Page fault or synchronous page fix waits
I/O waits
Abnormal termination processing, that is, SVC D RB

Once you have analyzed the RB structure you might want to go back and further
analyze the TCBs. Following are additional important fields in the TCB:
1.

TCBFLGS (TCB + X'lD') - indicators of how the system currently considers
this task.

2.

TCBGRS (TCB + X'30') - general purpose registers (0-15) saved when a
TYPE 1 SVC is issued or for an interruption for a non-locked task.

3.

TCBSCNDY (TCB + X'AC') - additional system indicators for this task that
help to determine why this task is not executing.

4.

TCBRTWA (TCB + X'EO') - pointer to the RTM2 work area (mapped in the
Debugging Handbook) which contains information similar to the SDWA but
also data for RTM processing.

Summary

This chapter contains major considerations you must be aware of when analyzing
a stand-alone dump in MVS. A disciplined approach is important; resist the
tendency to go off on tangents upon finding the first unexplainable condition.
After gathering all the facts, try to resolve the "cause and effect" situations you
are bound to uncover. Generally, at this point you will have isolated the error
and can start a detailed component/process analysis.

Section 2. Important Considerations Unique to MVS

2-9

System Execution Modes and Status Saving
MVS differs significantly from previous operating systems by having multiple
executjon modes. Status is saved and restored from many different locations
depending upon the execution mode at the time control was lost. This chapter
explains those modes and how they affect problem· analysis.

System Execution Modes
MVS has four executiori modes:
•
•
•
•

Task mode
SRB mode
Physically disabled mode
Locked mode

Code always executes in one of these modes or, in certain cases, in a combination
of modes. For instance, code running in task or SRB mode can also be either
locally locked or physically disabled.
In general, the supervisor dispatches units of work according to the following
priority: SRB, locked, and task mode. Because a unit of work that is disabled is
already executing, disabled mode work is not dispatched as such.
When a unit of work is running, the locally locked ASCD is found through
PSALOCAL or PSAAOLD. IfPSALOCAL=O and PSACLHS indicates that a
local lock is held, then PSAAOLD points to the locked ASeD. If PSALOCAL"O
then PSALOCAL points to the CML locked address space.
In conjunction with the four execution modes, a unit of work can execute in cross
memory mode. Cross memory mode is defined by control registers 3 and 4 and
the PSW S-bit. The S-bit (bit 16 of the PSW) indicates whether current
addressability is to the primary address space (S-bit = 0) or the secondary address
space (S~bit= 1). The primary and secondary address spaces are defined by the
ASIDs in control registers 3 and 4. The home address space is the address space
in which the unit of work resides (indicated by PSAAOLD) when that unit of
work is executing. When primary and secondary addressability is to the home
address space and the S-bit = 0, then the unit of work is not in cross memory
mode.
Task Mode
Task mode describes code that is executing in the s.ystem because the dispatcher
selected work from the task control block (TCD) chain or from the interrupt
handler save area (if the interrupted TCD held a local lock). To start execution,
the dispatcher sets up the environment (registers, PSW, cross memory state,
PCLINK stack, and FRR stack)· and then passes control to the code to be
executed.

2-10

MVS Diagnostic Techniques

1.

Information for an unlocked task dispatch environment is found as follows:
TCB + X'30' (TCBGRS)
TCB + X'O' (TCBRBP)
RB + X'lO' (RBOPSW)
RB-X'20' (RBXSB)
XSB + X'S' (XSBXMCRS)
XSB+X'lS' (XSBSTKE)
TCB + X'E4' (TCBNSSP)
NSSA + X'C' (NSSAFRRS)

2.

- General purpose registers.
- Address of the RB.
- Old PSW.
- Address of the XSB.
- Cross memory status.
- PCLINK stack header.
- Address of the NSSA.
- FRR stack for an enabled unlocked task mode FRR.

Information for a locally locked or a CML locked task dispatch environment
is found in the locally locked address space as follows:
•

From the ASCB of the locally locked address space:
ASCB + X'ES' (ASCBLOCI)

Contains either the address of the ASCB holding this
ASCB's local lock as a CML lock, or zero if this ASCB's
local lock is held as a LOCAL lock.

ASCB + X'EC' (ASCBCMLH) Address of the TCB holding this ASCB's local lock.

•

From the task holding a local lock:
TCB + X'ES' (TCBXLAS)

Contains either the address of the ASCB of the locally
locked address space, or zero if holding the LOCAL lock.

ASCB + X'6C' (ASCBASXB)

Address of the ASXB.

ASXB + X'20' (ASXBIHSA)

Address of the IHSA.

IHSA + X'3S' (IHSAGPRS)

General purpose registers.

IHSA + X'10' (IHSACPSW)

PSW for the redispatched task.

IHSA + X'SO' (IHSAXSB)

Address of the XSB.

XSB + X'g' (XSBXMCRS)

Cross memory status.

XSB + X' IS' (XSBSTKE)

PCLINK stack header.

IHSA + X'SC' (lHSAFRRS)

FRR stack.

Task mode is probably the most common execution mode. All programs given
control via ATTACH, LINK, and XCTL operate in this mode.
SRB Mode

SRB (service request block) mode describes code that is executing in the system
because the dispatcher found an SRB on one of the SRB queues. SRB set-up is
started by the SCHEDULE macro. SCHEDULE is a macro that places the
requestor-furnished SRB directly on the queue or, alternatively, calls a routine to
do so. SRBs are generally placed on the service management queue (SMQ),
unless both the SMQ and the service priority list (SPL) are empty, in which case
the SRB is placed on the SPL. The global services management queue (GSMQ) is
located at SVTGSMQ (SVT + X'20'). It is also pointed to by CVTGSMQ
(CVT+ X'264'). The global service priority list(GSPL) is located at SVTGSPL
(SVT + X'24') and can also be found from CVTGSPL (CVT+ X'26C'). The SVT
local service management queue (LSMQ) is located at SVTLSMQ (SVT + X'28'),
and can be found from CVTLSMQ (CVT + X'268'). Finally, there is one local

Section 2. Important Considerations Unique to MVS

2-11

SMQ and one local SPL per address space. ASCBLSMQ is located at
ASCB + X'DO', and ASCBLSPL is located at ASCB + X'D4'. An SRB scheduled
globally for a swapped-out address space is moved to one of the local queues.
SRBs are selected from the SPLs by the dispatcher in order to start execution.
The dispatcher loads registers 0, 1, 14, and 15 from information in the SRB and
builds the PSW. The PSW key and address are the responsibility of the scheduler
of the SRB and are specified in the SRB. SRB mode has the characteristics of
being enabled, supervisor state, key requested and non-preemptable.
Non-preemptable means that the interrupt handler should return control to the
interrupted service routine (code running under SRB mode). However, service
routines can be suspended because of a page fault or because a lock (cross
memory services or local) is unavailable.
SRB is interrupted. SRBs are non-preemptable. The registers, PSW, and cross
memory status are saved in the PSA during interrupt processing. When the
system has handled the interrupt, the SLIHs return to the FLIHs, the status is
restored from the PSA, and control is returned to the interrupted SRB routine.
SRB is suspended. SRBs that are suspended must have their status saved in a
unique area. The process that suspends an SRB is responsible for obtaining an
SSRB (suspended. SRB) and XSB (extended status block), which will contain the
interrupted status used to reschedule the service routine once the reason for
suspension has been resolved. See "Locating Status Information in a Storage
Dump" later in this chapter for a detailed description of how to find these SSRBs
and XSBs.

Physically Disabled Mode
Disabled mode is reserved for high-priority system code whose function is the
manipulation of critical system queues and data areas. It is usually combined
with supervisor state and key 0 in the PSW, and assures that the routine running
disabled is able to complete its function before losing control. It is restricted to
just a few modules in MVS (for example, interrupt handlers, the dispatcher, and
programs holding a global spin lock).
Physically disabled mode is used for one of two reasons:
1.

To assure that data remains static while the code is referencing or updating
the data.

2.

To assure that non-reentrant code does not lose control while performing
critical system functions. For example, lOS must run disabled while
enqueueing and de queueing requests to UCBs and while updating UCBs at
the start and end of I/O operations.

In the MVS system, physical disablement on a system basis because of MP must
be accompanied by locking in order to guarantee serialization. MVS disabled
code is usually accompanied by either a global spin lock or code executing under
a "super bit." The "super bits" are located in each processor's PSA (X'228').
They are used primarily for recovery reasons - they allow RTM to recognize that
a disabled supervisory function was in control at the time of error even though
global locks were not held. This indicates that FRR recovery processing should
be initiated by RTM.

2-12

MVS Diagnostic Techniques

Note that type 1 SVCs do not execute disabled in MVS. Instead they are entered
with the local lock. Thus they are considered to be task mode physically enabled,
holding the local lock.
Type 6 SVCs execute disabled. They are considered to be logical extensions of
the SVC FLIH and execute with all the restrictions (that is, cannot page fault,
etc.) of a disabled function.
Locked Mode
Locked mode describes code executing in the system while owning a lock. (See
the chapter on "Locking" later in this section.) A lock can be requested during
any execution mode (SRB, TCB, physically disabled).
Status saving while in a locked mode requires unique considerations from the
system. An example is a program that invokes a type 1 SVC, such as EXCP or
WAIT, that executes in locked mode. When a type 1 SVC is enabled, it can be
interrupted. However, if the SVC is interrupted, the registers cannot be saved in
the TCB because it is being used to save registers active at the time of the SVC
request for return to the requestor. Therefore, status must be saved elsewhere.
Status saving while in locked mode is described under the previous topics "Task
Mode" and "SRB Mode."

Determining Execution Mode From a Stand-alone Dump
Knowing the system's execution mode at the time a stand-alone dump was taken
is important in analyzing a disabled coded wait state or a loop. The following
areas may help determine the mode of execution:
LCCA Indicators
There is an important dispatcher flag byte at LCCA + X'21D'. For a global SRB,
the LCCAGSRB and LCCASRBM flags are set on. F or a local SRB, only the
LCCASRBM flag is set on.
PSA Indicators
•

Super Bits - Flags in the supervisor control field located at PSA + X'228'
(pSASUPER) indicate whether the dump was taken while in one of the
interrupt handlers or dispatcher. The dispatcher's super bit is left on when
the wait task is dispatched.

•

PSAMODE - PSA + X'49F' indicates the mode of the system:
X'OO'
X'04'
X'OS'
X'OC'
X' 10'
X'20'

•

- Task mode
- SRB mode
- Wait mode
- I/O recursion mode
- Dispatcher mode
- Non-preemptive bit (can be on with any of the above bits)

Recovery Stack - If the first two words of the RTM stack vector table
(pSA + X'380') are not equal, then control is in one of the interrupt handlers
or the dispatcher. The dispatcher stack is current when the wait task is
Section 2. Important Considerations Unique to MVS

2-13

dispatched. Compare the address at PSA + X'380' with each entry in the
FRR stack vector table starting at PSA + X'384' to determine the owner of
the active stack. (See the chapter on "Use of Recovery Work Areas for
Problem Analysis" later in this section for stack vector table analysis.)
•

Current Work - PSA + X'218' contains the addresses of the new TCB, old
TCB, new ASCB and old ASCB consecutively in a four-word area. If the
system is in SRB mode, the address of the old TCB equals O. If the addresses
of the new and old ASCBs are not equal, then the stand-alone dump was
taken between the time that an address space switch was requested and the
time that the dispatcher dispatched an address space, a global SRB, or the
wait task. In all cases, the old TCB and ASCB indicate the current work.

•

Locks - The PSA also contains the lock indicators. (See the chapter on
"Locking" later in this section for a description of how to determine the lock
mode.)

ASCB Indicators
The following ASCB locations help determine execution mode:
X'26'

Set to X'7FFF' indicates that the address space is not on the dispatching queue.

X'66-67'

RCT flags.

X'72-73'

Non-dispatchability flags.

X'76'

Count of SRBs suspended in this address space.

X'80'

Local lock (see "Locking" later in this section for how to interpret this field when "0).

X'84'

Address of the SRB suspend queue for local lock requestors.

X'DO'

Local service management queue (contains SRBs that have not been staged). When the
high-order bit of this field is I, it indicates that a "user-ready" SYSEVENT is required to
swap in the address space.

X'D4'

Local service priority list (contains SRBs that have been staged).

X'D8'

Number of ready TCBs that do not require the local lock.

X'DC'

Number of ready TCBs that require the local lock.

X'E8'

Contains either the ASCB address of the address space holding this ASCB's local lock as a
CML lock, or zero. If nonzero, then the lock is owned by a unit of work in the address
space pointed to by this field. If zero, then the lock is not owned or is owned by a unit of
work within this address space.

X'EC'

Contains either the address of the suspended TCB or SSRB that is holding this ASCB's
local lock, or zero. The high-order bit (bit 0) on indicates an SSRB.

Keep in mind that mixed modes frequently occur. For example, a local SRB can
obtain a lock, be interrupted, and the stand-alone dump taken while disabled in
the I/O supervisor. Depending on the system mode at the time of the interrupt, a
task's status (registers, PSW, etc.) can be saved in one of several places.

2-14

MVS Diagnostic Techniques

Locating Status Information in a Storage Dump
Status information is located in a storage dump depending on the conditions
under which it was saved.

Task and SRB Mode Interruptions
Status saving is required whenever the code gives up control, whether voluntarily
or involuntarily. Initial status is saved by the first level interrupt handler (FLIH)
as follows:

SVC FLIH - Initially:
•
•

Registers 7-9 saved at PSA + X'22C' (PSAGPREG)
If an error condition is found, registers saved at LCCA + X'380'

(LCCASGPR).
Then for all SVCs, status is saved in the TCB and the requestor's RB and XSB:
•
•
•
•

Registers 0-15 saved at TCB + X'30' (TCBGRS)
PSW saved at requestor's RB+X'IO' (RBOPSW)
Cross memory status saved at XSB + X'8' (XSBXMCRS)
PCLINK stack header saved at XSB + X' 18' (XSBSTKE).

Then for Type 2,3, and 4 SVCs:
•

Registers 0-15 saved at SVRB + X'20' (RBGRSAVE).

110 FLIH - Initially:

•

Register 1 saved at PSA + X'22C' (PSAGPREG).

Then for unlocked tasks, status is saved in the TCB, RB, and XSB:
•
•
•

Registers 0-15 saved in TCB + X'30' (TCBGRS)
PSW saved at RB+X'10' (RBOPSW)
Cross memory status saved at XSB + X'8' (XSBXMCRS).

For locally locked tasks, status is saved in the IHSA and XSB of the locked
address space:
•
•
•

Registers 0-15 saved at IHSA + X'38' (IHSAGPRS)
PSW saved at IHSA + X'10' (IHSACPSW)
Cross memory status saved at XSB + X'8' (XSBXMCRS).

For SRBs and non-preemptive TCBs:
•
•
•

Register 0-15 saved at PSA + X'678' (PSAGGRSV)
PSW saved at PSA + X'300' (PSASVPSW)
Cross memory status saved at PSA + X'5A8' (PGSAGXMSV).

ExternalFLIH - Initially:
•

Registers 14 and 15 saved at PSA + X'230' (PSAGPREG).
Section 2. Important Considerations Unique to MVS

2-15

Then for locally locked tasks, status is saved in the IHSA and XSB of the locked
address space:
•
•
•

Registers 0-15 saved at IHSA + X'3S' (IHSAGPRS)
PSW saved at IHSA + X'10' (IHSACPSW).
Cross memory status saved at XSB + X'S' (XSBXMCRS).

For unlocked tasks, status is saved in the TCB, RB, and XSB:
•
•
•

Registers 0-15 saved at TCB+ X'30' (TCBGRS)
PSW saved at RB+X'10' (RBOPSW)
Cross memory status saved at XSB + X'S' (XSBXMCRS).

For SRBs and non-preemptive TCBs:
•
•
•

Registers 0-15 saved at PSA + X'67S' (pSAGGRSV)
PSW saved at PSA + X'240' (pSAEXPS1)
Cross memory status saved at PSA + X'5AS' (PSAGXMSV).

If first recursion:
•
•

Registers 0-15 saved at LCCA + X'EO' (LCCAXGR2)
PSW saved at PSA + X'24S' (pSAEXPS2).

If second recursion:
•
•

Registers 0-15 saved at LCCA + X'120' (LCCAXGR3)
PSW remains at PSA + X'lS' (FLCEOPSW).

Progrllm check - 'Initially:

•

Registers saved at LCCA + X'OS' (LCCAPGR1) for recursive program
interruptions.

•

Registers saved at LCCA + X'4S' (LCCAPGR2) for nonrecursive program
interruptions.

•

Registers saved at LCCA + X'AO' (LCCAPGR3) for monitor call interrupts
that occur while processing a page fault

•

PSW saved at PSA + X'400' (PSAPCPSW).

For page faults that require I/O the following occurs:
.' Unlocked tasks:
-

2-16

MVS Diagnostic Techniques

Registers moved to TCB
PSW moved to RB

•

Locked tasks:
Registers moved to IHSA
PSW moved to IHSA

•

SRBs:
Are suspended: see "SRB Suspension" later in this chapter.

Locally Locked Task Suspension
Status saving is the same as for locked task interruptions (described earlier under
"I/O FLIH") except that IHSA of the locally locked address space also contains
the floating point registers, the FRR stacks, and the PSW. The ASCBLOCK
field is updated to contain X'7FFFFFFF'. The XSB contains cross memory
status, which includes control registers 3 and 4.
SRB Suspension
An SRB can be suspended in four cases. If a service routine encounters a page
fault and a page-in is required, then the SRB routine must give up control. In
that event, an SSRB (suspended SRB) must be obtained and the status saved in
that control block. Then the SSRB is queued from the page control block (PCB)
in the real storage manager. When the paging I/O completes, the SSRB is
scheduled to the local service priority list (LSPL) where it is found later by the
dispatcher. The SSRB must be obtained because the original SRB was not
retained after the dispatch. Status saved in an SSRB must include the current,
FRR stack.
In the second case, a service routine requests a page fix and a page-in is required.
This suspension is handled asin case one, except that the SSRB is queued from
the page control block root (PCRB).
The third case of SRB suspension is an unconditional request for- an unavailable
lock. Status saving for SRB suspension for a lock differs from the page fault
where the SSRB is queued and where control returns after the redispatch of the
SSRB. For a request for the LOCAL lock when it is unavailable, the SSRB is
queued from the ASCB. For a request for an unavailable CML lock, the SSRB is
queued from the ASCB whose lock is requested. For a request for an unavailable
cross memory services lock, the SSRB is queued on that cross memory service
lock's suspend queue. (For more detail see the chapter on "Locking" later in this
section.) In the cross memory services case of SRB suspension, resumption is at
the appropriate entry in the lock manager to try to acquire the lock. Upon
release of the cross memory services lock by the holder, any SSRBs are
rescheduled. Up6n release of the local lock by the holder, and if all suspended
elements are for LOCAL lock requests rather than CML lock requests, then the
first SSRB that was suspended is. given the local lock and rescheduled. The SRB
is given control at the next sequential instruction following the lock manager call.
If anyone of the elements on the local lock suspend queue is suspended as a
result of a CML lock request, then all queue elements are dequeued and
rescheduled to retry the lock request.
The fourth case of SRB suspension is SMF suspension. See the topic "SMF
Suspension" later in-this chapter for details of SMF suspension.

Section 2. Important Considerations Unique to MVS

2-17

Suspend SRB queues can be summarized:
Page Faults

•

PCB is chained from PVTCIOQF (at PVT + X'75C') for a common area page
and from RSMLIOQ (at RSMHD + X' 1C') for a private area page.

•

PCB + X' 1C' points to SSRB.

Page Fix

•
•
•

PCB is chained as for page fault.
PCB + X'09' points to PCBR.
PCBR + X' 18' points to SSRB.

Local Lock Requests

•

SSRB is queued from ASCBLSQH(ASCB + X'84').

CML Lock Requests

•

SSRB is queued from ASCBLSQH of the ASCB whose lock is requested.

Cross Memory Services Lock Requests

•

2-18

The SSRB is queued from a cross memory services lock's suspend queue in
lEAVESLA as shown:

MVS Diagnostic Techniques

(PSA+x'2
PSALITA

I EAVES LA
+0

LIT 
e - length (5 bytes)
f - data (SC 186)
g - key (X' 03' - product level)
h - length (7 bytes)
I
i-data (J881126)
\. SOWAVRA in
j - key (X' 22' - header)
key-length-data
k - length (10 bytes)
format
I - data (FOOTPRINTS)
m - key (X' 23' - footprint bytes)
n - length (3 bytes)
o - data (EOOOOo)

J

Figure

2-5.

Example of SDW AVRA in Key-Length-Data Format

Section 2. Important Considerations Unique to MVS

2-35

Important Considerations About SYS1.LOGREC Records
The LOGREC records are mostly SDWAs the system supplies, plus variable user
data areas the individual recovery routines supply.
Following are some special considerations pertaining to specific portions of
LOGREC entries:
•

Compare the time stamp at the top of the incident records with those in
adjacent records. If the system is percolating through FRRs, these times are
either identical or just a fraction of a second apart.

•

Abend Reason Code - If this field is zero, check System Codes to see if a
register contains a reason code for the system abend code.

•

Jobname - If the jobname is "NONE-FRR," this indicates that the record is
generated by an SRB's FRR (Functional Recovery Routine) or the current
ASCB was invalid.

•

Comp ID Involved - If the component ID is not formatted, you can
determine the ID of the failing component by using the name of the module
involved in the error and checking the "Module Summary" topic in the
Debugging Handbook.

•

"EC PS\V from ESTAE RB (0 for EST AI)" - This field has the following
possible meanings:
-

If the EST AE is associated with an RB level other than the one
encountering the error, this is the PSW at the time that the RB level
associated with the ESTAE last gave up control. Note: If this is the case,
the "RB of ESTAE Not in Control" flag should also be set.
If the ESTAE is associated with the RB level in error, the PSW is equal
to the "EC PSW at Time of ABEND" because the last time the RB level
gave up control was when the error occurred.
If the error occurred locked, disabled, or in SRB mode and is covered by
an ESTAE, the two PSWs might not match even for the top RB. "At
Abend" is the locked PSW, and "ESTAE RB" is the PSW for the last
unlocked interruption.

•

-

If the record was generated by an FRR, this is the PSW used to pass
control to the FRR and is therefore the address of the FRR.

-

If the record was generated by an FRR (that is, a locked/disabled routine
is in control, or the system is in SRB mode), and the "EC PSW at Time
of ABEND" is equal to the EC PSW from ESTAE RB, this is a
system-generated record.

"Regs of RB Level of EST AE Exit or Zero for ESTAI":
If the ESTAE exit is associated with the RB level that encountered the
error, these registers are the same as "Regs at Time of Error."

2-36

MVS Diagno~tic Techniques

If the ESTAE is associated with an RB level other than the one
encountering the error, then these are the registers at the time that RB
last gave up control.
If.this is an FRR-generated record, the two sets of registers are identical.
However, if the FRR or ESTAE has updated the registers for retry, these
registers are the new, updated registers.
•

"SVC by Locked or SRB Routine" - This indicator can be misleading. A
forced SVC 13, which is often the way FRR-protected code passes control to
recovery, also causes this flag to be set if the SVC occurred in locked,
disabled, or SRB mode. Although the flag is set, this situation is not a key
error indication in itself. The analyst must investigate why the issuing routine
invoked SVC 13.

•

Error Identifier - This field, as described in recovery termination management
(Section 5), contains pertinent information regarding the error described by
this SYSl.LOGREC entry, and provides a correlation to other
SYS1.LOGREC entries. Related software and MCH records have the same
sequence (SEQ) number that allows the correlation of records written in a
particular recovery path (that is, FRR and/or ESTAE percolation, or MCR
and subsequent software entries). For locked, disabled, or SRB routines, the
processor identifier (CPU) indicates the processor on which the routine was
running when it encountered an error. A zero processor identifier indicates
that the record was written by an ESTAE routine (that is, the processor
identifier is not uniquely identifiable). ASID indicates the current ASID at
the time of the error. TIME indicates the time that the ERROR ID was
generated. It is normally very close to the time that the record was written,
as indicated in the first line of the record. TIME can be used to
chronologically order related SYSl.LOGREC entries that contain the same
SEQ number. This ordering is useful in reconstructing the environment as it
was at the time of the error. Note that TIME changes only during recursion;
percolation does not change TIME.
If an SVC dump is taken, the ERROR ID as it appears in the
SYSl.LOGREC record, will also appear in the SVC dump output and
associated IEA9111 message. Do not be concerned if the ERROR ID
sequence numbers seem to have an increment of more than one. Although
the RTM adds one to the sequence number of each unique entry (not
percolation or recursion), there may be no associated recording of the error,
thus, the sequence number is updated internally but is not always externally
written. In particular, SDUMP and SNAP might get many expected program
checks (which are not recorded) when determining which storage areas can be
dumped.

As shown above, the SYS1.LOGREC data set is a vital tool in debugging. At
times, the information in the LOGREC printout can be used to describe the entire
problem situation. A search of the APAR data base on Retain for the CSECT,
recovery routine, and abend code will often identify the problem as a known one.

Section 2. Important Considerations Unique to MVS

2-37

SYSl.LOGREC Recording Control Buffer
This is one of the most important areas to be used when analyzing problems in
MVS. The previous discussion of LOGREC records analysis generally applies to
the in-storage LOGREC buffer as well.
This buffer serves as the intermediate storage location for data that the recovery
process uses after it has completed but before the data reaches SYS1.LOGREC.
The physical I/O is done from this buffer. Its real significance is in the error
history it displays. Also, any records in the buffer that have not reached
SYSl.LOGREC are almost certainly related to the problem you are trying to
solve.
Formatting the LOGREC Buffer
The in-storage LOGREC buffer can be formatted by specifying the LOGDATA
verb under AMDPRDMP. This verb causes the entries still in the buffer to be
formatted in the same manner as those printed from SYS1.LOGREC. For
detailed information on how to invoke the AMDPRDMP service aid, see OS/VS2
SPL: Service Aids.
Finding the LOGREC Recording Control Buffer
There are two 4K recording buffers in the SQA - one for LOGREC messages, and
one for WTO messages.
The CVT + X'23C' (CVTRTMCT) points to the RTCT (recovery termination
control table); and RTCT + X'20' (RTCTRCB) points to theRTMRCB
(LOGREC recording control buffer). The LOGREC recording control buffer
resides in fetch-protected SQA on a page boundary and is 4K bytes in length. On
the next page boundary is the 4K buffer that contains WTO messages. By adding
X'lOOO' to the address in RTCT+ X'20', you can obtain the address of the WTO
message buffer. The WTO message buffer also uses the RCB mapping format.
Format of the LOGREC Recording Control Buffer
The LOGREC recording control buffer is a "wrap-table" similar to the MVS
trace table. The entries are variable in size. The latest entries are the most
significant especially if they have not yet been written to SYS1.LOGREC.
Knowing the areas of the system that have encountered errors and the actions of
their associated recovery routines, information obtained from SYS1.LOGREC
and the LOGREC recording control buffer, helps provide an overall
understanding of the environment you are about to investigate. Figure 2-6 shows
the format of the buffer and Figure 2-7 shows the format of individual records
within the buffer.

2-38

MVS Diagnostic Techniques

o

8

4

t

RCBBUFB
start of
record
area

RCBBUFE
end of
record
area

t

C

t

RCBFREE
next
available
space

E

RCBFLNG
number
of bytes
available

X'40'

10

RCBDUM
Dummy
Displacement

(

SRB used to post
Recording Task in Master)
Address Space in order to~
write record to
SYS 1 . LOGREC

X'50'

Missing Record Header - This
record shows the number of times
space was requested but was not
available.

Processor serial number

X'5E'

X'59'
FLGS
SRB in use
flag

LCNT
Missing
record
count

RCBTLNG
Total buffer length

If the record contains a counter or is present in SYS1 . LOGREC, you have a good
indication of a recovery loop.
X' 60' ,. first possible record header

Figure 2-6. Format of the LOGREC Recording Control Buffer

o

Record Header

2

Length
of
Record

4

3
Record
Types

Options

8

6
ASID
for
POST

C
ECB

Reserved

10
J

Actual
Record

)-

)
\

Record Type - X' 80' - This record wraps around from the end of the buffer space
back through the beginning.
X' 40' - This record is to go to SYS1 . LOGREC.
X' 20' - This record is a WTO.
Options

- X' 08' - Record not buffered; the address of the record exists at X' 10' .
X' 04' - The recording requestor is to be posted when the record is written.
X' 01' - Record is ready to be written.
constructed.

Note:

If not set, the record is still being

The beginning of the actual record + X' 20' is the start of the SDWA for software
records. The SDWA contains software diagnostic information at the time of the
error and is mapped in the Debugging Handbook.

Figure 2-7. Format of Records Within the LOGREC Recording Control Buffer

Section 2. Important Considerations Unique to MVS

2-39

FRR Stacks
The FRR (functional recovery routines) stacks are often useful for understanding
the latest processes on the processors. Entries are added and deleted dynamically
as processing occurs. The PSA + X~380' contains the pointer to the current stack.
The format is described in Data Areas section of the Debugging Handbook under
FRRS. Experience has shown that the normal stack (located at X'COO' in each
PSA) is perhaps the most useful, although all stacks have been beneficial on
occasion.
The FRR stack + X'C' (FRRSCURR) points to the current recovery stack entry.
(Unless the FRRSCURR matches FRR stack +0 (FRRSEMP), in which case no
recovery is present on the stack.) This entry + 0 (FRRSFRRA poin~ed to by
FRRSCURR) points to the recovery routine that is to gain control in case of
error. The entry + 4 (FRRSFLGS) contains flags used for RTM processing; a
X'80' indicates this FRR is currently in control, a X~40' indicates a nested FRR is
currently in control. The next 24 bytes (FRRSPARM) serve as a work area for
the mainline function associated with the FRR pointed to by this entry. This
parameter area may contain footprints useful to your debugging efforts. The
previous entry in the stack (X'20' bytes in front of the current) represents the next
most current recovery routine. Only the current and previous entries are valid.
The stacks do contain residual information associated with recovery that was
previously active but is no longer valid. You should not rely on any information
beyond the current entry.
Also consider the case where:
A
A
B
C

gains control and establishes recovery;
passes control to B;
establishes recovery, performs its function, deletes recovery, and passes control to C;
establishes recovery and subsequently encounters an error.

The FRR stack will contain entries for module A's and C's recovery routines.
There is no indication from the FRR stack that B was ever involved in the
process although it might have contributed to or even caused the error. The
debugger gains an insight into the process but is not presented with the exact
flow. Although you can get an idea of the general process or flow, do not make
assumptions based solely on the FRR stack contents.
If you have trapped a specific problem, the stacks often contain valuable
information. The same is true or-a stand-alone dump taken because of a
suspected loop~ If RTI W + 0 (RTI TLPN) at FRR stack + X'28' is not zero, the
FRR stack contains current, valid data. Following are some of the more valuable
fields in the FRR stacks from a debugging viewpoint:
1.

FRR stack+X'28' (FRRSRTMW) - RTM 1 work area (RTIW)
In the case of an error, the RTI \V + 2 (RTI TENPT) field indicates the error
type as follows:
X'Ol'

X'02'
X'03'
X'04'
X'OS'
X'OA'
X'OB'
X'OC'

2-40

MVS Diagnostic Techniques

- program check
- restart key
- SVC error (SVC was issued while in locked, disabled, or SRB mode)
- DAT error
- machine check
- paging 1/0 error
- abnormal termination
- branch entry to abnormal termination (compatibility interface)

X'OD'
X'OE'
X'OF'
X'lO'
X'14'

2.

- cross memory abnormal termination reentry
- abnormal termination of current TCB
- memory termination
- cross memory abnormal termination
- MCH (machine check handler)

RTIW + X'34' (RTIWRTCA) - address of system diagnostic work area
(SDWA)
If no pointers can be found, the global SDW A for the super stacks is located
at the respective super stack + X'410'. For the normal stack, the global
SDWA immediately follows the RESTART super stack SDWA at + X'3FO'.
(PSA + X'3BS' points to the restart stack.)

3.

RTIW+X'40' (RTIWMODE) - mode at entry to RTMI
X'80'
X'40'
X'20'
X'tO'
X'08'
X'04'
X'02'
X'O l'

- supervisor control mode (PSASUPER"O)
- physically disabled mode
- global spin lock held
- global suspend lock held
- local lock held
- Type 1 SVC mode
- SRB mode
- unlocked task mode

This is the system mode at the time of entry to R TM I. The mode may
change as processing continues through recovery; the current mode is at
RTIW+X'41' (FRR stack+X'69').

Extended Error Descriptor (EED)
The extended error descriptor (EED) passes error information between RTM 1
and RTM2 and also ?etween successive schedules of RTMI. The EED address is
found at RTIW+X'3C' (RTIWEED), at TCBRTM12 (TCB+X'104'). or in the
RTM2 SVRB at X'7C'. The EED, pointed to by RTM's SVRB. is generally not
valid because RTM2 releases it early in its processing. The EED is described in
the Debugging Handbook. Important EED fields are:
EED+O (EEDFWRDP)

pointer to the next EED on the chain. or zero

EED+4 (EEDID)

description of contents of the rest of the EED
BYTE 0

= 1 - software EED
=

2 - dump parameters

= 3 - hardware EED
=

4 - errorid EED

For a software EED:
EED + X'C' (EEDREGS)

registers 0-15 at the time of the error

EED + X'4C' (EEDPSW)

PSW/lnstruction Length Code (ILC)/TransJation Exception Address
(TEA) at time of error

EED + X'5C' (EEDXM)

control registers 3 and 4 at the time of the error

RTM2 Work Area (RTM2W A)
This is the work area used by RTM2 to control abend processing. Registers,
PSW, abend code, etc. at the time of the error are recorded in the RTM2WA.
This area is often useful for debugging purposes and is described in the Debugging
Handbook by RTM2WA. This work area can be found through TCB+ X'EO'
(TCBRTWA), or RTM2 SVRB+X'SO'.

Section 2. Important Considerations Unique to MVS

2-41

Formatted RTM Control Blocks
RTM control blocks are formatted either by AMDPRDMP as a TCB exit with
the FORMAT, PRINT CURRENT, and PRINT JOBNAMES control
statements, or with the ERR option under SNAP/ABEND. With the exception of
the RTCT, the formatted control blocks are all TCB-related, and are formatted
only when they are associated with the TCB. The formatted control blocks are:
•

RTCT (recovery termination control table) - formatted with the first TCB of
the current address space on the processor on which the dump was initiated.
(This control block is formatted only by AMDPRDMP.)

•

FRRS (functional recovery routine stack) - has the RTI W embedded within it
and is formatted with the current TCB if the local lock is held. (This control
block is formatted only by AMDPRDMP and it is mutually exclusive of the
IHSA).

•

IHSA (interrupt handler save area) - has the normal FRR stack saved within
it and is formatted with the TCB pointed to by the IHSA, if the address space
was interrupted or suspended while the TCB was holding the local lock.
(This control block is formatted only by AMDPRDMP and it is mutually
exclusive of the FRRS.)

•

RTM2WA (RTM2 work area) - formatted if the TCB pointer to it is not
zero.

•

ESA (extended save area of the SVRB) bit summary - formatted only if the
RTM2W A formatted successfully and the related SVRB could be located.

•

SDWA (system diagnostic work area) - formats the registers at the time of
error only if the ESA formatted successfully and theSDWA could be located.

•

EED (extended error descriptor block) - formatted if the TCB or RTI W
pointer to it is not zero.

•

SCB (STAE control block) - formatted under AMDPRDMP for abend tasks
only. It is formatted under SNAP/ABEND whenever the TCB pointer to it is
not zero.

System Diagnostic Work Area (SDWA) Use in RTM2
This work area is used to pass information to ESTAE recovery routines. It is
found by: SVRB + X'80' points to RTM2WA; RTM2WA + X'D4' points to
SDWA. Also, register 1 contains the address of the SDWA when the recovery
routines are entered.

2-42

MVS Diagnostic Techniques

Effects of Multiprocessing On Problem Analysis
The multiprocessing (MP) capability of MVS allows multiple processors to share
real storage using one control program. (MP refers to multiprocessing on both
multiprocessors and attached processors.) MVS also functions on a uniprocessor
configura~ion, which may be only one processor configured out of what is
otherwise an MP system. In MP mode, each processor has addressa bili ty to all of
main storage and executes under the control of one set of supervisor routines.
Because various queue structures must be processed in a serial fashion,
interlocking facilities are implemented in both the hardware and software to allow
serialization of portions of the control program where conflicts may arise. Queue
structures that don't require serialization are processed in parallel, that is, without
regard to other processors.

Features of an MP Environment
The main features of a multiprocessing configuration are:
PSA - Each processor has a unique real storage frame, called a prefixed save area
(PSA), referenced with addresses from 0 to 4K. Its location in real storage is in
the processor's prefix register.
Inter-Processor Communication - Malfunction alerts (MFA) are automatically
generated by failing processors before entering the check-stop state. Other
inter-processor signaling is accomplished with the SIGP instruction. (This feature
is discussed in detail later in this chapter.)
VARY Command - Performs three functions: (1) dynamically add or remove a
processor from the configuration; (2) dynamically increase or decrease the amount
of useable real storage; (3) control the availability of channels and devices.
QUIESCE Command - Quiesces the system so that I/O pools or two channel
switches or both can be reconfigured.
Locking - Access to various supervisory services is serialized by means of a
software locking structure.
Dispatching - Assures that highest-priority ready work is processed by available
processors.
PTLB (purge translation lookaside buffer) - When an entry is to be invalidated in
a page or segment table, the translation lookaside buffer (TLB) on every
processor must be purged before permitting subsequent references to the
corresponding virtual address.
Timing - The TOD clocks must be synchronized among the configured processors.
RMS - When components of the hardware operating system fail, it becomes the
responsibility of the recovery management support (RMS) to help define the
extent of the damage.

Section 2. Important Considerations Unique to MVS

2-43

Compare and Swap - Two instructions assure interlocked update operations. They
are Compare and Swap (CS) and Compare Double and Swap (CDS). References
to storage for these instructions are interlocked the same way as the Test and Set
(TS) instruction.

lOS - has the ability to initiate I/O activity to a device from whichever processor
has an available path.
ACR - When one processor fails in an MP configuration, the alternate CPU
recovery (ACR) function takes the failing processor offline and attempts to release
the global system resources held on that processor so that system operation can
continue with the remaining processors. (See Miscellaneous Debugging Hints.)
CPU Affinity - The ability to force a job step to execute on a particular processor
is a feature of MVS. (For example, because an emulator feature is generally
installed on only one of the processors in an MP environment, processor affinity
will force the execution of programs that require this feature to the proper
processor. )
MP Storage Usage - The following diagram shows storage relationships.
Processor 0
Vi rtua I Storage
FFFFFF

Processor 1
Virtual Store e
FFFFFF

DUPLEX PSA

DUPLEX PSA

FFFOOO

FFFOOO
Absolute Main
Store e

B

A

ABSOLUTE
LOW STORAGE

......'IfI'

......,;-

PSA FOR
PROCESSOR 0

PSA FOR
PROCESSOR 1

PSA FOR
PROCESSOR 1

A

ABSOLUTE
LOW STORAGE

PSA FOR
PROCESSOR 0

1000

PSA FOR
PROCESSOR 0

0

1000
0

ABSOLUTE LOW
STORAGE
0

PSA FOR
PROCESSOR 1

Note that a processor's virtual PSA and the duplex PSA map to the same real
address (0). A processor can access the other processor's PSA by using the virtual
address of the other processor's PSA. A processor can access absolute low
storage by using the virtual address of its own PSA. The duplex PSA is used only
by lOS.

2-44

MVS Diagnostic Techniques

MP ·Dump Analysis
Experience with MVS has shown that there are comparatively few bugs unique to
MP. Usually, problems encountered in an MP environment could also be
discovered in a UP environment. The increased interaction (parallelism) between
software components in an MP environmen.t tends to increase the probability of
hitting bugs that are not unique to MP. Thus, the odds are that the dump you
are trying to debug could also occur on a UP configuration.
The first step of MP dump analysis is to determine conclusively that it is an MP
dump. To do this, you must find the common system data area (CSO). The
CSO address is located at offset X'294' in the CVT. The halfword CSOCPUOL,
at offset X'A' in the CSO, gives the number of processors currently active. If this
number is more than one, you are looking at an MP dump. For the rest of this
discussion, we will assume that CSDCPUOL=2.
Several other fields in the CSO are informative. For example, the byte CSOACR
at offset X'16', indicates whether or not ACR is in progress. ACR in progress
(X'FF' in CSDACR) indicates that one of the processors in the configuration is
becoming inactive. If this is the case, the problem may be the result of a failure
during ACR processing, and the MP dump will probably present at least two
problems:
1.

A failure causing ACR to be invoked.

2.

A failure during ACR processing. (See the discussion on ACR processing in
the "Miscellaneous Debugging Hints" chapter later in this section.)

Data Areas Associated With the MP Environment

There are several processor-related areas with which you should be familiar:
1.

2.
3.

The PCCA (physical configuration communication area)
The LCCA (logical configuration communication area)
The PSA (prefixed save area)

There is a set of these control blocks for each processor located as follows:
CVT + X'2FC' points to the PCCAVT (contains the address of a PCCA for
each processor)
CVT + X'300' points to the LCCAVT (contains the address of an LCCA for
each processor)
PCCA + X'IS' is the virtual address of the PSA for that processor
PCCA + X'IC' is the real address of the PSA for that processor
PSA + X'20S' is the virtual address of the PCCA for that processor
PSA + X'20C' is the real address of the PCCA for that processor
PSA + X'210' is the virtual address of the LCCA for that processor
PSA + X'214' is the real address of the LCCA for that processor
The PSA is the "low storage area" (first 4K bytes of storage) and it contains,
among other things, the hardware-assigned storage locations. Systemj370
Principles of Operation details the prefixing mechanism the hardware uses to
Section 2. Important Considerations Unique to MVS

2-45

reassign a block of real storage for each processor to a different block in absolute
main storage. Prefixing permits processors to share main storage and operate
concurrently.
The PCCA contains information about the physical facilities associated with its
processor, the LCCA contains save areas for use by the first level interrupt
handlers (FLIHs). The need for processor unique areas arises, for example,
because external interrupts could occur simultaneously on each processor, and
therefore a processor-related area must exist for status saving by the external
FLIH. Such areas are in the processor's PSA and LCCA. After locating these
control blocks, you can determine several things about the status of each
processor.
•

The PSWs at the time of the last program, I/O, SVC, external, and machine
check interrupts for each processor (PSA)

•

The general purpose registers at each program check and machine check
interrupt (LCCA)

•

The mode (SRB or task) of each processor (LCCA or PSA)

•

The address of the device causing the last I/O interrupt on each processor
(PSA)

In addition, a work/save area vector table (WSAVTC) pointed to at
LCCA + X'218' is associated with each processor. This vector table contains
pointers to processor-related work/save areas. For example, there is a large save
area for use by ACR, which is pointed to in the processor's WSAVTC. It is
important to be aware of the existence of these processor-related areas because
GTF, SRM, ACR, lOS, etc., use them; but you must narrow your problem to one
of these processes (such as GTF, SRM, etc.) before the information in the
associated work/save areas become helpful.
Parallelism

The most important characteristic of the MVS MP capability is parallelism. In
looking at MP dumps, you must always remember that several processes might
run in parallel and reference the same main storage locations. As a result, queue
structures and common data areas are vulnerable. In order to preserve their
integrity, the system must insure that they are accessed serially. The resources
that must be serialized in order to guarantee their integrity are called serially
reusable resources (SRRs). The use of shared resources is the key item to pe kept
in mind in debugging an MP dump. There are various mechanisms available for
serializing SRRs:
•
•
•
•
•
•
•
•
•

2-46

ENQ/DEQ
WAIT/POST
Disablement
'Locking
Compare and Swap (CS) instructions (CS and CDS)
Nondispatchability
Test and Set (TS) instruction
RESERVE/RELEASE
Intersect

MVS Diagnostic Techniques

Obviously all users of a particular SRR must use the same serialization
mechanism. The integrity of an SRR is reduced if one user uses locking and
another uses ENQ/DEQ. You need to understand the processes going on in all
processors at the time of the failure. The processor on which the failure occurred
might not be the one that caused the problem.
Use of the work/save areas pointed to from the ASXB is a good example. These
areas are serialized with the local lock. The following diagram shows what could
happen if the same address space is running on two processors and one of the
processes involved fails to serialize properly.
PROCESSOR 0

PROCESSOR 1

Branch enters validity check routine

Gets local lock
Branch enters validity check routine

••
••
••

••
•

Releases local lock

••

In this example, assume that the process executing on processor 0 fails to get the
local lock before it branch enters the system validity check routine. The validity
check routine uses the local lock to serialize one of the save areas mentioned
above in order to save the caller's registers. The registers saved by the validity
check routine on processor 1 can be overlaid by the registers saved by the validity
check routine on processor O. Thus, the failure would be encountered on
processor 1, but the processor 0 process would be the one that caused the failure.
OI/NI (OR Immediate and AND Immediate) instructions also illustrate this
phenomenon. These instructions take more than one machine cycle to complete
(that is, the operand is fetched, altered, and then stored). In previous operating
systems, physical disablement and UP environments were enough to insure the
completion of one instruction before another was executed. In MVS, with
multiple processors, this is no longer true.
F or example, suppose processor 0 issues 01 and the operand has been fetched.
Before processor 0 stores the changed byte, processor 1 executes the fetch cycle of
an NI instruction to change a different bit in the same byte. Now, processor 0
stores the original status plus the 01 change; subsequently the NI instruction
completes, which erases the effect of the 01 on the same byte. In MVS, locking is
used to solve some of the problems arising from such multi-cycle instructions.
When locking is not an appropriate solution, the Compare and Swap instructions
could be the appropriate solution. CS serializes the word containing the byte
against other processors. CDS serializes a doubleword. The point is that in
debugging an MP dump, all processors must be considered because interaction
between processes and shared resources is generally the key to solving the
problem.
When a program serializes a resource incorrectly, other programs can alter the
resource before the first program completes its update. The other programs may
be running on other processors, or they may have received control on the same
processor because the first program was preempted (for example, SRB suspension
because of a page fault) before completing its update. Proving that a problem

Section 2. Important Considerations Unique to MVS

2-47

resulted from incorrect serialization is accomplished by finding both the "other"
program and the interval in which a program opens a serialization exposure.
The system trace table can sometimes be used to find potential "other" programs.
If the occurrence of the error has not been overlaid in the trace table, it may be
possible to reconstruct the series of events leading up to the failure by:
1.

Listing all events on that processor, in order, using the logical processor
address field in each event's trace entry

2.

Making a similar list of all of the events on the other processor(s)

3.

Comparing the lists to see if the processes executing in parallel on the
processors are altering a common re~ource

Try to relate these processes that are executing in parallel to the serialization
problem that caused the dump.
General Hints For MP Dump Analysis
The following is a list of general hints to help you analyze an MP dump.

2-48

1.

The use of PRIORITY and DPRTY parameters no longer ensures the order
in which tasks are dispatched. First, the SRM, when attempting to handle
resources, can allow a task or job with a lower DPRTY to run prior to a job
with a higher priority. Second, as the dispatcher dispatches tasks on other
processors, tasks of different priority may be executing on multiple processors
simultaneously.

2.

The CHAP (change priority) SVC does not ensure that tasks are dispatched in
the expected order when dispatching on other processors.

3.

Attached tasks can execute at the same time as the mother task on different
processors. Therefore, if both tasks reference the same data, serialization of
the data is required.

4.

Any references made to system control blocks that change dynamically after
IPL must be serialized to preserve the integrity of the data. The serialization
technique for the data item must match that employed by the system.

5.

Tasks can be redispatched on a different processor from the one on which
they were previously operating. Therefore, do not use the LCCA, PCCA,
WSA, or PSA when enabled for interrupts, because redispatch on a different
processor results in different data being referenced.

6.

If subpools are shared between tasks, users must serialize the use of any data
in the subpools common to the two tasks.

7.

SRBs can be dispatched on any processor unless they are scheduled with
affinity for a particular processor.

8.

Asynchronous appendages on one processor can operate simultaneously with
the task on another processor.

MVS Diagnostic Techniques

9.

Enabled recovery routines can run on any processor, not necessarily the one
on which the error was detected.

10. STATUS STOP SRB request does not prevent SRBs from being added to the
local queue; it merely quiesces the address space after any currently executing
or suspended SRBs have completed.
11. When access methods allow sharing of data sets between tasks in the same
address space, access to the data sets must be serialized between the tasks.

Inter-Processor Communication
MVS uses the inter-processor communication (IPC) function in doing its
inter-processor related work. The IPC function uses the SIGP (Signal Processor)
instruction to provide the necessary hardware interface between the
MP-configured processors. This instruction provides twelve distinct functions.
Two of these functions are augmented by the control program to request services
of the other processor; external call (XC) and emergency signal (EMS) which are
SIGP codes 02 and 03, respectively. Thus, there are two classes of IPC services:
1.

Direct - These services are defined for those control program functions that
require the modification or sensing of the physical state of one of the
processors. Ten of the twelve SIGP functions are defined as IPC direct
services:
Function

sense
start
stop
restart
initial program reset
program reset
stop and store status
initial microprogram load
initial processor reset
processor reset

Function Code
01
04

05

06
07
08
09

OA
OB
OC

Note: Codes OA, DB, and OC are not valid on a Model 158.
2.

Remote - These services are defined for those control program functions that
require the execution of a software function on one of the processors. The
two remaining SIGP functions, external call (XC) and emergency signal
(EMS), provide the hardware interface and interruption mechanism to initiate
the desired program on the proper processor. The remote service function is
provided in two categories:

•
•

Pendable service - use the XC function of SIGP
Immediate service - use the EMS function of SIGP

When processor A issues a SIGP (XC or EMS) instruction to processor B, a
request for an interrupt becomes pending in processor B for the external class.
If external interrupts are disabled in the current PSW for processor B, the
interrupt is not taken. If the PSW for processor B is enabled. then separate
mask bits for XC and EMS are interrogated in control register O. Interrupts
are taken one at a time for those requests enabled in the control register. If

Section 2. Important Considerations Unique to MVS

2-49

processor B is disabled, processor B keeps pending at most one XC and one
EMS request. XC requests can pend simultaneously. Each specific XC
request is encoded in a physical configuration communication area (PCCA)
buffer associated with the receiving processor.
Both the direct and remote services may be used to initiate the desired
function on any of the processors physically attached via the MP feature,
including the processor the request is initiated on.
Direct Services
The direct service function consists of a macro instruction (DSGNL) and a SIGP
issuing routine (IEAVEDR). The DSGNL macro generates an in-line sequence of
instructions that:
1.

Loads general register 0 with one of the ten SIGP function codes used to
perform the desired hardware action

2.

Loads general register 1 with the address of the specified processor's physical
configuration communication area (PCCA)

3.

Loads general register 15 with the address of IEAVEDR

4.

BALRs 14, 15

Upon return from IEAVEDR, register 15 contains a return code indicating the
status of the request. If the return code is 8, register 0 contains sense information
about the receiving processor as shown in Figure 2-8.
Return Code of 8:

Register 0
Bit

o
1-23

24
25

26
27
28
29
30
31

Meaning
Equipment check
Reserved
External call pending
Stopped
Operator intervening
Check stop
Not ready
Reserved
Invalid order
Receiver check

The other return codes are:

o-

SIGP instruction successfully initiated. The function is not necessarily completed upon
return to the caller.

4 - SIGP function not completed because path to the addressed processor was busy or the
addressed processor was in a state where it could not accept and respond to the function
code.
12 - Not operational, that is, the specified processor is either not installed or is not configured
into the system or is powered off.
16 - SIGP unsuccessful. Processor is a uniprocessor and does not have SIGP sending and
receiving capabilities.

Figure

2-50

MVS Diagnostic Techniques

2-8.

SIGP Return Codes

Remote Pendable Services

The remote pendable services function (external call) consists of a macro
instruction (RPSGNL) and a routine (IEAVERP) which are used to invoke the
execution of a specified program on a specific processor. This service is used by
supervisor state, zero protection key functions that are not dependent upon the
completion of the specified service in order to continue their processing. The
RPSGNL macro generates an in-line instruction sequence that:
1.

Loads register 0 with a code identifying one of the services to be initiated

2.

Loads register 1 with the address of the PCCA of the processor on which the
service is to be initiated

3.

Loads register 15 with the address of lEAVERP

4.

BALRs 14, 15

Upon return, register 15 contains a return code. If the return code is 8, register 0
contains sense information (see Figure 2-8). There are currently six functions that
can be initiated via external call:
1.

Switch specifies that the task execution on the other processor is to be

preempted.
2.

SIO - specifies that the lOS start I/O routine (IECIPC) is to be executed on
the specified processor.

3.

RQCHECK - specifies that the timer supervisor TQE check service routine
(lEAPRQCK) is to be executed. This routine ensures that the top TQE on
the real-time queue is being timed.

4.

GTFCRM - specifies the GTF service routine (AHLSTCLS) that modifies the
Monitor Call (Me) control registers is to be executed.

5.

MODE - specifies the recovery management services (RMS) service routine
(IGFPEXI2) that modifies the RMS oriented control registers is to be
executed.

6.

MEMSWT - specifies that the memory switch service routine (lEA VEMS3) is
to be executed, either to force the signaled processor to master's address
space, or to initiate work on a waiting processor.

The rem.ote pendable services routine (IEAVERP) sets the appropriate code in the
external call buffer of the receiving processor's PCCA (offset X'84') as follows:
SWITCH
SIO
RQCHECK
GTFCRM
MODE
MEMSWT

X'SO'
X'40'
X'20'
X'tO'
X'04'
X'Ol'

Then IEAVERP sets the external call (XC) function code (X'Ol') in regi",ter 0 and
uses the DSGNL service routine instruction to cause the SIGP instruction to be
issued. If a busy condition is indicated by the DSGNL ~ervice routine, IEAVERP
Section 2 Important Considerations Onique to MVS

2-51

calls the excessive spin notification routine (IEEVEXSN) which issues message
IEE331A. The receiving processor will take an external interrupt when it becomes
enabled for such interrupts. The external FLIH determines that the interrupt was
an XC and passes control to the XC SLIH. The XC SLIH locates the XC buffer
(X'84') in his PCCA, determines the function requested, and branches (BAL) to
the appropriate routine. Refer to Figure 2-9 for the XC process flow.
Remote Immediate Services
The remote immediate services function consists of a macro instruction, RISGNL,
and a routine, lEA VERI, which are used, like the remote pendable services, to
cause the execution of a specified program on any of the online MP-configured
processors. However, the immediate service differs from the pendable service in
two important ways:
•

The processors in an MP configuration are enabled for the emergency signal
(EMS) interrupt at times when the processors are not enabled for the external
call interrupt. In particular, EMS interrupts are enabled when the processor
is in the "window spin" state in which all other asynchronous interrupts
(except machine check and malfunction alerts) are disabled. This "window
spin" state is entered by a routine, such as the lock manager, when a point is
reached in its processing that requires an action on the other processor in
order for processing to continue. The "window spin" state specifically allows
either the malfunction alert or EMS interrupts that are used to trigger the
alternate CPU recovery (ACR) function to be accepted and processed.

•

An immediate service routine can be requested to execute serially or in
parallel with the function requesting the service. That is, IEAVERI will spin
while waiting for the designated processor to signal either that the receiving
routine has completed execution (serial) or that the receiving routine has been
given control (parallel).

Some of the functions that can be initiated via EMS are:
•

HIO - A Halt I/O command is issued to the designated device by the
receiving processor.

•

ACR Function - The receiving processor helps the sending processor from a
failure by alternate CPU recovery procedures.

•

Clock Synchronization - TOD clocks are adjusted so the same value is in each
clock.

•

PTLB - The receiving processor purges its translation-Iookaside buffer (TLB).

The remote immediate services macro, RISGNL, generates an in-line sequence of
instructions that:

2-52

l.

Loads register 0 with the PARALLEL/SERIAL indication

2.

Loads register 1 with the address of the PCCA of the processor on which the
service is to be executed

MVS Diagnostic Techniques

3.

Loads register 11 with the address of a parameter list to be passed to the
service routine

4.

Loads register 12 with the entry point address of the service routine to be
executed

5.

Loads register 15 with the address of IEAVERI

6.

BALRs 14, 15

As for direct and remote pendable services, upon return register 15 contains a
return code. Register 0 contains sense information in case the return code was
eight. (See Figure 2-8.)
lEAVERI builds the emergency signal buffer in the sending processor's own
PCCA at offset X'88', sets the EMS function code X'03' in register 0, and uses the
DSGNL service routine to cause the SIGP to be issued. The receiving processor
will take an external interrupt when it becomes enabled. The external FLIH
determines that the interrupt is an EMS and routes control to the EMS SLIH.
The SLIH locates the EMS buffer of the sender and, for a parallel request, the
SLIH turns off the parallel bit and calls the receiving routine. For a serial
request, the receiving routine is given control, and, upon completion, the serial bit
is turned off. During this interrupt handling process, the sending processor was in
the window spin state until the serial or parallel bit was turned off. Figure 2-10
shows the EMS process flow.
If the receiving routine does not acknowledge the serial request within a certain
period of time, the EMS SIGP is reissued. If the spinning processor does not
receive acknowledgement of the serial or parallel request after a certain time
period, the excessive spin notification routine (IEEVEXSN) is called to issue
message IEE331A.

Section 2. Important Considerations Unique to MVS

2-53

SENDING PROCESSOR
Invoked via Macro
(See Below)

Input Registers
RO

..

>

I

Function Code

Receiving
:
Processor's PCCA
R14 Return Address
R1

IEAVERP

External Call Buffer (In
Receiving Processor's PCCA)

1 . Disables (STNSM)
External and 10 Interrupt
Set up (see Note 1 .)
2. Is Receiving Proceesor
Online?
Yes
No
RC=4
£.

~I
~0

3. Turns on External Call's
Sub-Function Code in
External Call's Buffer in
Receiving Processor's
PCCA. (Compare and
Swap On)

R15 IEAVERP EP

~

~

I-

.-..

li

X'04'
X'01 '

2. Establishes SIGP Registers
a. Physcial Processor Address
R2 = PCCACPUA baseed on R 1
b. Establishes Parameter Register
R1 = 0
c. Establishes Function Code
R3 .. RO
SIG R1, R2, 0 (R3)

.. @

(To

~ IEAVERP
Returns to

I

Return Registers

~ ~

RO
R14

RO Status Bits
R14 Return Address
R15 Return Code

R15

l::::::>

Input Registers
RO

I

Status Bits'
Return Address
Return Code
Note: R. C. 8 means
status bits are set in
Register 0

-=

IEAVERP Invoked via RPSGNL Macro Expansion:

R14 Return Address
R15 IAVEDR EP
Entry Point

"I

RPSGNL -<

SWITCH
SIO
RQCHECK
GTFCRM
MODE
MEMSWT
(0)

Figure

2-9 (Part 1 of 2).

External Call (XC) Process Flow

2-54

MVS Diagnostic Techniques

-"

>-

,PROCESSOR.. {PCCA

Part 2)

~

4. Restores Caller's Status and
Returns to Caller

I

Function Code
)('02'
R1 Receiving
Processor's PCCA

X' 10'

1. Disables (STNSM)
External and I/O interrupts
Set up - see Note 1 .

9. Restores ca Iler' s status
and returns to caller.

Return Registers

X'80'
X'40'
X'20'

3 . Checks Condition Code
CC2 - Busy - Retry (See Note 2)
CC1 - Eq. Chk, Operator
Intervention
Receiver Check - Retry
Within Limits
CC 1 - All Others - R. C. 8
CC3 - R. C. 1'2 (See Note 3.)
CCO - R. C. 0

7. Call IEEVEXSN with the
appropriate MSGID for
message IEE331 A
(See Note 5.)

...

..

--,.

6. Checks return codes:
• If RC=8 and status is
an external call
pending, set return®
code=8 . . .
9
• If RC .. 4 or 8 (not an
external call pending)

8. Is ACR active?
Yes (RC=4) No

SWITCH
SIO
RQCHECK
GTFCRM
MODE
MEMSWT

IEAVEDR

4. Sets Externa I Ca II
Function Code, X' 02' in
Reg 0
15. BALRs to IEAVEDR.

I

I

Code
Code:

E~y? Address}

RECEIVING PROCESSOR
External FLIH

(From Part 1)

A
Determine If
Interrupt Is An
External Call

I
Input Registers
R2

FLIH Return
Address

R10 Ext. Call SLIH
Entry Address

,

External Call SLIH
1 . Turns On Active Bit

2. Locates External Call Buffer
PSA - - . . PCCA
3. If Buffer Equals 0,
Retu rns to FLIH
4. Determines Subfunction
Requested, Compare and Swap
Bit Off, BAL 14 to Appropriate
Routine.
X ' 80' SWITCH
X'40' SIO
X' 20' RQCHECK
X'10' GTFCRM
X'04'MODE
X' 01' MEMSWT

(Note 4)
IECIPC
IEAPRQCK
AHLSTCLS
IGFPEX12
IEAVEMS3

Appropriate
Routine

..
~

5. Turns Off Active Indicator and
Returns Control to the Address
Established by the External
FLIH (BR2)

Notes:

1 . Turns on active indicator
Saves callers registers
Establishes addressability
2. Retry for a period of time because the processor
is temporarily busy.
3. If CC = 3 and yet the processor is logically online, a SIGP
hardware failure may exist. A "Soft ACR" option is
available to the system operator to reconfigure to a
UP system.
4. Returns to the dispatcher forcing the interrupted task to
be preempted.
5. MSGIDs are determined by the status bits in register 0 if
RC .. 9 is indicated.

Figure 2-9 (Part 2 of 2). External Can (XC) Process Flow

Section 2. Important Considerations Unique to MVS

2-55

SENDING PROCESSOR
See Macro Below

Input Registers

L.

RO Parallel/Serial

R1 Receiving
Processor's PCCA
R1 1 Parameter Address
R1 2 Receiving Routine
EP
R1 4 Return Address
R1 5 lEAVERI. EP

IEAVERI
1 . Disables (STNSM)
External and 10 Interrupts
Sets up (see Note 1 .)
2. Is Receiving Processor online~
Yes
No ..... RC-4 . . . . 7

--•

3. Builds Emergency Signal Buffer
in Own PCCA.
a) Turn On Parallel or Serial
Indicator
b) Place Receiving
1) Routines's EP
2) Routine's Parameter Address
3) Processor's Address
In The Buffer

Emergency Signal Buffer
(In Sending Processor's PCCA)
_ _ _ / I Bit
O-Parallel
(To Part 2)
Bit 1-Serial
Bit 31-RMS indicator
Receiving Routine' s
Parameter Address
Receiving Routine's
Ent Point
Receiving Processor's
Physical Processor ID

IEAVEDR
4. Sets Emergency Signal Function
Code. X' 03' in Reg 0 .
BALRs to IEAVEDR.
5. Checks Return Codes:
Unsuccessfu I
Successful

~

.Z
•••••• P ••• P
•••••• p ••••
•••••• Z. >.p
•••••••• H••
••••••• 0+ ••
•••••• ;0+ ••
•• , •••• R •••
••••••• R •••
•••••••••••
•••••••••••
•••••••••••
•••••••••••
••••••• R •••
••••••• R •••
. . . . . . . . H ••
•••••••••••
•••••••••••

i
N

1 second

where:
abcde-

address column in SQA
PSW or device address/CAW if an SIO operation
variable, see TTE in Debugging Handbook
I LC/CC/PM from the PSW
Channel set 10 for an SIO or I/O interrupt entry. (This field is zero for I/O interrupt
entries when channel set switching is not installed.)
f - CPU 10: 0 for processor 0; 1 for processor 1
g - ASIO: 0001 is master scheduler; 0002 is usually JES;
0000 is dummy task or N/A
h - TCB address
i -Timer value

Figure 2-11. How to Locate the Trace Table

If low address storage is overlaid and the trace table pointer (X'S4') is lost, you
can locate the trace table (which is in the SQA) by searching through the high
address range of common storage. Each trace entry is X'20' bytes in length and
begins in the extreme left-hand column ofa storage dump. Once you locate a
pattern of X'07' and X'04' combinations, you have found the trace table.
If location X'S4' has not been overlaid, then it will point to· the control
information for the trace; this information is directly in front of the actual table.
The trace routine places an entry (record) type indicator in the fifth position of
the PSW and moves the interrupt code in to make the PSW appear as Be mode,
Figure 2-12 explains each of the trace entry types.

2-62

MVS Diagnostic Tec~niques

Position 5

G}-0000l101
07807000
@-07802012
070C203C
®-070C803C
078C2078
~ 078C8078
018C3011
(D--070C6000

00009F08
0009C1A2
00096CEO
0001EBD8
0001EBD8
0001EC94
0001EC94
0001ECB8
0004AFFO

~g~:g~g~~ ggg~~~~:
QD--078C51Dl
060C5582
060C5950
®-070C4000

0001EE18
00018424
00018424
0004AF98

00000000
00000000
00095288
00095288
00000000
OOOOE500
00000000
00000000
00000011
00000000
00000000
0007D740
8000B1A8
0007E6B8
00000012

00000000
00000001
000955E8
~OOOOOOO
00000000
00000178
00000178
007A2FFO
00FEC760
31000163
31000163
OCOOOOOl
OCOOOOOl
OCOOOOOl
00FA3F40

c¥g~:~~g~~ gg;~~ ~~~ ggggggg~ gg~g~g~~
070C7003 0001F360 0001F360 00000001

00FOABD8
0017C2BE
00096F80
007FD69C
007F069C
00000000
007A2E88
007A2E8D
00FEC78C
40000005
40000005
00000000
00000000
00000000
00FA3F60
00105F71
00106F71
00FA3F40

00010001
60010011
40010011
60010011
60010011
40010011
40010011
C00100ll
00010011
00010000
40010011
00010011
30010011
30010011
00010012
4001003B
8001003B
40010012

00000000
007C40D8
007C4008
007C40D8
007C4008
007C40D8
007C40D8
007C40D8
007C4008
000115A8
007C40D8
007C40D8
007C40D8
007C40D8
007CDEB8
007FA930
007FA930
007FE080

AB57A140
AB57AA30
AB58A680
AB58AA40
AB58B190
AB58B3DO
AB58C350
AB58C610
AB5D8130
AB58D800
AB5A1BEO
AB5A1EOO
AB5A3DOO
AB5A4300
AB5A5A30
ABSA6220
ABSAC540
ABSAFB70

*

J

Q

Q

AS

B
H
H

Q
Q

*
*
*
*
*
*
*
*
*
*

*

M
M

Y
0
0

V
H

0
G

Q

G

Q
Q
Q
Q
Q
Q
Q
Q

Y

P

J

B

D
D

Y
W

w*

Q

*
*
*
*
*

E

*

C
F
A

Q
Q
Q
Q

Q

5
5
3

where:
Fifth digit = O. This is an SIO entry. The CAW address is '9FD8'. The 10SB address is X'FDABD8.' The
channel set id is O.
Fifth digit = 1. This is an external type. The interrupt code is X'1 004' generated by a clock comparator interrupt.
Fifth digit = 2. This is an SVC interrupt. An SVC '12' was issued from iocation X'96CEO' (minus the
I LC). Variable fields are registers 15,0, and 1.

@-

Fifth digit = 3. This is a program interrupt. Interrupt code X'11' is a page exception. Word 4 is the
referenced translation exception address (TEA).

@-

Fifth digit = 4. This is an SRB dispatch. The address in the PSW (X'4AF98') is the entry point address.
Offset X'16' contains the ASID to be dispatched. Word 3 isthe purge ASI 0 and word 7 the purge TCB.

@-

Fifth digit = 5. This is an I/O interrupt. The device address has been moved into the PSW. Words 3 and
4 are the CSW with channel end/device end.

0-

Fifth digit = 6. This is an SRB redispatch. SRBs can be suspended because of lock contention or a page
fault. The address in the PSW is the lock manager return address or the instruction that caused the
page fault.

@-

Fifth digit = 7. This is a task dispatch. The interrupt code is from the last task interrupt. If the interrupt code is 0, it could be the first dispatch of this request block (RB) forthe task.

@-

Fifth digit = 8. This is an SVC return. The interrupt code is from the last SVC interrupt for the RB.

Note: Additional trace entry types are:
Fifth digit = 9. This is a Program Call (PC) instruction. Word 3 contains the new PASI 0 (offset X '8') and
the new SASID (offset X'A').
Fifth digit = A. This is a Program Transfer (PT) instruction. Word 3 contains the new PASID (offset
X'8'). Word 4 contains the old PASID (offset X'C').
Fifth digit = B. This is a set secondary ASID (SSAR) instruction. Word 3 contains the new SASID (offset X'A'). Word 4 contains the old SASID (offset X'E').

Figure

2-12.

Types of Trace Entries

Note: In previous systems, the program check trace entries had registers 15, 0, 1
in words 3, 4, and 5. Also, the fourth word was the TEA for page fault entries.
This is changed in MVS; the fourth word for any type of program check is now
the TEA.

Section 2. Important Considerations Unique to MVS

2-63

Trace Entry for Service Processor Call SVC
The trace entry for the Service Processor Call SVC interruption is represented by
a type 2 entry (SVC interruption), with a 122 (X'7 A') SVC number, and an ESR
code of 6 in register 15.
The trace entry for the MSSFCALL DIAGNOSE or SERVICE CALL instruction
external (service signal) interruption (interruption code X'2401') is represented by
X'1401' in the trace table.
Both entries contain the following in the register 0 and 1 fields:
•

Register 0 field - contains the service processor command word (four bytes).

•

Register 1 field - contains the two-byte response that the service processor
puts in bytes 6 and 7 of the service processor data block; the one-byte caller
flags that the caller put in byte 2 of the data block; and one byte of zeros
(reserved).

This information helps you trace Service Processor Call SVC processing. For
additional information, refer to the topic "Service Processor Call SVC and
MSSFCALL DIAGNOSE Instruction" for processors with an MSSF, or the topic
"Service Processor Call SVC and SERVICE CALL Instruction" for processors
with the Service Processor Architecture.

Trace Examples
Figure 2-13 through Figure 2-16 illustrate different kinds of MVS and GTF
traces, as follows:
Figure
Figure
Figure
Figure

2-13.
2-14.
2-15.
2-16.

MVS Trace of a Page Fault Without I/O
MVS Trace of a Page Fault With I/O
GTF Trace of a Page Fault Without I/O
GTF Trace of a Page Fault With I/O

While trace tables do not include all system activity, they can be very helpful in
establishing a pattern. Remember that many MVS system services are branch
entered and therefore do not appear in any trace type entry.

2-64

MVS Diagnostic Techniques

Figure 2-13 illustrates a page fault that did not require I/O for completion. Note
that field IDS contains the information described in notes d, e, f, and g in
Figure 2-11.
PGM
SVC
PGM
SVC
RET

OLD
OLD
OLD
OLD
NEW

@

Figure

PSW L071C3011 00E44072
PSW
070C2013 00BA6B98
PSW
075C3011 00DDA3F6
PSW
075C203C 00DOA972
PSW
075C803C 00DDA972

R15/RO
R15/RO
R15/RO
R15/RO
Rl S/RO

00000000
00000000
00000000
009F1F2Q
00000000

009F2F50
00000198
009F1F20
00000000
00000000

R1
Rl
Rl
Rl
Rl

009F2F50
009F4C78
OOOOOOEO
809F1F08
809F1F08

IDS
IDS
IDS
IDS
IDS

90000003
60000003
70000003
50000003
50000003

TCB
TCB
TCB
TCB
TCB

00AOC318
00AOC318
00AOC318
00AOC318
00AOC318

TME
TME
TME
TME
TME

F09679CO
F096D6CO
F09728AO
F097EE70
F0980A 70

Fifth digit = 3 and the interrupt code is X'11 ' .. The faulting instruction is at
X'E44072' and is referencing X'9F2F50'. Because the next entry for this ASID and TeB
is not a redispatch of the same location, it can be assumed that the page exception was
satisfied by reclamation or the first time reference after a GETMAI N. No I/O was
required.

2-13.

MVS Trace of a Page Fault Without I/O (Formatted by SNAP in SYSUDUMP/SYSABEND)

Figure 2-14 illustrates another possible format of a page fault.

CD--

®F

078C3011
000001D2
Q78D7000
078D5951
070C4000

OOF68SD8
00009FFO
0009D3F'0
0009D3FO
0004AF98

OOF68008
0007D740
00 3F5 2FO
103BC8F8
00000002

007COOOO
OCOOOOOl
FF17E980
OCOOOOOO
00FEC178

078D7000 0009D3FO 003F52FO FF17E980
@--n78D51D2 001l8FOO 0007D740 OCOOOO01
~078C7000 001'685D8 001'68008 007DE7CO

007CI'.000
OOFDABD8
0011E1B4
00000000
00FEC1A4

40010015
00010001
5E010010
lE010010
00010002

007C7958
00000000
007CFCFO
007CFCFO
007FC588

AB5FB280
AB5FE470
AB5FEOAO
AB5FFOOO
AB5FF870

0011E184 5E010010 007CFCFO AB613350
00000000 OE010010 007CFCFO AB614600
007CAOOO 40010015 007C7958 AB616840

*
*
*
*
*
*
*
*

K

6EQ 6
P
0
1.0
0
LO H8
Q
1,0

0

P

K
6EQ 6

Q
Z
A

z
x

AU

U
0
0
EH

*

*
*

o *
8

0
0

where:

CD
@
@
@
Figure

The page exception.
The SIO by lOS after a branch entry from ASM.
The I/O interrupt with channel end/device end.
Redispatch at page faulting location.

2-14.

MVS Trace of a Page Fault With I/O (Unformatted)

Note that the sequence illustrated for the page fault path is not a mandatory one.
Frequently ASM finds more than one request for paging on the queue and can
satisfy them with one I/O. Also, if RSM queues a request and notes that a
request already exists, it does not interface with ASM. The ASM SRB has been
scheduled previously.
The next two examples are of GTF traces with the following options in effect:
FORMAT=SYS
SVC=ALL
SIO=ALL
PI=ALL
IO=ALL
EXT = YES
RR=YES

USR=YES
GTF=NO
DSP=YES
PCI=YES
RNIO=NO
SRM=YES
USERTIME=YES

Note: The fields in GTF trace records are described in Debugging Handbook.
Volume 1.

Section 2. Important Considerations Unique to MVS

2-65

Figure 2-15 illustrates one of two situations:

I'GM

1.

A first reference to a page after a GETMAIN was issued for it.

2.

A reclaim; that is, a fault on a page which was stolen but whose real frame
had not yet been reused.

017 ASCB OOFD5858 CPU 0000 JOBN USRT085
OLD PSW 075C0011 00D853F6 TCB 008B8EB8 MOON SVC-RES VPA 00885F5F
RC 00885FtiO III ooooalAO R2 00000050 R3 0050F602 R'I 000000E6 R5 00D85000 R6 AOD85220 R7 C00000050
R8 0008B120 R9 UUOU0001 Rl0 00055020 Rll 008BE740 R12 000001AO R13 00000000 R14 008B5E60 R15 00000000
TIME
44413.312955

~Figure

2-15.

GTF Trace of a Page Fault Without 1/0

Figure 2-16 shows the steps taken to acquire a new page following a page fault.
017 ASCB 00F05858 CPU 0000
RO 0000005B Rl 0000005B
R8 008B5F04 R9 00000000
44413.3111696
TIME
ASCB 000167)"0 CPU 0000
SRB*
'14413.343055
TIME
SIO 0353 ASCB 00016780 CPU 0000
FLGS 00000010 8801
44413.344333
TIME
OSP
ASCB 00017058 CPU 0000
411413.3115269
TIME
0353 ASCB 00016780 CPU 0000
10
CSW 00078498 ocoaOO01
44413.372394
TIME
OSP
ASCB 00F05858 CPU 0000
TIME
114413.375033
PGM

PGM 017
SRB

j"OBN USR1085
OLD PSW 075COOll 00C6BOOO TCB 00888FB8 MODN SVC-RES
VPA 00C68000
R2 8F8B5B78 R3 40C69002 R4 008B58F8 R5 01885F2C R6 008B5EE4 R7 018B5F20
Rl0 00000008 Rll 008B5A04 R12 00000000 R13 0000005B R14 008B8EB8 R15 00C6BOOO
JOBN *MASTER*

SRB PSW 070COOOO 00061A40

SRB 00FE7400

PARM 00000000

JOBN *MASTER*
STAT 0000

R/V CPA 00078740 00078470
SY. AOOR 00000000 OEOO0803

CAW OOOOEFBO
CC 0

OSID 00000000

JOBN NIl'.

OSP PSW 070EOOOO 00000000

TCB 00017158

MOON NIl'.

JOBN *MASTER*
SNS NIl'.

OLO PSW 070EOOOO 00000000
R/V CPA 00078470 00078470

TCB NIl'.
FLG C0108801

USID 00000000
A2000353 00

JOBN USRT085

OSP PSW 075COOOO 00C6BOOO

TCB 008B8EB8

MOON SVC-RES

TYPE GLOBAL

The page fault. VPA;:;address of fault.
.- The dispatch of ASM's part monitor routine in master's address space.

SIO 353

The Start I/O to page-in the requested page.

DSP

The dispatch of any ready work while the page-in I/O is in progress.
In this case, there is 110 ready work, so the wait task is dispatched.

10353

The I/O interrupt from the paging device. ASM's disable interrupt exit
(DIE) routine gets control.

DSP
The faulter resumed where he left off.
.. Note: This entry appears when ASM is unable to start the I/O in the page faulter's
address space because ASM resources are unavailable.

Figurt:

2-16.

GTF Trace of a Page Fault With 1/0

Notes J1'or Traces
The trace provides a history of some of the events that lead to a storage dump.
Trace interpretation is one of the most important aspects of debugging.
Tracing Procedure
When attempting to recreate the process that was occurring on the processor(s)
when the dump was taken, start at the current entry in the trace table (identified
either by the trace header or by the highest clock value in the last column) and
scan upwards. While scanning, look for unexpected events. These include:

2-66

•

Unit check, unit exceptions on I/O devices

•

Non-CC =0 on SIOs

MVS Diagnostic Techniques

•

Non-type 11 program checks

•

SVC D, SVC 33, SVC errors - (see number 6 under "Cautionary Notes" later
in this chapter)

•

Malfunction alerts (X'1200' external interrupt)

•

Entries that show both processors executing the same code as indicated by the
ICs (instruction counter) in the entries

•

Large time gaps in the TOD clock value

•

MP environment and only one processor doing anything

These entries indicate a potential for errors. Do not be distracted if you discover
an entry of this type. Record the incident for future use. Then continue scanning
back through the trace and try to determine what was happening in the system
that might have caused the failure. Remember to conduct the scan by unique
processor. Separate the processes that occur on each processor and watch for any
obvious interactions in the processes.
You can further subdivide the activity by address space (as depicted by ASID) or
by task (TCB address; remember to stay under the same ASID). As you recreate
the situation, remember that you are relating individual entries to real events that
must occur in order to accomplish work. Do not be distracted. For example, do
not look for an I/O interrupt just because you see an SIO. The two events should
be associated, but you should also determine the following:
•

Why the I/O is occurring;

•

If the I/O is related to the process, address space, task, page fault, etc. that
you are concerned with;

•

If the I/O completion should trigger another event. This is the way work is
accomplished in MVS, that is, events triggering more events. As you become
familiar with trace coding you learn to expect this "event causing" sequence.
Certain sequences occur very frequently; you learn to recognize these and to
look for less familiar sequences.

As you are searching trace entries, watch for repeating patterns, which can
indicate a loop in the system. These patterns can appear as constantly repeating
ICs (generally the case in a tight enabled loop), or as a repeating sequence of
entries (often the case in a process loop, such as an ERP constantly retrying an
I/O operation). Note that in the latter case, other entries from other processes
can intervene periodically in the trace table, especially in an MP environment.
If you reach a point in the trace analysis where you are somewhat comfortable
with the processes you are uncovering and recreating, and you feel you have a fair
understanding of the activity in the system, pause. Try to understand what you
have found. Is there any way you can relate your findings to the reason you have
taken the dump in the first place? Do the unexpected events have anything to do
with the problem, or are they unrelated to the problem? It can happen that the
events you have discovered are unrelated to the problem causing the dump and
you have exhausted the scope of the trace. In this case, you probably have to go

Section 2. Important Considerations Unique to MVS

2-67

into the system and study the address space and task structures, queues, and
global data areas in order to zero in on the problem.
However, if the events you have discovered are related to the problem causing the
dump, you must then attempt to isolate the erroneous process. Try to understand
how the unexpected events relate to the process. Look on both sides of the event:
did the event trigger the bad process, or is it a result of the bad process?
It is also necessary in trace analysis in MVS to understand whether you are

looking at the primary error or at some secondary problem. Is this a mainline
failure or a failure because of a problem in the recovery? Also, you must decide if
the problem is caused by a previous error from which the system has recovered.
Always be sure that it was not something several pages earlier in the trace that
caused recovery to be activated and eventually led to the current problem. If this
is the case you must now decide which error to pursue. The original error is
probably more important; however, much of the required information might be
lost because of recovery and the subsequent recovery failure. Also keep in mind
that if you must attack the secondary error condition, your search of the dump
and the recovery areas can often uncover information about the first error.
The trace is one of the most useful tools available for back-tracking through a
problem sequence. You must use it in conjunction with system control blocks and
indicators in order to recreate the error sequence. This is still true in MVS d~spite
the fact that the trace contains less information than in previous systems. In
MVS, the SVC calls have been greatly reduced because of branch entry logic for
both transfer of control and supervisor services. This means that trace entries are
not provided as in previous operating systems. Also, many significant events,
such as lock acquisition and release, SRB scheduling, and SlOP issuance, are not
traced. Because of these MVS considerations, you must be able to understand the
processes and interpret the trace table rather than just read it.
Bypassing GTF Lost Events
The following superzap is useful when you need to trace a large number of events
(such as identifying a performance problem during teleprocessing operations). It
increases the number of OTFBLOKs from 4 to 32.
NAME
VER
VER
VER
VER
VER
VER
VER
REP
REP
REP
REP
REP
REP
REP

0194
OlBC
01D2
0954
147C
148A
1674
0194
01BC
01D2
0954
147C
148A
1674

AHLCWRIT
50AE,CC03
58AA,CC03
5899,CC03
509A,CC03
587A,CC03
509A,CC03
0000,0004
50AE,CCF3
58AA,CCF3
5899,CCF3
509A,CCF3
587A,CCF3
509AJCCF3
0000,0020

Caution: Extreme care must be used when considering a system alteration in order
to gather additional data about a problem. No superzaps should be applied
before the system programmer has verified the logic being zapped and the trap

2-68

MVS Diagnostic Techniques

logic itself. Remember, if anyone location or offset within the module or trap
changes, all offsets and base registers must be verified.

Cautionary Notes
Listed below are some items the problem solver should understand when
analyzing an MVS trace table.
1.

2.

I/O Processing:

•

Much I/O is accomplished in MVS by the branch entry interface to lOS
and without the use of SVC 0 (EXCP). Therefore, you often find I/O
entries (SIO/I/O interrupt) that are not accompanied by SVC o.

•

Back-end I/O processing can result in an SRB schedule of IECVPST.
This trace entry should appear soon after an I/O interrupt. The register 1
slot will contain the 10SB address. The 10SB is the key to tracking the
I/O request.

Timer Value:

The last field of each trace entry contains bytes 3-6 of the eight-byte TOO
clock at the time the entry was made. The second digit (from the left)
represents the value to be increased approximately every second.
The following steps show how to determine the elapsed time between two
trace entries (such as from a SIO to the I/O interruption).
a.
b.
c.
d.
3.

Find the difference between the two hexadecimal timer values.
Convert the difference to a decimal value.
Divide the decimal value by 16 (result is microseconds).
Divide by 1,000,000 (result is seconds).

Enabled Wait State:

Because of recovery, the end symptom of many problems is an enabled wait
state. For tracing, the wait state presents particular problems in MVS. SRM
maintains a timer interval that periodically causes a clock comparator
interrupt (code X'1004'). These external interrupts are recorded in the trace
table. Also, an SRB is dispatched periodically in the master scheduler's
address space to run a section of SRM code which updates the page frame
tables unreferenced interval counts (UICs). In addition, in an MP/AP
environment there are external calls (code X'1202') issued between the two
processors requesting that the receiver look for ready work. These calls will
be followed by a re-dispatch of the no-work wait on the receiving processor.
In short, the wait state is a combination of dispatches of the no-work wait
task, clock comparator interrupts, and SIGP external calls. The IC
(instruction counter) will always be o.
All this extraneous activity can cause the trace to wrap around and overlay
the important trace entries of the events that led up to the enabled wait state.

Section 2. Important Considerations Unique to MVS

2-69

4.

MP/AP Activity:

The communication between the two processors in the MP/AP environment is
traced as the external interrupts are accepted by the receiving processor. An
external interrupt code of X' 1201' is an emergency signal; and an external
interrupt code of X'1202' is an external cail. (The previous chapter, "Effects
of MP on Problem Analysis," explains this communication process.)
5.

Trace Currency:

Various processes that occur in MVS turn off the MVS trace. The most
prominent of these are GTF and SVC dump. Determine if the trace was
running when the dump occUrred: if you are unaware that the trace was not
running when the dump was taken, you might go off on a fruitless chase and
lose considerable time. The trace was still active when the dump occurred if
the CVT+ X'190' value =X'07FA'.
Note: When SVC dump turns off the MVS trace, it sets bit 0 on in the ASID
identifier (offset X'16') in the current trace table entry.
6. . SVC D Entries:

SVC D is the means by which termination is invoked. In previous operating
systems, SVC D meant abnormal termination. This is not always true in
MVS. RTM2 is the mechanism for normal end~of-task processing as well as
for abnormal termination; RTM2 is invoked via SVC D. Consequently, SVC
D for normal termination is a valid situation and is traced. You can
determine whether SVC D implies normal or abnormal termination by
inspecting the register 1 slot associated with the SVC D entry. If the first
byte contains a X'08', RTM2 is being invoked for normal termination and
this is not an error situation.
MVS does not allow SVC routines to be invoked from code in one of the
following states: cross memory mode, non-task mode, any lock held, disabled
for I/O or external interruptions, or with any enabled unlocked task mode
FRR established. However, SVC D issued in one of these states is a common
means to enter RTMI to invoke recovery. RTM indicators show the SVC
error, and the system trace entries for the SVC and SVC error show the
issuer's state, but the real problem is why SVC D was issued.
7.

Important events not traced:

Since the enabled nowork wait task dispatch entry is now made while
enabled, the CS to obtain a slot in the trace table may be executed, but the
MVC that moves the entry from PSAWTENT to that slot may never occur.
This results in residual trace entries occurring among the "current" trace
entries which can be of any type.
8.

Unit exception I/O interrupt on a 3705 communications controller:

The presence of unit exception conditions from the 3705 is a common
occurrence while running VTAM. This is a normal situation and should not
be considered erroneo.~s. The host processor· has issued a set of read
commands to the 3705, and the channel progr~.Jll has been terminated before

2-70

MVS Diagnostic Techniques

all the reads have completed because the NCP did not have enough data to
satisfy each read CCW.
9.

GETMAIN, FREEMAIN - SVC X'A', SVC X78':

For SVC X'A', inspect the register 1 slot of the associated trace entry. A
value of X'SO' in the high-order byte indicates GETMAIN; a value of X'OO'
indicates FREEMAIN. SVC X'7S' uses a code in register 15 (see the
Debugging Handbook.) If a GETMAIN is indicated, the register 1 slot of the
associated re-dispatch of the SVC issuing code can be used to locate the
storage allocated by the GETMAIN process.
10. A GETMAIN for X'4D4' bytes is often seen soon after an SVC D is issued:

This is RTM2's request for storage for an RTM2WA and an SDWA for
RTM2. By locating the re-dispatch of RTM2 and inspecting the register 1
slot, you can locate the RTM2WA.

Master Trace
Master trace is useful for debugging problems when you need to know the content
of recently issued messages. Master trace maintains a wraparound table of the
messages that are routed to the hardcopy log. When a message becomes eligible
for the hardcopy log; it is entered into the master trace table by the
communications task queuing routines. The trace table resides in pageable virtual
storage in the master scheduler's private area.
The size of the master trace table is specified by the MT operand of the TRACE
command and by the MT= entries in the COMMNDxx member of
SYS1.PARMLIB. If a size is not specified, the default size is 24K bytes. The
master trace table is created during master scheduler initialization. After system
initialization, master trace may be activated and deactivated by using the TRACE
command.
The master trace table is included in SVC dumps as a part of the SDATA=TRT
option. The default size of 24K bytes accommodates approximately 336 messages
(wit~ an average length of 40 characters).
To locate the master trace table: field CVTMSER (at CVT + X'94') points to
IEEBASEA (master scheduler resident data area) and field BAMTTBL at offset
X'SC' in the IEEBASEA points to the master trace table.
When submitting an APAR, the SVC dump may be submitted for the hardcopy
log if the master trace table contains the required messages. For example:
•
•
•

The master trace table has wrapped at 9:00.
A message related to a problem was issued at 9:20.
An SVC dump is taken at 9:30.

In the example, the required messages are in the dump because the prot)lem
occurred between the time that the master trace table was wrapped and the dump
was taken.

Section 2. Important Considerations Unique to MVS

2-71

Master Trace Table

Master trace data is maintained in a wraparound table that is anchored in the
master scheduler resident data area. The format of the master trace table and
entries is described in the Debugging Handbook.
The table contains the following header and data areas:

TABLE

10

I @CURRENT I @START I

SP I LENGTH I
@WRAP I PROCFLAG

1

@END

1-""

WRAP TIME
DATA LEN I reserved

HEADER
>AREA

WRKMBB08
RESERVED

.,J

DATA
AREA

I

CURRENT ENTRY

I CURRENT ENTRY-1

1

Where:
TABLE 10

A fullword field with a constant of'MTT' to identify the beginning of the master
trace table.

@CURRENT

Address of the first byte of the current (most recently stored) entry.

@START

Address of the first byte of the data area.

@END

Address of the first byte beyond the end of the data area.

SP

Subpool in which this table resides.

LENGTH

Length of the header and data areas combined - the size specified on the TRACE
command.

WRAP TIME

Either the time that the table was initialized or the time at which the last table wrap
occurred. The form is:
xx
HH
MM
SS
T

@WRAP

2-72

MVS Diagnostic Techniques

- where IT indicates initialize time ,and WT wrap time
- hours
- minutes
- seconds
- tenths of a second

Address of the first byte of the last entry stored before the most recent table wrap.
It is initialized to zero and remains so until the first table wrap.

PROCFLAG

Processing flags used by IEEMB808.

DATA LEN

Fullword field containing the size of the data area of the table.

reserved

Reserved fullword.

WRKMB808

Sixteen word work area for IEEMB808 and IEEMB809 -- serialized by CMS and
local locks.

RESERVED

Reserved four word area.

Master Trace Table Entry
The master trace table entries (located in the data area of the master trace table)
contain the following fields:

(

HEADER
----------------~----------------

I

\

FLAGS

TAG

IMMEDIATE DATA

LENGTH

I MESSAGE

DATA

Where:
FLAGS

Halfword containing the flags set by the caller in the parameter list passed to
IEETRACE.

TAG

Halfword value indicating the identity of the caller. Values are defined in
macro IEZMTPRM, which maps the parameter list.

IMMEDIATE DATA

Fullword containing 32 bits that are defined by the caller. This area is stored
in the table without validity checking by the trace service routine.

LENGTH

Halfword containing the length of the message data.

MESSAGE DATA

Variable length field containing message data provided by the caller. The
maximum size is the length of the data area less 10 bytes, or 65,535 bytes,
whichever is less.

The table entries are of variable length. If the length of the data is specified as
zero by the caller, only the 10 byte header is entered in the table and used to store
immediate data .. The significance of the immediate data is defined by the caller.
Entries are placed into the table from back to front in the data area. Thus the
current entry immediately precedes the entry stored on the previous call to
IEETRACE.

Section 2. Important Considerations Unique to MVS

2-73

The Message Processing Facility Table (MPFT)
By using the SET MPF (message processing facility) system command, you can
suppress messages from being displayed on the operator's console.
The message processing facility builds the message processing facility table
(MPFT, mapped by macro IEEZB809), which contains an entry for each message
ID to be suppressed. The table includes the following:
•

Table header:
Subpool number (where the table resides)
Size of the table (in number of bytes)
Number of entries in the table following the header
PARMLIB suffix from which the table was built
Address of the first entry in the table
Length of each entry

•

Table entry (one IO-byte entry for each message to be suppressed):
Message ID
Length of the message
Flag byte

The MPFT is located in the common service area (CSA) and is pointed to by field
UCMFMPFP in the UCM (from the fixed extension base).

2-74

MVS Diagnostic Techniques

Miscellaneous Debugging Hints
This chapter is a collection of miscellaneous debugging hints to aid the problem
solver in specific situations not covered elsewhere in this book. It includes the
following topics:
•
•
•
•
•
•
•
•

Alternate CPU Recovery Problem Analysis
Pattern Recognition
OPEN/CLOSE/EOV ABENDs
Debugging Machine Checks
Debugging Problem Program ABEND Dumps
Debugging From Summary SVC Dumps
Started Task Control ABEND and Reason Codes
SWA Manager Reason Codes

Alternate CPU Recovery (ACR) Problem Analysis
Alternate CPU recovery (ACR) is the process by which MVS dynamically adjusts
to the unexpected failure of a processor in a multiprocessing (MP) configuration.
ACR is initiated by the failing processor. If the, failing processor's hardware
detects the failure, it issues a malfunction alert (MFA) external signal to another
processor. If the failing processor generates the severe machine check interrupt
(recursive or invalid logout) type, the machine check interrupt handler will initiate
ACR via the SIGP instruction with the emergency signal (EMS) order code,
which generates an external interrupt on the receiving processor.
When a running processor detects that a failing processor is requesting ACR, it
places X'FF' in the CSDACR byte (CSD + X'16') in the CSD control block. The
byte will be restored to X'OO' after ACR is complete.
ACR works in three phases: pre-processing, intermediate, and post-processing
phase. Pre-processing is the initialization phase: the running processor copies the
PSA and normal functional recovery routine (FRR) stacks of both processor's
and places them in the area pointed to from their respective LCCA's WSACACR
pointer. The WSACACR pointer is located at X' 10' beyond the area pointed to
by LCCACPUS. Additionally, LCCAs are marked so that in both processor's
LCCAs, LCCADCPU points to the LCCA of the failing processor and
LCCARCPU points to the LCCA of the running processor. By means of the
LCCACPUA field in the LCCA, you can determine which processor has failed
and which are still running.
Note that in a storage dump, the physical PSA of the failed processor is the same
as it was when the processor decided that ACR should be initiated. The normal
FRR stack, pointers to other FRR stacks, locks, PSASUPER bits etc. all reflect
the state of the processor at the time it failed. This will be useful for solving
problems in the recovery initiated for the process on the failed processor.
The ACR intermediate phase gets control from the MVS dispatcher, or lock
manager global spin lock routine. In this phase, ACR switches from the process
on one logical processor to the process on the other logical processor. This
switching continues until the RTMI recovery (routing to FRRs) completes on
behalf of the process on the failed processor. At this point, the ACR
post-processing phase is entered.
Section 2. Important Considerations Unique to MVS

2-75

ACR post-processing invokes I/O restart (IECVRSTI) to initialize the channel
reconfiguration hardware (CRH) function on a Model 168, or the channel set
switching function on a processor that supports this function, or to mark
outstanding I/O from the failed processor with a permanent error which then
initiates error recovery processing via error recovery procedures (ERPs). Console
switch is invoked via POST and the system resources manager (SRM) is notified
of the loss of the processor. On a system with an MSSF, post-processing invokes
the Service Processor Call SVC (lEAVMSF) to physically vary the processor
offiine. Finally, ACR issues message IEA858E 'ACR - COMPLETE', and resets
the CSDACR flag to X'OO'.
Note: The I/O error processing invoked during the ACR process has caused
many of the problems discovered to date. Of significant importance is EXCP I/O
error processing. The following flow describes the non-CRR situation for an
MVS 158 MP system.

1.

I/O restart (IECVRSTI) determines all devices that have outstanding requests
at the time of a machine check.

2.

IECVRSTI simulates an I/O interrupt for each device that was active on a
failing channel and sets the channel control check and interface control check
(X'OOOOOOOO 00060000') bits in the CSW and the pseudo interrupt bit in the
IRT (IRTPINT bit at X'02' in IRTENVR). This prevents lOS from
interfacing with the channel check handler (CCH).

3.

IECVRSTI passes control to lOS.

4.

lOS sets the 10SCOD field in 10SP to X'74' and schedules IECVPST.

5.

IECVPST routes control to the abnormal exit routine.

6.

For an EXCP, the EXCP compatibility interface routine receives control.

7.

EXCP converts the X'74' to X'7F' in the lOB.

8.

EXCP branches to abnormal end appendage.

9.

Abnormal end appendage returns to EXCP, which returns to IECVPST.

10. IECVPST invokes normal ERP processing.
11. If no path remains to a device, subsequent I/O requests (either ERP retry or
normal new requests) are intercepted by lOS and flagged with
IOSCOD = X' 51' and IECVPST is scheduled.
12. IECVPST routes control to the abnormal exit routine.
13. For EXCP requests, the abnormal exit is again the EXCP compatibility
interface routine.
14. EXCP converts the X'51' to a X'41' (permanent error) in the lOB and enters
the abnormal end appendage.

2-76

MVS Diagnostic Techniques

15. The abnormal end appendage returns to EXCP; EXCP returns to
which enters the termination routine.

IECVPST~

The important point in the preceding discussion is that EXCP changes the ACR
completion codes to conventional error post codes.
The most frequent I/O problems have been:
•

ERP's abnormal end appendages not coded for a 0 CCW address in CSW.

•

ERP's abnormal end appendages not recognizing that the last path to a
device has been lost (as with asymmetric I/O) and thus going into an I/O retry
loop.

Pattern Recognition
When analyzing a dump you should always be aware of the possibility of a
storage overlay. System incidents in MVS are often caused by storage overlays
that destroy data~ control blocks, or executable code. The results of such an
overlay vary. For example:
•

The system detects the problem and issues an abnormal completion code~ yet
the error can be isolated to an address space.

•

Referencing the data or instructions can cause an immediate error such as ,a
specification or op-code exception.

•

The bad data can be used to reference a second location, which then causes
an evident error.

When you recognize that the contents of a storage location are invalid and
subsequently recognize the bit pattern as a certain control block or piece of data,
you generally can identify the erroneous process/component and start a detailed
analysis. This section discusses pattern recognition and potential causes of
storage over1ays~ and points out common patterns that aid the debugger.
Once you recognize an overlay ~ analyze the bit pattern. If you do not recognize
the pattern at all~ try to determine the extent of the damaged area. Look at the
data on both,sides of the obviously bad areas. ,See if the length is familiar; that
is~ can you relate the length to a known control block length, data size~ MVC
length~ etc.? If so~ check various offsets to determine their contents and, if you
recognize some, try to determine the exact control block/data. Even if you do not
recognize the pattern~ take one more step. Can you determine the offset from
some base (X) that would have to be used in order to create the bit pattern? If
so~ the fact that there is a certain bit pattern at a certain offset (Y) can be helpful.
For example, a BALR register value (X'40D21C58') at an offset X'C' can indicate
that a program is using this storage for a register save area (perhaps caused by a
bad register 13). Another field in the same overlaid area might trigger
recognition.
Look at the overlaid area and scan for familiar addresses such as device
addresses, UeB addresses, and BAL/BALR register values (full word with
high-order byte containing some "l"bits). If you find any of these, try to

Section 2. Important Considerations Unique to MVS

2-77

determine what components or modules are involved or what control blocks
contain these addresses.
Repetition of a pattern can indicate a bad process. If you can recognize the bad
data you might be able to relate that data to the component or module that is
causing the error. This provides a starting point for further analysis.
Low Storage Overlays
Low storage overlays are generally very difficult problems to solve, primarily
because the error is not detected until some time after the error occurs. In order
to reduce the number of these incidents, a low address protection feature exists.
The feature can be enabled or disabled. When the feature is enabled, any attempt
to store into virtual locations 0 through X'lFF' (even with PSW key=O) results in
a protection exception. Any routine using a zero pointer as a control block
address will be caught when it attempts to store into the control block (assuming
the control clock is less than X'200' in size).
Several fields are used to control low address protection. Examine the following
fields.
control register 0, bit 3
CVTPRON
PSACROCB
PSACROSV bit 3
Hardware uses control register 0 bit 3 to determine if the feature is enabled or
disabled. At IPL time, if CVTPRON = B' I' (default value), control register 0 bit
3 is set to B' l' and PSACROCB is set to X'O l' The control register is then saved
in PSACROSV. If CVTPRON = B'O', the corresponding fields are set to O.
PSACROCB is used as a mask byte by the PROTSPA macro when enabling low
address protection. The macro enables low address protection (when the
byte = X'OI ') by altering the value in PSACROSV and loading control register 0
from that field.
The low address protection feature operates on a logical address (that is: prior to
translation and prefixing being performed). Therefore, if a program uses a virtual
address that translates to an address between 0 and X' IFF', a protection
exception may not occur. However, the PSW key must be zero in this case. This
method is used by lOS module IECIOSAM to store the channel address word
(CAW) prior to issuing the SIO instruction. IECIOSAM is the only module that
uses the duplex PSA. It is always at location X'FFFOOO'.

2-78

MVS Diagnostic Techniques

FFFFFF
DUPLEX PSA

X' FFFOOO'

1---------1

same real storage location
as viewed from anyone processor

X'1000'

o

PSA
1 . - -_ _ _ _- - '

Note: The page at X'FFFOOO' is not backed by real storage but translates to real
location O.

The following is critical data in low storage and may be overlaid only when
protection is disabled:
•

Location X'IO' (CVT pointer) should contain a nucleus address. This
location is refreshed by the program check first level interrupt handler and so
is often valid when adjacent locations are bad.

•

Locations
PSWs.

•

Location X'4C' should be equal to location X'IO'.

•

Locations X'58' through X'7F' (new PSWs) should contain valid PSWs.

X~18'

through X'3F' (old PSWs) should always contain valid

If any of the above statements is not true, consider a low storage overlay.
Further analysis is required to determine what the cause may be. Also consider
that, on a non-prefixed machine, the low storage locations described above can be
overlaid by CCWs for the stand-alone dump program, starting at location X'IO'.
Do not consider this an error situation.
Two common low storage problems are:
•

A register save area starting at location X'30'. This can happen when an area
of the system saves register status in a TCB at location O. Or it can be caused
by a routine using PSATOLD for a TCB address when the system is in SRB
mode; this is indicated by PSATOLD=O.

•

An SRB/IOSB combination starting at location X')'. This can be caused by a
problem in the lOS storage manager. The contents vary depending upon how
many control blocks the code has initialized. Points to consider are:
1.
2.
3.

The two blocks might point to each other (X'IC' into each).
An ASCB address might be at location 8.
Addresses of IECVEXCP routines might be at X'68' and/or X'6C'.

Section 2. Important Considerations Unique to MVS

2-79

Common Bad Addresses
Common bad addresses are:
•

X'COOOO', and this address plus some offset. These are generally the result of
some code using 0 as the base register for a control block and subsequently
loading a pointer from 0 plus an offset, thereby picking up the first half of a
PSW in the PSA.
Look for storage overlays in code pointed to by an old PSW. These overlays
result when 0 plus an offset cause the second half (IC) of a PSW to be used as
a pointer.

•

X'COO', X'CEO', X'DOO', X'D08', X'D20', and other pointers to fields in the
normal FRR stack. Routines often lose the contents of a register during a
SETFRR macro expansion and illegally use the address of the 24-byte work
area returned from the expansion.

•

Register save areas. Storage might be overlaid by code doing an STM (Store
Multiple) instruction with a bad register save area address. In this case, the
registers saved are often useful in determining the component or module at
fault.

OPEN/CLOSE/EOV ABENDs
When a dump shows an abend issued from O/C/EOV, the key area to start your
diagnosis in is the RTM2 work area. The failing TCB has a pointer (at
TCB + X'EO') to this area. This work area contains information current at the
time of the abend, the most important being the register contents. Register 4
points to the current O/C/EOV work area. This work area is built by IFGORROA
during problem determination and contains key information about the problem:
the JFCB, lOB, DEB and other pertinent fields are all saved in the work area for
use later by the recovery routines. The O/C/EOV work area is documented on
microfiche in each O/C/EOV module.
The module in control at the time of the abend can be determined from the
"Where To Go" (WTG) table, which is pointed to by register 6 in the RTM2
work area. The WTG table is contained within another work area called the O.C.
work area. IFGORROA saves a copy of the current DCB in this work area. If
multiple DCBs are involved, the prefix to the DeB work area points to another
DCB work area. These DeB areas are laid out precisely like a DeB. All these
work areas and their prefixes are documented at the end of every O/e/EOV
module in the microfiche.
In an MVS environment, O/e/EOV must build these work areas rather than rely
on what is in real storage at the time of the dump. The main task is to find these
areas and interpret their fields using microfiche. A quick way to find these work
areas is to find subpool 230 in the dump. All O/e/EOV data is in this subpool.
Assuming you have all the pertinent information about the failure, the problem
becomes the same as an O/C/EOV problem in OS. One more point: built into the
code is message IEC999I. This message indicates that there is a problem in the

2-80

MVS Diagnostic Techniques

O/C/EOV code that cannot be determined. While you may be able to circumvent
this problem, you should also submit an APAR for it.

Debugging Machine Checks
The machine check interruption is the hardware's method of informing the MVS
control program that it has detected a hardware malfunction. Machine checks
vary considerably in their impact on software processing. Some machine checks
notify software that the processor detected and corrected a hardware problem that
required no software recovery action (software calls these errors soft errors).
Hard errors are hardware problems detected by a processor but that require
software-initiated action for damage repair. Hard errors also require software
recovery to verify the integrity of the process that experienced the failure.
Obviously, if there are software problems after a machine check, it is more likely
that the machine check was a hard error. It is important to get a feeling for
which software components are affected by particular hardware failures.
The machine check interrupt code (MCIC), located in the PSA (at X'E8'),
describes the error causing the interrupt. (Refer to Principles of Operation for a
complete description of the MCIC.) The following discussion shows how to find
MCICs and how to interpret them for subsequent software processing. Machine
checks can be found in a LOGREC buffer (LRB), the SYSl.LOGREC data set,
or in the storage area used as a buffer prior to writing records to SYSl.LOGREC
(see the discussion of SYSl.LOGREC analysis in the "Recovery Work Areas"
chapter earlier in this section). Also, a pointer to the LRB that describes the last
machine check that occurred on a processor can be found in that processor's
PCCA at
PCCALRBV (PCCA + X' AO'). The LRB contains the machine check interrupt
code (MCIC), except when:
•

The machine check old PSW is zero. The MCIC is also zero. The
LRBMTCKS bit (field LRBTERM at LRB + X'20') is turned on by software.

•

MCIC is zero and the machine check old PSW is non-zero. The LRBMTINV
bit (field LRBTERM at LRB + X'20') is turned on by software.

The MCIC is the principal driver of software processing after a machine check. It
must be examined to determine the actions that MVS should take. The MCIC
contains bits describing the conditions that caused the interrupt. Note that more
than one failing condition can be described by a machine check at one time.
Software performs repair processing for each condition found; software recovery
processing is initiated if any hard error conditions are found (except in the cases
described on the following pages).
Because hard errors require FRR and EST AE processing, identifying a hard error
is important. Important MCIC bits follow with a description of their hardware
significance and impact on software. A handy MCIC reference matrix, containing
additional machine check and ensuing action-taken information appears at the
back of this section.
Bit 0 (System damage) - The processor is still useable, but damage occurred while
the processor was in the process of changing PSWs or otherwise changing system
control, and thus has lost th:e associated process or interrupt. Software recovery
routines (FRRs) are entered for this hard error.
Section 2. Important Considerations Unique to MVS

2-81

Bit 1 (Instruction processing damage) -'The processor is still useable, but an
instruction has failed to operate as intended. Software recovery is initiated for
this hard error, unless the backed-up bit is on with storage error or key error
uncorrected on refreshable storage (see Bit 16 description).
Bit 2 (System recol'ery) - The processor detected and corrected a potential
hardware problem. The interrupted process is completely restored by software for
this soft error; no repair is performed and no recovery routines are entered.
Bit 3 (Timer damage) - The interval timer at PSA location X'50' has failed.
Because MVS does not use this timer, this failure is ignored (indicated as a soft
error).
Bit 1/ (Timing facility damage) - Damage has occurred to the CPU timer, clock
comparator, or time-of-day clock. The particular clock facility that is damaged is
described by MCIC bits 46 and 47. A first failure to a facility results in an
attempt to reuse it. Subsequent failures result in taking the facility offline
(described in the PCCA fields PCCATODE, PCCACCE, or PCCAINTE). Ifno
clock of a particular type remains in the system, any task which requests timing
using that type of clock is sent through software recovery. This is treated as a
soft error for the process current on the processor at the time of the interrupt.
Bit 5 (External damage) - Damage has occurred to a unit external to the
processor. MVS expects more information in a channel check I/O interrupt. This
is treated as a soft error.
Bit 7 (Degradation) - The system has detected that elements of the high-speed
buffer (cache) or translation look-aside buffer have had bit (parity) errors. The
bad elements are automatically reconfigured out of the buffer~ Once a predefined
threshold of degradation machine checks is reached, the buffer and the translation
look-aside buffer are reset, thus making the entire buffer available again. This
threshold has a default value of 3 which can be changed by the operator via the
MODE command. Until then, the system might perform at a reduced rate
because of increased storage access time (cache element deletion) or increased time
to translate virtual addresses (because of translation look-aside buffer element
deletion). However, because no damage has been done to any software process or
data, this soft error is merely recorded in SYS1.LOGREC. The system state at
the time of the error is re-established, ignoring the occurrence of the buffer bit
error. It is treated as a soft error and no software recovery is initiated.
Bit 8 (Warning) - Damage is imminent; there is a cooling loss or a power drop,
etc. Software determines if the error is transient or permanent. If it is transient,
the warning interrupt is treated as a soft error. If permanent, an attempt is made
to invoke the power warning feature -software, to record the system state at the
time of this hard error.
Bit 16 (Storage error uncorrected) - There is a block in storage with a double bit
error that is located at the real, prefixed address stored in PSA location X'FS'. If
the frame's page is refreshable, that is, unchanged, pageable, and in the current
address space, it is marked invalid so a future reference will cause a fresh copy to
be paged into a new frame. (Note: More than one error can occur before the
page goes offiine.) In all cases, an attempt is made to take the damaged frame
offiine (unless the frame is in the nucleus). For unchanged nucleus frames, the
page is refreshed from a copy paged-out at NIP time. When a storage error

2-82

MVS Diagnostic Techniques

uncorrected condition occurs in conjunction with a system recovery or external
damage error, it is treated as a soft error and no recovery routines are entered. If
the storage error occurs in conjunction with instruction processing damage when
the backed-up bit (bit 14) and storage logical validity bit (bit, 31) are on, and the
frame's page is refreshable, the error is treated as soft and no recovery routines
are entered.
Any other occurrences of storage error uncorrected are treated as hard errors and
software recovery is initiated for the error.
Bit 17 (Storage error corrected) - A single-bit storage error was detected and
successfully corrected by hardware. Software treats this error as a soft error.
This error sometimes appears in conjunction with system recovery (bit 2). For a
double bit storage error, see bits 16 and 19.
Bit 18 (Storage key error uncorrected) - Hardware has detected a bit error in a
storage key. Software attempts to reset the storage key to its original value. If
the key is successfully reset, and the storage key error occurs in conjunction with
instruction processing damage when the backed-up bit (bit 14) and the storage
logical validity bit (bit 31) are on, the error is treated as soft and no recovery
routines are entered. When the storage key error occurs in conjunction with a
system recovery or external damage error, it is 'also treated as a soft error and no
recovery routines are entered. Change bits are set to one in case the frames have
been altered. Any other occurrences of storage key error are treated as hard
errors and software recovery is initiated for the error.
Bit 19 (Double J,it storage error) - If the storage error corrected bit (bit 17) is also
on, bit 19 indicates that a double bit storage error was detected and successfully
corrected by hardware. If the page containing the data can be paged, software
obtains a new frame, moves the data from the frame that has the indicated double
bit error correction into the new frame, and then marks the frame that had the
'
double bit error offiine. If the page containing the data cannot be paged,
software marks the associated frame as intercepted to go offline, which causes the
frame to be taken offline when the page is freed.

In addition to these error description bits there are other MCIC fields that
describe the time-of-occurrence of the machine check interrupt, or the validity of
the registers, PSW, and other data logged out during the machine check
interruption process.
The two time-of-occurrence bits are bits 14 and 15. The backed-up bit (bit 14),
when set to 1, indicates that the machine check occurred before actual damage
occurred. The delayed bit (bit 15) is set to 1 when the processor has been
disabled for one or more of the interrupt conditions described in the MCIC. The
processor had been processing after damage was detected.
Validity bits describe the validity of the associated field logged out during the
machine check interrupt. If a validity bit is 0, the associated data logged out is
incorrect. Validity bits are:
•
•
•
•

Bit 20
Bit 21
Bit 22
Bit 23

(PSW EMWP mask validity)
(masks and key validity)
(program mask and condition code validity)
(instruction address of machine check old PSW validity)
Section 2. Important Considerations Unique to MVS

2-83

•
•
•
•
•
•
•
•

Bit 24
Bit 25
Bit 27
Bit 28
Bit 29
Bit 30
Bit 46
Bit 47

(failing storage address validity)
(region code validity)
(floating point register validity)
(general purpose register validity)
(control register validity)
(processor model-dependent logout validity)
(CPU-timer validity)
(clock comparator validity)

Additionally, the storage logical validity bit (bit 31 set to 1) indicates that all store
operations (that were to occur before the machine check interrupt) have
completed.
The following chart attempts to show the action taken for each error condition.
For example: In column 6 the condition involves recursive machine checks, or, a
check stop, or, invalid logout. The condition originated on either a Model 158 or
a Model 168 attached processor system, and did not involve the APU. The action
taken resulted in a disabled wait. Where multiple errors do exist, appropriate
repair action is taken for all errors, and recovery action is taken for the most
severe error.
With the exception of I/O reserve outstanding, the status of each of the conditions
can be determined from examination of MCH SYSl.LOGREC records.

2-84

MVS Diagnostic Techniques

CONDITION

1

2

3

4

Recursion

X

X
X
X

X
X
X

X
X
X

Check Stop

II

Ilx

Invalid Logout
Subclass (MCIC)

5

6

7

8

9

10

X

X

X

11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

I(x [(xl
Ifx ITx
Ilx lex
X

System Damage
Inst. Proc'g. Damage

X
X
X

System Recovery
Timer Damage

X

Clock Damage

X

X

X

X

X

X
X

External Damage
Degradation

X

Warning
Time

Backed Up

X

X

Delayed

0

0

Type

Stor Err Uncorr

X

0

X

X

X

X

X

X
X

Stor Err Corr

X

Key Error

X

X
X

Key Err Unresetable
Validity

PSW (WP, MS, PM, IA)

X

X

Failing Stor Addr

X
X

X

X

X

Registers (FP. GR, CR)

X

0

-

0

0

X

Logout
Storage Logical

Location

CPU Timer

0

0

X

X

X

Clock Comparator

X

X

0

0

X

Pageable

X

LSQA, SOA
Fixed

X

V"R

0

0

X

X

X

X

158

X

X

X

X

X

168
APU

1/0

Reserve Outstanding
1st

X

X

X

X
X)

X

X

X

MP

Occurrence

X)

X

X

X

X

AP
Processor

X
X

Changed
UP

X

X

0

Unchanged
System

X

X

--I

Outside Curro Memory
Storage State

X
X
X

Nucleus

X
X

X

X

I(x

X

reX

X

X

0

--r--

X
X

X

X

X

X

2nd

X

ACTION TAKEN
X

Reset timing component

X

X

I--

X

Mark CPU Timer perm. damaged

X

X

Mark Clock Camp perm. damaged

X

Mark TOO Clock perm. damaged

X

. Invoke PWF if available

X

Activate CRH
Take frame offline immed.

X

X

X

X

X

Take frame offline when avail.
Invalidate Page Table Entry

Take Processor offline
Resume at MCOPSW

X

X
X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X X

X

X

X

X

X

X

X

X

X

)(

X

X

X

X
X

X
X

X

X

X
X

X

X
X

X

X

X
X

X

X

X

X

X

X

X

X

Refresh the nucleus page
·Possible loss of Job.

X

X

X

X

X

Restartable Wait
Enter RTM for Recov.
Record

X

X

Repair SP F Key
Disabled Wait

X

Notes:
• Key.

X = Condition must be present

o

= Condition must

©=

not be present

The action is the same no matter which condition represents the situation

Section 2. Important Considerations Unique to MVS

2-85

Debugging Problem Program Abend Dumps
The following steps may provide some initial assistance in this debugging process:
1.

Locate the RTM2 work area (RTM2WA), which is pointed to by the
TCBRTWA field in the TCB and the ESART2WA field in the abend SVRB.
It provides a summary of the abend as follows:
Name

Offset

Explanation

RTM2CC

ID

Abend completion code.

RTM2ABNM

8C

Abending program name. This is the name of a load module or an
external entry point (ALIAS) in the load module.

RTM2ABEP

94

Abending program address (the beginning of the load module or
an ALIAS in the load module).

RTM2EREG

3C

Registers at time of error.

RTM2APSW

7C

EC PSW at time of error.

RTM2ILCI

85

Instruction length code for PSW at time of error.

RTM2ERAS

36C

Error ASID.

RTM2TRCU

37C

Address of current trace entry for saved system trace table.

RTM2TRFS

380

Address of first trace entry for saved system trace table.

RTM2TRLS

384

Address of last trace entry for saved system trace table.

RTM2ERRA

B4

Error type.

Notes:

2.

a.

The RTM2ABNM and RTM2ABEP fields do not contain information
'about the abending program if an SVC has abended.

b.

In a recursive abend (an abend occurring while the original abend is being
processed by an ESTAE or other recovery routine), more than one
RTM2WA may be created, and the RTM2PREVor RTM2PRWAfield
points to other RTM2WAs associated with the problem. The system
diagnostic work area (SD W A) is pointed to by the RTM2RTCA field
during recovery routine processing, and has register contents at time of
error stored in the SD WAG RSV field. These register contents may differ
from those in the RTM2WA after a recursive abend.

To find the abend code and its explanation, look at the completion code at
the top of the abend dump. A user completion code is printed as a 4-digit
decimal number and a system completion code is printed as a 3-digit
hexadecimal number.
If the user code is non-zero, a user program has specified the completion code
in an abend macro instruction. Looking up the name of the abending
program in the RTM2WA, and investigating why the program would issue
this completion code, should lead directly to the cause of the error in the user
program.

2-86

MVS Diagnostic Techniques

Usually the system code is non-zero. This indicates that a system routine
issued the abend but a problem program might indirectly have caused the
abnormal termination. For example, a problem program might have
branched to an invalid storage address, specified an invalid parameter on a
macro instruction, or requested too much storage space.
Often the explanation of the system code 'gives enough information to
determine the cause of the termination. The explanations of system
completion codes, along with a short description of the action for the
programmer to take to correct the error, are contained in Message Library:
System Codes.
3.

To find the name of the abending program look in the RTM2 work area.
System routines usually start with the letters A or I; and module prefixes for
system routines are listed in the Debugging Handbook Volume 1.
Note: If the RTM2 work area is not available, or if the name of the
abending program is not given in the RTM2 work area, the routine name can
be obtained from the contents directory entry (CDE) queued to the program
request block (PRB). If the ABEND dump was taken to a data set (or to
SYSOUT) specified with a SYSABEND, SYSMDUMP, or SYSUDUMP DD
statement, the last two RBs are SVRBs for the SNAP and SYNCH SVCs
used to take the dump. The SVC numbers can be checked by obtaining the
hexadecimal SVC number from the interruption code of the WC-L-IC field in
the RB. The Debugging Handbook contains a list of SVC numbers. The
SNAP SVC is hexadecimal '33', and the SYNCH SVC is hexadecimal 'OC'.
The RB for the program that caused the abend is immediately before these
two RBs.

CSECTs within load modules in the private area of an address space can be
located using a linkedit map produced by the AMBLIST service aid.
CSECTs in load modules in the nucleus, FLPA, or PLP A can be located
using a nucleus or link pack area map, also produced by AMBLIST.
4.

To find the instruction that caused a program interrupt (program check)
completion code (OCx) in a problem program, examine the PSW at the time
of error. It is at the top of the abend dump, in the RTM2 work area, and in
the RB for the program that caused the abend. The instruction address field
in the PSW contains the address of the next instruction to be executed.
The length of the abend-causing instruction is printed following the
instruction length code's title 'ILC' at the top of some abend dumps. It is
also located in the RTM2ILCI field (see the RTM2 work area), and is
formatted in the third and fourth digits (OOxxOOOO) of the WC-L-IC field in
the PRB. The address of the instruction that caused the termination can be
found by subtracting the instruction length from the address in the PSW.
Subtract the program address found in the RTM2W A (and in the last PRB)
from the instruction address. The resulting offset can be used to find the
matching instruction in the abending program's assembler listing for this
CSECT.

Section 2. Important Considerations Unique to MVS

2-87

5.

To find the cause of a program interrupt, check the explanation of the system
completion code and the instruction that caused the interrupt. Also check the
registers from the time of error which are saved in the RTM2WA and in the
SVRB following the RB for the program that caused the abend. The
formatted save area trace can be used to check the input to the failing
CSECT.

6.

To find the cause of an abend code from an SVC or from a system I/O
routine, check the explanation of the system completion code, then find the
last instruction executed in the failing program and examine the related SVC
and I/O entries in the trace table or GTF trace records.
The last PRB in the formatted RBs has a PSW field ·containing the address of
the instruction following the instruction that issued the SVC. For I/O
requests, check the entry point address ('EPA') field in the last PRB. The
formatted save area trace gives the address of the I/O routine branched to,
and the return address in that save area is the address of the last instruction
executed in the failing program.
The trace information can be checked for SVC entries that match the
formatted SVRBs, or for I/O entries issued from addresses in the failing
program. The trace information is formatted in the dump if the installation
has specified it as a dump option. If the system trace table is not formatted,
look in the RTM2 work area for pointers to the copy of the system trace
table that was saved from the time of the error. Location X'54', which is the
FLCTRACE field in the prefixed save area (PSA), points to the system trace
table header. The system trace table is frequently overlaid with entries for
other system activity by the time the dump is produced.
If the dump contains trace records, begin at the most recent entry and
proceed backwards to locate the most recent SVC entry indicating the
problem state. From this entry, proceed forward in the table. Examine each
entry for an error that could have terminated the SVC or I/O system routine.
The format of system trace table entries is described in the Debugging
/-landbook under the heading 'TTE Trace Table Entry.' The format of GTF
trace records is also described in the Debugging Handbook.

7.

In a cross memory environment, many services are requested by use of the
Program Call (PC) instruction rather than by SVCs or SRBs. When an abend
is issued by the PC routine, it can be confusing trying to identify the caller
and exactly where the PC instruction was issued. This is because the RB old
PSW contains the instruction address of the PC routine issuing the abend and
the abend SVRB contains the registers of the PC routine.
To determine if a program is in cross memory mode, examine the SASID and
PASID fields in the XSB control block. If they are not equal, the program is
executing in cross memory mode. To locate the XSB:

2-88

•

In a formatted dump, the XSB is printed following the RB with which it
is associated.

•

In storage, field RBXSB (RB-X'20') points to the XSB.

MVS Diagnostic Techniques

In cross memory mode, you can determine the caller of a PC routine by
examining the PC LINK stack. To locate the PCLINK stack element
(STKE):
•

In a formatted dump, the STKEs are printed following all of the RBs. If
there is more than one STKE, the pointer to the one you want is
contained in field XSBSTKE (XSB + X'18') of the XSB associated with
your RB.

•

In storage, field RBXSB (RB-X'20') points to the XSB and field XSBSEL
(XSB + X' I C') points to the current STKE.

Important fields in the STKE are:
•

STKERET (STKE + X' 18') - contains the return address of the caller of
the PCLINK service.

•

STKEPR15 (STKE+ X'lC') - contains parameter register 15 passed to
the PC routine.

•

STKEPRMO (STKE + X'20') - contains parameter register 0 passed to the
PC routine.

•

STKEPRM 1 (STKE + X'24') - contains parameter register 1 passed to the
PC routine.

•

STKESA (STKE+X'14') - contains the address of the previous save area
passed by the caller of the PC service.

Debugging From Summary SVC Dumps
The summary dump area formatted by the SUMDUMP option of SDUMP
should contain the most current data relevant to the problem present in the dump.
It is strongly recommended that the SUMDUMP output be reviewed prior to
investigating the usual portions of the dump. The SUMDUMP option provides
different output for SVC and branch entries. For example, branch entries
generally dump PSA, LCCA, and PCCA control blocks, and SVC entries
generally dump RTM2WA control"blocks. Each output type is indicated by the
header ,,----tttt--~- RECORD ID X'nnnn'," where tttt is the title for the type of
SUM DUMP output, and nnnn is the hexadecimal record identifier assigned to the
type. The record id values are described in the table below. They are also
described by the IHASMDLR mapping macro in the Debugging Handbook.

Section 2. Important Considerations Unique to MVS

2-89

SUMDUMP Output For SVC-Entry SDUMP
The following table summarizes the SUMDUMP output types for an SVC entry
to SDUMP:
SVC-ENTRY TABLE
Record ID
Dec
Hex
4
46
48
49
53

4
2E
30
31
35

57
58
60

Title

Mapping
Macro
TTE

39

TRACE TABLE
SUMLIST RANGE
REGISTER AREA
PSW AREA
NORMAL DATA END
RTM 2 WORK AREA

3A
3C

RTM2WA TRACE TAB
ASID INFO

TTE

IHARTM2A

Fields used to Dump
PSW or Register Areas

RTM2NXTl
RTM2EREG

For an SVC entry to SDUMP, the SUM DUMP output can contain information
that is not available in the remainder of the SVC dump if options such as region,
LSQA, nucleus, and LPA were not specified in the dump parameters.
For each address space that is dumped, the SUM DUMP output is preceded by a
header with the ASID, plus the jobname and stepname for the last task created in
the address space. The SUMDUMP output contains RTM2 work areas for tasks
in address spaces that are dumped. Many of the fields in the RTM2WA provide
valuable debugging information. (See "Debugging Problem Program ABEND
Dumps" for more details.)
Each RTM2WA is followed by 'RTM2WA TRACE TAB' output (record id
X'3A'), if there is a copy of the system trace table associated with the RTM2WA
(RTM2TRCU, RTM2TRFS, and RTM2TRLS fields are non-zero). The current
entry in the trace table copy is pointed to by RTM2TCRU (offset 37C) in the
associated RTM2 work af(~a. System trace table entries are mapped by the TIE
(Trace Table Entry) section in the Debugging Handbook.
Each RTM2WA is also followed by 'PSW AREA' output (record id X'31'). A
PSW area, consisting of the instruction pointed to by the RTM2NXTI field in the
EC PSW saved in the RTM2WA, and the preceding instruction with length from
the RTM2ILCl field, is dumped if the instructions can be accessed.
After information for all RTM2W As associated with a task is dumped, 'PSW
AREA' (record id X'31') and 'REGISTER AREA' (record id X'30') output
appears. This consists of 2K of storage before and after each valid unique
address pointed to by the PSW and the registers from the time of the error
(RTM2NXTl and RTM2EREG fields) from all the RTM2 work areas. Up to 32
unique addresses can be dumped for each task. Register addresses less than 2K
are not dumped because they are considered to be counters. If the storage that is
2K before and after an address cannot be accessed, a length of 300 bytes is tried.
If that amount of storage cannot be accessed, the address' record entry appears
with a zero length.
'TRACE TABLE' output (record id X'04') appears if the first address space
dumped has no trace table saved in an RTM2 work area and the system trace was

2-90

MVS Diagnostic Techniques

active. The output includes the header (pointers to the current, first, and last
entries) and the entries in the system trace table. System trace table entries are
mapped by the trace table entry (TTE) described in the Debugging Handbook.
'SUMLIST RANGE' output (record id X'2E') appears at the beginning of the
SUM DUMP output if the SUMLIST keyword was specified in the SDUMP
macro instruction.
SUMDUMP Output For Branch-Entry SDUMP
The following table summarizes the SUMDUMP output types from a branch
entry to SDUMP:
BRANCH-ENTRY TABLE
Record ID
Dec
Hex

~

Title

Mapping
Macro

1
2
3

1
2
3

PCCA
LCCA
PSA

IHAPCCA
IHALCCA
IHAPSA

4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

4
5
6
7
8
9
A
B
C
D
E
F
10
11
12
13
14
15
16
17
18
19
IA
IB
lC
ID
IE
IF
20
21
22
23
24
25
26
27
28
29
2A
2B
2C
2D
2E

TRACE TABLE
FRR STACK
GWSA PAGE 10 ERR
GWSA GET/FREEMAIN
GWSARSM
GWSA RSM SUSPEND
GWSA MEM SWITCH
GWSA STATUS
GWSASRM
GWSA MEM TERM
GWSA ENQ/DEQ
GWSA STOP/RESTRT
GWSA IEAVESCO
CWSA LOW-LVL CMN
CWSAGTF
CWSASRM
CWSA TIMER
CWSAACR
CWSA RTM/MACHK
CWSA lOS FLIH
CWSA DISPATCHER
CWSAMFI
CWSAABTERM
CWSA I/O RESTART
CWSASTATUS
CWSA SUPR REPAIR
CWSA RTM-CCH
LWSA LOW@LVL CMN
LWSA VALID'Y CHK
LWSARTM
LWSASDUMP
LWSAABTERM
LWSA CIRB
LWSA STG2 EXT EF
LWSA EXIT (SVC3)
LWSAPOST
LWSA WAIT
LWSASTATUS
LWSA STAE
LWSA EVENTS
LWSARSM
LWSA ASCB CHAP
SUMLIST RANGE

TIE
IHAYSTAK

44

45
46

Fields used to Dump
PSW or Register Areas:

FLCIOPSW, FLCPOPSW
FLCEOPSW, FLCROPSW

-

-

Section 2. Important Considerations Unique to MVS

2-91

BRANCH-ENTRY T ABLE
Record ID
Dec Hex

(ContiDued)~

Title

47
48
49
50

2F
30
31
32

INT HANDLER SA
REGISTER AREA
PSWAREA
GBL WSA VEC TABL

51

33

CPU WSA VEC TABL

52

34

LCL WSA VEC TABL

53
54
55
56
60

35
36
37
38
3C

NORMAL DATA END
CWSAASM DIE
CWSA ASM SRB@I/O
SDWA
ASID INFO

Mapping
Macro

Fields used to Dump
PSW or Register Areas:

IHAIHSA

IHSAGPRS

IHAWSAVT
(WSAVTG)
IHAWSAVT
(WSAVTC)
IHAWSAVT
(WSAVTL)

IHASDWA

SDWAGRSV

The SUMDUMP output for a branch entry to SDUMP might not match the data
that is at the same addresses in the remainder of the dump. The reason for this is
that the SUMDUMP is taken at the entry to SDUMP, and while the processor is
disabled for interrupts. The system data in the remainder of the dump is often
changed because other system activity occurs before the dump is complete. The
SUMDUMP output is preceded by a header with the ASID for the failing address
space.
From a branch entry into SDUMP, the SUM LIST range and trace table output is
handled similarly to that from an SVC entry. However, SUM LIST addresses
must point to areas that are paged-in or they cannot be dumped.
The PSA, LCCA, and PCCA are dumped for each alive processor (record ids
X'03', X'02', and X'OI' respectively).
The interrupt handler save area (IHSA - record id X'2F') is dumped for the
current address space. This save area includes the current FRR stack for
suspended address spaces.
The system diagnostic work area (SDWA - record id X'38') is dumped for the
current error if the RTMI work area is currently valid and being used.
Unique register contents are obtained from the IHSA and the current SDWA.
Each unique register value is used as an address and storage is dumped from 2K
plus and minus this address for a total of 4K each. These 'Register Areas' are
printed with record id X'30'.
The Super FRR Stack (record id X'05'), includIng RTMI work areas are dumped.
The global, local, and processor work save area vector tables (record id ,X'32',
X'34', and X'33' respectively) are dumped. The save areas pointed to by these
save area vector tables are also dumped. The branch-entry table at the beginning
of this description lists the record ids for each work save area.
2K of storage on either side of the address portion of the 1/0 old PSW, the
program check old PSW, the external old PSW, and the restart old PSW saved in

2-92

MVS Diagnostic Techniques

the PSA for all processors, is dumped. These 'PSW Areas' are printed with
record id X'31'.
Note: The SUMDUMP output from a branch entry to SDUMP only contains
areas that were already paged-in when the SUM DUMP was. taken.

Started Task Control ABEND and Reason Codes
In case of an irreparable error, the started task control (STC) routines issue these
ABEND codes:
OB8 -

An error occurred while STC routines were processing a START, MOUNT, or LOGON
command.
In each case, the command task is terminated; for a START or MOUNT command, the STC
routines issue message IEE8241.
The following error codes can appear in register 15 at the time of the ABEND:

OB9 -

04 -

Module IEEPRWI2 or IEFJSWT detected an invalid command code in the CSCB; the
command code was incorrect for a START, MOUNT, or LOGON command.

08 -

Module IEESB605 invoked IEF AB4FC (an Allocation routine) to build a TIOT for
the START, MOUNT, or LOGON task; IEFAB4FC returned control to IEESB605
with a return code indicating failure.

12 -

Module IEESB605 invoked IEFJSWT (an STC routine) to write the internal JCL text
for the START, MOUNT, or LOGON command into system data set; IEFJSWT
returned control to IEESB605 with a return code indicating that it failed in its attempt
to open the data set.

16 -

Module IEEPRWl2 received an undefined return code from the system address space
initialization routine. The defined codes are 0 and 4.

20 -

Module IEEPRWl2 requested a SYSEVENT TRANSWAP (via the POST macro)
and received a nonzero completion code in the ECB. This indicates that the address
space cannot be made nonswappable.

Module IEESB605 invoked the master subsystem via the subsystem interface to determine
whether a START command was issued to start a subsystem; an error occurred during
master subsystem processing.
The command task is terminated; for a START or MOUNT command, IEESB605 issued
message IEE8241.

OBA -

Module IEESB605 invoked the master subsystem via the subsystem interface to determine
whether a START command was issued to start a subsystem; an error occurred during
subsystem interface processing.
The command task is terminated; for a START or MOUNT command, IEESB605 issues
message IEE824I.

Section 2. Important Considerations Unique to MVS

2-93

SWA Manager Reason Codes
In case of an irreparable error, the SWA manager routines issue a OBO ABEND.
Before abending, both object modules IEFQB550 and IEFQB555 place a code in
register 15 indicating the exact cause of the error.
These are the error codes that can appear in register 15.

2-94

04 -

The routine that called SWA manager requested an invalid function.

08 -

The routine that called SWA manager passed an invalid SWA virtual address (SVA). Either the
SVA does not point to the beginning of a SWA prefix or the SWA prefix has been destroyed.

oc -

A SWA manager routine has attempted to read a record not yet written into SWA.

10 -

Either IEFQB550 (move mode module) has attempted to read or write a block which is not 176
bytes or IEFQB555 (locate mode module) has attempted to assign a block with a specified length
of 0 or a negative number.

14 -

The routine that called SWA manager has specified an invalid count field. For move mode, an
invalid count is 0 for a READ, WRITE, or ASSIGN function; an invalid count for
WRITE/ASSIGN is 00.

18 ,.

The routine that called SWA manager by issuing the QMNGRIO macro instruction specified
both or 'neither of the READ or WRITE options.

1C -

The routine that called SWA manager was attempting to write into a SWA block for the first
time; it either passed a nonexistent ID or failed to pass one at all.

20 -

IEFQB555 has attempted to write a block using an invalid pointer to the block.

MVS Diagnostic Techniques

Additional Data Gathering Techniques
This chapter describes additional techniques for gathering data and circumventing
certain system problems. The superzaps should be checked out before they are
applied to your system. Displacements vary according to release level and PTF
activity.
The examples were deliberately kept simple and are designed to illustrate a
technique rather than to be practical in themselves.
CAUTION: Extreme care must be used when you are considering a system
alternation in order to gather additional data about a problem. None of the
Superzaps described in this chapter should be applied before the system
programmer has verified the logic being zapped and the trap logic itself.
Remember if anyone location or offset within the module or trap changes, all
offsets and base registers must be verified.
This chapter contains the following topics:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

Using the CHNGDUMP, DISPLAY DUMP, and DUMP Comrilands
How to Print Dumps
How to Automatically Establish System Options for SVC Dump
How to Copy PRDMP Tapes
How to Rebuild SYSl.UADS
How to Print SYSl.DUMPxx
How to Clear SYSl.DUMPxx Without Printing
How to Print the SYSl.COMWRITE Data Set
How to Print an LMOD Map of a Module
How to Re-create SYSl.STGINDEX
Software LOG REC Recording
Using the PSA as a Patch Area
Using the SLIP Command
System Stop Routine
How to Expand the Trace Table

Using the CHNGDUMP, DISPLAY DUMP and DUMP Operator Commands
A dump obtained from MVS contains those storage areas specified in the dump
request and those defined as system defaults in SYSl.PARMLIB for
SYSABEND, SYSMDUMP, and SYSUDUMP. Normal system defaults are:
SYSABEND:

CB, ENQ, TRT, ALLPA, SPLS, LSQA, PSW, REGS, SA, DM, 10, and ERR

SYSMDUMP:

LSQA, NUC, RGN, SQA, SWA, and TRT

SYSUDUMP:

CB, ENQ, TRT, ALLPA, SPLS, PSW, REGS, SA, DM, 10, and ERR

For an SVC dump, the normal system defaults are SQA, ALLPSA, and
SUMDUMP.

Section 2. Important Considerations Unique to MVS

2-95

The CHNGDUMP command is used to dynamically alter the options specified
originally by SYS1.PARMLIB or by previous CHNGDUMP commands. Dump
mode may be set to ADD, OVER, or NODUMP. System action for each setting
is:
ADD -

merges the options specified on the dump request with the options in the system dump
options list.

OVER -

ignores the options specified in the dump request and uses only the options in the
dump options list.

NODUMP -

ignores the request and does not dump.

To determine the current system dump options, use the DISPLAY DUMP,
OPTIONS command. If an error is made while specifying the CHNGDUMP
command, the system rejects the command and issues an error message.
The topic "How to Automatically Establish System Options For SVC Dump,"
which appears later in this chapter, describes how to·issue the CHNGDUMP
command during IPL. See Operator's Library: System Commands for the format
of the CHNGDUMP command.
The DISPLAY DUMP command is used for the following:
•

To display the effects of the CHNGDUMP command or to determine the
current system dump options. (DISPLAY DUMP, OPTIONS)

•

To determine which dump data sets are full and which are available.
(DISPLAY DUMP,STATUS)

See Operator's Library: System Commands for the format of the DISPLAY
DUMP command.
The DUMP command must be used carefully if the desired dump is to be
obtained. For instance, the following typical error can occur when requesting a
dump. The operator enters DUMP COMM = (title). The system responds with
message IEE094 requesting the dump parameters. If the operator replies 'U' to
this message, the system dumps the current address space which is the master
scheduler address space. The operator must reply with ASID, Jobname, or
TSOname. See Operator's Library: System Commands for the format of the
DUMP command.

2-96

MVS Diagnostic Techniques

How to Print Dumps
The PRDMP control statements can be used to minimize the size of the output
produced from a stand-alone dump and still keep the number of reruns to a
minimum. This section discusses the DD statements and selected control
statements used in the following example:
IIASIDDMP JOB MSGLEVEL=l
II EXEC PGM=AMDPRDMP
IIPRINTER DD SYSOUT=A
IISYSPRINT DD SYSOUT=A
IITAPE DD UNIT=TAPE,LABEL=(l,NL) ,VOL=SER=ABCTPE,DISP=OLD
IISYSUTl DD UNIT=251,SPACE=(CYL,(20,1)),DISP=NEW
11* PRINT STORAGE=ASID(X)=(X,X,X,X,X,X) IS PROPER FORMAT
CVTMAP
CPUDATA
SUMMARY
QCBTRACE
SUMDUMP
LPAMAP
FORMAT
EDIT
PRINT CURRENT,SQA
PRINT STORAGE=ASID(X) = (xxxx,xxxx,xxxx,xxxx)
PRINT JOBNAME=(jobnarnes)
PRINT REAL=(xxxx,xxxx)
ASMDATA
END

See SP L: Service Aids for a complete description of PRDMP DD and control
statements.
The PRINTER DD statement defines the output data set for the dump itself. It
should be directed to a SYSOUT class as shown.
The SYSPRINT DD statement defines the data set for PRDMP messages, etc.
The TAPE DD statement defines the input data set to PRDMP. It can define
one of the SYS1.DUMPxx data sets, a stand-alone dump tape, or a GTF output
data set on either tape or DASD.
The SYSUT1 DD statement defines work space to PRDMP. It can be used to
define the input data set. It is not required if the input data set is defined by the
TAPE DD statement. It does, however, significantly enhance the performance of
PRDMP when it is used in conjunction with the TAPE DD statement and when
the input is a tape data set.
The SPACE parameter is determined by the size of the dump. Generally 5
cylinders or 95 tracks or 285 4104 records should be specified for each megabyte
of real storage dumped by SADMP.
Control Statements

The placement of the control statements determines the sequence in which the
dump is printed. Refer to the "Dump and Trace Formats" section of the
Debugging Handbook for examples of how these statements format a dump.

Section 2. Important Considerations Unique to MVS

2-97

Note: To reduce the volume of output, select only those PRDMP control
statements that provide the desired control blocks and output.

The following statements can be specified with PRDMP:
CVTMAP - formats the CVT and can be an aid in finding other significant
control blocks in the system.
CPUDATA - formats the CSD, PSA, PCCA and LCCA for each active
processor.
SUMMARY - defines and prints the dump ranges of the dump, active processor,
active tasks, etc.
QCBTRACE or GRSTRACE - formats the ENQ/DEQ control blocks in use at
the time the dump was taken.
SUMDUMP -locates and prints the summary dump data provided by SVC
dump. It should be used on all SVC dumps.
LPAMAP - provides a listing of the modules on the link pack area list. It
identifies the entry point address of those modules and their length. It does not
identify SVC modules since they are found by the SVC table.
The FORMAT statement can produce voluminous data depending on the number
of address spaces defined at the time the dump is taken., It produces the.
formatted TCB summary showing the abend completion codes for each TCB in
the system and the global and local SPLs.
The EDIT statement formats and prints the GTF buffers (that is, all internal trace
buffers or those external trace buffers that have not been written to the TRACE
data set) if GTF is active at the time the dump is taken. If GTF is not active,
only an error message is printed.
The PRINT statement can be used several ways:
•

PRINT CURRENT,SQA - should be included in the initial run of PRDMP.
It formats and prints the address space and task-related control blocks of the

address space active at the time the dump is taken. SQA should be printed
for the valuable data it contains such as trace table, and LOGREC buffers.
PRINT CURRENT prints only the current address space of the processor
from which the SADMP program was IPLed;except in cross memory mode,
PRINT CURRENT also includes the home, secondary, primary, and CML
address spaces.

2-98

•

PRINT NUC,CSA - should not be included in the initial run of PRDMP
because of the volume of data it produces. Once a problem is suspected in
this area, the PRDMP program should be rerun specifying only these
parameters.

•

PRINT STORAGE = ASID(x) = (xxxx,xxxx) - should not be included in the
initial run of PRDMP. Once a problem is isolated to an address space or a
range of storage addresses, rerun PRDMP specifying only these parameters.
Several ASIDs and several address ranges can be requested with one run of

MVS Diagnostic Techniques

i~

~

PRDMP. PRDMP does not duplicate address ranges for every ASID but
prints all storage dumped (NUC, CSA, SWA, LPA in storage) if only ASIDs
are specified without address ranges. PRINT STORAGE is useful for
printing SVC dumps. See the discussion "How to Print SYS1.DUMPxx"
later in this chapter.
•

PRINT JOBNAME = Gobnames) - produces output equivalent to PRINT
CURRENT except it prints the private address space of job(s) requested. It
should not be used for the initial run of PRDMP unless the jobname is
known from another source, such as the system log.

•

PRINT REAL = (xxxx,xxxx) - prints real storage in specified address range
pairs. Use this option only when the system cannot find adequate data to
format the dump.

ASMDATA - formats and prints all ASM control blocks. It produces
voluminous data and should not be run until an ASM failure is suspected.

How to Automatically Establish System Options For SVC Dump
A potential problem is that the SVC dumps written to the SYSl.DUMPxx
contains only those address ranges that the FRR or ESTAE routine passes to
SDUMP. When these dumps are subsequently printed by PRDMP, the PRDMP
formatting program might not find sufficient data to format the dump properly.
This can make it difficult to find data in an SVC dump and it can provide
erroneous indicators to the problem solver.
The CHNGDUMP command can be used to alter the SVC dump system options
and provide a complete dump. The following job updates the COMMNDOO
member of SYSI.PARMLIB to issue the CHNGDUMP command automatically
at IPL time. The CHNGDUMP command can also be entered by the operator.
(See Operator's Library: System Commands for a description of the CHNGDUMP
command.)
IIUPDAT JOB ("S,S),MSGLEVEL=l,REGION=lOOK
II EXEC PGM=IEBUPDTE
IISYSPRINT DD SYSOUT=A
IISYSUTl DD UNIT=SYSDA,VOL=SER=SYSRES,DISP=OLD,
II
DSN=SYS1.PARMLIB
IISYSUT2 DD UNIT=SYSDA,VOL=SER=SYSRES,DISP=OLD,
II
DSN=SYS1.PARMLIB
IISYSIN DD DATA
.1 REPL NAME=COMMNDOO,LIST=ALL
.1 NUMBER NEW1=lO,INCR=20
COM=/TRACE ON'
COM='CD SET,SDUMP=(PSA,NUC,SQA,LSQA,RGN,TRT),Q=YES,ADD'
.1 ENDUP

How to Copy PRDMP Tapes
It is sometimes necessary to copy dump tapes to supply another location with a
copy of the dump while retaining your own. It is particularly useful to be able to

supply a dump tape

~ith; an

'APAR.

Section 2. Important Considerations Unique to MVS

2-99

A simple way to do this is to use PRDMP as a copy program. Define the input
tape with the TAPE DD statement and the output tape with.the SYSUT2 DD
statement. It is also possible to put several dumps on oile tape or take one dump
. from a multiple dump tape by manipulating the file number parameters in the
label parameter. The following example shows how this is done:
IIASIDDMP JOB MSGLEVEL=l
II EXEC PGM=AMDPRDMP
IIPRINTER DD SYSOUT=A
IISYSPRINT DD SYSOUT=A
IITAPE DD UNIT=TAPE,LABEL=(2,NL) ,VOL=SER=DMPIN,DISP=OLD
IISYSUT2 DD UNIT=TAPE,LABEL=(,NL),VOL=SER=DMPOUT,
II
DISP=(NEW,KEEP)
IISYSIN DD *
END

1*
After copying a PRDMP tape, a quick run through PRDMP to verify that the
CVT can be formatted and printed. will prove that the copy was successful.
IIADMP JOB MSGLEVEL=l
II EXEC PGM=AMDPRDMP
IIPRINTER DD SYSOUT=A
IISYSPRINT DD SYSOUT=A
IITAPE DD UNIT=TAPE,LABEL=(l,NL),VOL=SER=DMPTPE,DISP=OLD
/ISYSUTl DD UNIT=SYSDA,SPACE=(TRK,(400,20»,DISP=NEW
IISYSIN DD *
CVTMAP
END

1*
Another, and faster way to copy PRDMP tapes is to use the IEBGENER utility
program. The following example shows how this is done:
IICOPYDMP JOB MSGLEVEL=l
II EXEC PGM=IEBGENER
//SYSIN DD DUMMY
IISYSPRINT DD SYSOUT=A
IISYSUTl DD UNIT=TAPE,LABEL=(2,NL),VOL=SER=DMPIN,
II
DCB=(RECFM=FB,LRECL=4104,BLKSIZE=4104)
.
/ISYSUT2 DD UNIT=TAPE,LABEL=(l,NL),VOL=SER=DMPOUT,
II
DCB=(RECFM=FB,LRECL=4104,BLKSIZE=4104)

1*

How to Rebuild SYSl.UADS
The loss of the SYSl.UADS data set can significantly impact a TSO environment.
However, it is possible to run the TMP as a batch job and recreate SYS1.UADS
in the background. The following is an example of a job that has been run
successfully to scratch and recreate a SYS1.UADS data set.

2-100

MVS Diagnostic Techniques

IIBLDUADS JOB MSGLEVEL=l
II EXEC PGM=IEFBR14
IIDD2 DD VOL=SER=SYSRES,DISP=(OLD,DELETE),UNIT=3330,
II DSN=SYSl.UADS
II EXEC PGM=IKJEFTOI
IISYSPRINT DD SYSOUT=A
IISYSUADS DD DSN=SYSl.UADS,DISP=(NEW,KEEP),
II SPACE=(800,(20,9,30» ,UNIT=3330,
II VOL=SER=SYSRES,DCB=(RECFM=FB,
II DSORG=PO,LRECL=80,BLKSIZE=800)
IISYSLBC DD DSN=SYSl.BRODCAST,DISP=SHR
IISYSIN DD *
ACCOUNT
SYNC
ADD (USEROI TSOTEOI * IKJACCOl) UNIT(SYSDA) ACCT OPER JCL MOUNT
ADD (USER02 TSOTE02 * IKJACC02) UNIT(SYSDA) OPER JCL MOUNT
ADD (USER03 TSOTE03 * IKJACC03) UNIT(SYSDA) JCL MOUNT
ADD (USER04 TSOTE04 * IKJACC04) UNIT(SYSDA) JCL MOUNT
ADD (USEROS TSOTEOS * IKJACCOS) UNIT(SYSDA) JCL MOUNT
ADD (USER06 TSOTE06 * IKJACC06) UNIT(SYSDA) JCL MOUNT
ADD (USER07 TSOTE07 * IKJACC07) UNIT(SYSDA) JCL
ADD (USER08 TSOTE08 * IKJACC08) UNIT(SYSDA) JCL
ADD (USER09 TSOTE09 * IKJACC09) UNIT(SYSDA) OPER
ADD (USEROA TSOTEOA * IKJACCOA) UNIT(SYSDA)
ADD (USEROB TSOTEOB * IKJACCOB) UNIT(SYSDA)
ADD (USEROC TSOTEOC * IKJACCOC) UNIT (SYSDA)
LIST (*)
END

1*

How to Print SYSl.DUMPxx
See the discussion under "How to Print Dumps" earlier in this chapter to define
the control statements required. The same rules apply except in this case the
T APE DO statement points to one of the SYSl.DUMPxx data sets. These are
cataloged data sets and require no further definition.
Be aware that the dump data sets contain only those address ranges passed to
SVC dump by the dump requestor and might not contain sufficient data for
PRDMP to properly format all requested control blocks.
Because SVC dumps usually contain a limited number of address ranges, printing
the entire SYS1.DUMPxx data set is feasible and assures that all the information
about the problem will be available.
See the next topic "How to Clear SYS1.DUMPxx Without Printing" for a
description of how to clear the dump data sets for reuse. Note: Printing the dump
data sets does not clear them as it did on previous systems.

Section 2. Important Considerations Unique to MVS

2-101

The following example shows how to print SYS1.DUMPOO:
IIASIDDMP JOB MSGLEVEL=l
II EXEC PGM=AMDPRDMP
IIPRINTER DD SYSOUT=A
IISYSPRINT DD SYSOUT=A
IITAPE DD DSN=SYSl.DUMPOO,DISP=OLD
IISYSUTI DD UNIT=SYSDA,DISP=NEW,SPACE=(CYL,{lO,S»
IISYSIN DD *
SUMMARY
CVTMAP
CPUDATA
SUMDUMP
LPAMAP
PRINT STORAGE

1*

How to Clear SYSl.DUMPxx Without Printing
In previous systems, printing the dump data set also cleared it and made it
available for reuse. In MVS this is no longer true .. The dump data sets can be
cleared at 'SPECIFY SYSTEM PARAMETERS' time during IPL. They can also
be cleared and made available for reuse by using PRDMP to copy the data set to
tape with the SYSUT2 DD statement pointing to the output data set. This must
be a separate job step from printing the dump. If it has been determined that the
SYSI.DUMPxx data set need not be saved, it can be cleared and made available
for reuse by running PRDMP with the SYSUT2 DD statement defined as
DUMMY. The following example shows how to clear SYS1.DUMPOO. See the
example in the discussion "How to Copy PRDMP Tapes" earlier in this chapter
for how to define the SYSUT2 DD statement to unload the SYSI.DUMPxx data
sets.
IIASIDDMP JOB MSGLEVEL=l
II EXEC PGM=AMDPRDMP
IIPRINTER DD SYSOUT=A
IISYSPRINT DD SYSOUT=A
IITAPE DD DSN=SYSl.DUMPOO,DISP=OLD
IISYSUT2 DD DUMMY
IISYSIN DD *
END

Another, and faster way to clear a SYSI.DUMPxx data set without printing is to
use the IEBGENER utility program. The following example shows how to clear
SYSI.DUMPOO:
IICLEARDMP JOB MSGLEVEL=l
II
EXEC PGM=IEBGENER
IISYSIN DD DUMMY
IISYSPRINT DD SYSOUT=A
IISYSUTI DD DUMMY,DCB=SYSl.DUMPOO
IISYSUT2 DD DSN=SYSl.DUMPOO,DISP=OLD,DCB=SYSl.DUMPOO

1*

2-102

MVS Diagnostic Techniques

How to Print the SYSl.COMWRITE Data Set
The following job will format and print the TCAM SYSl.COMWRITE data set.
Note that the PARM fields in the EXEC statement define the traces to be
formatted and printed. See OS/VS TeAM Debugging Guide Level 10 for more
information on the use of the SYSl.COMWRITE data set.
IICOMWRITE JOB MSGLEVEL=l
IISTEPl EXEC PGM=IEDQXB,PARM='STCB,IOTR,BUFF'
IISYSPRINT DDSYSOUT=A
IISYSUTl DD DSN=SYS1.COMWRITE,DISP=SHR

1*

How to Print an LMOD Map of.a Module
The following job produces a module cross-reference of the nucleus, module
IEFW2ISD, and a link pack area map. In addition, AMBLIST produces an IDR
listing or a complete hexadecimal dump of an object module. If you include the
RELOC parameter, the cross-reference listing is based at the address the module
is loaded in LPA.
Note that the JCL must contain a DD statement for every data set containing a
module you referenced in the control card section.
For more information about AMBLIST, see SPL: Service Aids.
IIAMBLIST JOB MSGLEVEL=l
II EXEC PGM=AMBLIST
IISYSLIB DD DSN=SYS1.LPALIB,DISP=OLD
IILOADLIB DD DSN=SYS1.NUCLEUS,DISP=OLD
IISYSPRINT DD SYSOUT=A
IISYSIN DD *
LISTLOAD OUTPUT=XREF,MEMBER=IEANUC01,DDN=LOADLIB
LISTLPA
LISTLOAD OUTPUT=XREF,MEMBER=IEFW21SD

1*

How to Re-Create SYSl.STGINDEX
It is possible for the SYSl.STGINDEX data set to be destroyed because of system
failure or operator intervention during an IPL with the cold start (CLPA,CVIO)
option. Loss of this data set prevents warmstarting the system or restarting jobs
using VIO data sets.

Section 2. Important Considerations Unique to MVS

2-103

The following job can recreate this data set. Remember to change the VOLUME
and CYLINDERS parameters to apply to your system.
IISTGINDEX JOB MSGLEVEL=l

II EXEC PGM=IDCAMS

IISYSPRINT DD SYSOUT=A
IIVOL DD DISP=OLD,UNIT=3330,VOL=SER=SYSRES
IISYSIN DD *
DEFINE SPACE(VOL(SYSRES)FILE(VOL)CYL(7»
DEFINE CLUSTER.,.
(NAME(SYS1.STGINDEX)VOLUME(SYSRES)CYLINDERS(7)KEYS(128)BUFFERSPACE(5120)RECORDSIZE(2041 2041)REUSE)DATA(CONTROLINTERVALSIZE(2048»INDEX(CONTROLINTERVALSIZE(1024»

Software LOGREC Recording
The following JCL defines a two-step job. The first step prints an event history
report for all SYSl.LOGREC records. The second step formats each software,
IPL, and EOD record individually. The event history report is printed as a result
of the EVENT = Y parameter on the EXEC statement of the first step. .It can be
a very useful tool to the problem solver because it prints the records in the same
sequence they were recorded and therefore shows an interaction between hardware
error records and software error records.
IIEREP JOB MSGLEVEL=l
IIEREPA EXEC PGM=IFCEREP1,PARM=/EVENT=Y,ACC=N',
II
REGION=128K
IISERLOG DD DSN=SYS1.LOGREC,DISP=SHR
IITOURIST DD SYSOUT=A
IIEREPPT DD SYSOUT=A,DCB=BL~SIZE=133
IIEREPB,EXEC PGM=IFCEREP1,PARM=/TYPE=SIE,PRINT=PS,ACC=N',
II
REGION=128K
IISERLOG DD DSN=SYS1.LOGREC,DISP=SHR
IITOURIST DD SYSOUT=A
IIEREPPT DD SYSOUT=A,DCB=BLKSIZE=133

1*
See the discussion on LOGREC analysis in the "Use of Recovery Work Areas"
chapter earlier in this section for an explanation of its use and for examples of the
output produced.

Using the PSA as a Patch Area
There are areas in the PSA reserved for future expansion. They can be used for
quick implementation of a trap without having to consider base registers. Check
the mapping of the PSA (lHAPSA) for possible areas to be used. Once an area is
chosen, verify that the value of this storage is zero.
CAUTION: Use extreme. care when you use this method. Patches should be made
only to disabled code unless the patch is completely reentrant. Saving registers

2-104

MVS Diagnostic Techniques

and data in the PSA while the system is enabled could produce unpredictable
results, especially in an MP environment where more than one PSA exists and the
code could be interrupted and subsequently redispatched on the other processor.
Extreme care must be used when considering a system alteration in order to
gather additional data about a problem. No superzaps should be applied before
the system programmer has verified the logic being zapped and the trap logic
itself. Remember, if anyone location or offset within the module or trap changes,
all offsets and base registers .must be verified.

Using the SLIP Command
SLIP (serviceability level indication processing) provides a way of getting
information concerning an error prior to ESTAE or FRR recovery processing.
This is in addition to the information ordinarily supplied by dumping services
during abnormal termination. The SLIP command is also used to establish PER
monitoring for instruction fetch, storage alteration, and successful branch PER
events within a range of virtual addresses. When the requested PER event occurs,
a PER interrupt causes control to be given to the SLIP processor. The purpose of
the SLIP command is to establish SLIP traps that describe the system conditions
which must exist at the time of the error or interrupt so that an action will be
taken.
The SLIP command is usually entered by a system programmer, either at the
console or via the input stream. It can also reside in the COMMNOxx
PARMLIB member. The SLIP command can also be entered as a subcommand
of the OPERATOR command from a TSO terminal or TSO CLIST. Information
about SLIP traps can be displayed by using the DISPLAY operator command.
As long as enough system queue area storage is available, SLIP traps may be
established at any time. The recovery termination manager (RTM) compares the
SLIP trap event qualifiers with the dynamic system conditions at the time of the
error or interrupt. If RTM detects a match, the requested action is taken.
SLIP Event Qualifier Keywords
When specified on a trap, an event qualifier keyword is checked against current
system conditions to determine a match or no match condition. The following
keywords are described in this topic.
ADDRESS
ASID
ASIDSA
COMP
DATA
ERRTYP
JOBNAME

JSPGM
LPAMOD
MODE
PVTMOD
RANGE
RBLEVEL

Because the RTMjSLIP processor runs in one of four environments, the checking
done for each event qualifier keyword is described in terms of the applicable
environment. The four environments are:
RTS

an error has occurred that will cause routing to FRRs.

RT2

an error has occurred while in enabled unlocked task mode which will cause routing to
ESTAEs but not FRRs.

Section 2. Important Considerations Unique to MVS

2-105

RTM

an abnormal address space termination has occurred.

PER

a PER interrupt has occurred.

Note: The names of these four environments are taken from the names of the
modules that call the RTMjSLIP processor; namely IEAVTRTS, IEAVTRT2,
lEAVTRTM, and IEAVTPER.

ADDRESS Event Qualifier Keyword
The checking done for the ADDRESS keyword is:
RTS

the address from the PSW at the time of the error (SDWANXTI) is used in the comparison.

RT2

the RBLEVEL keyword determines which RB is used to get the address (RBPSWNXT) used
in the comparison.

RTM

the address of the instruction that branched to RTM is used in the comparison.

PER

the address of the instruction that caused the PER interrupt (LCCAPERA) is used in the
comparison.

ASID Event Qualifier Keyword
The checking done for the ASID keyword is:
RTS

The PASID of the failing address space (field SDWAPRIM) is used in the comparison.

RT2

ThePASID in the XSB of the RB located from the RBLEVEL keyword -(field XSBPASID) is
used in the comparison.

RTM

The PASID of the address space being terminated is used in the comparison.

PER

The PASID at the time of the interruption is used in the comparison.

ASIDSA Event Qualifier Keyword
The ASIDSA keyword associates an address space with a storage alteration (SA).
ASIDSA is only valid when it is specified with SA on the SLIP command. The
PASID, SASID, HASID, and the S-bit at the time of the interruption are used to
determine the address space where the storage alteration occurred.
COMP Event Qualifier Keyword
The checking done for the COMP keyword is:
RTS

field SDWACMPC is used in the comparison.

RT2

field RTM2CC is used in the comparison.

RTM

the completion code for the address space being terminated (ASCBMCC) is used in the
comparison.

Because many recovery routines change the abend completion code to make it
more specific, the value supplied on the COMP keyword must be the original
value b~fore a recovery routine changes the code. This is because RTMjSLIP
checking is done before processing by the recovery routines.
For example, a SLIP trap will not match if any of the following completion codes
are specified: l1A, 12E, 15D, 15F (reason codes 12 and 16), 200, 212, 25F, 279,

2-106

MVS Diagnostic Techniques

282, 402, 42A, 57D, 6FC, 700, 72A, AOO, BOO, and EOO. Most of these codes
were -originally a program check (OC4) that has been converted to a more specific
value. If you want to specify a program check, use COMP = OC4 or
ERRTYP=PROG. To avoid having the SLIP action occur for all program
checks, you should also specify some other event qualifier such as program name
or module name.
Similarly, specification of 13E or 33E might prevent a trap from matching if these
completion codes occur for any active subtasks associated with a task that is
abending. These secondary abends occur for the purpose of clean-up and
therefore the SLIP processor is not called when they occur.
Note: The SDUMP and ABDUMP dumping programs might cause many OC4
program checks while taking a dump. Therefore, when you specify COMP = OC4
on a trap, you should avoid these unwanted matches by also specifying another
event qualifier, such as MATCHLIM.
DATA Event Qualifier Keyword

The DATA keyword checks data in the system at the time of the error or
interrupt against the data conditions specified in the SLIP trap_ Addressing is
established to the address space specified with the address. Indirect addresses are
resolved by using the registers at the time of the error or interrupt.
For some errors, register contents at the time of error are not valid. In such a
case, if registers are used, the data is considered unavailable and the trap does not
match. Other conditions that can cause the data unavailable situation are: the
address space specified with the address does not exist; data is paged out; or a
pointer. required for an indirect address is paged out.
When data is unavailable, a counter associated with the trap is incremented and
message IEA4131 is sent to the SLIP user. For a PER trap, message IEA4l3I is
issued only the first time that the data unavailable situation occurs~ However, the
counter is made available by displaying the trap. The data unavailable counter is
also part of the SLIP standard, SLIP standard/user, and SLIP DEBUG GTF
trace records.
The SLIP command processor does not perform any reasonability checking on the
data tests requested. For example, the SLIP command processor would allow the
following DATA keyword specification even though its specification prevents the
trap from ever matching.
DATA = (H.CD300,EQ,00,HASID.CD300,NE,00)
The DATA keyword may be used as a validity check for RANGE addresses or
LPAMOD offsets when used on an IF (instruction fetch) or SB (successful
branch) PER trap. For example, if RANGE = (CD300,CD303) is used to
establish the range of addresses for an IF trap, you can ensure that the expected
instruction is being monitored by specifying DATA = (CD300,EQ,47FOB020)
where 47FOB020 is the expected instruction. If the wrong instruction is being
monitored (for example, due to a typing error ora change in the system), the trap
would not match because the DATA keyword does not match. This technique
can be especially useful on traps that take potentially disruptive actions (for

Section 2. Important Considerations Unique t~ MVS

2-107

example, WAIT or RECOVERY actions) in order to ensure the action is taken
only when desired.
ERRTYP Event Qualifier Keyword
. The checking done for the ERRTYP keyword is:
RTS

the RTITENPT field is used in the comparison. The value field RTITENPT of the RTMI
work area indicates the reason for entry into RTMI:
l=PROG
2=REST

3=SVCERR
4=DAT

5=MACH
lO=PGIO

The SLIP processor recognizes an SVC error for SVC 13 as either an ABEND or SVCERR
error and allows a match for the ERRTYP keyword if either is specified.
RT2

the RTM2ERRA field is used in the comparison. The reason for entry into RTM2 is indicated
by flags in the RTM2 work area as follows:
RTM2MCHK = MACH
RTM2ABTM = ABEND
RTM2PCHK=PROG
RTM2TEXC=DAT
RTM2RKEY=RESTART RTM2PGIO=PGIO
RTM2SVCD = ABEND

RTM

an abnormal address space termination (MEMTERM) causes a match.

JOBNAME Event Qualifier Keyword
The checking done for the JOBNAME keyword is:
RTS

if the failing address space has been identified by RTM (field SDWAFMID), both the failing
and current address space job names are tested for a match. The job names pointed to by
fields ASCBJBNI and ASCBJBNS are tested and either job name may match the job name
specified in the trap.
if the failing address space has not been identified, then only the current address space is tested
for a job name match.

RT2

if the failing address space has been identified by RTM (field RTM2FMID), both the failing
and current address space job names are tested for a match. The job names pointed to by
fields ASCBJBNI and ASCBJBNS are tested and either job name may match the job name
specified in the trap.
if the failing address space has not been identified, then only the current address space is tested
for a job name match.

RTM

the job names for the address space being terminated are used in the comparison.

PER

the job names for the current address space are used in the comparison.

Note: The job, logon, or started task named by JOBNAME need not be active
when the trap is set.
JSPGM Event Qualifier Keyword
The checking done for the JSPGM keyword is:
RTS

if a job step program name is available (field JSCBPGMN), it is compared to the job step
program name specified in the trap.
if a job step program name is not available (PSATOLD or TCBJSCBB = 0), the trap will not
match.
if the reason for entry is a DAT error, the trap wi1l not match.

2-108

MVS Diagnostic Techniques

RT2

if a job step program name is available (field JSCBPGMN), it is compared to the job step
program name specified in the trap.
if a job step program name is not available (PSATOLD or TCBJSCBB =0), the trap will not
match.

RTM

the trap will not match because the job step program name in the address space being
terminated is not available.

PER

if a job step program name is available (field JSCBPGMN), it is compared to the job step
program name specified in the trap.
if a job step program name is not available (pSATOLD or TCBJSCBB =0), the trap will not
match.

LPAMOD Event Qualifier Keyword

The checking done for the LPAMOD keyword is:
RTS

the address from the PSW at the time of error (field SDWANXT1) is used in the comparison.

RT2

the RBLEVEL keyword determines which RB is used to get the address (field RBPSWNXT)
to be used in the comparison.

RTM

the address of the instruction that branched to RTM is used in the comparison.

PER

the address of the instruction that caused the PER interrupt (field LCCAPERA) is used in the
comparison. (For additional information, refer to the note under the description of the
RANGE keyword.)

Note: If the name specified on the LPAMOD keyword is an alias of a load
module name, all monitoring is done by SLIP as though the load module name
was specified.

MODE Event Qualifier Keyword

The system mode at the time of error is indicated in the MODE BYTE as follows:
1. ..... .
.1. .... .
.. 1. ... .
... 1 ... .
.... 1.. .
..... 1..
...... 1.
....... 1

MODESUPR
MODEDIS
MODEGSPN
MODEGSUS
MODELOC
MODETYPI
MODESRB
MODETCB

Supervisor control
Physically disabled
Global spin lock held
Global suspend lock held
Locally locked
Type I SVC
SRB mode
Task mode (unlocked)

The checking done for the MODE keyword is:
RTS

as a part of error processing, RTM determines the mode of the system (MODEBYTE value in
field RTIWMODE). Also, the PSW at the time of the error (field SDWAECl) is examined to
determine key and state. The SDWASTAF bit indicates if the error occurred while a recovery
routine was in control. The PASID at the time of the error (SDW APRIM) is compared to the
HASID. If they are equal, the instruction executed in home mode.

RT2

the system mode, as determined by RTM, is obtained from the ABEND SVRB extended save
area (MODEBYTE value in field ESAMODE). Also, the PSW (field RBOPSW) in the RB (as
determined byRBLEVEL processing) is examined for key and state. The RTM2RECR and
RTM2XIP bits indicate if a recovery routine was in control at the time of error. The PASID
at the time of the error (obtained by the RBLEVEL keyword, field XSBPASID) is compared
to the HASID. If they are equal, the instruction executed in home mode.

Section 2. Important Considerations Unique to MVS

2-109

RTM

because RTM has not determined the system mode for an address space termination, various
fields are tested by the RTM/SLIP processor to determine the system mode at the time of the
MEMTERM request. (The mode will always indicate supervisor state and system key because
these are requirements for issuing a MEMTERM request.)

PER

various fields are tested to determine the system mode at the time of the interrupt. In the
SLIP trace record (system mode indicators), all bits are filled in. However, no attempt is made
to determine if a recovery routine was in control when the interrupt occurred. Therefore, the
recovery-routine-in-control bit will always be zero for a PER interrupt. Because of this,
MODE = RECV is invalid for a PER trap and if MODE =ALL is specified for a PER trap,
ALL does not include RECV (recovery-routine-in- control). If the PASID and HASID are
equal at the time of the interruption, the home mode indicator is set.

PVTMOD Event Qualifier Keyword

The checking done for the PVTMOD keyword is:
RTS

if RTM has identified a failing address space (field SDWAFMID) and it is not current, the
trap will not match.
to check for a private area module, the local lock must be obtained. If it cannot be obtained,
the trap will not match. If the local lock is already held, the chain that is to be searched for a
private area module may be in the process of being changed. The search is performed, but the
results may not be valid. The address obtained from the PSW at the time of error (field
SDWANXTI) is used in the comparison.

RT2

the RBLEVEL keyword determines which RB is used to get the address (field RBPSWNXT)
used in the comparison.

RTM

this keyword test will not match because the private area chain in the failing address space is
not available for searching.

PER

the trap will not match for the PVTMOD keyword test if the interrupt occurs in the nucleus or
FLPA because these areas cannot contain private area modules.
to check for a private area module, the local lock must be obtained. If it cannot be obtained,
the trap will not match. If the local lock is already held, the chain that is to be searched for a
private area module may be in the process of being changed. The search is performed, but the
results may not be valid. The address of the instruction that caused the PER interrupt (field
LCCAPERA) is used in the comparison.

If offsets are specified on the PVTMOD keyword, the RTMjSLIP processor does
not check to make sure that the offsets define an area wholly within the private
area module.
RANGE Event Qualifier Keyword

The checking done for the RANGE keyword is:
PER

the address of the instruction that caused the PER interrupt (field LCCAPERA) is used in the
comparison. Note that if the first address specified is greater than the second, the monitored
range wraps storage addresses.

Note: For successful branch monitoring, hardware PER processing does not
check the address range specified on the RANGE and LPAMOD keywords. This
means that a branch taken by an instruction anywhere in the system would cause
a successful branch PER interrupt. However, to simulate an address range for
successful branch monitoring, SLIP initially sets up instruction fetch monitoring
for the desired address range. Then when instruction processing enters the
requested range (indicated by an instruction fetch PER interrupt), PER
monitoring is automatically switched to successful branch mode. You should be
aware that the first PER event that occurs when instruction processing enters the

2-110

MVS Diagnostic Techniques

requested range may not be a successful branch event. This "extra" event
(instruction fetch) may affect values supplied for other keywords such as
MATCHLIM. When instruction processing leaves the requested range, PER
monitoring returns to instruction fetch monitoring on the requested range to
avoid unnecessary PER interrupts. If the instructions being monitored are
enabled for I/O and/or external interrupts, control may leave and then re-enter
the monitored range due to normal interrupt processing.
The previous note applies to processing on behalf of a non-IGNORE successful
branch PER trap. Mode switching does not occur for successful branch PER
traps with ACTION = IGNORE specified. This means that if the initial entry into
a monitored area matches an IGNORE trap, the mode remains instruction fetch
and the "extra" event is delayed. Also, output that appears to be a contiguous
successful branch trace may not actually be contiguous if an IGNORE trap
matches intermittently.
For successful branch monitoring, if an EXECUTE instruction has a successful
branch target, the location of the EXECUTE instruction is used to determine
whether or not the branch was within the monitored area without regard to the
location of the executed branch.
RBLEVEL Event Qualifier Keyword

The RBLEVEL keyword applies only to enabled unlocked task mode errors. It is
used to direct the SLIP processor to the registers and PSW of interest for a
particular error. The SLIP processor will use the PSW identified by the
RBLEVEL keyword when processing the LPAMOD, PVTMOD, ADDRESS, and
MODE keywords. The SLIP processor will use the registers identified by the
RBLEVEL keyword when processing the DATA, TRDATA, LIST, and
SUM LIST keywords.
The following diagram shows which RBs are chosen by the three RBLEVEL
keyword options for an example RB chain.
PREVIOUS

TeB

SVRB

r--------~~--------~,
-

...

v---

PSW

PSW

REGS

The RBLEVEL keyword can be used in an error situation where several nested
services are involved. For example, program A calls service B which calls service
C. If an error occurs in service C, the default RBLEVEL = ERROR can be used
to qualify the error or obtain information concerning the error. However, if the
error in service C is the result of incorrect input supplied by service B or program
A, the RBLEYEL=PREVIOUS or RBLEVEL=NOTSVRB can be used to

Section 2. Important Considerations Unique to MVS

2-111

qualify the error or obtain information concerning the input supplied by service B
or program A respectively.
Using the ACTION Keyword

The ACTION keyword is used to specify the action to be taken when a SLIP trap
matches the specified system conditions. The following ACTION options are
described in this topic:
ACTION = SVCD
ACTION = WAIT
ACTION = TRACE
ACTION =TRDUMP
ACTION = NODUMP
ACTION = IGNORE
ACTION Keyword

• schedule an SVC dump.
• put the system in a wait state.
• write a GTF trace record.
• write a GTF trace record and then schedule an SVC dump.
• suppress dump requests.
• take the IGNORE action.
• with RECOVERY option (PER traps only), initiate recovery processing.

ACTION = SVCD Option

ACTION = SVCD indicates that an SVC dump will be scheduled for the failing or
home ASID. This is the default option if ACTION is not specified. If the SVC
dump cannot be taken, message IEA412I is issued and SLIP processing continues.
No attempt is made to reschedule the SVC dump.
One of the advantages of the SVC dump over one taken by a recovery routine is
that nothing has been done to correct the error situation. Although the bulk of
the SVC dump is not taken until later, the summary dump portion preserves as
much volatile data as possible. An SVC dump also contains more data (for
example, more than one address space can be dumped) than a SYSABEND or
SYSUDUMP, and because it is machine readable, it can, if necessary, be copied
onto a tape to accompany an APAR, or used with interactive dump display
programs. SYSMDUMP also provides a machine readable dump. The biggest
advantage is in situations where no dump was occurring.
When ACTION = SVCD is specified or defaulted, the default SDATA parameters
are: SQA, RGN, TRT, LPA, CSA, NUC, ALLPSA, and SUM. These default
SDATA parameters are affected by the current CHNGDUMP command settings
which may add to or override the requested dump options. The SDATA
parameters can be changed by the SLIP user. Refer to "Dump Tailoring" later in
this section.
If an SVC dump is already in progress, another dump cannot be taken and
message IEA412I is issued. When an SVC dump is scheduled on behalf of a SLIP
trap by the SLIP processor, debugging information is placed in the SDUMP 4K

2-112

MVS Diagnostic Techniques

buffer (if the buffer is available). This buffer is pointed to by field CVTSDBF
and contains:
Offset

Length

Content

0(0)
4(4)

4
4

8(8)
12(C)
16(10)
20(14)
84(54)
88(58)
96(60)
100(64)
102(66)
106(6A)
108(6C)

4
4
4
64
4
8

The characters 'TYPE' to identify the following field.
RTM/SLIP processor environment indicator:
X'OOOOOOOI' - RTS
X'0000OO02' - RT2
X'00000003' - RTM
X'00000004' - PER
The characters 'CPU' to identify the following field.
Logical CPUID.
The characters 'REGS' to identify the following field.
Registers at the time of error or interrupt. (RO-RI5)
The characters 'PSW' to identify the following field.
The PSW at the time of error or interrupt.
The characters 'PASD' to identify the following field.
The primary ASID at time of error or interruption.
The characters 'SASD' to identify the following field.
The secondary ASID at time of error or interruption.
The SDWA if offset 4 is 1 (RTS).
The RTM2WA if offset 4 is 2 (RT2).
The ASCB if offset 4 is 3 (RTM).
The PER interrupt code if offset 4 is 4 (PER).

4

2
4

2
variable

When a summary dump is requested, the storage on either side of the addresses in
the registers used are from the SDUMP 4K buffer. You can use the SUMLIST
keyword in the form: OR 0/0-800, + 1000,1R 0/0-800, + 1000,2R %-800, + 1000, ... to
dump 2K bytes of information on either side of the addresses in the registers at
the time of the error or interrupt.
If ASIDLST is not specified with the SLIP trap, the following information
describes which address space will be dumped depending on the environment of
the RTM/SLIP processor.
RTS

the failing address space (field SDWAFMID) or the home address space is dumped.

RT2

the failing address space (field RTM2FMID) or the home address space is dumped.

RTM

the master address space is dumped because the address space that is terminating cannot be
used to take the dump. The summary dump information is collected in the home address
space (of the issuer of the CALLRTM TYPE=MEMTERM macro), and the asynchronous
dump runs later in the master address space.

PER

the home address space is dumped.

If a dump request for a failing address space fails (such as SDUMP returning a
bad return code), then a second attempt is made to schedule a dump in the home
address space. In the second attempt, no information is put in the SDUMP 4K
buffer. If the second attempt fails, the message IEA412I is issued.
If a summary dump is requested, it may be suppressed under certain conditions.
Refer to the topic "Placement of PER Traps" later in this section.
The entire dump may be suppressed if the operator has chosen the CHNGDUMP
NODUMP option.
ACTION = WAIT Option
ACTION = WAIT indicates that the system will be placed in an 01B wait state.

Section 2. Important Considerations Unique to MVS

2-113

If a PER.trap is used to put the system into the wait state, the time spent in the
wait state is attributed to the PER interrupt that caused the wait state. This
makes it look as though a lot of time has been spent processing PER interrupts.
Therefore, if the trap is intended to be used so that the system is restarted and the
trap is to remain enabled, you may want to use PRCNTLIM = 99 on the trap.
Otherwise, the trap .may be disabled after the system has been restarted. Use
PRCNTLIM = 99 with caution because limit checking is not performed while
waiting for the trap to match.
Once in the wait state, you can use the debugging work area provided by SLIP to
begin debugging a problem. This area is pointed to by PSA + X'40C' and
contains:
Offset

Length

Content

1(1)
3(3)

2
1

RTM/SLIP processor environment indicator:
X'Ol' - RTS
X'02' - RT2
X'03' - RTM
X'04' - PER
Logical CPUID.
System mask (if offset 0 is 2).

4(4)

4

Pointer to registers at the time of error or interrupt. (RO-RIS)

8(8)
12(C)

4
4

Pointer
Pointer
Pointer
Pointer
Pointer

16(10)

4

Pointer to cross memory information (control registers 3 and 4) at the time of
the error or interruption.

0(0)

to
to
to
to
to

PSW at the time of error or interrupt.
SDWA if offset 0 is 1.
RTM2WA if offset 0 is 2.
ASCB being terminated if offset 0 is 3.
PER code if offset 0 is 4.

ACTION = TRACE Option
ACTION = TRACE indicates that a GTF SLIP trace record is written each time
that the SLIP trap matches. GTF must be active and the GTF SLIP option
specified in order for the record to be built and recorded. (Use the TRDATA
keyword if you want to tailor the GTF trace records.)
The TRACE option is designed for those situations where a relatively small
amount of data is required each time that a matching event occurs. Such a
situation might occur when you are trying to determine the path through a
module. But the TRACE option can handle a relatively large amount of data
when required. Refer to the TRDATA keyword.
The registers at the time of the error or interrupt are used to resolve indirect
addresses specified for the trace record fields. Under some circumstances,
registers at the time of error may not be available. If this is the case, indirect
addresses that contain a register value cannot be resolved and related fields
cannot be collected. A zero length field is -used in the user portion of a SLIP
standard/user or SLIP user record to indicate that the requested field was not
available. Also, a field is not available if it is paged out or if one of the pointers
to it is paged out. When using indirect addresses, use the REGS keyword to get
the contents of the registers used to resolve indirect addresses.

2-114

MVS Diagnostic Techniques

Checking for too much data is done at the time that the GTF SLIP trace record
is built, not at the time the trap is entered. Therefore, you may want to exceed
the trace record size when setting a trap if you expect that some of the data will
not be available. If data is unavailable, trap information takes up only one byte
in the record rather than the amount of space it would take if data were available.
When using this technique, prioritize the fields so that the most important fields
are earliest in the record so that they are collected. If all the data is available,
and the maximum size of the trace record is exceeded, the record is truncated.
Another technique that is useful when using long indirect addresses is to request
the same field twice if there is more than one path to the field. In this way, if a
P9inter is bad or is paged out in one path to the data, it may be-available via the
other path.
GTF Considerations: When using ACTION = TRACE, be aware that starting
GTF will suppress the system trace (if it is active). Therefore, you may want to
choose other GTF trace options in addition to SLIP to obtain other valuable
diagnostic data that is available in a trace of system events. GTF options SYS or
SYSM can be used to have GTF collect information similar to that collected by
the normal system trace. Note that using the internal GTF trace instead of the
external trace helps to reduce system overhead. Be sure to stop GTF after the
traps which require the TRACE option are disabled or deleted.
ACTION =TRDUMP Option
ACTION = TRDUMP is a combination of the SVCD and TRACE options.
While the trap remains enabled, a GTF SLIP trace record is written when the
trap matches. When the trap is disabled (automatically by MATCHLIM or
PRCNTLIM or via the SLIP MOD operand) or deleted (via the SLIP DEL
operand), a dump is scheduled. When you use the SLIP MOD or DEL operand
to disable or delete a trap that has the TRDUMP option specified, the dump does
not contain diagnostic data in the SDUMP 4K buffer.
The default SDATA parameters are TRT, NOSQA, NOALLPSA, and NOSUM.
These default are affected by the current CHNGDUMP command settings which
may add to or override the requested dump options. The SDAT A parameters can,
be changed by the SLIP user. Refer to "Dump Tailoring" later in this section.
When u~ed in conjunction with the MATCHLIM keyword, the TRDUMP option
can be useful in getting an idea of what events lead up to an error. For example~
a problem is narrowed to a particular module. You could use a successful branch
PER trap and the TRDUMP option. The trace records that are written could
trace the fields that are critical to the operation of the module. An estimate of
the number of successful branches that would enable you to determine the path
through the module could be specified on the MATCHLIM keyword in order to
automatically disable the trap and initiate the dump.
The TRDUMP option can also be used to obtain GTF SLIP trace records
without tracing to an external data set (and then using PRDMP to print the data
set). When starting GTF, specify the number of 4K GTF trace buffers (on the
BUF parameter) to be saved for a dump. When the dump is taken, the trace
records are passed to the SVC dump routine and become a part of the dump.

Section 2. Important Considerations Unique to MVS

2:-115

ACTION = NODUMP Option
ACTION = NODUMP indicates that SLIP is to set a flag in the RTM work area
which is checked by the dump programs ABEND and SVC dump. If the bit is
on, all dtmlP requests are ignored. Because the bit is in the RTM work area, only
dumps requested during processing of this error by RTM (requested by an FRR
and/or an ESTAE) are suppressed. Should the error involve recursive entry into
RTM, the bit setting is propagated to the next RTM work area.
ACTION = NODUMP applies only to non-PER traps for errors in the RTS and
RT2 environments.
This action is useful for preventing dumps that may not be needed (for example,
X37, etc.) because accompanying messages provide sufficient information. It can
also be used to prevent duplicate dumps for known problems which have already
been documented.
ACTION = IGNORE Option
ACTION = IGNORE indicates that the SLIP processor is to take the IGNORE
action. The IGNORE action does not result in any specific action being taken
but a match is indicated for the trap and other processing for the trap occurs
normally (such as messages being issued, and processing for the MATCHLIM,
PRCNTLIM, RECOVERY, and DEBUG options).
This option is generally used on a trap to prevent a different, and more general
trap, from matching. (Note that for any event, the SLIP processor stops
examining SLIP traps for a match condition when a matching trap is found.)
Because SLIP traps are tested in last-in-first-out order, IGNORE traps used in
this way must be entered after the more general non-IGNORE trap. Also, the
traps should be specified in the disabled state to prevent the non-IGNORE trap
from matching while the IGNORE traps are being specified. After the
non-IGNORE and all related IGNORE traps have been set, they can be enabled
in a last-in-first-out order by using the MOD operand of the SLIP command.
For PER traps, the IGNORE trap must be of the same type (IF, SA, or SB) as
the non-IGNORE trap or it will not be tested. For IF and SB PER traps,
IGNORE traps can be used to simulate multiple ranges for monitoring as shown
in Example 14 in the following topic "Examples of Using the SLIP Command."
This technique cannot be used for SA PER traps. The use of the IGNORE trap
with a more general IF or SB PER trap does not prevent PER interrupts from
occurring in the range specified on the IGNORE trap. You should consider this
when you are selecting a percent limit value.
In general, there is no limit to the number of IGNORE traps that can be set to
work in conjunction with a non-IGNORE trap. You should be aware that
IGNORE traps are considered as independent traps, and the SLIP command
processor does not know when IGNORE traps are being used in conjunction with
a non-IGNORE trap. For example, at the time a trap is being set, no checking is
done between traps to ensure that the range to be ignored falls within the range
specified on the non-IGNORE PER trap. Such checking is the responsibility of
the user.

2-116

MVS Diagnostic Techniques

ACTION Keyword With RECOVERY Option (PER Traps Only)

Normal processing of a PER interrupt causes control to be returned to the next
sequential instruction after the PER interrupt is processed. The RECOVERY
keyword can be used to force recovery processing to be initiated after the PER
interrupt has been processed.
The RECOVERY keyword is used to initiate recovery processing in those
situations when an error is occurring, but the error is not being detected by the
system or it is being detected too late for recovery routines to adequately handle
the error situation. By initiating recovery processing via a SLIP trap, you have a
way to use the error correction function that is built into MVS recovery routines.
To avoid unexpected results when using the RECOVERY keyword, you should be
thoroughly familiar with the MVS recovery concepts and ensure that:
•

Recovery is initiated at an appropriate point in the program.

•

The recovery routine is designed to handle the error situation that exists at
that point.

The RECOVERY action initially causes an 06F abend code to be generated.
Dump Tailoring

When ACTION = SVCD or ACTION = TRDUMP is specified on a SLIP trap,
the ASIDLST, SDAT A, SUM LIST, and LIST keywords can be used to tailor the
dump to the particular problem that is being trapped.
ASIDLST Keyword

The ASIDLST keyword is used to specify the address spaces that are to be
dumped. Note that a specification of zero indicates the home address space
(pointed to by PSAAOLD).
SDATA Keyword

The SDAT A keyword is used to specify the system data areas that are to be
dumped. If the default SDAT A specification is used, the current system
CHNGDUMP setting can affect (add to or override) the areas requested. The
system CHNGDUMP settings do not affect (add to or override) the areas
specified on SDATA except when CHNGDUMP has been set with the
NODUMP option. In t~is case, the SLIP trap does not produce a dump when
the trap matches.
When SDATA is specified, the areas specified to be dumped completely replace
the default specification on the dump request. For example, on an
ACTION = SVCD dump, if SDATA = (NOSQA) is specified, the NOSQA
completely replaces the default SDATA specification of SQA, RGN, TRT, LPA,
CSA, NUC, ALLPSA, and SUM. The dump request of NOSQA is presented to
SDUMP which merges it with its own defaults (SQA, SUM, and ALLPSA) and,
in this case, produces a dump that contains only a summary dump and ALLPSAs.

Section 2. Important Considerations Unique to MVS

2-117

Also, the SLIP command processor does not make any reasonability checks on
the SDATA options specified. For example, SDATA=(SQA,NOSQA) is allowed
even though the SQA and NOSQA options are contradictory. In this case, SQA
would not be part of the dump produced.
SUMLIST and LIST Keywords
The SUMLIST and LIST keywords are used to dump user-defined areas of
storage. The storage areas are defined by specifying address space qualifiers
followed by address pairs that specify the beginning and ending addresses of
storage to be dumped. Address space qualifiers can be either explicit or symbolic.
They specify the address space to which the address pairs refer to. If a qualifier is
not specified, the previous qualifier is used as the default. If the first address pair
does not have a qualifier, CURRENT is used as the default. The beginning
address must be less than or equal to the ending address. If the beginning address
is greater, then the characters *AI > A2* are dumped instead of the requested
area. Direct or indirect addresses can be used to specify the address pairs and can
be mixed. Indirect addresses are resolved using the registers at the time of error
or interrupt. If for any reason an indirect address cannot be resolved, the
characters *RC = 4* are dumped rather than the requested area.
The difference between SUMLIST and LIST is the point in time when the
requested information is collected. SUMLIST collects information as a part of
SDUMP summary dump processing. This is close to the time of error or PER
interrupt and the information that is collected will probably be unchanged since
the time of error or interrupt. (Note that storage areas must be paged in; and if
not paged in, they are ignored by SDUMP.) LIST collects information when the
scheduled dump is processed. (Note that storage areas are paged in if necessary.)
This is some time after the error or interrupt and the information that is collected
may have been changed since the time of error or interrupt.
Examples of Using the SLIP Command
The following examples briefly describe a system problem and show the SLIP
command that can be used to match on a system event. The resulting dump or
GTF SLIP record can then be used by the debugger to obtain diagnostic
information in order to solve the problem.
Example 1: Match on Storage Alteration
Problem: An unknown program is incorrectly modifying location CD30 lOin the
LPA.
Action: The debugger sets the following SLIP trap:
SLIP SET,SA,ENABLE,ACTION=SVCD,
RANGE=(CD3010),END

Result: When location CD3010 is altered, a SLIP match occurs and an SVC
dump is scheduled. For this PER trap, MATCHLIM defaults to 1 which
prevents a dump from being taken each time that location CD3010 is altered.

2-118

MVS Diagnostic Techniques

Example 2: Match on Storage Alteration
Problem: Same as Example 1 exceptlocation CD3010 is normally modified by
JES2 (ASID = 3) but should not be modified by any other program (in ASIDs 1,
2, 4, 5, 6, 7, 8, and 9).
Action: The debugger sets the following SLIP trap:
SLIP SET,SA,ENABLE,ACTION=SVCD,
RANGE=(CD3010),ASID=(1,2,4,5,6,7,8,9),END

Result: When any program in an address space specified on ASID = alters
location CD3010, a SLIP match occurs and an SVC dump is scheduled.

Example 3: Match on Storage Alteration
Problem: Same as Example 2 except there is an unknown number of address
spaces (in addition to JES2 in ASID 3).
Action: An IGNORE trap is used in conjunction with the non-IGNORE PER

trap. The debugger sets the following SLIP traps:
SLIP SET,SA,ID=TRPl,DISABLE,ACTION=SVCD,
RANGE=(CD3010),END
SLIP SET,SA,ID=TRP2,DISABLE,ACTION=IGNORE,
ASID=(3) ,END

Then issues the following SLIP commands:
SLIP MOD,ENABLE,ID=TRP2
SLIP MOD,ENABLE,ID=TRPI

Result: Any alterations to location CD3010 by JES2 (ASID = 3) are ignored.
Alterations to location CD3010 by programs in any other address space result in
a SLIP match, and an SVC dump is scheduled. Note that the SLIP traps are
inspected in a last-in-first-out (LIFO) order.

Example 4: Match on Storage Alteration
Problem: Location CD30 10 contains an address that is normally modified by
many programs. Intermittently, it is set to zero and causes an error.
Action: The debugger sets the following trap:
SLIP SET,SA,ENABLE,ACTION=SVCD,
RANGE=(CD3010),DATA=(CD3010,EQ,OOOOOOOO),END

Result: When location CD3010 is set to zero, a SLIP match occurs and an SVC
dump is scheduled.

Section 2. Important Considerations Unique to MVS

2-119

Example 5: Match on Instruction Fetch
Problem: An LPA routine is consistently abending and the debugger does not

know if the routine is in error or it is being passed bad parameters. The LPA
routine entry point is CD3IOO.
Action: The debugger sets the following SLIP trap:
SLIP SET,IF,ENABLE,ACTION=SVCD,
RANGE=(CD3100) ,END

Result: The routine still abends. However, when entry is made to the routine at
location CD3IOO, a SLIP match occurs and an SVC dump is scheduled.
Information in the SVC dump allows the debugger to determine the validity of
the parameter data.

Example 6: Match on Successful Branch
~nstruction path taken
through module MODOI starting at offset X'I08' through X'4FC' during the
execution of the JOBX.

Problem: The debugger needs a "branch trace" of the

Action: GTF must be active with the GTF trace option SLIP and MODE = EXT
specified in order to collect the GTF SLIP trace records in an external data set.
The debugger sets the following SLIP trap:
SLIP SET,SB,ENABLE,ID=PERl,ACTION=TRACE,
LPAMOD=(MODOl,108,4FC),JOBNAME=JOBX,
MATCHLIM=20,END

Result: When 20 successful branch events have occurred during the execution of
MODal when JOBX is in control, the trap is automatically disabled because
MATCHLIM = 20. T)1e collected GTF SLIP standard trace records may be
printed by the debugger via the EDIT function of the AMDPRDMP service aid.

Example 7: Match on Successful Branch
Problem: For Example 6, if the debugger wants to collect the GTF SLIP
standard trace records in GTF's address space and obtain these records as a part
of an SVC dump, then GTF must be active with GTF trace option SLIP and
MODE = INT specified.
Action: The debugger sets the following SLIP trap:
SLIP SET,SB,ENABLE,ACTION=TRDUMP,
LPAMOD=(MODOl,108,4FC),JOBNAME=JOBX,
MATCHLIM=20,END

Result: When 20 successful branch events have occurred in the range of addresses
from 108 to 4FC in MODO! while JOBX is in control, an SVC dump is
scheduled. The dump contains the GTF trace buffers (assuming the SDUMP
TRT trace option is in effect). The number of GTF buffers dumped is determined
by the BUF parameter on the GTF START command. Note that if the
CHNGDUMP command has been invoked, then the latest areas defined by
CHNGDUMP are dumped.

2-120

MVS Diagnostic Techniques

Example 8: Match on Instruction Fetch
Problem: The debugger needs to collect specific data (as a part of a summary
dump) when the instruction at offset X'200' in MOD02 is executed in ASID 27.
Action: The debugger sets the following trap:
SLIP SET,IF,ENABLE,ACTION=SVCD,
LPAMOD=(MOD02,200) ,ASID=(27),
SUMLIST=(2R%%,2R%%+DCF,4R%%+28,4R%%+lC9) ,
SDATA=SUMDUMP,MATCHLIM=l,END

Result: When the instruction at offset X'200' in module MOD02 is executed in
ASID 27, the selected data (specified on SUM LIST) is gathered. Control will
resume at the next sequential instruction after the point of interrupt.
Additionally, the trap is disabled after a single match occurs because
MATCH LIM = 1.
Note: To obtain the same data, the SUMLIST keyword could have been
specified as:
SUMLIST=(2R%%,+DCF,4R%%+28,+lC9),

Example 9: Match on Program Check
Problem: The debugger wishes to take a dump of the current private region when
an OC7 program check occurs during task mode processing in module MOD03.
Action: The debugger sets the following SLIP trap:
SLIP SET,ENABLE,ERRTYP=PROG,ACTION=SVCD,
COMP=OC7,PVTMOD=MOD03,MODE=TCB,
SDATA=RGN,END

Result: When the OC7 program check occurs in TCB mode, the trap matches and
an SVC dump is scheduled. Normal recovery processing then takes place.

Example 10: Match on Completion Code
Problem: The debugger wishes to take an SVC dump when a 806 completion
code occurs for a job TEST99 when program PGM5 is in control.
Action: The debugger sets the following trap:
SLIP SET,ENABLE,COMP=806,ACTION=SVCD,
JOBNAME=TEST99,JSPGM=PGM5,END

Result: When the job step that executes program PGM5 of job TEST99 is
abended with a completion code of 806, the trap matches and an SVC dump is
scheduled.

Section 2. Important Considerations Unique to MVS

2-121

Example 11: Match on SVC Error
Problem: The debugger wishes to f'>rce the system into a wait state when an SVC
error occurs in job TEST98 to take a stand-alone dump.
Action: The debugger sets the following trap:
SLIP SET,ENABLE,ERRTYP=SVCERR,ACTION=WAIT,
JOBNAME='l'EST98 , END

Result: When job TEST98 encounters an SVC error, all processors in the system
are put into the wait state. The operator may then initiate a Stand-alone dump
(SADMP).

Example 12: Mat~h on Data
Problem: The debugger wishes to force entry into recovery processing for LPA
module MODX when MODX is processing a specified input (X'0105').
Action: The debugger sets the following SLIP trap but does not start GTF:
SLIP SET,IF,ENABLE,ACTION=(TRACE,RECOVERY),
LPAMOD=(MODX,16) ,DATA=(lR%,EQ,OlOS),
MATCHLIM=l,END

Result: When the input parameter pointed to by general purpose register 1 is
equal to X'0105', the trap matches and the SLIP processor forces the recovery
path to be taken. Because GTF is not active, no trace record is written. The trap
is then disabled because MATCH LIM = 1.

Example 13: Match on Storage Alteration
Problem: The ·debugger wants to monitor a common storage location in a
production system for alteration to X'FIF2F3F4'.
Action: To keep the trap overhead to a minimum, the debugger specifies the
JOBNAME and ASID keywords. Also, because the trap is being set on a
production system, the PRCNTLIM keyword is specified to prevent the
trap from using more than 200/0 of the available system processing time. The
debugger sets the following trap:
SLIP SET,SA,ENABLE,ACTION=SVCD,
ASID=(7,9),JOBNAME=JOBX,
RANGE=(CD3100,CD3103),
DATA=(CD3100,EQ,FIF2F3F4),
PRCNTLIM=20,END

Result: When the specified area is altered by JOBX in ASID 7 or 9 and the
pattern of data is X'FIF2F3F4', then the trap matches and an SVC dump is
scheduled. The processing time used by the PER interrupts is being monitored
and if the time exceeds 20%) of the available system time, the trap is disabled and
the debugger is notified.

2-122

MVS Diagnostic Techniques

Example 14: Match on Instruction Fetch
Problem: The debugger wants to monitor a range of instruction addresses in LPA
module MODX but ignore instructions that form an iterative loop within a subset
of this range.
Action: The debugger sets the following traps:
SLIP SET,IF,DISABLE,ID=TRP1,ACTION=TRACE,
LPAMOD=(MODX,110,lFB),JOBNAME=JOB1,
TRDATA=(STD,REGS),MATCHLIM=500,END
SLIP SET,IF,DISABLED,ID=TRP2,ACTION=IGNORE,
LPAMOD=(MODX,lC4,lD7),END

Then the debugger issues the following SLIP commands:
SLIP MOD,ENABLE,ID=TRP2
SLIP MOD,ENABLE,ID=TRPl

Result: PER interrupts are taken for each instruction that is executed within the
range specified on trap TRPl, but those interrupts that fall within the range
specified. on trap TRP2 are ignored. Therefore, tracing occurs in MODX for
those instructions that fall in the ranges of X'llO' to X'IC3' and X'ID8' to
X' 1FB'. Note that the IGNORE trap must be defined after the non-IGNORE
trap because the traps are processed for match tests in last-in-first-out order.
Note: The use of IGNORE traps with non-IGNORE PER traps effectively
allows you to discard selected events that occur in one or more subsets of the
monitored range. Be aware that PER interrupts occur within the ignored ranges
and cause system degradation.

Example 15: Match on Instruction Fetch
Problem: The debugger wants to force the system into a wait state when JOBI
executes in address space 5, 7, or 10 within a given address range.
Action: The debugger sets the following trap:
SLIP SET, IF,ENABLE, ID=PNKl,ACTION=WAIT,MODE= (HOME) ,
JOBNAME=JOB1,ASID=(5,7,lO),RANGE=(E300,EOOO),END

Result: When job JOBI starts in address space 5, 7, or 10, and an instruction is
fetched within the specified address range, then the trap matches and the system is
put in a wait state.
Note: Because MODE = HOME was specified, if job JOBI starts in address
space 5, issues a program call to address space 7, and then an instruction is
fetched within the specified address range, the trap will not match.

Section 2. Important Considerations Unique to MVS

2-123

Example of SLIP Command From TSO Terminal
The following example shows the use of the SLIP command from a TSO terminal
and the prompting that can occur.
Problem: A debugger suspects that a module is being passed an improper
parameter list that causes the module ISTAPCll to abend during job APPLEI.
By the time the abend occurs, all evidence of the cause has been eliminated by
recovery processing. A history of the caller's parameter list can be obtained by
using the SLIP IF PER function with ACTION = TRDUMP.
Action: The debugger issues the following commands:
tso user:

OPERATOR

system:

OPERATOR

tso user:

slip set,if,enable,id =perl,action = trdump,
jobname = apple I ,lpamod = (sstapc 11,16),
trdata = (std,regs, lr%, Ir% + 32),
matchlim = 5,end

system:

IEE736D SLIP ID=PERI,SSTAPCll IS NOT IN THE LPA.
ENTER KEYWORD, NULL LINE, OR 'CANCEL'

tso user:

lpamod = (istapcll,16)

system:

IEE727I SLIP TRAP ID = PERI SET BUT GTF IS NOT ACTIVE

tso user:

send 'please start gtf with mode = int and trace = slip and notify me when done'

system:

OPER GTF IS ACTIVE

tso user:

send 'please start apple 1'

system:

IEA992I SLIP TRAP ID = PER 1 MATCHED

system:

IEA4111 SLIP TRAP ID=PERI DISABLED FOR MATCH LIM

system:

IEA911A COMPLETE DUMP ON SYS1.DUMPOI TSO USE RID (DI0XYZl)

tso user:

send 'please stop gtr

Result: The dump has been taken. The debugger may now want to copy the
dump to another data set, clear the SYS1.DUMPOl data set, and obtain a
hardcopy of the dump. This additional processing can be accomplished from the
TSO terminal by using TSO commands to execute the print dump
(AMDPRDMP) program.
Note: You may want to establish a cataloged procedure to invoke GTF. This
procedure could specify all of the desired GTF options and keywords for using
GTF with the SLIP command. Using such a procedure would allow you (when
working from a TSO terminal) to pass only the name of the procedure to be
started to the operator instead of the GTF parameters as shown in the example.
This reduces the burden on the operator and is more effective when
communicating with the operator.

2-124

MVS Diagnostic Techniques

Designing an Effective SLIP Trap
The design of a SLIP trap requires knowledge of the error conditions and what
makes the error unique. An effective trap should catch only the intended error.
To do this, the description should be as specific as possible.
Note that SLIP does not detect any events that occur while running in
TRASMODE mode. (Control register I points to the segment table origin for an
address space other than the current address space.)
The best way to design a trap is from a dump of the error. In the case of the
NODUMP action, a dump should be available. In other cases, an approximate
dump (one taken near the time of the error) or one without sufficient information
to debug might be available.
It should be understood that for error events (non-PER traps), SLIP operates as a
subroutine within the RTM. SLIP is called from either RTMI or RTM2,
depending on whether the error environment allowed FRR or only EST AE
recovery respectively. The level of RTM in control affects the data areas
available. The calls to SLIP are prior to calls to any error recovery routine,
therefore it is possible that the data areas contained in a dump may have been
changed since SLIP examined them. This is especially true of the COMP
keyword value. Many recovery routines change the abend completion code to
make it more specific. For example, a system service that receives a bad address
from a user parameter list will get an OC4 which it converts to its own completion
code meaning a bad parameter list.

Controlling SLIP Traps

This topic describes how the MATCHLIM and PRCNTLIM keywords are used
to limit the system resources that a SLIP trap is allowed to use. Also, for PER
traps, it includes some performance hints.
MA TCHLIM Keyword

The MATCHLIM (match limit) keyword provides a way to set an upper limit on
the number of times that a trap is allowed to match. This keyword can be
specified to ensure that resources are not used unnecessarily (for example, using
dump data sets when ACTION = SVCD is chosen) or to remove the overhead
associated with a PER trap as soon as possible.
The MATCHLIM keyword should always be specified for enabled traps that are
unattended in order to avoid undesirable results, such as filling several dump data
sets for multiple occurrences of the same error.
If MATCHLIM is not specified on a trap, there is no limit to the number of

times the trap can match. However, if MATCHLIM is not specified on a PER
trap with ACTION = SVCD, the trap is disabled after one match.
If a MATCHLIM value has been specified for a trap, you can tell if the trap is
matching and approaching the limit set by displaying the trap via the DISPLAY
command.

Section 2. Important Considerations Unique to MVS

2-125

When the MATCHLIM keyword is used on an IGNORE type trap, it can
provide the effect of ignoring a specified number of events before an action is
taken by the associated non-IGNORE trap.
PRCNTLIM Keyword

The PRCNTLIM (percent limit) keyword provides a way to set a limit on the
amount of system time that is committed to processing on behalf of a PER trap.
The percentage of time that is computed is based on the amount of time spent
processing PER interrupts and space switch interrupts (as compared to the
amount of time elapsed since the first PER interrupt for the trap). The
percentage that is computed is related only to software processing and does not
include any PER hardware processing. The percentage is computed each time
that a PER interrupt is processed and is compared to the percent limit specified
on the PRCNTLIMkeyword.
Percent limit checking is not performed for the first 33 seconds (approximately)
after the first interrupt is taken for the trap. This avoids a high initial percentage
which might disable the trap immediately.
The accuracy of the percent limit calculation is affected by the instructions that
are executed on behalf of the PER interrupt and space switch interrupt but are
not included in the calculation. These instructions include:
•

instructions that are executed before the first timestamp is taken. (For
example, instructions in the program check first level interrupt handler.)

•

instructions'that are executed after the last timestamp is taken. (For example,
the percent limit calculation itself.)

•

instructions that are indirectly related to the PER interrupt. (For example,
instructions used for PER trap messages.)

Because these instructions are not accounted for in the percent limit calculation,
the accuracy of the calculation may vary between different traps. For example, if
there are many very explicit traps to be checked and one of them takes an action,
the large number of instructions executed between the timestamps taken will result
in a fairly accurate percentage calculation even though some instructions were not
accounted for in the calculation. Conversely, if there is one very simple trap that
does not match, the instructions that are not accounted for in the calculation
represent a large portion of the instructions executed and their exclusion makes
the percentage calculation more inaccurate.
Also, the percentage calculation is affected because the calculated percentage is
truncated to an integer.
If you have any' doubt as to whether or not a PER trap will work properly in a

system, a conservative value (such as the default PRCNTLIM = 10) should be
chosen. Thus, if the trap should consume large amounts of processing, it will be
quickly disabled. After approximately 33 seconds, you can display the PER trap
(via the DISPLAY command) and obtain the current system percent utilization by
the trap.

2-126

MVS Diagnostic Techniques

Specifying PRCNTLIM = 99 indicates that percent limit checking is not to be
performed. It is intended for non-critical environments (such as testing) and
certain special situations (see the ACTION = WAIT option). In general, all
non-IGNORE PER traps should have a reasonable value specified for percent
limit.

Performance Hints For PER Traps
For PER traps, you can minimize system performance degradation by:
•

Choosing values for the RANGE and LPAMOD keywords which will reduce
the range of storage that is monitored by the PER hardware. This will avoid
unnecessary PER interrupt processing.

•

Specifying the ASID and/or JOBNAME event qualifier keywords to avoid
having PER active in all address spaces in the system. When ASID and/or
JOBNAME is specified, PER monitoring is set up in only the requested
address spaces. Performance degradation due to PER monitoring occurs only
when the requested address spaces are in control. Also, when
MODE = HOME is specified, PER monitoring is set up only when the unit of
work is executing in the home address space.

Placement of PER Traps
The PER support provided by SLIP is designed to be non-disruptive at the
possible expense of not collecting data or performing a user requested action.
Several aspects of this non-disruptive characteristic are discussed in this topic:
Certain parts of the system cannot tolerate PER interrupts. For those parts, the
PSW PER bit is set off to prevent interrupts. Most notably, the PER bit is set off
in the program check, machine check and restart new PSW s. PER remains off in
such critical paths until processing reaches a point where a PER interrupt is
considered "safe." For example, if a SLIP IF PER trap is set on for the first
instruction in the program check FLIH, no PER interrupts would occur and the
trap would not match. Note, however, that you are not prevented from setting
such a trap.
Some PER interrupts that occur are not always processed by the SLIP processor.
The SLIP processor ignores (that is, does not process) PER interrupts if the
interrupt:
•

occurred while DAT was off (PER support for SLIP applies only to virtual
addresses ).

•

is redundant. (Refer to 8/370 Principles of Operation for a description of
redundant PER interrupts.)

•

occurred while an enabled non-IGNORE PER trap does not exist. Note that
this implies that PER interrupts caused by a non-SLIP tool which has set up
the PER control registers is ignored by SLIP and the PER bit is turned off by
SLIP in the resume PSW before returning to the program check FLIH.

Section 2. Important Considerations Unique to MVS

2-127

Because the SLIP processor uses certain system services, SLIP is sensitive to the
recursive use of those services where a recursive entry could cause an error.
Recursive calls to a function may occur in one of two ways; either directly or
indirectly. A direct recursion is the result of placing a PER trap in a function and
then causing SLIP to use that function. For example, suppose a SLIP trap is
placed in GTF entry code· and the action specified is TRACE. If the trap
matched and SLIP tried to take the action, a GTF trace record would not be
written because of the recursive checks within GTF. A similar situation exists
with other tracing actions, dump actions, and wait. In general, direct recursions
result in the action not being taken. Such direct recursions can be avoided by the
appropriate choice of another SLIP action. Note that you are not prevented from
setting a trap that can cause a direct recursion.
Indirect recursions are a result of a PER interrupt occurring in a system service
that is called by a service that SLIP uses. For example, suppose a PER interrupt
occurred in the lock manager, the non-IGNORE PER trap matched and the
action was SVCD with a summary dump requested. To produce a summary
dump, SVC dump calls the lock manager to obtain certain locks. If the recursive
call to the lock manager is allowed, an error could result due to information being
overlaid because of the recursive call. In this case, SLIP suppresses the summary
portion of the SVC dump to avoid the recursive call to the lock manager. A
similar situation can occur if a PER interrupt occurred in code where the
SALLOC lock is held (for example, in an RSM module) and a summary dump is
requested (thus causing RSM to be recursively entered). In this situation also, the
summary dump is suppressed. For both of these situations, the debugging
information in the SDUMP 4K buffer and the asynchronous portion of the dump
are available for debugging.
PER Monitoring and Checkpoint/Restart

For PER monitoring, specific PER support is not included in the
checkpoint/restart function. Therefore, two possibilities exist for a checkpointed
program.
Case 1.

A program is running in an address space that has not been selected for PER monitoring and
the program is checkpointed.

Case 2.

A program is running in an address space that has been selected for PER monitoring and the
program is checkpointed.

These two cases could result in one of three conditions when the checkpointed
program is restarted.

2-128

•

In Case 1, if the program is restarted in an address space that has been
selected for PER monitoring, the restarted program is not monitored.

•

In Case 2, if the program is restarted in an address space that has not been
selected for PER monitoring, but other address spaces are being monitored,
unwanted PER interrupts may occur (depending on the PER control register
settings). If unwanted PER interrupts occur in the restarted program, the
PSW PER bit is turned off in the restarted program. This may eventually
remove all possible degradation due to the unwanted PER interrupts from the
restarted program.

MVS Diagnostic Techniques

•

In Case 2, if the program is restarted and PER monitoring is not active in the
system (that is, control register nine is zero), the system may suffer some
degradation due to the PSW PER bit being on in the restarted program as the
restarted program is running.

SLIP Command Keyword Summary
Figure 2-17 is a summary of the SLIP command keywords. The keywords are
shown across the top of the figure and are grouped by the function that they
perform.. For each keyword, a brief description is given for the use of the
keyword, the valid options, required and default options, restrictions, comments
and other information.

Section 2. Important Considerations Unique to MVS

2-129

tv
I

w

0

~

(JQ

...=
f'D

"",r

~

,....
I

.......

<::
til

.-

t:l

=
...

j;.)'

0Cl

=

0

....
(S.
VJ

~

-C

rJJ

..0

-C

s::
f'D
VJ

",CTION
ADDRESS
ASID
ASIDLST
ASIDSA
COMP
DATA
DEBUG
DISABLE
ENABLE
ENO
ERRTYP
IF.,
10.
JOBNAME

Options

I

...
~

~

JSPGM
LIST
LPAMOD
MATCHLIM
MODE
PRCNTLIM
PVTMOD
RANGE
RBLeVEL
SA
se
SDATA
SUMLIST
TRDATA

e

Required

END

:I

O.fluh

ENABLE,
A':TlON' SVCD, and
RBLEVEI."EQROR

Restriclion I

MUll follow SLIP

aa
=
c::>.
rJJ

=
a
a
=
...

~

DEL

E nabl, or disable one or
:nor. PE R traps

Oele18 one or more PER
trapl.

Set an I nSlrU(;tlon fetch

Set a successful branch

PER trap.

PER trap

Specialized Keywords

Trap Control Keywords

SB

SA
Enable

Set a storage alte,atlon
PER trap

ENABLE

DISABLE

PER trap

Disable I PER trap.

8

10

DEBUG

END
Indicate, the trap

Provide an idlntifier for
• PEA trap.

C...... the GTF SLIP
DEBUG retord to be

definition i, compl •••.

wriuen when the trap
ilchecked.
O.. ,te

one or more

Enable or disable one or

non·PER trap •.

Di,able • non-PER
trap

Eanble a non-PEA

more non-PER traps,

"ap

Provide an identifi" for
• non-PEA trap.

C...... tho GTF SLIP
DEBUG record to be

I odicltlS the
definition il complet •.

il checked .

I

~

Trap Type Keywords

IF

MOD

writt.n when the trap

e~

t:r'

e.

i

/Valid

(1)

0

i

I

~-+--~'on'-P

,....

~

SET

ISui • PE~ trap

• PER

N

SLIP Control Keywords

ALL
DISABLE
ENABLE
10

ALL
10

ACTION
ASID
ASIDLST
DATA
DEBUG
DISABLE
ENABLE
END
10
JOBNAME
JSPGM
LIST
LPAMOD
MATCH LIM

MODE
PRCNTLIM
RANGE
SDATA
SUMLIST
TRDATA

Samea.IF.

ACTION
ADDRESS
ASID
ASIDLST
ASIDSA
DATA
OEBUG
DISABLE
ENABLE
END

MATCH LIM
MODE
PRCNTLIM
PVTMOD
RANGE
SDATA
SUMLIST
TRDATA

- --

Four-character identifier.

10

JOBNAME
JSPGM
LIST
LPAMOD

ID or ALL, and
ENABLE Or DISABLE

10 orALL

RANGE (unla..
ACTION-IGNORE i.

RANGE or LPAMOD

RANGE or LPAMOO

specified)

t:=-.
MenU

I

1

1

1- --

1---

Must follow SLIP.

Must follOW SLIP

1
1

Must follow SET,

Qualify

ASIO. and/or
JOB~kME (0 minimize
performance degradation.
IN'';'

I

I

I

I

MUll follow SET.

Sama •• IF

Must f"now SET.

Same as IF.

I1

I ---

I

1- - -

1- --

Only one non· IGNORE . / - _. -

PEA trap may be enabled

System ..,ppliod.

I

J

Specify at end of the

command
GTF must be activl
end with the SLIP
option ChOM"

Supplied by .ystam if not / UN with SET.

specified on SET.

'I Mifliml:m
Value
Maximum

Value
Spec

i.'

ALL .ndicI... all SLIP

\',Iue

trIP'

r--Abbr.... ia-

-

ALL indicales all SLIP
Irapl.

f---

tio.,
example

SLIP SET,

I SLIP DEL,

SLIP MOD,

1--I SLiPSET,IF,

1- -I SLIP SET, SB,.

1 - -I SLIP SET. SA ...

EN

SLIP

10

,EN, .

I

SLIP . . , D,

I

ID-TRPI

I

SLIP SET, . , . ,END

I

DeeUG

:!1

IJQ.
I:

t2

~
PER

w
I

1-1

~

::l

w
e

ADDRESS
forSA,lfPKi'inth.
edck... ' .... oflhe
instruction that mull
ceu .. ,he 1t00agi

ASIDSA

ASID
SpKi'in the ASIO,

Specifies the ASIO$
(addr,,, spaces) in which

monitored.

the storage being altered

C_... _

..llobo

COMP

ERRTYP

DATA
SpKifies condition of

JOBNAME
Specifi.s the lob
to be monito,Nt

I1or.or,qi.te"

"IP program " .. n.
tha' mUlt be In conuol

Non-PER ISpeciliesl"'_,_
Ih.. must be in contrliJl
when lhe error OCCUR.

~,~,

I::':.:'

range 10 be monitored

For SA. JPKlfin the LPA

1101. . . . . . . ' •• ion.

LPAMOD
For IF and SI. definel.he

lIor..... te'ltton
Specilies, ... ASID,
C_... _I,hllmu"
be in control when the

1- --

.... if. . . u., or system
compIltion code.

1- --

'::=

I~,;..

Specifies conditton of

Itorlllor rqi,ter•.

I

Speci.'" IYltem·detKted
error type.

Speci' ... th. lob thlt mull
be in conlrol wh.n the

SpecI'Wi thl lob step
Pfotr.-n Mme that mUI'
be In control when the

modul. th" must be in
cont,oI when the

ABEND
OAT
MACH
MEMTERM
PGIO
PROG
REST
SVCERR

Any Vllid iem name,
TSO 10. or Itlrted ,.k

Any veltd job step

N_

p'oeremneme

Stilt dilPlKement
EnddiipllCement

Specifi.s system mode

Speciliesl'" LPA

Indi... I _ ...

~

~

=a

-=
VJ

g
0'

!'-l

~0

...
;

g:
-=
=

( ')
0

~

fa

0'
fIJ

c:

=

.E'

R

0

t:

<

VJ

N
I

"'W"""
"'"""

I

Requited

N_

011... 11

Ent.,. module.

ALL
DIS
GLOC
GLDCSD
GLOCSP
HOME
LLOC
LOCK
PKEY
pp
RECV
SKEY
SRB
SUPER
SUPA

-...

for
tr_.
SA only
St
...PER
__
muIlbo_

Mooi....,.. 0116 ASlD, ...
be_iliad

Com·

ISpecify .irtuol_,_
inhe. .decimel.

Minimum

Logictli "or" if mor. th.,.
one e"or " IPKified.

$pteify u .., code ..
four ~imel dilih.

Specify d~lCement in
hexedec.mel

Limi'l PER monito,ing to
th. ASIO of the job

SpKily",,,... . - ..
..........MIocimal_ ...

11
Eotl,._10

en option).

fo---'C___E_XIT_ _)

YES

YES
MOVE TO GSPL

YES

INDICATE
SRB MODE

SET UP

~

lEAVESC5
MOVE TO
APPROPRIATE
ASCBLSMQ

C

SCHEDULE TO
ASCBLSMQ

-.(j)

0
YES

YES

Figure

5-3 (Part 1 of 3).

5-10

MVS Diagnostic Techniques

INDICATE
SRB MODE

NO

MOVE TO LSPL

Dispatcher Processing Overview

{;\

~~

psw

LPSW

)

YES

RESTORE STATUS
FROM IHSA

RESTORE STATUS
FROM SSRB

NO

C___

LP_SW_ _
)
FREE SSRB

C__

L_PS_W_ _)

DISPATCH CMS
LOCK HOLDER
NO

(

i

LPSW

)

DISPATCH CML
LOCK HOLDER

(
Figure

5-3 (Part 2 of 3).

~

LPSW

)

Dispatcher Processing Oveniew

Section 5. Component Analysis

5-11

IF ASCBS3S= 1•
THE STAGE 3
EXIT EFFECTOR
PROCESSES WORK

GET HIGHEST
PRIORITY
READY TCB

GET NEXT ASCB

RESTORE
STATUS
FROM TCB

NO

(

RECURSIVE SEARCH
OF THE DISPATCHING
' - - - - - - - - - 1 QUEUE TO VERIFY
THAT NO READY WORK
EXISTS

Figure

5-3 (Part 3 of 3).

Dispatcher Processing Overview

5-12

MVS Diag~ostic Techniques

LPSW

)

Dispatchability Tests
The dispatcher conducts the following dispatchability checks:

SRB Tests
Test*

Condition
Dispatchability flags

1. ASCBDSPljjASCBSSND

System non-dispatchable and this address space non exempt

2. ASCBDSPljjASCBFAIL

Address space in failure mode and in the process of being
terminated

3. ASCBDSPljjASCBSSS

System-level SRBs stopped (does not apply to nonquiesceable
SRBs)

4. ASCBDSPljjASCBSNQS

All SRBs stopped

5. SRBCPAFF

Does SRB. have affinity to this processor? (PCCACAFM defines
the current processor)

6. SRBFLGSj jSRBLLREQ

LOCAL lock required at dispatch time

7. SRBFLGSjjSSRLLHLD

This SRB holds the LOCAL lock. The ASCBLOCK will be
changed from X'4FFFFFFF' to the CPU ID when the SRB is
dispatched.

8. SRBASCB

Does SRB point to valid ASCB? (Global SRBs only)

*Format of test description is "field//bit within field."

Address Space and Task Tests
The following address space test criteria must be met before the task dispatcher
gets control.
Address Space Tests

Condition

1. ASCBDSPljjASCBSSND

System non-dispatchable and this address space not exempt.

2. ASCBDSPI//ASCBFAIL

The ASeB is in failure mode and in the process of being
terminated. The address space will not be dispatched.

3. ASCBDSPI//ASCBSTND

TCBs not dispatchable. STATUS (lEAVSETS) is stopping
SRBs.

4. LOCAL LOCK//ASCBLOCK
Free
(X'OOOOOOOO')

If any ready work exists in the address space, it can be dispatched.

Other CPUID

If any ready work exists that does not require the LOCAL lock,
it can be dispatched.

Interrupt ID
(X'FFFFFFFF')

Compare and swap CPUID into LOCAL lock and restore the
status (FPRs, GRPs, FRR Stack, CPU timer value,
PSATOLD PSATNEW, and resume PSW) from the IHSA.

Suspend ID
(X'7FFFFFFF')

If suspension is due to an unsuccessful cross memory services
lock request and the holder of the lock has a lower priority,
then dispatch the lock holder. Otherwise, if any work
exists that does not require the LOCAL lock, that work
can be dispatched.

Section S. Component Analysis

5-13

Ready-to-run ID
(X'4FFFFFFF')

If the lock is held as a CML lock. then dispatch the lock holder
if the lock holder has a lower priority and is dispatchable.
Otherwise. if any work. exists that does not require the LOCAL
lock, that work can be dispatched.

s. ASCBFLGl//ASCBS3S

Interface with Stage 3 exit effector, if the LOCAL lock is
available.

6. ASCBTCBS + ASCBTCBL
> ASCBCPUS

The LOCAL lock is available. If the total number of ready
TCBs (those not requiring the LOCAL lock. plus those
requiring it) exceeds the number of processors currently
executing in the address space. the address space can be
dispatched.

7. ASCBTCBS>ASCBCPUS

The LOCAL lock is not available. There are more ready TCBs
(those not requiring the LOCAL lock) than there are processors
currently executing in the address space; the address space can be
dispatched.

After these seven tests indicate that the dispatcher should dispatch an address
space, the following task indicators are tested.
Task Tests

Condition

I. TCBFLGS4 + TCBFLGS5

TCB primary non-dispatchability flags must not be set.

2. RBWCF

RB must not be waiting.

3. TCBXSCTI//TCBACTIV

If on. this TCB is active on the other processor (TCBCCPVI). or
is suspended holding a local lock.

4. TCBXSCTI//TCBLLREQ

If on, this TCB requires the LOCAL lock before being
dispatched.

5. TCBXSCTI//TCBCMLR

If on. this TCB holds a CML lock and is read) to run.

6. TCBAFFN

TCB affinity, if any, must match this processor's (which is
located in PCCACAFM).

Miscellaneous Notes About the Dispatcher

1.

You can determine the last SRB dispatch by examining the PSW at location
X'420' and the last task dispatch by examining the PSW at location X'468'.
At each dispatch the processor timer is set to a value that will not expire over
a 208-day period unless a task has a TQE, in which case it is set to the TQE
value.
For all initial SRBs, the processor timer is also set to the 208-day value. For
SSRBs, the processor timer is set to the remaining time value stored in the
SSRBCPUT field.

2.

The dispatcher sets the following mode indicators before dispatching work.
a.

For a global SRB - LCCADSF2jjLCCASRBM, LCCAGSRB, and
LCCADSRW
PSATNEWjPSATOLD = O's

5-14

MVS Diagnostic Techniques

b.

For a local SRB - LCCADSF2//LCCASRBM, and LCCADSRW
PSATNEW/PSATOLD = O's

c.

For a task - LCCADSF2//LCCADSRW
PSATNEW /PSATOLD " O's TCB address

Dispatcher Recovery Considerations
Dispatcher recovery is designed to record information about the error, reconstruct
critical dispatching queues, and to retry to continue normal dispatching functions.
The data that the dispatcher records in the system diagnostic work area (SDWA)
is the following:

Fixed Data
SDWAMODN - lEAVEDSO, dispatcher module name
- lEAVEDSO, dispatcher CSECT name
SDWACSCT
SDWAREXN - lEAVEDSR, dispatcher recovery routine
SDWACID
- SCIC5, component ID
SDWAMLVL - module date and level

VtlI'iable Data
SDWAVRA - The variable data is written in the key-length-data format. Data
items include control block mapping names followed by pairs of field offsets and
the contents of the control block at the time of error as follows:
Control
Block

Offset

Field
Name

Description

IHAPSA

X'224'
X'2IC'
X'2BO'
X'2FS'
X'49C'

PSAAOLD
PSATOLD
PSALOCAL
PSAHLHI
PSAMODEW

Current ASCB address.
Current TCB address, or zero.
ASCB address of the CML lock, or zero.
Locks held indicator.
Word containing PSAMODE.

IHAASCB

X'80'

ASCBLOCK

Local lockword value.

X'ES'
X'EC'

ASCBLOCI
ASCBMLH

X'B4'
X'13C'

ASCBSRQ
ASCBRCMS

Address of ASCB holding this ASCB's CML lock.
Address of suspended unit of work holding this ASCB's local
lock as a CML lock or LOCAL lock.
Local dispatcher intersect flags.
Address of the requested cross memory services lock for
which the local lock holder is suspended.

IHALCCA

X'36C'
X'2IC'
X'53C'

LCCAFSSJ
LCCADSFI
LCCAPRMT

SRB journal queue header.
Dispatcher flag bytes.
Address space promotion indicators.

IHASVT

X'IC'

SVTDSREQ

Global dispatcher intersect flags.

. If the dispatcher lock and global intersect can be obtained, the following recovery
routines are called by the dispatcher recovery routine:
•
•
•

lEAVESCR - Scheduler recovery routine; it recovers SRB queues.
lEAVEQV3 - Verifies, and possibly reconstructs, the ASCB ready queue.
IEAVEGAS - Verifies each ASCB on the ready queue.

Section 5. Component Analysis

5-15

If the LOCAL lock and local intersect can be obtained, the error was not a OAT
(dynamic. address translation) error; and if the current ASCBSTOR value equaled
the CRt value, then the following recovery routines are invoked by the
dispatcher:
•
•
•

lEAVEEER - Exit effector recovery routine (if the ASCBS3S is on).
IEAVEQV3 - Verifies, and possibly reconstructs, the TCB queue.
lEAVETCB - Verifies each TCB on the TCB queue.

Note: The queue verification routine, lEAVEQV3, also records error information
in the SOWAVRA about any changes to the queue structure.
By removing elements that have been overlaid (or "clobbered") from the queue,
the dispatcher recovery routine attempts to keep the system up at the cost of a
particular user, job, address space, etc. There is a certain exposure in this
philosophy because the element that has been lost might have owned a critical
system resource or might be a critical function in itself (for example, a TCB that
represents the user's main application program). If a TCB queue is truncated or
found to have invalid data, the address space is terminated. Once the element is
lost, there might be no indication that it was a critical resource (a valid control
block, for example) or that it owned a critical resource.
Dispatcher Error Conditions
•

Abend 075 is issued from CSECT lEAVESCO when a local SRB is scheduled
to an invalid ASCB at the time the SRB is scheduled. The SRB SCHEDULE
requester can usually be determined by examining the registers.

•

The dispatcher issues the following abends:

•

Abend
Code

Reason
Code

x'on'

none

A task or SRB is found with CPU affinity to a processor not currently
online.

X'22F'

none

There is no usable CPU timer available for tasks with task type TQE, or the
processor to which the task has affinity has no operable timer.

X'066'

X'04'

A completed SRB returned to the dispatcher and the SRB holds a lock.

X'066'

X'OC'

An SRB holds the CML lock of an address space that is failing.

X'066'

X'IO'

An SRB or SSRB points to an ASCB without a valid ASCB acronym.

X'066'

X'14'

A task holds the CML lock of an address space that is failing.

Explanation

Program check interrupts (usually of the page, addressing, or segment
exception variety) occur when:
PSAANEW is overlaid and the dispatcher attempts to switch address
spaces into the value in the PSAANEW
PSALCCAV or PSAPCCAV values are overlaid
The CVT pointer is overlaid
The ASCB ready queue is overlaid
The TCB queue or the TCBRBP field is overlaid

5-16

MVS Diagnostic Techniques

SRB/SSRB Pool Manager
The SRBjSSRB pool manager obtains and frees SRBs from the SRB pool and
SSRBs (with their associated XSBs) from the SSRB pool. System routines (in key
0, supervisor state) issue the GETSRB, FREESRB~ GETSSRB, and FREESSRB
macros to request the pool manager services.
This topic describes the following:
•
•
•

SRB/SSRB pool manager entry points
SRB/SSRB pool manager recovery considerations
SRB/SSRB pool manager error conditions

SRB/SSRB Pool Manager Entry Points
The pool manager entry points are:
IEAVSPMI - entered key 0, supervisor state, enabled for OAT, system mode acceptable to SETFRR
(not EUT), no locks required (except the SALLOC might be required for UNCONO
and EXPANO type requests.
This entry point is called by the GETSRB macro and obtains an SRB and six-word
parameter area from the SRB pool. The SRB is initialized as follows:
•
•
•
•

SRB acronym field
pointer to the parameter area
FREEMAIN flags, which indicate the origin of the SRB
other fields and the parameter area cleared.

IEAVSPM2 - entered key 0, supervisor state, enabled for OAT, system mode acceptable to SETFRR
(not EUT), no locks required (except the SALLOC lock might be required).
This entry point is called by the GETSSRB macro and obtains an SSRB and its
associated XSB from the SSRB pool. The SSRBjXSB are initialized as follows:
•
•
•
•
•
•
•
..

SSRB acronym field
pointer to a resource management termination routine (RMTR)
pointer to the SSRB save area
SSRB pointer to the XSB
non quiescable and suspended flags set on
FREEMAIN flags, which indicate the origin of the SSRBjXSB
XSB acronym field
other fields cleared.

IEAVSPM3 - entered key 0, supervisor state, enabled for OAT, system mode acceptable to SETFRR
(not EUT), no locks required (except the SALLOC lock might be required).
This entry point is called by the FREESRB macro and frees an SRB and its six-word
parameter area. If the specified SRB acronym field is not the same as when the SRB
was obtained, the program issuing the macro is abended.
IEAVSPM4 - entered key 0, supervisor state, enabled for OAT, system mode acceptable to SETFRR
(not EUT), no locks required (except the SALLOC lock might be required).
This entry point is called by the FREESSRB macro and frees an SSRB and its XSB. If
the specified SSRB acronym field is not the same as when the SSRB was obtained, the
program issuing the macro is abended.

Section 5. Component Analysis

5-17

SRBISSRB Pool Manager Recovery Considerations

When an error occurs, the SRBjSSRB pool manager recovery routine
(lEAVSPMR) records information about the error in the SDWA. The queue
verifier routine (lEAVEQV1) then uses an SRBjSSRB verification routine in
lEAVSPMR to verify· that the SRB and SSRB pools are intact. Two tests are
used to determine if a given storage area is a valid SRB or SSRB: (1) the storage
address must be a valid virtual address, and (2) the acronym field must contain
the correct acronym.
If an error is found with a pool, the queue verifier routine attempts to repair the
pool, which might include removing invalid SRBs or SSRBs from their pools.
Any removed blocks of storage are unavailable for the remainder of the IPL.

The data recorded in the SOWA is:
Fixed data
SDWAMODN
SDWACSCT
SDWAREXN
SDWACID
SDWASC
SDWAMLVL
SDWARRL

- NUCLEUS, pool manager is nucleus resident.
- IEAVESPM, CSECT name.
- lEAVESPM, recovery CSECT name.
- SCIC5, component ID.
- descriptive module name.
- module level information.
- lEAVSPMR, recovery routine label.

Variable data

The variable data in the SOWAVRA is recorded in the key-length-data format.
•

FRR parm area - the six-word parameter area passed to lEAVSPMR by the
mainline routine is as follows:
Mainline SALLOC footprint - indicates if the SALLOC lock was held on
entry to the pool manager.
FRR SALLOC footprint - indicates if the SALLOC lock was held on
entry to the recovery routine.
Return address - contents of register 14 on entry to the pool manager
(caller's return address).

5-18

•

ASCBASID - address space ID of the current ASCB.

•

PSATOLO - address of the current TCB.

•

General register 14 - contents of register 14 on entry to the mainline pool
manager (caller's return address).

•

Pool problem information - information recorded by the queue verifier
.
routine if problems are found with the SRB or SSRB pools.

•

Lock name - SALLOC, indicates that the SALLOC lock was held by the pool
manager mainline routine.

MVS Diagnostic Techniques

~

SRB/SSRB Pool Manager Error Conditions
If the lEAVSPM3 (FREESRB) or lEAVSPM4 (FREESSRB) routines are called
and an error is detected, completion code X'OSA' is issued and the caller is
abended. Register 2 contains the address of the invalid SRB or SSRB.

Refer to System Codes for a description of code X'OSA' and specific reason codes
in register 15.

Stop/Reset Services
When a unit of work (a current task or SRB) has been dispatched and is
executing, the unit of work might need to be suspended. For example, to satisfy a
page-in due to a page fault.
System routines (in key 0, supervisor state) use the stop/reset service to suspend
and then reset a unit of work. The caller is not required to have addressability to
the home address space to suspend a unit of work, and is not required to have
addressability to the address space containing the unit of work to reset the unit of
work.
This topic describes the following:.
•
•
•

Stop/reset entry points
Stop/reset recovery conditions
Stop/reset error conditions

Stop/Reset Entry Points
The stop/reset entry points are:
lEAVSUSP - entered disabled, key 0, supervisor state, no locks required (except the SALLOC lock
might be required).
This entry point is called by the paging supervisor to suspend a current task or SRB
because a page fault occurred.
IEAVSUSQ - entered disabled, key 0, supervisor state, no locks required (except the SALLOC lock
might be required).
This entry point is called by system routines (other than the paging supervisor) to
suspend the current task or SRB.
IEAVRSET - entered disabled, key 0, supervisor state, no locks required (except the SALLOC lock
might be required.
This entry point is called by the paging supervisor to reset a task or SRB that was
suspended because of a page fault.
IEAVRSTD - entered disabled, key 0, supervisor state, no locks required (except the SALLOC lock
might be required).
.
This entry point is called by system routines (other than the paging supervisor) to reset
a task or SRB that was suspended.

Section 5. Component Analysis

5-19

Stop/Reset Recovery Considerations
The stop recovery routine (STOPFRR) records information about the error and,
depending on the error, either attempts to restore the system and unit of work to
a consistent state, or attempts to complete the stop function.
The reset recovery routine (RESETFRR) records information about the error and
then attempts to complete the reset function.
The reset STERM, reset schedule, and reset SRB recovery routine (lEAVSCHF)
frees the SRB (if one was obtained but not scheduled), clears the stop/reset super
bit (PSASTPRT), and releases the LOCAL lock (if the LOCAL lock was obtained
by the calling routine).
The data that the stop/reset recovery routines record in the SDWA is:
Fixed data
The fixed data recorded by all of the recovery routines is:
SDWAMODN
SDWACSCT
SDWAREXN
SDWACID
SDWAMLVL
SDWARRL

- NUCLEUS, stop/reset is nucleus resident.
- IEAVESRT, CSECT name.
- lEA VESRT, recovery routine.
- SCIC5, component 10.
- module level information.
- STOPFRR, RESETFRR, or lEAVSCHF, label of the recovery routine.

Variable data
The variable data in the SDWA is recorded in the key.;.}ength format. The
variable data recorded by the recovery routine is:
For the stop recovery (STOPFRR) and the reset recovery (RESETFRR) routines:
•

FRR parm area - the six-word parameter area passed to STOPFRR and
RESETFRR by the mainline routine is as follows:
General register 13 - caller's register save area address.
TCB/SSRB address - address of the TCB or SSRB to be reset.
RB address - address of the RB if a TCB is to be reset.
Request code - type of reset requested (conditional, unconditional, or
page I/O error), or completion code for a termination reset.
Flag byte - if X '80', recovery has been entered recursively.

5-20

•

ASCBASID - address space ID of the current ASCB.

•

PSATOLD - address of the current TCB.

•

General register 14 - contents of register 14 on entry to the mainline stop
routine (caller's return address).

MVS Diagnostic Techniques

•

General registers - for STOPFRR, contents of the original registers, if they
were changed by the recovery routine.

•

Abend code - for STOPFRR, the original abend code, if it was changed by
the recovery routine.

For the reset STERM, reset schedule, and reset SRB recovery routine
(lEAVSCHF):
•

FRR parm area - the six-word parameter area passed to lEAVSCHF by the
mainline routine as follows:
SSRB address - address of the SSRB associated with the scheduled SRB.
(Note that an SSRB is obtained, made to look like an SRB, and
scheduled as an SRB. The remainder of the SSRB is used as a work area
by the scheduled routine. The SSRB is restored to an SSRB before it is
returned to the SSRB pool.)
Flag byte - recovery footprint flags:
X'80' - stop/reset super bit footprint, indicates the mainline code set the bit.
X'40' - LOCAL lock footprint, indicates the mainline code had obtained the LOCAL lock
and had not released it before the error occurred.

•

ASCBASID - address space ID of the current ASCB.

•

PSATOLD - address of the current TCB.

•

If an SRB was obtained but not scheduled, the following are also present in
the SDWAVRA:
IHASRB - identifies the following control block.
SRB - contents of the unscheduled SRB.
SRB parm area header - describes the following six-word parameter area.
SRB parm area - contents of the SRB parameter area.

•

Lock name - LOCAL, indicates the LOCAL lock was held.

Stop/Reset Error Conditions
The stop/reset services issue the X'059' completion code when an error exists, and
abnormally terminates the program requesting the service.
Refer to System Codes for a description of code X'059' and specific reason codes
in register 15.

Section 5. Component Analysis

5-21

SUSPEND/RESUME/TCTL Services
The SUSPENDjRESUMEjTCTL services are used to place an unlocked task in a
suspended state (SUSPEND), resume an unlocked task from a suspended state
(RESUME), and to transfer control from an SRB to an unlocked task (TCTL).
These macros can only be issued by key 0, supervisor state routines.
SUSPEND can be issued in any cross memory mode and in task mode; it places
the caller in a suspended state. Control is returned to the caller and the task is
suspended only when the task incurs an interruption or enters the dispatcher (such
as via CALLDISP).
RESUME can be issued in any cross memory mode and in SRB or task mode,
with current addressability to the address space of the TCB that is to be resumed.
TCTL can be issued in SRB mode and home mode, with current addressability to
the address space of the task to which control is to be transferred.
This topic describes the following:
•
•
•

SUSPENDjRESUMEjTCTL entry points
RESUMEjTCTL recovery considerations
SUSPENDjRESUMEjTCTL error conditions

SUSPEND/RESUME/TCTL Entry Points
The SUSPENDjRESUMEjTCTL entry points are:
lEAVSPND - entered enabled or disabled, key 0, supervisor state, task mode, no locks held, any cross
memory state.
This entry point is called by the SUSPEND macro and places the current TCB/RB in a
suspended state.
lEAVRSUH - entered enabled, key 0, supervisor state, no locks held, SRB or task mode, home mode.
This entry point is called by the RESUME macro to resume a task in the home address
space. This entry point performs an unconditional synchronous resume function. The
caller must execute enabled and hold no locks unless the LOCAL lock is already held,
because this entry point can require the LOCAL lock to serialize the resume function.
This is the only entry point where RETURN = N can be specified to indicate that
control should be transferred from the calling SRB to the resumed task.
.
lEAVRSUS - entered enabled, key 0, supervisor state, no locks held, SRB or task mode, any cross
memory state, current addressability to the resumed TCB.
This entry point is called by the RESUME macro to resume a task in the address space
specified by the input. Current addressability to the task to be resumed must have been
established by the caller. This entry point performs an unconditional synchronous
resume function. The caller must execute enabled and hold no locks unless the LOCAL
lock of the address space of the resume~ TCB is already held, because this entry point
can require the specified lock to serialize the resume function.
lEAVRSCS - entered enabled or disabled, key 0, supervisor state, SRB or task mode, any cross
memory state, locks can be held, current address ability to the resumed TCB.
This entry point is called by the RESUME macro to resume a task in the address space
specified by the input. Current addressability to the task to be resumed must have been
established by the caller. This entry point performs a conditional synchronous resume
function. If serialization to perform the resume function is not available, the function is
not performed and the caller receives a nonzero return code.

5-22

MVS Diagnostic Techniques

~

~

IEAVRSUA - entered enabled or disabled, key 0, supervisor state, SRB or task mode, any cross
memory state, locks can be held, current addressability to the resumed TeB.
This entry point is called by the RESUME macro to resume a task in the address space
specified by the input. Current addressability to the task to be resumed must have been
established by the caller. This entry point performs an unc~nditional asynchronous
resume function. If serialization to perform the resume functiJn is not available, an
SRB is obtained and, asynchronously, an unconditional synchronous function is
performed; a nonzero return code is returned to the caller.
lEAVRSCA - entered enabled or disabled, key 0, supervisor state, SRB or task mode, any cross
memory state, locks can be held, current addressability to the resumed TCB.
This entry point is called by the RESUME macro to resume a task in the address space
specified by the input. Current addressability to the task to be resumed must· have been
established by the caller. This entry point performs a conditional asynchronous resume
function. If serialization to perform the resume function is not available, an SRB is
obtained conditionally, and if successful, asynchronously scheduled to perform an
unconditional synchronous resume function. Return codes are returned to the caller to
indicate whether the SRB could be obtained or not obtained.
lEAVTCTL - entered enabled or disabled, key 0, supervisor state, SRB mode, hometmode, no locks
held.
This entry point is called by the TCTL macro to transfer Control from an SRB to a task
in the home address space.
lEA VETCR - entered disabled, key 0, supervisor state, any cross memory state, SRB or task mode.
This entry point is caUed by RTM and performs recovery processing for the resume and
transfer control functions.

RESUME/TCTL Recovery Considerations
RESUME/TCTL processing is protected by an FRR (lEAVETCR) that receives
control from RTM when an error occurs. The FRR records debugging
information in the SDWA, attempts to restore the system and unit of work to a
consistent state, and then percolates to the caller's recovery routine.
The data recorded in the SDWA is:
Fixed data
SDWAMODN
SDWACSCT
SDWAREXN
SDWACID
SDWASC
SDWAMLVL
SDWARRL

- NUCLEUS, nucleus load module.
- lEAVETCL, mainline microfiche name.
- lEA VETCL, recovery microfiche name.
- SCIC5, component ID.
- RESUME ABEND or TCTL ABEND, subfunction in error.
- module level information.
- lEAVETCR, recovery routine name.

Section S. Component Analysis

5-23

Variable data
Variable data in the SDWAVRA is recorded in the key-length-data format. A
header contains RSLG in key-length-data format followed by the RSLG mapping
in key-length-data format as follows:
Offset

RESUME data

TCTL data

X'O'
X'I'
X'2'

flag byte: Bit 0 = O,RESUME
0
flag byte: Bit 0 = I, lock obtained
Bit 1= 1, SRB obtained
PSASUPER
PSACSTK
PSATOLD
PSAAOLD
input TCB address
input ASCB address
PSAHLHI
home address space ID
0
ASCBTCBS
address of SRB, or 0

flag byte: Bit 0 = I,TCTL
SVTDACTV

X'4'
X'S'
X'C'
X'tO'
X'14'
X'IS'
X'IC'
X'20'
X'22'
X'24'
X'2S'

o
PSASUPER
PSACSTK
PSATOLD
PSAAOLD
input TCB address
SVTDSREQ
ASCBSRQ

SUSPEND/RESUME/TCTL Error Conditions
The SUSPEND, RESUME, and TCTL macros issue the X'070' completion code
when an error condition exists, and abnormally terminate the program issuing the
macro.
Refer to System Codes for a description of code X'070' and specific reason codes
in register 15.

5-24

MVS Diagnostic Techniques

lOS
The purpose of the I/O supervisor (lOS) is to provide a central facility to control
and conduct I/O activity through the operating system. The structure of lOS in
MVS is somewhat different than that of previous operating systems. In MVS,
lOS "front end processing" is responsible for device control and I/O initiation;
lOS "back end processing" is responsible for processing interrupts, providing
sense information in error situations, and scheduling the posting of the I/O
requestor at completion time. Figure 5-4 provides an overview of I/O front-end
and back-end processing. Figure 5-5 shows the major lOS and EXCP control
block relationships.

Front-End Processing
The major portion of the I/O process (the queueing of I/O requests and starting
them) is contained in CSECT IECIOSCN (microfiche name IECIOSAM), which
is called the channel scheduler. The channel scheduler is invoked through an
interface provided by the STARTIO macro via a branch entry. The channel
scheduler assumes that all channel program translation and page fixing of buffers
and CCWs is performed by the caller. The control block interface is the
SRB/IOSB combination, which must be non-pageable and commonly addressable
from any address space (that is, SQA and fixed CSA). The channel scheduler
operates in physically disabled mode. Invokers (called "drivers") of the channel
scheduler include EXCP, VSAM block processor, VTAM TPIOS, and PCI fetch;
they are identified by the driver ids located in the IOSB + 4 (lOSDVRID).

Back-End Processing
When lOS is invoked for an I/O interrupt, processing starts in the I/O first level
interrupt handler (FLIH) which branches to an entry point, IECINT, within the
channel scheduler. Back-end lOS executes physically disabled in the address
space that is active on the processor at the time of the I/O interrupt. lOS then
schedules the SRB/IOSB to the address space of the requestor. The module
IECVPST (post status) receives control under the SRB and interfaces with the
driver's special exits and termination routines (channel end, abnormal end exits).
Figure 5-4 shows an overview of the I/O process using EXCP as the I/O driver.

lOS Problem Analysis
Problems in the I/O process can cause three symptoms:
1.
2.
3.

Abend codes
Loops
Wait states

These symptoms are discussed in the following sections.

Section 5. Component Analysis
"

5-25

Back-End Processing

Front-End Processing
User

I/O Interrupt
SVC 0

BR

EXCP
Driver

IECVSMGR
Gets storage
for SRB/IOSB,
TCCW, BEB,
FIXLIST, ROE

I/O FLIH
BR

-

-

IECINT
(lOS)

-

I
-

I ECVTCCW
CCW
Translation
Fixing

BR

Scheduled via SRB/IOSB

IECVPST
BALR
SRB/IOSB (input parameter)

.'

EXCP Driver

-

IECIOSCN

-

(lOS)

BR

IECVSMGR
Gets storage
for IOOE U/O
Queue Element)

BR

• POST
• Appendage Interface
.IECVTCCW
- Retranslation
- Unfixing
.IECVSMGR
- Free blocks

EXCP Driver

Dispatcher

User

Figure 5-4.

5-26

BR

I/O Processing Overview

MVS Diagnostic Techniques

IECVSMGR
Frees IOOE

cvr
8C cvrrLcH

Virtual
channel
program

rOB
rOBSTART

o~

ROE

roo
~ Last roo

iI

4

[0 +uca

1st

( ....-- f - , - - - - - I

SRB

4

I

I
I
I

81 SRMscal

\ . . ~lOO

10SB

8
C
f------I

10

/
(

DCBDEBAD

ROEIOB

8

ASCB

rOOrOSB

rOSUCB

I
I

I
I
I

I

UCB Prefix

I

I
I

1C

rOSSRB

D

1-----1

I

I•

.••.... __I - - - - - - l

20

UCB

EWA
34 1--1O_S_E_RP----l· -----~II....._

f-----:-I

IOSUSE - -----------------------./

__

--l

14
48

IOSRST
(real)

4C

rOSVST
(virtual)

Common UCB
Extension

D
Figure

5-5.

4

TCCWUCB

CHAN PGM

8

TCCWBEB

8

C TCCWFZX

I~
I
I
,.,.J
CCWn

BEB

FZX

I

!.•.._.,,,.•

Major lOS and EXCP Control Block Relationships

Section 5. Component Analysis

5-27

lOS ABEND Codes
lOS abends are generally caused by an invalid control block. The error can be
caught by validity checking or it can cause a program check. The recovery
routines, generally FRRs, receive control on a program check. For either a
validity check or a program check~ the error is converted to an abend code.
EXCP FRR processing saves the abend code and the relevant status (that is, error
PSW, and error registers) at the time of errbr in the EXCP problem determination
area, which is pointed to by the TCB (X'CO'). lOS abend codes are documented
in Message Library: System Codes. The EXCP problem determination area is
documented later in this section in the topic "The EXCP Debugging Area." A list
of lOS abend codes and issuing procedures is found in the topic "Wait State
Codes."
Note: During abend processing, the EXCP problem determination areas are not
freed. When you find the area pointed to by the TCB, scan that area for
previously-obtained areas to help with lOS analysis.

Loops
If an invalid control block is passed to lOS and it is not caught by the validity
check routines, a loop is often the result. The traditional problem has been
caused by a driver that reuses the 10SB before its first use is complete.
Consequently, the requestor initializes the block and overlays some fiel4 whose
use is not complete. On occasion the block is cleared to zeros. The fact that
most of the I/O process runs -in supervisor state, key 0 means that the PSA can be
overlaid. This usually causes a program check loop whenever any type of
interrupt is subsequently received by the processor.
At this point, pattern recognition is important to determine whether the storage
manager has been involved in the problem. (Pattern recognition is discussed in
the "Miscellaneous Debugging Hints" chapter in Section 2.) Try to determine
whether 0 has been used as the address of an SRB/IOSB or EWA control block.
The first X'AO' bytes of PSA may be affected. The routine responsible for this
could be an lOS driver or recovery routine. Look for addresses of exit routines
which are pointed to by the 10SB; they give an indication of the driver and
potentially some idea of the process. Remember that the hardware stores the
current PSW as an old PSW (at locations X'18' - X'40') if any interrupt occurs.
Therefore these locations may not look bad.
Often double freeing has occurred some time earlier, which makes the recreation
of the erroneous process very difficult. Extensive analysis and piecing are
required. Multiple dumps may help provide the pieces necessary to recognize a
pattern or common occurrence. Or, a trap might have to be devised.
If there is evidence of a recent error in the I/O process, searching the in-storage
LOGREC buffer or SYSl.LOGREC records for an lOS error helps recreate the
process. Generally the lOS recovery routines attempt to free control blocks and
might inadvertently free one that has just been freed. Try to determine if there is
any way that the channel scheduler or I/O driver and its associated exits could
have freed blocks before or after recovery processing. In a retry situation, normal
termination procedures could have freed a block that was already freed by
recovery. Again, traps might be required.

5-28

MVS Diagnostic Techniques

~

lOS WAIT States
Another problem is an enabled wait state with work remaining for lOS to
accomplish. For a list of lOS wait state codes and the procedures that issue them,
refer to the topic "Wait State Codes" later in this section. To analyze a wait
state, it is necessary to determine the current status of lOS.
To determine current lOS status, scan the UCBs for valid IOQEs in UCBIOQ
(UCB-4). The 10QE is valid if UCBPST (UCB + 6, bit X'20') is on. The 10QE
address is valid only when it is active. Understand that once a block is freed, it is
generally reused quickly when a subsequent request for an I/O operation is
encountered. Because of this, it is very uncommon to find a significant IOQE
pointed to by the UCB prefix once lOS has returned the block. The block usually
represents another request. If the UCB pointer in the IOQE does not equal the
address of the UCB you started with, the blocks have been reused and the data is
invalid.
Additionally the 10QEs can be found in the storage manager areas. These are
located by CVT + X'7C' which points to 10COM + X'24' which points to module
IECVSMGR. Label IECVSHDR is an external symbol for the storage pool
headers for small blocks (IOQEs). These are followed by the pool headers for
medium (RQEs) and large (SRB/IOSBs, BEB, TCCW, ERPWA, fix lists) blocks.
The pool headers are 16 bytes long and the last word points to segment headers
for 2K bytes (small block) or 4K bytes (medium and large blocks) of storage.
The 10QE + 5 contains an allocated indicator. If all X'3C' bits are on, the block
is allocated and, in the case of 10QEs, represents I/O requests that are started or
that have been requested by a driver but have not been started because of a busy
or not ready condition (UCBFLA).
After the storage manager (medium and large) blocks are found, notice their
8-byte prefixes, the first halfword of which contains the ASID of the address
space to which the block is allocated. Note that the ASID is 0 when the block is
not allocated and in special cases such as when unsolicited device ends are not
associated with any address space. Scanning these prefixes for an ASID that
matches the problem address space can help in finding blocks associated with I/O
requests related to that address space. Medium and large blocks that contain a
X'I7' in the fourth byte of the prefix are not allocated. A value of X'75' for
medium blocks, and X'76' for large blocks, indicates that they are currently
allocated. (Note that the third byte of this first word of the prefix is unused.)
The 10QE points to the associated 10SBs which contain information about the
channel programs and pointers to the requestor's control blocks.
In general, UCBs and associated IOQEs/IOSBs indicate active I/O. Any flag bits
set in the UCB + 6/7 help identify the status of the requestor. Also, investigate
UCB flags indicating the quiesce option, DAVV (direct access volume
verification) processing, I/O restart, missing interrupt handler (MIH), or message
pending.
Another place to look is the LCHs (logical channel queues). When a STARTIO
macro is issued, if both the channel and device are available, lOS attempts to
issue the SIO instruction. If any bit in UCBFLA (UeB + 6) is on, the device is
considered busy. The TCH instruction IS used to determine if the channel is busy.
If either is busy, the IOQE for the request is queued to the LCH. This queue then

Section 5. Component Analysis

5-29

indicates all requests that have been accepted for processing but for which either
no SIO has yet been issued or an SIO was issued but a non-zero condition code
was received. The first LCH is pointed to by CVT + X'8C'. Each LCH is X'20'
bytes long. UCBLCI (UCB + X'A') is an index to the LCH for the given UCB.
Each LCH is a double-headed, single-threaded queue of 10QEs. The LCH +0
points to the first 10QE and LCH +4 points to the last, or only,. 10QE. If
LCH +0 is' all Fs or Os the queue is empty, in which case there are no requests for
that channel. The 10QEs themselves are linked with 10QELNK (IOQE + 0).
10QEIOSB (IOQE + 8) points to the 10SB for the request it represents. Note that
10QENQ (lOQE + 4, bit X'40') must be on for all 10QEs on the LCH.

General Hints For lOS Problem Analysis
1.

Saveareas. lOS does not use save areas in the standard manner. When
registers are saved, the order is often 0-15 at offset 0 into the save area. If the
local lock is obtained (as is generally the case), IECVPST, the first module to
execute in the user's address space after an I/O interrupt, uses the local lock
save area (ASXBFSLA at ASXB + X'24') to pass the address of the loc~illock
save area to the exit routines. An exception is I/O interrupt processing for a
paging pack where an lOS storage manager or ASM area is used. Basic lOS
uses the lOS save area (LCCA + X'218' points to the CPU work save area
vector table (WSAVTC); WSAVTC + X'18' points to the lOS 'saye area).
This save area is also passed to DIE (Disable Interrupt Exit) routines. Also,
the TCCW control block contains a save area. EXCP passes the address of
the associated TCCW + X'48' (in Register 13) to appendages for use as a save
area.

2.

EXCP back-end processing does all the interfacing to the traditional
appendages. In MVS, appendages are entered in SRB mode, physically
enabled, and with register 13 containing the address of a save area.

It is EXCP's responsibility to map the 10SB to the lOB to maintain
compatibility. Also on return from the appendage, EXCP re-maps the lOB to
the 10SB.
3.

The EWA (ERP work area) can be important in problem analysis. The
10SB + X'34' points to EWA, which contains information, including sense
data, passed to the ERPs from lOS as well as work areas and counters for the
ERPs. The ERPIB, which is useful for channel errors, is contained in the
EWA.
See the topic "Error Recovery Procedures (ERPs)" later in this section for a
description of ERP processing.
Several problems have been uncovered where ERPs constantly retry an I/O
operation that constantly fails. The EWA can contain the number of retries
and other control information helpful in determining the reason why. EWAs
often contain the retry CCWs.

4.

5-30

The LCCA of each processor contains an lRT (lOS recovery table). lOS uses
various fields in the lRT to checkpoint i.ts progress. The lRT also contains
pointers to the active control blocks on whose behalf lOS is processing.

MVS Diagnostic Techniques

~

5.

Two 10SB flags (IOSEX, 10SERR) are used to control error processing. For
a permanent error the general flow is:
•

Abnormal or normal exit initially entered with 10SCOD = 7F, 10SEX = 0
or 1, 10SERR=0.

•

ERP exit entered with IOSCOD = 7F, IOSEX = 1, IOSERR = O.

•

SVC F or branch entry back to IECVPST for direct access (DA) ERP:
with IOSERR = 1, IOSEX =0 for retry
with IOSERR = 0, IOSEX = 1 for permanent error

•

Assuming retry, SVC F issues STARTIO.

•

At I/O completion, IECVPST returns control to ERP with 10SERR = 1,
10SEX= 1.

•

ERP returns to IECVPST with 10SERR=0, 10SEX= 1 to indicate a
permanent error.

•

IECVPST enters abnormal exit for second time with 10SCOD = 41,
10SERR = 0, IOSEX = 1.

•

Abnormal exit returns to IECVPST for termination processing.

In general, the 10SB flag settings are defined as:
IOSERR = 0
IOSEX=O

no error or corrected error

lOS ERR = 1
IOSEX= 1

ERP retry in progress

lOS ERR = 1
IOSEX=O

ERP requesting retry

IOSERR=O
IOSEX=l

permanent error

6.

I/O error processing during ACR has caused several problems. The chapter
"Miscellaneous Debugging Hints" in Section 2 addresses the ACR processing
and potential exposures.

7.

Check the trace table for unit check/unit exception interrupts. These
interrupts often cause abnormal processing which may contribute to the
problem. (For information on "MVS Trace Analysis," see that chapter in
Section 2.) The fourth word of the SIO trace entry is the 10SB address
associated with the I/O request. The SRB + X' 1C' points to the IOSB address
associated with the interrupt that caused the post status module (IECVPST)
to be scheduled.

8.

Check the LOGREC created by lOS modules (the CSECT name in the record
will be an lOS module name). Register 2 quite often is the 10SB address
associated with a request to be processed at the time of error.

Section 5. Component Analysis

5-31

9.

Prior to SU64, a channel on processor 0 was distinguished from a channel
with the same number on processor 1 by the processor address. This address
is contained in such fields as UCBCPU and EWACPU. With channel set
switching, the channel set ID is not used to distinguish between two similarly
numbered channels. As a result, control block fields contain the channel set
ID even though the field name is shown as 'CPU'.

10. By using the GTF CCW trace option, you can trace the CCWs associated
with a given SIO or I/O operation along with data to show what was
presented to the channels. The EWAs (see hint 3) and the 10SB (see hint 5)
can be printed as part of the trace information.

lOS Diagnostic Aids
Both EXCP and lOS diagnostic aids are described in this chapter under separate
headings. For detailed information about lOS modules and procedures, refer to

I/O Supervisor Logic.
Table of EXCP Abend Codes
The following table lists abend codes with the lOS module and symbolic names of
the EXCP procedures that issue them. For the meanings of the abend codes, refer
to System Codes.

5-32

Code

Module

Procedure - Name

X'15C'

IECVEXCP

XCPOOO - Validity check

X'l72'

IECVEXCP

XCPOOO - Validity check

X'200'

IECVEXPR

XCPFRR - Functional recovery

X'300'

IECVEXCP

XCPOOO - Validity check

X'400'

IECVEXCP

XCPOOO - Validity check

X'500'

IECVEXCP

XCPOOO - Validity check

X'700'

IECVEXCP
IECVEXPR

XCPTER - Termination
XCPFRR - Function recovery

X'800'

IECVEXCP
IECVEXCP
IECVEXCP

XCPPFA - PGFX interface
XCPTERM - Termination
XCP115 - Translation interface

X'AOO'

IECVEXCP
IECVEXPR

XCPTERM - Termination
XCPFRR - Functional recovery

X'BOO'

IECVEXPR

XCPFRR - Functional recovery

X'C22'

IECVEXCP

XCP035 - Get RQE

X'EOO'

IECVEXCP

XCPTERM - Termination

MVS Diagnostic Techniques

EXCP Debugging Area (XDBA)

EXCP's functional recovery procedure, XCPFRR, does not put diagnostic data in
the SDUMP buffer. Instead, it gets storage for its own debugging area (the
XDBA) and puts diagnostic data there. (Note that an XDBA is not provided for
EOO abend codes.)
To locate the debugging area (XDBA) in a SYSABEND, SYSMDUMP, or
SYSUDUMP dump, you must:
1.

Get the address of the CVT from location X'4C' (PSA field FLCCVT2) in the
dump.

2.

Get the address of the TCB from the first word of the CVT (CVTTCBP).

3.

Look X'CO' bytes into the TCB (TCBEXCPD) and get the address of the
de bugging area.

4.

If the address of the debugging area is zero then no debugging area is
available.

The format and contents of the EXCP debugging area (XDBA) are as follows:
Byte Contents

o

The ABEND code that EXCP issued.

2

A byte that shows where the error occurred. These are the possible bit settings and their
meanings:
X'80':

The error occurred while EXCP was preparing to send an I/O request to lOS.

X'40':

The error occurred while EXCP was processing an I/O request that lOS was finished
with.

X'21':

The error occurred in a PCI appendage.

X'll':

The error occurred in a CRE appendage.

X'09':

The error occurred in an ABE appendage.

X'05':

The error occurred in an EOE appendage.

X'03':

The error occurred in a PGFX appendage.

X'OI':

The error occurred in an SIO appendage.

3

Reserved

4

The PSW before RTM was entered. (RTM is entered when a program check occurs or when an
ABEND macro is issued.)

C

Reserved

E

ABEND code at entry to the FRR.

10

The register contents before RTM was entered.

50

Translation exception address.

54

The RQE for the I/O request that was being processed.

7C

XDBA chain pointer

Section 5. Component Analysis

5-33

The remainder of the debugging area contains up to twelve 160 byte blocks
involved with the EXCP request. If these blocks are present, they appear in the
following sequence:
EWA
SRBjIOSB
TCCW
IDAL
FIX list
BEB

The first 160 bytes following the last block are zero. The SRB and TCCW are
valid only if the address of the RQE within these blocks is valid.
Note: For errors that occur in the PCI appendage during disabled interruption
exit (DIE) processing, IOCIOSCN provides a SYSl.LOGREC record and an SVC
dump. The r~gister contents and PSW at the time of the original error are
contained in the SYS1.LOGREC record and the dump. EXCP uses the DIE exit
when processing V = Rand EXCPVR requests.
SDWA Variable Recording Area

The format and contents of the SDWA variable recording area are as follows:
Byte

(offset in
SDWA)

Contents

194
196
198
19C
1B4

original ABEND code
adjusted ABEND code set by XCPFRR
highest lock held word from the PSA
contents of the 6 word FRR parameter area
contents of the active RQE
TCCW option byte
TCCW translation flag byte
IOSB completion code from the IOSCOD field
reserved
ASID of the EXCP request

1DC
lDD
IDE
IDF
lEO

Output of lOS Recovery Procedures
Functional (FRR) and ESTAE recovery procedures can record their virtual
storage environment by two means:

5-34

•

By issuing an SDUMP macro, which causes the contents of the 4K SDUMP
buffer to be written in a SYS1.DUMP data set. (There are ten SYSl.DUMP
data sets, SYSl.DUMPOO-09.)

•

By issuing a SETRP macro, specifying RECORD=YES, which directs RTM
to write the SDWA in the SYSl.LOGREC data set.

MVS Diagnostic Techniques

Some Facts about SYSl.DUMP Dumps
To format a dump for a SYSl.DUMP data set, use the AMDPRDMP service aid.
If the dump contains an SDUMP buffer record that was put in the SYSl.DUMP
data set by an lOS recovery procedure, each page will be titled "lOS-module name
ERROR," where module name identifies the module to which the recovery
belongs.
To locate the SDUMP buffer record, you must:
1.

Get the address of the CVT from location X'4C' (PSA field FLCCVT2) in the
dump.

2.

Look X'24C' bytes into the CVT (CVTSDBF) and get the address of the
SDUMP buffer record.

The third halfword of the SDUMP buffer record tells you how much of the 4K
bytes contains meaningful data; six bytes of zeros mark the end of the meaningful
data.
Some Facts about SYS1.LOGREC Dumps
To get a dump of the SYSl.LOGREC data set, use the IFCEREPI service aid.
IFCEREPI formats the standard area - the first 404 bytes - of each SDWA into a
series of titles, each followed by pertinent data found in the standard area. (For
example, under the title Component/Module/ Name/ID, you would find the
module name IECIOSCN if the functional recovery procedure of the basic lOS
module wrote in the SDWA.) IFCEREPI puts the variable area - the last 108
bytes - of each SDWA in a decimal or hexadecimal format, whichever you
request.
The remaining topics in this section describe the output - the SDUMP buffer
record and SDWA variable areas - of lOS recovery procedures. Before looking at
the descriptions for the first time, note these facts:
•

Offsets into SDUMP buffer records and SDWA variable areas are given in
hexadecimal numbers.

•

The formats of data areas listed as part of an SDUMP buffer record or
SDWA variable area are shown in the microfiche document Data Areas,
unless stated otherwise.

Output of the Basic lOS Module (IECIOSCN)
The module's functional recovery procedure, IECFRR, puts one or more of these
settings in byte 6 of the SDUMP buffer record:
X'80',

indicating that an IRT is in the record, beginning at byte 8.

X'40',

if a UeB is in the record.

X'20',

if an IOQ is in the record.

X'IO',

if an IOSB is in the record.

X'08',

if a logical channel queue, the header of the "small block" pool, and the first 2048-byte
segment of the pool are in the record.

Section 5. Component Analysis

5-35

If a UeB lock was held when IECFRR was entered, the UCB associated with
that lock appears in the record. If an LCH lock was held when IECFRR was
entered, the· LCH associated with that lock, the header of the "small block" pool,
and the pool's first 2048-byte segment is included. Ifan I/O request was being
processed, its 10Q and 10SB appears. These data areas appear in this order:
UCB, 10Q, 10SB, logical channel queue, "small block" pool header, first "small
block" pool segment.
Other 4K records and the output of IECFRR follow the SDUMP buffer record in
the dump. These records contain the SQA (system queue area), the system's trace
tables, and the nucleus.
IECFRR puts the following data in the variable recording area of the SDWA:
At byte 0:

X'80', if an IOQ is in the SDWA. X'40', if a UCB is in the SDWA.

At byte 1:

the code that was returned when IECfrr issued an SDUMP macro to write in the
SYS1.DUMP data set. (X'FF' means nothing was written.)

At byte 4:

an IOQ, if an I/O request was being processed when IECFRR was entered.

At byte 10:

a UCB (prefix segment included), if a UCB lock was held when IECFRR was entered.

Output of the Build Reserve Table Module (IECVBRSV)
The functional recovery routine (BRSVFRR) of IECVBRSV issues an SDUMP
macro requesting an SQA, nucleus, all PSAs and a summary.
BRSVFRR puts the 24-byte FRR parameter area into the SDWA variable
recording area.
Output of the DAVV Module (IECVDAVV)
The module's ESTAE recovery procedure, DAVVESTA, puts the following data
in the SDUMP buffer record:
At byte 6:

the SRB being processed when it was entered.

At byte 32:

the IOSB being processed when it was entered.

At byte 9E:

the ERP work area used by DAVV. (The work area includes the common segment,
EWA, and the direct-access segment, EWD.)

At byte 13E:

the UCB (prefix segment included) used in the processing that preceded the error.

DAVVESTA puts the following data in the variable area of the SDWA:

5-36

At byte 0:

the IOSB being processed when it was entered.

At byte 6C:

X'04', a code indicating that DAVVESTA asked RTM to return control instead of
continuing termination processing.

MVS Diagnostic Techniques

Output of the Dynamic Pathing Initialization Module (lECVIOSI)
This module's ESTAE procedure (IOSIRECV) issues the SDUMP macro.
IOSIRECV puts the following data in the variable recording area (SOWAVRA)
of the SOWA in a key-length-data format:
•
•
•
•
•
•

Component 10
Date and SU or PTF 10
ENF parameter list (ENFPM) or EVARY parameter list
Flag field (includes ENF and/or ESTAE return codes)
ESTAE parameter list
Path group 10 field, if created

Output of the Dynamic Pathing Module (IECVDPTH)
This module's functional recovery procedure (DPTHFRR) issues the SDUMP
macro.
DPTHFRR puts the following data in the variable recording area (SOWAVRA)
of the SOW A in a key-length-data format:
•
•
•
•
•

Component 10
Date and SU or PTF 10
Parameter list (EVARY)
Footprint and flags fields (FLAGSDP)
Path group 10 field (HOSTIDEN)

If IECVDPTH cannot complete the dynamic pathing request, an OBR-DPA
record (type X'3A') is written to SYSl.LOGREC. The device-dependent data in
the record contains the following two 12-byte fields:
First field:

1 byte
11 bytes

.. Function control byte (contains the requested function)
.. Path group ID for the system

Second field:

1 byte
.. Function control byte (contains the status of the path)
11 bytes .. Path group ID for the path, if one exists

Output of the Force Device Module (IECVFDEV)
This module's functional recovery routine (FDEVFRR) issues the SDUMP
macro.
FDEVFRR puts a copy of the FRR work area in the variable recording area
(SDWAVRA) of the SDWA in a key-length-data format.

Section 5. Component Analysis

5-37

The FRR work area contains:
Word
Word
Word
Word

0:
1:
2:
3:

Word 4:
Word 5:

DCB common address.
Module base register.
Data pointer register.
Flags and footprints:
Function indicator flags:
Byte 0:
X'80' DCB lock held.
X'40' Device to be boxed.
X'20' Device to be released.
Byte I:
Footprints:
X'80' Initialization complete.
X'40' DCB data stored.
X'20' Halt data transfer complete.
X'IO' DCB lock released - Clear reserve complete.
X'08' Dynamic pathing call is complete.
X'04' Simulation of interrupts is complete.
X'02' FRR entered due to an error.
Byte 2:
Reserved.
Byte 3:
Reserved.
Reserved.
DCB lockword address.

Output of the Force Channel Offline Module (IECVFCHN)
This module's functional recovery routine (FCHNFRR) issues the SDUMP
macro.
FCHNFRR puts the following data in the variable recording area (SDWAVRA)
of the SDWA in a key-length-data format:
•

A copy of the FRR work area, which contains:
Word 0:
Byte 0:
Byte 1:
Byte 2:

Word
Word
Word
Word
Word

•

1:
2:
3:
4:
5:

Channel set ID.
Channel number.
Function indicator flags:
X'80' The other processor receives control through EMS SLIH due to
RISGNL.
X'40' The error occurred while the other processor was in control.
X'20' Do not retry RISGNL.
X' 10' Free any extra reserve table segments that were obtained by the
build reserve table routine.
X'08' The IEAOl9A message was issued.
X'04' The clear channel instruction was issued.
X'02' SALLOC lock held.
Byte 3:
Footprint indicator flags:
X'80' Initialization completed.
X'40' Force channel offiine subroutine entered.
X'20' Load wait state subroutine entered.
X'IO' Free reserve table segments subroutine entered.
Module base address.
Module workarea address.
Module savearea address.
FRR retry address.
FRR 200-byte workarea pointer.

The first reserve table segment if any devices were entered in the reserve table
segment.

FCHNFRR loads a nonrestartable wait state if reserves have been released
without rereservation.

5-38

MVS Diagnostic Techniques

Output of the lOS Restart Support Module (IECVRSTS)
This module's functional recovery routine (RSTSFRR) puts the following data in
the variable recording area (SOWAVRA) of the SOWA in a key-length-data
format:
•

A copy of the FRR work area, which contains:
Word 0:
Word 1:
Word 2:
Word 3:
Word 4:
Word 5:

SRB address.
The SRB and module work area serialization byte address.
FRR retry address.
MIH message block queue pointer.
IECVRSTS caller's return address.
Byte 0:

•
•
•

Footprint indicator flags:
X'SO' Redrive I/O requests segment is entered.
X'40' IOSGEN macro is invoked to mark all generated channels on the
current processor for restart.
X'20' IOSINTRP macro is invoked to simulate a channel available
interruption for the current processor.
X' 10' There is a second processor.
X'08' 10SGEN macro is invoked to mark all generated channels on the
second processor for restart.
X'04'
RPSGNL macro is invoked to shoulder tap the second processor.
X'02' Scan MIH message queue segment is entered.
X'OI' Terminate address space segment is entered.

The contents of the input SRB.
The OCCB, if the scan MIH message queue segment has received control.
The DCCBMSGS, if the scan MIH message queue segment has received
control.

Output of the Hot 1/0 Recovery Module (IECVHREC)
This module's functional recovery procedure (HRECFRR) takes an SDUMP but
puts no data in the SDUMP buffer.
HRECFRR puts the following data into the variable area of the SDW A:
At byte 0:
At byte 32:

A copy of the SCD.
A copy of the FRR work area, which contains the following:
first base register
word 0:
word I:
second base register
SRB pointer
word 2:
word 3:
work area pointer
SCD pointer
word 4:
word 5, byte 0:
Flags
X'ot'
reserved
X'02' reserved
X'04' FRR recursion indicator
X'08' address of work area is valid
X'IO' reserved devices found, message IEA42lE not yet issued
X'20' channel can be enabled
X'40' channel was reset, re-reserves not complete
X'SO' SALLOe lock held
word 5, bytes 1-3: reserved

Section 5. Component Analysis

5-39

Output of the I/O Restart Module (iECVIRST)
The functional recovery procedures, (lRSTFRR), of this module issues an
SOUMP macro requesting SQA, the nucleus, and the 4K buffer to be dumped.
The work area (storage area retrieved via GETMAIN that holds the compiler's
automatic data) is copied to the 4K buffer along with each reserve table segment.
IRSTFRR puts the following data in the variable area of the SOWA:
At byte 0:

The 24 byte FRR parameter area returned by the SETFRR macro.

At byte 24:

Halfword channel mask. Each bit in the halfword channel mask corresponds to a given
channel.
(Bit 1 corresponds to channel 1

••
•

Bit 16 corresponds to channel 16.)
If a bit is on, the corresponding channel encountered an error.

IECVIRST loads one or more wait states. For each loaded wait state, a system
termination record is written to the SYSl.LOGREC data set. Note: this record
may not appear in the data set since the system may not be able to perform I/O
operations before the wait state is loaded. It appears in the SYSl.LOGRBC
buffer located in the SQA in storage. The mapping macro, IHALRB, maps the
system termination record. The variable area within the system termination
record contains:
At byte 0:

Current registers (0-15)

At byte 64:

The 24 byte FRR parameter area returned by the SETFRR macro.

At byte 84:

Halfword channel mask. Each bit in the halfword channel mask corresponds to a given
channel.
Bit 1 corresponds to channel 1

••
•

Bit 16 corresponds to channel 16.)
If bit is on, the corresponding channel encountered an error.
At byte 86:

Halfword channel set id.

Output of the Nonresident Halt-I/O Module (IGC0003C)
The module's functional recovery procedure, HALT0900, writes no SOUMP
buffer record. If HALT0900 is the first recovery procedure entered by RTM, it
writes the following data in the variable area of the SOWA:

5-40

At byte 0:

the contents of register 0 and 1 when the module was entered to halt a teleprocessing
operation.

At byte 8:

the IOQ for the teleprocessing operation.

At byte 14:

the DeB (prefix segment included) for the teleprocessing device.

MVS Diagnostic Techniques

Additionally, HALT0900 directs RTM to put trace data, task-related data areas,
and all the IECIHIO code in a user dump (SYSABEND, SYSMDUMP, or
SYSUDUMP), if such a dump was requested.
Output of the Nonresident Purge Module (IGCOOOIF)
The module's functional recovery procedure, PURGEFRR, puts data in the
SDUMP buffer, but the module's ESTAE recovery procedure, PRGESTAE,
writes the contents of the buffer into the SYSl.DUMP data set. PURGEFRR
puts the following information into the SDUMP buffer:
At byte 10:

the PPL.

At byte 20:

the IPIB.

At byte 50:

a work area whose contents include a variable number of saved registers, a list of pages
to be fixed, and the list forms of macros used by the module.

At byte 140: if the module holds a UCB lock, the UCB (prefix and common segments only) associated
with that lock.
At byte 160: if the module holds an LCH lock, the logical channel queue associated with that lock and
all the IOQs on the logical channel queue.

PURGEFRR puts the following data into the variable area of the SDWA:
At byte 0:
At byte 8:
At byte 16:

IGCOOOIF (the module name).
IGC016 (the module's entry point).
PURGEFRR (the recovery procedure's name and entry point).

PRGEST AE puts the same data in its SDWA, except at byte 16, where it writes
its own name.
Output of the Post-Status Module (IECVPST)
The module's functional recovery procedure, PSTFRRTY, puts at byte 6 of the
SDUMP buffer record the IOSB that was being processed when the error
occurred.
PSTFRRTY puts the following data in the variable area of the SDWA:
At byte 0:

the IOSB that was being processed when tbe error occurred.

At byte 6C:

IECVPST (the module name).

At byte 73:

X'04', a code indicating that PSTFRRTY asked RTM to return control instead of
continuing termination processing.

At byte 74:

the address of the IOSB.

At byte 78:

the address of the FRR work area.

At byte 7C:

the contents of the base register.

Output of the Redrive 1/0 Service Routine (IECVRDIO)
The module's functional recovery procedure, RDIOFRR, puts at byte 6 of the
SDUMP buffer record the general work area used for automatic data.

Section 5. Component Analysis

5-41

The following is placed in the variable area of the SDWA:
At byte 0:

a copy of the 24-byte FRR work area pointed to by SDWAPARM.

Output of the Re-Reserve Service Routine (lECVRRSV)
The module's functional recovery procedure, RRSVFRR, writes no SDUMP
buffer record. The following is placed in the variable area of the SDWA:
At byte 0:

a copy of the 24-byte FRR work area pointed to by SDWAPARM.

Output of the Resident Halt-I/O Module (lECIHIO)
The module's functional recovery procedure, HIOFRR, puts at byte 6 of the
SDUMP buffer record the UCB (prefix segment included) for the device on which
a channel program was to be halted. Following the SDUMP buffer record in the
dump are other 4K records written by HIOFRR. These contain all the IECIHIO
code, the PSA or prefixed save area (the first 4K bytes of low storage), and the
system's trace tables.
HIOFRR puts the following data in the variable area of the SDWA:
At byte 0:

X'OC', if the error occurred in the shoulder-tapped processor; otherwise, the code that
was returned when HIOFRR issued an SDUMP macro to write in the SYS1.DUMP data
set. (X'FF' means nothing was written to the SYSl.DUMP data set.)

At byte 1:

the UCB (prefix included) for the device on which a channel program halted.

Output of the Special SIO Module (IECVESIO)
This module's functional recovery procedure, ESIOFRR, does not use the
SDUMP buffer. However, the following is placed in the variable area of the
SDWA.
At byte 0:

The 24-byte FRR parameters.

Output of the Storage Manager Module (IECVSMGR)
This module's functional recovery procedure, IECVSMFR, puts at byte 6 of the
SDUMP buffer record the pool headers for the "small block," "medium block,"
and "large block" pools.
Following the SDUMP buffer record in the dump are other 4K records written by
IECVSMFR. These contain the SQA (system queue area), the system's trace
tables, and the code in the IECVSMGR module.
The output of the system's queue verification routine is in the variable area of the
SDWA. IECVSMFR passes the variable area to that routine for use as a QVOD
(queue verification output data area). The free queue for small, medium, and
large blocks is moved to SDWA.
Output of the Unconditional Reserve Detection Module (IECVURDT)
This module's functional recovery procedure does not use the SDUMP buffer.
However, the following is placed in the variable area of the SDWA.
At byte 0:

5-42

MVS Diagnostic Techniques

The 24-byte FRR parameters.

Output of the Unconditional Reserve Service Module (IECVURSV)
This module's functional recovery procedure does not use the SDUMP buffer.
However, the following is placed in the variable area of the SDWA.
At byte 0:

The 24-byte FRR parameters.

Output of the Resume 1/0 Service Routine (IOSVRSUM)
The module's functional recovery procedure, RSUMFRR, places the following in
the VRADAT A field of the SDWA:
•

The IOSB that initiated the request. (If there is not an IOSB, "IOSB ZERO"
is put in VRADATA.)

•

The DCB associated with the request. (If there is not a DCB, "DCB ZERO"
is put in VRADATA.)

Informative 10SB Fields
An examination of three IOSB fields, 10SDRVID, 10SPROC, and 10SCOD,
answers these questions:
1.

Did lOS create the 10SB, or did one of its drivers create it? If one of the
drivers, which one?

2.

If lOS created the IOSB, why did it?

3.

If a driver created the 10SB, what does the 10SB show about the status of
the I/O request it represents?

The 10SDRVID field answers (1), the 10SPROC field answers (2), and the
10SCOD field answers (3).
The 10SDRVID Field
IOSDRVID is a one-byte field at an offset of four bytes into the 10SB. The
possible contents and their meanings are:

,
~l

Contents

Meaning

X'OO'

lOS created the IOSB.

X'Ol'

The driver wants to be anonymous to lOS because it doesn't want to take part in certain
kinds of I/O processing. (For example, the driver might not want to be called to dispose of
the 10SB during a purge operation.)

X'02'

EXCP is the driver.

X'03'

ABP (VSAM) is the driver.

X'04'

VTAM is the driver.

X'OS'

TCAM is the driver.

X'06'

OLTEP is the driver.

X'07'

Program fetch is the driver.

X'08'

JES3 is the driver.

X'09'

MSC is the driver.

X'OA'

IECVIOPM is the driver.

X'OB'

VPSS is the driver.

Section 5. Component Analysis

5-43

X'OC'

CRYPTO is the driver.

X'OE'

ASM is the driver.

The IOSPROC Field
IOSPROC is a one-byte field at an offset of three bytes into the IOSB. The field
is used as an index to a branch table in the post status module (IECVPST). The
possible contents and what they tell about the IOSB are:
Contents

What They Tell about the IOSB

X'OO'

Indicates "normal" non-lOS generated 10SB.

X'04'

The 10SB was created by EDIEINTl when a PCI interruption occurred without other
status information. It was marked X'04' to direct PSTIOSB to enter the driver's PCI
appendage.

X'08'

The 10SB was created by EATTENTl when tests of the CSW, UCB, and attention table
indicated that control should be routed to an attention routine. The 10SB was marked
X'08' to direct PSTIOSB to branch to the attention routine for the device.

X'OC'

The 10SB was created by LCHPURG to replace a purged 10SB for an I/O operation that
must be completed - a sense, reserve, or release operation. After the I/O operation is
completed, PSTIOSB sees the the X'OC' and enters FREEBLK, which frees the 10SB.

X'lO'

The 10SB was created by EDEVENDl when called by IECVXDAS because a direct-access
device was readied. It was marked x'to' to direct PSTIOSB to enter IECVDAVV via the
exit effectors and ERP loader.

X'14'

The 10SB was created by EPOSTIOI when it determined that a message must be sent to
the operator about the availability of the device. The 10SB was marked X'14' to direct
PSTIOSB to enter, via the exit effectors and ERP loader, the ERP message"writer
(IGE0025C).

X'20'

The 10SB was created by EDETECTl when it determined that unconditional reserve
recovery was needed. It was marked X'20' to direct PSTIOSB to enter IECVURDT and
IECVDURP.

The IOSCOD Field
IOSCOD is a one-byte field at an offset of five bytes into the IOSB. The possible
contents, with explanations of what they mean are:

5-44

Contents

Explanation

X'41'

An ERP, the ABE appendage, or the CHE appendage detected an I/O error and
determined that is was uncorrectable. (An ERP does not put X'41' in 10SCOD. IGCOl5
does it if, on receiving control from the ERP, it finds the "exceptional-condition" bit
(lOSEX) on, the "retry" bit (lOSERR) off, and X'7F' in 10SCOD.)

X'42'

The EOE appendage detected an extent error and directed the driver to put X'42' in
10SCOD.

X'43'

A paging I/O operation couldn't be started immediately, and the 10SB specified that
I/O-request processing be terminated in such a case. ETCHI compiled by putting X'43' in
10SCOD and scheduling IECVPST. (ABP, on finding X'43', submits a new I/O request to
read a duplicate page on another device.)

X'44'

ETCHl stopped processing the I/O request because its SRB and 10SB were needed to
process a hardware error on the device allocated to the request. (ETCH I does not put
X'44' in IOSCOD. IGC015 does it if, on receiving control from the ERP, it finds the
"exceptional-condition" bit (lOSEX) on, the "retry" bit (lOSERR) off, and X'7E' in
IOSCOD.)

MVS Diagnostic Techniques

X'4S'

I/O-request processing was terminated abnormally. Reasons for the termination are:
•

The IECIOSCN or IECVPST module took a program check.

•

. The operator pressed the RESTART key while an I/O request was being processed.

•

A program check occurred while a nonresident ERP or ERP service module was in
control.

•

A program check occurred in the NRM/ABM exit processing of module, IECVEXCP.

IECFRR, PSTFRRTY, or the ERP loader's ESTAE procedure (ERPLESTA) was entered
by RTM.
X'48'

The I/O request was purged. The driver's purge procedure put X'48' in 10SCOD.

X'4B'

An I/O error occurred when the tape ERP requested that a volume be repositioned. The
ERP put X'4B' in 10SCOD.

X'4C'

In asking for an I/O operation on a specific 2305 exposure, the driver specified an invalid
exposure number in the 10SB. IECVXDRS puts X'4C' in 10SCOD and scheduled
IECVPST.

X'4D'

The driver guaranteed the availability of a path to the device, but when the start-I/O
instruction was issued, the condition code was set to 3 (channel or device not operational).
EPOSTIOI put X'4D' in 10SCOD and scheduled IECVPST.

X'4E'

One of the following occurred:
•

The driver guaranteed the availability of a path to the device, but the device was
reserved to another path.

•

The driver asked lOS to release a device, and in trying, lOS found that at least one
other user of the device wanted it to be reserved.

A device dependent SIO module (IECVXDAS, IECVXDRS, IECVXSKS, or IECVXVRS),
put X'4E' in 10SCOD and scheduled IECVPST;
X'4F'

The driver guaranteed the availability of a path to the device, but ETCH 1 found that the
channel set on that path was not configured. ETCHl puts X'4F' in 10SCOD and
schedules IECVPST.

X'51'

ETCHI determined that the device has been boxed and placed offiine, and scheduled
IECVPST. (ETCHl does not put X'51' in 10SCOD if the driver is EXCP. The ERP is
eventually given control, and if it enters IGCOl5 with the "exceptional-condition" bit
(I0SEX) on, the "retry" bit (I0SERR) off, and X'74' in IOSCOD, IGCOl5 overlays X'74'
with X'51'.)

X'7l'

Set by the direct-access ERP when the sense bytes show a data check and the 10SDRVID
field shows that the driver is program fetch.

X'74'

Set by ETCH 1 when it determined that a device was boxed and placed offiine, and the
request was from EXCP. (X'74' may be altered by IGCOIS. See the explanation for
X'SI'.)

X'7E'

Set by ETCHI when it determined that the SRB and 10SB for the request were needed to
process a hardware error on the device allocated to the request. (X'7E' may be altered by
IGCOIS. See the explanation for X'44'.)

X'7F'

Set the IECHNSCH before the I/O operation was started. If the 10SB has been returned
to the driver's termination procedure, X'7F' signifies that the I/O operation completed
successfully.

,
,~

Section 5. Component Analysis

5-45

Table of lOS Messages
The table below gives the numbers of lOS and ERP messages, identifies the lOS
modules that detect a need for the message, and indicates the non-lOS module
that issues it.
Message

Issued by

Module Detecting Need for Message

IEAOOOA
IEAOOOI
IEAOOll
IEAOO31
IEA0041
IEA0041
IEA0041
IEA0041
IEA018A
IEA019A
IEA0261
IEA066A
IEA067A
IEA068A
IEA069A
IEA070A
IEA071E
IEA0721
IEA073A
IEA151W
IEA151W
IEA151W
IEA151W
IEA410E
IEA410E
IEA421E
IEA421E
IEA427A
IEA4281
IEA4291
IEA438A
IEA439D
IEA440A
IEA442E
IEA4431
IEA444I
IEA446D
IEA604A
IEA605A
IEA6061
IEA9191
IEA9701
IEA9711
IEA9721

IGE0025C·
IGE0025C
IGE0025C
IEAVTRET
IEAVTRET
IEAVTRET
IEAVTRET
IEAVTRET
IEEVLDWT
IEEVLDWT
IEAVTRET
IEEVLDWT
IEEVLDWT
IEEVLDWT
IEEVLDWT
IEEVLDWT
IEEVLDWT
IEEVLDWT
IEEVLDWT
IGFPTERM
IEEVLDWT
IEEVLDWT
IEEVLDWT
IEAVTRET
IEAVTRET
IEAVTRET
IEEVLDWT
IECVDURP
I ECVDURP
IECVDURP
IEEVLDWT
IEEVLDWT
IEEVLDWT
IECLMSGD
IECVIOSI
IECVDPTH
IEEVLDWT
IECVDAVV
IECVDAVV
IECVDAVV
IEAVTRET
IEAVTRET
IEAVTRET
IEAVTRET

EPOSTIOI DAVERR or an ERp··
an ERP
EPOSTIOI
CLEARDEV·"
ACRPROC·"
UCBACT···
LOSTCHAN···
IECVRDIO
IECVRSTS
IECVFCHN
IECVRRSV
IECVHREC
IECVHREC
IECVHREC
IECVHREC
IECVHREC
IECVHREC
IECVHREC
IECVPST
IECVRRSV
IECVRSTI
IECVHREC
IECVFCHN
LOSTCHAN···
IECVIRST
IECVIRST
IECVFCHN
IECVDURP
IECVDURP
IECVDURP
IECVIRST.
IECVIRST
IECVRSTI
an ERP
IECVIOSI
IECVDPTH
IECVIRST
DAVINT
DAVINT
DAVINT
IECVCINT
IECVCRHA
IECVCRHA
IECVCRHD

*This is the ERP message writer.
**IEAOOOA is issued only if an ERP module finds the "intervention-required" bit
on in the sense bytes.
***The message is formatted by another lOS procedure, RECORDIT. It gives
control to lEAVTRER, which schedules lEAVTRET to write the message
asynchronously.

5-46

MVS Diagnostic Techniques

lOS Wait State Codes
The following table lists wait state codes with the modules that issue them. For
the meanings of the codes, refer to System Codes.
Code
X'022'
X'02F'
X'041'
X'04C'
X'04D'
X'04E'
X'066'
X'067'
X'06S'
X'069'
X'06A'
X'06B'
X'06D'
X'06E'
X'06F'
X'OE6'

Issuing Module
DAVESTA (ESTAE Recovery)
PSTWAIT
ACRPROC (ACR Call Procedure)
IECVIRST
IECVIRST
IECVIRST, IECVHREC, IECVRRSV, IECVRSTI, IECVFCHN
IECVHREC
IECVHREC
IECVHREC
IECVHREC
IECVHREC
IECVCINT
IECVRSTS
IECVFCHN
IECVDURP
IECVFCHN

Table of lOS Return Codes
The following table matches a return code with the names of lOS modules that
exit with the code in register 15.
Return
Code
Module Name

Return
Code
Module Name

Return
Module Name
Code

X'OO'

X'OS'

X'24'

IECVESIO

X'28'

IECVESIO

X'2C'

IECVESIO

X'30'

IECVESIO

X'34'

I ECVESIO

X'3C'

IECVESIO
I ECVDPTH

X'04'

~

HIOCCH
IECIHIO
IGCOOOIG
IGCOOO3C
IGC016
SMGFREVR
TCCWROOO
IECVCINT
I ECCONCS
IECVDPTH
IECVESIO
IECVFCHN
IECVIOSI
IECVRRSV
IECVURSV
IOSVLEVL
IOSVSUCB
HIOCCH
IGCOOOIG
IGCOOO3C
IGC016
SMGFREVR
TCCWROOO
TCCWUOOO
TCCWXOOO
IECVCINT
IECCONCS
IECVDPTH
IECVESIO
IECVFCHN
IECVRRSV
IECVURSV
IOSVLEVL
IOSVSUCB

HIOCCH
HIOLOP
IECIHIO
IGCOOO3C
IGCOl6
SMGFREVR
TCCWROOO
I ECVCINT
I ECVDPTH
IECVESIO
IECHFCHN
IECVIOSI

X'OC'

IGCOOO3C
TCCWMOOO
TCCWMIOO
TCCWM300
TCCWM400
I ECVDPTH
IECVESIO
IECVFCHN

X'IO'

IGCOOO3C
IECVDPTH
IECVESIO

X'14'

IGCOOO3C
IGC016
IECVESIO

X'lS'

IGCOOO3C
IECVESIO

X'20'

IGCOOO3C
IECVESIO

Section 5. Component Analysis

5-47

Error Recovery Procedures (ERPs)
This topic describes ERP routines and helps you determine the module
responsible for problem symptoms.
. lOS and ERP Processing

Error recovery procedures (ERPs) are scheduled by the lOS post status routine
(IECVPST). When lOS receives an interrupt with a unit check, unit exception,
incorrect length, program check, chaining check, channel data check, chan,nel
control check, or interface control check, the IOSEX bit (in the IOSB) is turned
on. If the interrupt shows a unit check, the sense information is read into the
ERP work area (EWA).
lOS Sequence

The sequence of lOS post status events is:
1.

Inspect the IOSERR (in the IOSB) to determine if error recovery is already in
progress, if it is, step 2 is bypassed.

2.

Turn on IOSEX (in the IOSB) and issue a BALR to the abnormal end
appendage.

3.

Upon return from the appendage, or if ERP is already in progress:
a. For DASD error recovery - issue a BALR to IECVDERP.
b. For nonDASD error recovery - branch to IEAOEFOO (the exit effector).

4.

Upon return from the ERP, lOS takes action to perform the ERP
requirements listed in step 3 of the following topic "ERP Sequence."

ERP Sequence

The sequence of ERP events is:
1.

The required ERP inspects the status and sense information using an ERP
error interpreter table and an lOS routine referred to as the lOS error
interpreter (IECVITRP).

2.

The lOS error interpreter routine makes a branch vector return to a label
within the ERP for a given error.

3.

For a given error, the ERP determines the requirement for and initiates one
or more of the following actions:
a.
b.
c.
d.
e.

5-48

MVS Diagnostic Techniques

Retry jrestart the channel program
Issue console message IEAOOOI or IEAOOOA
Log the error
Indicate that the error is permanent
Indicate that the error has been recovered

Identifying ERP Module Names

The name of an ERP routine (for nonDASD devices) must be of the form
IGEOxxxx, where xxxx is a positive decimal number. The decimal number xxxx
corresponds to the one-byte binary value in the UCBETI. When an error routine
is needed, this byte is converted to decimal, unpacked, and substituted for the
value xxxx to complete the name. For example, the ERP routine for the IBM
2540 is IGEOOOIC. The UCBETI for a 2540 contains X'OD'. When this byte is
converted to decimal, it becomes a plus 013. When the plus 013 is unpacked, it
becomes FOFIC3, which is printed as OIC to complete the name IGEOOOIC.
How ERP Transfers Control

ERP routines frequently transfer control. They may give control to another load
module of the same ERP, to the outboard recorder (OBR), to an lOS statistics
update routine (IGE0025D), or to the lOS write~to-operator routine (IGE0025C).
The CVT + X'2C' points to the transfer control routine that uses the contents of
register 13 to determine which module should receive control. The technique used
is the same as described in the previous topic "Identifying ERP Module Names."
The contents of register 13 are converted to decimal, unpacked, and placed in the
low-order halfword of IGEOxxxx.· The following table shows a few examples:
Contents of Register 13

Control Given to Module

00000009
OOOOOOOE
00000017
OOOOOOFE
000007D6

IGEOOOOI
IGEOOOID
IGE0002C
IGE0025D
IGE0200F

Abnormal End Appendages

Abnormal end appendages are of critical importance to ERP. Within lOS, the
BALR issued to the appendages is located immediately before a return vector
table. Two important facts are:
•

The ability to modify the necessary control blocks allows the appendage to
tum off error indicators, or to perform error recovery actions, without ERP
being invoked.

•

Because lOS gives control to the appendage via a BALR instruction
immediately before a return vector table, the appendage can branch back to
lOS as follows:
Return register + 0·- 10BFLAGl in the lOB is examined for the
10BERRTN and IOBIOERR bits and the following actions are taken:
IOBERRTN

o

IOBIOERR

o

Action
The user channel program is posted complete.
The ERP is scheduled.

1

o

0

Should not occur during error recovery.

1. If this is the first time the appendage was entered
(lOBEeB = X'7F'), schedule error recovery if allowed by
the DCBIFLG field in the DCB. If error recovery is not
allowed, handle as permanent error.
2. If this is the second time the appendage was entered
(IOBECB not equal to X'7F'), handle as a permanent error.

Return register + 4 - channel program not posted complete.
Section 5. Component Analysis

5-49

Return register + 8 - the request is retried.
Return register + C - D D R processing required.
The abnormal end appendage should be examined when analyzing possible error
recovery problems.
Retry IRestart the Channel Program

F or retry, errors are retried from the first CCW. F or restart, errors are restarted
from the failing CCW. An ERP's decision to retry or to restart a channel
program is primarily dependent upon the type of chaining, and secondarily
dependent upon the type of error. For channel programs using data chaining or
no chaining, the request should be retried beginning with the first CCW.. On a
request using command chaining, the restart is done from the failing CCW. The
10SB address of the real channel program (IOSRST) is updated with the real
address of the CCWat which restart is to begin.
After a retry or restart has been successful, the ending status is presented to lOS,
but the ERP is given control again because the 10SERR bit is still on (indicating
that error recovery is in control). ERP performs error inspection using the error
interpreter table to assure a cleanup of the 10SB. The 10SERR and 10SEX bits
(in the 10SB) are turned off, the error count fields are cleared, the abnormal
status bits in the CSW are turned off, and return is made to lOS.
Ei'ror Interpreter

An ERP module usually contains subroutines to handle various errors for the
device types for which the module is responsible. In order to test the two CSW
bytes and the first two sense bytes, ERP' uses a common lOS routine (IECVITRP)
pointed to by CVT + X' 44'. This routine uses the ERP module's error interpreter
table to determine which subroutine within the calling ERP module should be
branched to for handling the error condition detected by lOS. The error
interpreter table establishes the priority and sequence in which errors are handled.
Each entry in the table represents an error condition, and in the entry there is a
label for the subroutine to be branched to when the error condition is detected by
the lOS routine. The label names vary from module to module, but the technique
used is consistent throughout ERP.
Example of an Error Interpreter Table

The following table shows an example of an error interpreter table.
DC
DC
DC
DC
DC

X'ID',AL1(CCC-* + I)
X'IE',AL1(lCC-*+ I)
X'08',AL1(PERM-* + I)
X'03',AL1(EQUP-* + I)
X'2F',AL1(ENDI-* + I)

Channel control check
Interface control check
Permanent error
Equipment check
End of test

In th~s example, if ERP is entered with a status of channel control check, the
entry shows that a branch is taken to the label CCC. If ERP is entered with sense
bytes indicating only a permanent error, then a branch is taken to label PERM.
The table shows that the lOS routine checks for four error conditions, and if none
of the conditions is satisfied, then a branch is taken to ENDl.

5-50

MVS Diagnostic Techniques

The lOS routine tests the table from the top, ana the first error condition detected
results in a branch to the label within the entry. Because ERP handles only one
error condition at a time, if two or more error conditions are indicated, only a
branch to the first label is taken. For example, if both the interface control check
and equipment check are indicated, then a branch is taken only to the label ICC.
Note that the UCB, IOSB, and EWA are required for ERP to inspect the status
and sense information.
ERP Messages and Logging

ERP causes an error message to appear on the console or an OBR or MDR
record to be written to SYSl.LOGREC based on the 10SMSG and IOSLOG bits
in the IOSB. The following table shows the action taken for the possible settings
of the bits.
Bit Setting

IOSMSG IOSLOG

o
1

o
1

o
o
1
1

Action
1.
2.
3.
4.

No message, no SYS1.LOGREC entry
Console message, no SYSl.LOGREC entry
No message, SYS1.LOGREC entry
Console message, SYSl.LOGREC entry

•

Action 1: Certain permanent errors do not require logging or error messages,
such as no record found.

•

Action 2: Certain errors require only an error message, such as intervention
required.

•

Action 3: Certain errors are logged but messages are not issued. For
example, if a DASD equipment check is recovered, the error is logged, but a
message is not issued because the recovery was successful.

•

Action 4: Some errors are logged and an error message issued to the operator.
For example, if a DASD equipment check is not recovered, an OBR type
record is logged and message IEAOOOI is issued.

ERP transfers control to lOS module IGE0025C for messages and logging. If
logging is required, IGE0025C transfers control to the outboard recorder (OBR).
Intercept Conditions

The conditions that cause entry to an ERP occur at S10 time (indicated by a
condition code of one), or at channel end time. However, if an error condition
occurs at device end time after channel endhas been handled, there is no 10SB
because it was freed with channel end posting. In this case, lOS saves the two
CSW status bytes and complete sense information, and sets the intercept flag
(UCBITF) in the UCB. When the next request for this device is processed, lOS
detects the UCBITF flag and moves the CSW and sense data to the new IOSB.
lOS sets X'7E' in the completion code field of the IOSB and passes control to
ERP via the abnormal end appendage route.
Some intercept conditions are recoverable (such as the 1403 device end with the
channel 9 or 12 sense, or device end with intervention required sense for any
device). If the intercept condition is recoverable, ERP changes the code X'7E' in
Section 5. Component Analysis

5-51

the completion code field of the 10SB to X'7F'. However, most intercept
conditions cannot be recovered. Inthis case, ERP marks the IOSB in error, turns
off the ERP in-control bit in the 10SB, and returns to lOS which changes the
X'7E' to X'44'.
Unit Cheek on Sense CODlDland

lOS handles a unit check on the sense command as an equipment check~ To do
this, lOS simulates an equipment check by setting the equipment check in sense
byte zero of the 10SB, and X'FE' in sense byte one. The ERP can then
distinguish a unit check on a sense command from an ordinary equipment check.
Compound Errors

A compound error is one that occurs when a previous error has been successfully
retried. In most cases, this condition is handled by normal flow through the ERP.
However, if the compound error is either a unit exception or wrong length
indication in the CSW, special processing must take place to guarantee that the
channel end appendage is entered before the ERP tests the condition. This
processing is needed because lOS does not enter the channel end appendage if
ERP is in control. Therefore, on conditions of unit exception and wrong length
indication, ERP turns off the exception (IOSEX) and error (IOSERR) bits in the
10SB and returns to lOS. lOS then enters the channel end ·appendage, and later,
the ERP is scheduled because the CSW in the 10SB still contains the error status.
Diagnostic Approach

The ERP diagnostic approach has two major

objectives~

1. To determine the recovery action that is being. performed by the ERP module.
2. To determine what recovery action should be performed, according to the
manuals that provide the component description for the devices ..
The previous topics have explained how to perform the first objective. This topic
explains the use of IBM documentation to perform the second objective.
If the manuals mentioned in this topic do not show that error recovery action is

required, or if the referenced "priority" figures do not show the priority in which
a given error is to be handled, the problem may not be suitable for an APAR.
The component description manuals show the required/suggested error recovery
actions, and these actions are the specifications for the ERP software. If there are
no specifications for a given error condition, or if the specifications seem
incorrect, then the hardware CE should assume responsibility for any necessary
changes.
For brevity, only those manuals for the devices that require the greatest PSR,
field support, and APAR activity are shown.

S~S2

MVS Diagnostic Techniques

DASDERP
The error recovery actions for DASD are documented in the following manuals in
the topic "Error Condition Table" or "Recovery Action Table."
Order Number
GA26-3599
GA26-1589
GA26-1615
GA26-1619
GA26-1638

-

IBM Device Type
2314 Direct Access Storage Facility
2305 Fixed Head Storage and 2835 Storage Control
3330 Disk Storage
3340 Direct Access Storage Facility and 3344 Direct Access Storage
3350 Direct Access Storage

The manuals indicate a required action number for each valid combination of
error status and sense information, whether the error condition should be logged,
and the action to be taken for each action number. The description includes the
CCWs that must be prefixed to the channel program being retried or restarted.
DASD ERP is totally contained in the ERP module IECVDERP. A BALR is
issued by IECVPST to IECVDERP for DASD ERP. If console messages or
logging are required, control is given to IGE0025C via lOS.
Tape ERP
The error recovery actions for tape devices are documented in the following
manuals in the topic "Error Recovery Procedures."
Order Number

IBM Device Type

GA32-0020
GA32-0021
GA26-1647
GA32-0022

3803
3803
3803
3410

-

Tape Control Modell and 3420 Magnetic Tape Unit Models 3, 5, and 7.
Tape Control Model 2 and 3420 Magnetic Tape Unit Models 4, 6, and 8.
Tape Control Model 3 and 3420 Magnetic Tape Unit Models 3 and 5.
Magnetic Tape Unit and 3411 Magnetic Tape Unit and Tape Control.

The manuals indicate a required action number for each valid combination of
error status and sense information, and the action to be performed for each action
number. The action description includes a verbal description of CCWs to be used
for error recovery, such as "Set the correct mode (if seven track) and reposition
the tape." Also, the priority assignment given to the valid combinations of error
status and sense information is shown in the manuals in the topic "Status and
. Sense Indicator (Bits) Checking Sequence."
Printer ERP
For the IBM 3211 Printer, the manual GA24-3543 describes the error recovery
actions to be performed in the topic "Suggested Error Recovery Procedures." The
priority assignment for handling valid error status and sense combinations is
shown in the figure "Error Recovery Priority Sequence."
For the IBM 3800 Printing Subsystem, the manual GA26-1635 describes error
recovery actions in the chapter "Error Detection, Recovery, and Recording.",The
figure "3800 Error Conditions and Suggested Recovery Actions" describes various
status and sense error indicators, the possible cause of the error conditions, and
what the ERP should do to recover the error. Within the same chapter is a topic
for permanent errors with the required content of operator messages, and a topic
for error logging that specifies the types of SYSl.LOGREC entries (CCH, SDR,
OBR, and MDR). Also, the figure "3800 Error Recording Actions" specifies

Section 5. Component Analysis

5-53

which error conditions require·.SYSl.LOGREC recording and the type of
SYSl.LOGREC entry to be created for specific errors.

ERPTraps
The· previous topic "Error Interpreter" explains how to determine the assigned
label for various error routines within an ERP module. These labels are excellent
places from which to bran~h to the module trap area for traps. However, extra
care should be used because the module location to which an error interpreter
table causes a branch may be used by more than one entry. It is possible that
more than one table entry can contain the same name, and that different label
names can reside at the same module displacement if defined as DS. It is
important, therefore, that code placed in the patch area test the reason for
receiving control. If the patch area verifies the expected reason for receiving
control (by testing the status and sense information), then a program check or
one-instruction loop is an excellent trap/documentation technique.
MVS systems run with ERP enabled, in supervisor state, and under the RCT
TCB. DASD ERP runs in SRB mode. Checking tl1e ERP program is effective
when an OC3 abend is caused (use an EXECUTE instruction to execute itself),
and a SLIP command is used to catch the abend before the system FRR has freed
the 10SB and EWA control blocks.
An abend (such as a program check) in an ERP module causes the address space
to remain unusable until a re-IPL is performed.
When possible, a one-instruction loop in the ERP patch area should be followed
by a stand-alone dump for documentation of the ERP's action and failure.
A GTF trace or CCW trace is usually required to debug ERP problems. When
possible, use a full trace; but for intermittent problems, it may be useful to modify
the interrupt handler so that the trace occurs only for the desired I/O or selected
SVC operations.
Diagnostic Approach Summary

In summary, debugging ERP problems consists of:
1.

Determining which ERP module and subroutine receives control for error
recovery (if the abnormal end appendage and DCBIFLG field permit ERP to
execute).

2.

Inspecting the routine to determine if it conforms to the specifications for
error recovery provided in the component description of the device.

3. Assigning responsibility for the problem to the CE if ERP operates according
to the specifications, or document the problem using GTF, dumps, and traps
within ERP to assure adequate APAR documentation.

5-54

MVS Diagnostic Techniques

Program Manager
The program manager controls the various means by which programs are located,
brought into storage, and subsequently given control for execution. This chapter
describes the program manager and includes the following topics:
•
•
•
•
•
•
•
•

Functional Description
Basic Functional Flow
806 ABEND
APF Authorization
Module Subpools
Fetch/Program Manager Work Area (FETWK)
RB Extended Save Area (RBEXSAVE)
CDE Pool Control

Functional Description
The program manager's primary functions are to create and maintain control
block queues necessary to fetch load modules into virtual storage and delete load
modules from virtual storage, and to transfer control between load modules
during program execution.
Load modules fetched into virtual storage reside in one of the link pack areas
(fixed, modified, or page able) or in a job step's job pack area. External
communication to the program manager during program execution is
accomplished by means of the system macros: LINK, XCTL, LOAD, DELETE,
SYNCH, and IDENTIFY.
Program Manager Organization
The program manager consists of six modules, IEAVLKOO, IEAVLKOl,
lEAVLK02, lEAVLK03, lEAVIDOO, and lEAVNP05. Their major functions are
described Figure 5-6.
Program Manager Control Blocks
The major program manager control blocks and work areas are the contents
directory entry (CD E), the link pack directory entry (LPDE), the load list element
(LLE), the fetch work area (FETWK), the extent list (XL), the program request
block (PRB), and the DE (directory entry) save area. These control blocks and
work areas are described in Figure 5-7.
Program Manager Queues
The job pack queue (JPQ), active link pack area queue (ALPAQ), the load list
(LL), and the SVRB suspend queue (SSQ) are the four basic queues maintained
by the program manager. These queues which are summarized in Figure 5-8, are
described below:
JPQ -

Each job step has a job pack queue. The queue consists of CDEs (built in subpool 255)
representing modules (or minor entry points of modules) explicitly requested by one or
more tasks in the step via the LINK,LOAD, XCTL, or IDENTIFY macros, but not
available in one of the link pack areas: This queue is empty at the initiation of the job
step.

Section 5. Component Analysis

5-55

ALPAQ -

The active link pack area is a system queue consisting of CDEs (built in subpool 245)
representing modules (and minor entry points of modules) that are in the:
•
•
•
•

Modified link pack area
Fixed link pack area
Pageable link pack area and listed in the IEALODOO member of SYSl.PARMLIB
Pageable link pack area, with no CDE already on the queue, and currently in use

This queue initially consists of CDEs representing modules belonging to the first three
categories listed above.

Module
Name
IEAVLKOO

CSECT
Name
IEAVLKOO

LL -

The load list is a task-oriented queue consisting of LLEs representing load modules the
task has accessed via the LOAD macro. Each LLE points to the CDE on the JPQ or the
ALPAQ representing the module LOADed. The load list for each task is initially empty.

SSQ -

The SVRB suspend queue is a CDE-headed queue consisting of program manager SVRBs
representing requests within the job step for that particular module. The request could
not be immediately satisfied either because the module is currently being fetched into
virtual storage by a previous request or because the module is serially reusable and
currently in use.

PLPAD -

The pageable link pack area directory is a table of LPDEs built at system initialization
time. Each LPDE in the table represents a module (or an alias entry point of a module) in
the pageable link pack area. Once built, the table is static and read-only.

Residence
Nucleus

IEAVLKOI

IEAVLKOI

Nucleus

IEAVLK02

IEAVLK02

Nucleus

IEAVLK03

IEAVLK03

Nucleus

IEAVIDOO

IGC041

IEAVNP05

IEAVNP05

Pageable
LPA
Exists only
during
system
initialization

Figure

5-6.

5-56

MVS Diagnostic Techniques

Major External
Entry Points
IGCOO6
IGCOO7
IGCOO8
IGCOO9
IGC012
IEAQCSOI
IEAQCDSR
IEAVVMSR
None
IEAPPGMA
IEAPPGMX
FRRPGMMG
FRRPGMX
IGC041

Program Manager Modules

IEAVNP05

Primary Function
Contains the entry points for LINK (IGC006, XCTL (IGCOO7),
LOAD (IGC008), DELETE (IGC009), and SYNCH (lGC012).
Along with module IEAVLKOl, it services each of these
functions.

Along with module lEA VLKOO, it services the LINK, XCTL, and
LOAD function.
Cle.ans up resources in case of an ABEND (IEAPPGMA) and
whenever a PRB exits (IEAPPGMX).
Program Manager Functional Recovery Routines.
Service routine and FRR for IDENTIFY.
Creates the modified, fixed, and pageable link pack areas. Creates
the initial active link pack area queue. Creates the pageable link
pack area directory.

Area

Mapping
Macro

Size
(Bytes)

Subpool
Number

Usage

Created by

Deleted by

CDE

IHACDE

32

245 or
255

A CDE represents a copy of a module
in virtual storage (called a major
CDE). Minor CDEs are also used to
represent minor entry points.

Program Manager
(LINK,XCTL,
LOAD, or
IDENTIFY)

Program Manager

CDE
Pool
Control
Area
LPDE

None

16

245

Controls access to pools of CDEs
used for active LPA modules.

SystelIl
Initialization

Not deleted

IHALPDE

40

252

Similar to CDE, except are used for
the load modules in the pageable
link pack area.

System
Initialization

Not deleted

LLE

IHALLE

12

255

An LLE is used to control LOAD and
DELETE references to a module.

Program Manager
(LOAD)

Program Manager

FETWK

IHAFETWK

1540

253

Used as a work area and communication
area by FETCH and program
manager.

Program Manager
when a FETCH is
necessary

Program Manager

XL

IHAXTLST

16

255

Contains the load point and size of
a load module fetched into virtual
storage.

FETCH, or
Program Manager
Program Manager,
or OS/LOADER

PRB

IHARB

136

253

Controls the execution of a load
module.

Program Manager

Exit Processing

DE
Save
Area

None

64

255

Used to save the user-supplied BLDL
entry while program manager is
processing.

Program Manager
or ATTACH
Processor

Program Manager

Figure

5-7.

Program Manager Control Blocks and Work Areas

Queue

Serialization

JPQ

local lock

Type of
Queue

Elements

Queue
Header

When Element is Enqueued

When Element is Dequeued

push down
Note I

CDE

Field TCBJPQ
in the job step
TCB

When a module is fetched
into virtual storage or an
IDENTIFY is used to define
an embedded entry point

When the module is no
longer needed - that is, its
use count goes to zero.

ALPAQ general
cross'
memory
services
lock (CMS)

push down
Note I

CDE

field
IEAQLPAQ
pointed to by
CVTQLPAQ

At system initialization and
thereafter whenever a
pageable LPA module is
activated

When an activated pageable
LPA module is no longer
needed. CDEs enqueued
during system initialization
are never dequeued.

LL

local lock

push down

LLE

field
TCBLLS

Whenever a module, not
previously loaded by the
task, is loaded

Whenever the load count
goes to zero or when the
task terminates.

SSQ

local lock

in order
ofTCB
priority

SVRB
Note 2

field
CDRRBP

Whenever a request within
the job step cannot be
satisfied because a module
is being fetched or it is
reusable, but in use

When the module becomes
available.

Notes:
1.

Queues is push down except when minor CDEs are enqueued. Minor CDEs are always queued following the associated major CDE.

2.

If the suspend queue is for a serially-reusable module that is in use, the PRB using the module will be queued between the CDE and the
first SVRB.

Figure

5-8.

Program Manager Queues

Section 5. Component Analysis

5-57

Qa,eue VaIid_tiOB

JPQ and ALPAQ
The program manager functional recovery routine (module lEAVLK03) calls the
queue verifier (module lEAVEQVO) to verify and repair CDE elements on the
JPQ and on the ALPAQ. Queue verifier validity checks the parameter list, then
verifies and corrects the queue structure, removing elements with bad data.
Errors encountered are recorded as 16-byte entries in the queue verification
output data (QVOD) area. For program management, the QVOD is mapped in
the SDWA variable recording area starting at SDWAVRA + X'E'. On exit to the
caller, register 15 contains return information as follows:
•

Byte 0, bit 0 = 0 indicates that any error encountered has been recorded in
the QVOD area.

•

Byte 0, bit 0 = 1 indicates that there were more errors than could be
recorded in the QVOD area. Errors were detected but not recorded.

•

Byte I

•

Byte 2 = count of errors detected.

•

Byte 3 contains one of the following return

=

count of errors recorded.

cod~s:

o-

No errors detected

4-

Elements with bad data were removed from the queue. Their addresses were recorded in the
QVOD area.

8-

Damage to the queue structure - the queue is operational but an undetermined number of
elements may have been lost.

24 - Invalid input parameters - the queue verifier has not performed its function.

Load List
The load list is validated by the program manager FRR itself, beginning at the
queue's header in the TCB (TCBLLS). When an invalid LLE is encountered the
queue is truncated.
System Initialization

During system initialization the program manager RIM (resource initialization
module), lEAVNP05, is called to create the modified LPA, the fixed LPA, the
pageable LPA, the initial ALPAQ, and the PLPAD. lEAVNP05 fetches modules
into the link pack areas from SYSl.LINKLIB, SYSl.LPALIB, SYSl.SVCLIB,
and user libraries. It is driven by SYSl.PARMLIB members IEAFIXxx,
IEALPAxx, IEALODOO, IEAPAKOO, LNKLSTxx, and by the CLPA system
parameter. (See Figure 5-9.)

5-::58

MVS Diagnostic Techniques

Vlrtua. Storage

IEAVNP05

CDEs

~

ALPAQ
(SQA)

-

~

-

If CLPA is specified-,
builds pageable LPA
MOdUleSlb
and PLPAO for all
v"
modules on
SYS1 . LPALIB.
~_____________________~,-_-_~~L~P~O~E~s~

~r-~~~----_~I'~
Modules

LPALIB
Modules

Builds fixed LPA (via
IEAFIXxx) and puts
COEs on the ALPAQ.
Note: Some modules
can now be in both
the pageable and
fixed LPAs.

-

o

Ul

LINKLIB
Modules

~
1------------"'0
o

I------~~

,--v"

Builds modified LPA
(via IEALPAxx).
Fetches modules and
enaueues COEs on
bottom of ALPAQ only
if modules are not
already in the fixed
LPA.

Uses IEALODOO to
build "permanent"
COEs for specified
pageable LPA
modules.

-

J
l

Pageable
LPA

PLPAO

Modified
LPA

n
L...--..,.I

-

Fixed LPA

SVCLIB
Modules

Figure

5-9.

IEAVNP05 Initialization

Section 5. Component Analysis

5-59

Basic· FUllCtiOBai Flow
The following section describes the program manager's major functions.
LINK

Module lEAVLKOO is called by the SVC FLIH when the LINK SVC (SVC 6) is
issued. Its first function is to locate a usable copy of the requested load module.
An abend occurs if it cannot. If a usable copy is found, but not in virtual
storage, module IEAVLKOI brings it in.
If a usable copy is found already in virtual storage, the reques~or can use the
module immediately or may be suspended until it becomes available. In the latter
case, a module can be unavailable if either:
•

A previous request to fetch it into storage is being processed (indicated by bit
CDNIC being on in the CDE) or

•

It is a serially reusable module currently in use (indicated by the CDREN bit

being off, the CDSER bit being on, and a non-zero CDRRBP field).
If a usable copy of the requested module is not immediately available, the
requestor's program manager SVRB is put into a wait state and enqueued on the
SVRB suspend queue (SSQ). The SVRB is dequeued and posted out of its wait
when the desired module becomes available. For "not in storage" suspends,
module IEAVLKOI posts all SVRBs queued on a CDE's SSQ when it successfully
completes a module fetch. Each of these SVRBs then restarts the LINK request
essentially from the beginning at entry point IEAQCS02 in module lEAVLKOO.
For the serially reusable case, module IEAVLK02 posts the top SVRB on a
CDE's SSQ when the PRB that was using the module represented by the CDE
exits. In this case, execution resumes in module lEAVLKOO at entry point
IEAQCS03. The logic at this entry point assumes the requested module is in
storage and immediately available.
Once a module becomes available to a request, the module-use count in the CDE
is increased by one. This use count is decreased by one when. the current
requestor no longer needs the module.
Next, LINK processing gets storage for a PRB out of subpool 253. The PRB is
initialized (including setting the RBOPSW to point to the entry point of the
requested module) and enqueued on the current TCB's RB queue. It is enqueued
after the program manager SVRB, but before the linking module's RB. The
program manager then exits, thus causing the requested load module to gain
control next. (See Figure 5-10.)

5-60

MVS Diagnostic Techniques

PRB
Field

How initialized by lEAVLKOO for LINK
(and ATTACH)

RBPREFIX

zero

RBSIZE

13 double words

RBSTABI

zero

RBSTAB2

from PM SVRB except RBATTN =0

RBCDFLGS

zero

RBCDEI

@ requested CDE (may be a minor) Note 1

RBOPSW-LH

from caller's RB (or AABCODOO) Note 2

RBOPSW-RH

module entry point from CDENTPT

RBPGMQ

from PM SVRB

RBWCF

from PM SVRB

RBLINKB

@ caller PRB (or @ TCB if ATTACH)

RBGRSAVE

from PM SVRB

Notes:

1.

RBCDE1 will point to the CDE containing the requested load module name. This may be a minor
CDE. CDRRBP of the major CDE however will point to the new PRE. Field CDRRBP in a
minor CDE has no meaning.

2.

If ATTACH, RBOPSW (left half) is set to AABCODOO where,
AA
B
C
D

Figure

= from current PM PSW
= from TCB protect key (TCBPKF)
= X'C if TCBFSM = 1.. X'D', otherwise
= from PICA if there is one, else 0

5-10.

New PRB Initialization - LINK

ATTACH
When the ATTACH service routine completes the initialization of the requested
daughter TCB, it gives control to LINK in order to establish the first PRB for the
daughter TCB. ATTACH simulates the SVC FLIH by creating a program
manager SVRB under the daughter TCB and then causing the daughter to branch
enter module IEAVLKOO at entry point IEAQCSOl. Processing is essentially the
same as for LINK except for APF considerations which are explained later.

XCTL
Module IEAVLKOO gets control from the SVC FLIH at entry point IGC007
when the XCTL SVC (SVC 7) is issued. With XCTL, unlike LINK, the first
function of module IEAVLKOO is to establish the new RB. The method used
depends on the type of caller, as follows:
•

If the caller is an SVRB, the caller's SVRB is reused for the new module. It

remains in the TCB RB queue in the same position as it was when
lEAVLKOO got control.
•

If the caller is an IRB, storage is obtained from subpool 255 for a new PRB.
The new PRB is then enqueued on the TCB RB queue between the IRB and
the program manager SVRB.

•

If the caller is a PRB, storage is obtained for a new PRB from subpool 255
and then it is enqueued upon the TCB RB queue following the program
Section 5. Component Analysis

5-61

manager SVRB. The caller's PRB is then put on top of the queue. The
program manager then issues the EXIT SVC (SVC 3) forcing the caller's
PRB, since it now is on top of the queue, through exit processing. This
results in the storage for the caller's old module being freed before the new
module is obtained. The program manager then resumes execution at entry
point IEAQCS02 in module lEAVLKOO.
Figure 5-11 shows how the new PRB (SVRB in the case where the caller is an
SVRB) is initialized for an XCTL. Figure 5-12 shows how the new RB is
enqueued in the TCB RB queue before the program manager locates the new load
module.
The next function in the XCTL process is to locate the desired module. If the
caller is an SVRB, the module is searched for via the ALPAQ; if it is not found, it
is searched for via the PLPAD. If it is not found by either the ALPAQ or the
PLPAD, an 806 abend is generated. If the load module is found, final
initialization in the RB is completed and the program manager exits. The
following exceptions to normal processing occur when an SVRB issues an XCTL
macro (they are made for performance reasons):
•

Only the ALPAQ and PLPAD are searched.

•

If the CDE on the ALPAQ is found usable, the use count is not increased.

•

If an LPDE in the PLPAD is found usable, no CDE is built or enqueued on
the ALPAQ .. Furthermore, the RBCDEI field is made to point to the LPDE
rather than a CDE.

If the caller is not an SVRB, the requested load module is located as it is in
LINK. Once found, initialization is completed on the already existing PRB and
return is made to the caller.

RB Field
RBPREFIX
RBSIZE
RBSTABI
RBSTAB2
RBCDFLGS
RBCDEI
RBOPSW-LH
RBOPSW-RH
RBPGMQ
RBWCF
RBLINKB
RBGRSAVE

How Initialized by lEAVLKOO for XCTL
Caller is a IRB
Caller is an SVRB
left as is
zero
17 double words
left as is
zero
left as is except
RBTRSVRB, Note 1
from caller PRB
from caller IRB
left as is
except RBFDYN= 1
zero
left as is
zero
@·requested CDE
@ requested CDE
@ CDE or @ LPDE
from caller PRB
from caller IRB
left as is
@ module entry point
@ module entry point
@ module entry point
zero
left as is
zero
left as is
from caller IRB
from caller PRB
@ calling IRB
left as is
@ caller's
caller RB
from caller IRB
left as is
from caller PRB
Caller is a PRB
zero
from caller PRB
from caller PRB

Note:
1. Bit RBTRSVRB indicates (for a dump routine) the location of the load module. It will be set to 0
if the module was located via a CDE on the ALPAQ. It will be set to 1 if the module was located
in the pageable LPA.

Figure 5-11.

5-62

MVS Diagnostic Techniques

New RB Initialization - XCTL

XCTl by

PRB

At Start:

Before the SVC 3:

After SVC 3:

TCB

...

Program
Manager
SVRB

-

XCTL issuing
PRB

-...

XCTL issuing
PRB

-

Program
Manager
SVRB

-

Program
Manager
SVRB

TCB

TCB

I

-

...

XCTL issuing
PRBts
calling RB

XCTL -

l'J.ew PRB

-...

New PRB

-

... issuing
PRB's
calling RB

XCTL issuing
PRB's
calling RB

resume at lEAQCS02

XCTL by IRB

Program
Manager
SVRB

New PRB

Program
Manager
SVRB

New
SVRB

IRB

...

-

-

XCTL issuing
PRB's
calling RB

XCTL by SVRB

XCTL issuing
PRB's
calling RB

L

was XCTL-issuing PRB's SVRB

Figure 5-12. XCTL RB Manipulation

Section 5. Component Analysis

5-63

LOAD
Module lEAVLKOO is called by the SVC FLIH at entry point IGCOO8 when the
LOAD SVC (SVC 8) is issued. For a LOAD request~ the TCB's load. list is first
searched for an LLE representing a usable copy of the requested module. If
found, the LLE total responsibility count is increased by one. In addition~ if the
caller is in supervisor state and/or key 0-7, the system responsibility count is
updated. A separate system count is maintained to prevent a non-system user
from deleting a module loaded by a system routine.
If the load list does not yield a usable copy of the requested module, the module
is located and CDEs are manipulated as explained earlier for LINK. The final
step for LINK processing is the building of the PRB. For LOAD, however, no
PRB is built; instead, an LLE is built and enqueued at the top of the TCB's load
list queue. This LLE points to the CDE (whether it be on the JPQ or the
ALPAQ) of the requested module. The total responsibility count is initialized to
one, and the system responsibility count to zero or, if a system request, to one.

DELETE
Module lEAVLKOO is called by the SVC FLIH at entry point IGC009 when the
DELETE SVC (SVC 9) is issued. Since the module to be deleted must have been
previously loaded by the same task, IEAVLKOO searches the TCB's load list
queue for the module. If it is not found, the program manager exits with a return
code of 4.
If the module is found, the total responsibility count in the LLE is decreased by
one. The system responsibility count is also decreased by one if the DELETE was
issued by a system program. Finally, the use count in the CDE is decreased by
one.
The LLE is dequeued and freed if the total responsibility count goes to zero. If
the use count in the CDE also goes to zero, routine CDHKEEP in module
IEAVLK02 is called. This routine frees the CDE and all its minor CDEs, the
associated extent list, and the module itself. Once control is returned to
lEAVLKOO, the program manager exits.
Exit Resource Manager
Module lEAVLK02 is called by the exit prologue at entry point IEAPPGMX
whenever a PRB exits. The purpose is to clean up the program resources that
were being used by the PRB. First, the program manager decreases by one the
use count in the CDE being used by the PRB.
If the module is serially reusable, and there are SVRBs suspended on the CDE's
SSQ, the top SVRB is posted so it can begin using the module.

5-64

MVS Diagnostic Techniques

If the CDE's use count goes to zero, then the CDE, all its minor CDEs, the extent
list, and the module itself are freed. When the module is freed (by subroutine
CDHKEEP) it is freed from:

•
•
•

Subpool 0, if bit CDSPZ is 1
Subpool 251, if bit CDSPZ is 0 and bit CDJPA is 1
Subpool 252, if bit CDSPZ is 0 and bit CDJPA is 0

(See the discussion of "Module Subpools" later in this chapter.)
If the exiting 'PRB is the last in the TCB's RB queue, IEAVLK02 also does
end-of-task clean up. This consists of cleaning up and freeing all LLEs. remaining
on the TCB's load list queue.
SYNCH

Module IEAVLKOO is called by SVC FLIH at entry point IGC012 when the
SYNCH SVC (SVC 12) is issued. SYNCH essentially uses the tail end of LINK
processing to build and enqueue a PRB for the user exit. No module searching,
CDEs, LLEs, etc. are involved.
IDENTIFY

Module IEAVIDOO is called by the SVC FLIH at entry point IGC041 when the
IDENTIFY SVC (SVC 41) is issued.
IDENTIFY builds a minor CDE for the requested name and entry point. The
CDE is enqueued on the lPQ or ALPAQ following the major CDE that
represents the module containing the entry point. One exception to this is if the
requestor is not authorized (not supervisor state, not in a system key, and not
executing in an APF-authorized step) and the embedded entry point is in a
module that is CDE-authorized and from an APF-authorized library. In this
case, for integrity reasons, a major CDE for the embedded entry point is built and
enqueued on the lPQ. Since the CDE is initialized to represent the module as not
coming from an authorized library, no authorized user is allowed to use this
user-defined entry point.
Module lEAVIDOO also accommodates OS/LOADER with special processing.
When OS/LOADER issues the IDENTIFY SVC, it has loaded a module into
subpool 0, built an extent list, and now wants to be represented by a major CDE
and extent list build and enqueued on the lPQ. This request is called a "major
request" and is indicated when Register 0 contains 0 upon entry to lEAVIDOO.
Register 1 contains a pointer to the module name and extent list.
Figure 5-13 illustrates CDB initialization by IDENTIFY.

Section 5. Component Analysis

5-65

Normal Request

CDEField

Normal

CDCHAIN
CDRRBP
CDNAME
CDENTPT
CDXLMJP
CDUSE
CDNIP
CDNIC
CDREN
CDSER
CDNFN
CD MIN
CDJPA
CDNLR
CDSPZ
CDXLE
CDRLC
CDOLY
CDSYSLIB
CDAUTH

(behind major)
zero
as per input
as per input
@majorCDE
zero
as in major CDE
0
1

Figure 5-13.

1

0
1
0
1
0
0
0
0
0
as in major CDE

Non-authorized
requestor and
module from an
APF-authorized
library

(top of JPQ)
zero
as per input
as per input
zero
zero
0
0
as in major CDE
as in major CDE
0
0

Major Request

1

(top of JPQ)
zero
as per input
as per input
@ XL (at end of CDE)
zero
0
0
0
0
0
0
0

as in major CDE
0
0
0
1
0
0

1
1
0
0
0
0

1

CDE Initialization by IDENTIFY

ABEND Resource Manager

Module IEAVLK02 is called by RTM at entry point IEAPPGMA under two
circumstances: when a TCB is going to abnormally terminate; and when a
program manager SVRB is going to be forced through exit processing because of
a recovery retry.
When lEAVLK02 is called, its function is to clean up CDE SVRB suspend
queues. If the current TCB has any program manager SVRB on an SVRB
suspend queue for any CDE on the JPQ, the SVRB is dequeued. Furthermore,
when a TCB is going to abnormally terminate, if any CDE on the JPQ has the
CDNIC bit on and a program manager SVRB on the abending TCB's RB queue
is responsible for fetching the module into virtual storage, all other SVRBs
waiting for the module are posted and the CDE is dequeued and freed.
806 Abend

If the program manager cannot locate a load module in response to a LINK,
ATTACH, XCTL, or LOAD request, it issues an 806 abend. Two key areas in
the program manager should be understood if an unexpected 806 abend occurs or
if the program manager uses a copy of a module that was not anticipated. These
are (1) the module search sequence or search order and (2) the criteria used in
determining whether or not a module already in virtual storage is useable.
1.

Search Sequence
For a LOAD request, CDEs located on the task's load list queue are first
searched for a useable module. If this search fails, the search sequence for
LOAD is then the same as it is for LINK, ATTACH, and XCTL.

5-66

MVS Diagnostic Techniques

The search sequence for LINK, ATTACH, XCTL, and LOAD (if the LLE
scan is unsuccessful) is shown in Figure 5-14 and Figure 5-15.
2.

Usability Criteria
When searching for a module, the program manager looks for a COE already
enqueued on the JPQ or ALPAQ with a CONAME the same as that of the
requested name. If a matching name is found and the COE is on the
ALPAQ, the module is immediately available to the requestor because all
these COEs represent modules that are reentrant and from APF-authorized
libraries. If the COE is on the JPQ, however, certain tests have to be made
to determine if the module represented by the COE can be used by the
requestor. The routine CDALLOC (COE Allocation) performs this testing.
The COE with the matching name is the input to COALLOC. Output is a
return code indicating the usability of the associated module. Figure 5-16
describes tests and actions taken by COALLOC.

Section 5. Component Analysis

5-67

LINK, ATIACH,
XCTL

LOAD

Notes:
1. For XCTL, if caller is an
SVRB. only the ALPAQand
PLPAD are searched.

Search CDEs via
TCB's Load List
Queue

Search JPQ

TASKLIB=LlNKLlB DCB is
specified, no library other
than LlNKLIB is searched
for the requested module
and an abend 806-4
might occur.
No

3. For a LOAD request with the

No

4. If the limited library
search option is requested
(LSEARCH=YES parameter),
only the ibrary indicated
by the user-supplied DCB
is searched. A search of
SYS1 . LINKLIB involves a
preliminary search of the
link pack area.

explicit loqd option CADDR
keyword). only the library
indicated by the user-supplied
DCB is searched.

See Figure 5-15

Search Private
Libraries

2. For ATIACH. if the

Search ALPAQ

Search PLPAD

Order of CDEs on ALPAQ
First: Modules activated from the
pageable LPA -- newest
modules first

Search SVCLIB

Second: Modules in IEALODOO -in inverse order of
specification in list

Yes

Third: Modules in fix lists in
inverse order of
specification in lists.
Lists also in inverse order
of their specification
Fourth: Modules in MLPA lists -in inverse order of
specification in lists.
Lists also in inverse order
of their specification

806 ABEND

Figure

5-14.

Module Seal'ch Sequence for LINK, ATTACH, XCTL and LOAD

5-68

MVS Diagnostic Techniques

Yes

No

No

Yes

Yes

Search Library
Via Given DCB

Z Byte> 1

Search the Parent
Job/Step/T ask
Libraries Via
Z Byte

Search All
Job/SteplTask
Libraries

Search Library
Via Given DeB

..-_________________~ Byte

=

Z Byte> 1

1

806 ABEND

Search the Parent
Job/Step/Task
Libraries Via
Z Byte

Search curren]
Job/Step/Task
Libraries

1

Continue Search
with the ALPAQ

Figure

5-15.

--L---'--==r-.
i

CS06ABEND)

Module Search Sequence of Private Libraries

Section 5. Component Analysis

5-69

Type of Request

-Requestor is Authorized·

LOAD
Requestor is
Non-authorized

LINK
ATTACH
XCTL

CDALLOC
Return
Code

Module Condition via the Input CDE

Module from non APF-authorized library
From APF-authorized library = same as non-authorized request
Module being fetched (CDNIC= 1)
Reentrant or serially reuseable
No Load
Fetched by Program Manager
Module in
Nonreusable
Loaded by
Storage
Restrictions
USECT=O
(CDNIC=O)
(CDNLR=I)
OS/LOADER
USECT>O
Reentrant or serially reuseable
Load
Only
Non-reuseable
Module being fetched (CDNIC= 1)
Reentrant (CDREN= 1)
Serially
In use (CDRRBP"O)
Module in
No Load
Not in use (CDRRBP=O)
Storage
Restrictions
Reuseable
(CDNIC=O)
(CDNLR= 1)
Used (CDNFN = 1)
NonNever used (CDNFN=O)
reuseable
Load only (CDNLR=O)

I
I

8

16
4
0

4
0
4
0
16
4
12
4
8
4
406
ABEND

0:
Module not available via JPQ
4:
Module is immediately available
8: Module not available - continue JPQ search
12: Module not immediately available - suspend requestor until module is no longer in use
16: Module not immediately available - suspend requestor until fetch is complete
·In supervisor state, in system key, or as part of an APF-authorized step

Figure

5-16.

CDE Allocation

APF Authorization
The program manager performs two APF -related functions. The first function
determines whether or not a job step is APF-authorized when the job step TCB is
attached. The second function prevents any authorized program from accessing,
via LINK, ATTACH, XCTL or LOAD, a module that is not from an
APF-authorized library.
1.

Establishing APF-Authorization
An APF-authorized job step is executing if bit JSBAUTH is on in the JSCB.
This bit is turned on by the program manager if the following conditions exist
when LINK is called by ATTACH:

5-70

•

It must be a job step ATTACH. The program manager considers it a job
step ATTACH if field TCBJSTCB in the attached TCB points to itself
and if there is a JSCB for the step indicated by a non-zero TCBJSCB
field.

•

The load module being attached must have been link edited with an APF
authorization code of 1. This is indicated to the program manager when
bit PDSAPF is on in the module's directory entry.

MVS Diagnostic Techniques

•

The load module being attached must be from an APF-authorized library.
This is determined by FETCH and indicated to the program manager by
bit WKAUTH being on in the FETWK.

In summary, a job step is APF-authorized if the first program executed in the
step is both from an APF -authorized library and link edited with an APF
authorization code of one.
2.

306 ABEND
An authorized program is one that is executing in supervisor state, or with a
system protect key (0-7), or as part of an APF -authorized job step. An
authorized program must LINK to, ATTACH, LOAD and XCTL to modules
exclusively from APF -authorized libraries. The program manager issues an
abend code of 306 if the only usable copy of a module requested by an
authorized program is on a non-APF-authorized library.
When a load module is fetched into virtual storage, FETCH indicates to the
program manager via the FETWK bit, WKAUTH, whether it is (bit on) or is
not (bit off) from an APF-authorized library. If the requested module is
already in virtual storage, the program manager determines whether or not it
is from an APF-authorized library by examining the CDE bit, CDSYSLIB, If
it is on, the module can be used by an authorized program.
Bit CDSYSLIB = 1 if the associated module is from an APF-authorized
library except in the following cases:
•

The bit=O if the module is reentrant but is still fetched into subpool 251
because of TSO TEST considerations (see the following discussion on
"Module Subpools").

•

The bit=O when IDENTIFY creates a major CDE because a
non-authorized user indicates an embedded entry point in a module from
an APF-authorized library.

Module Subpools
All modules represented by CDEs on the ALP AQ are loaded into the pageable
LPA, the fixed LPA, and the modified LPA. These modules are never freed.
Modules represented by CDEs on the JPQ however, are freed by the program
manager and can occupy storage in subpool 0, subpool 251, and subpool 252.
Modules loaded by the OS/LOADER always use subpool O. This is indicated by
bit CDSPZ being set to one.
When bit CDSPZ is zero, modules fetched by the program manager use subpool
251 if bit CDJP A is set on or subpool 252 if bit CDJPA is set off.
Reentrant modules from APF-authorized libraries are always fetched into subpool
252 if the requestor is a system program (a program in supervisor state or with a
system key). Reentrant modules from APF-authorized libraries requested by
non-system programs are also fetched into subpool 252 provided TSO test (TCB
bit TCBTCP = 0) is not running. All other modules are fetched into subpool 25 L
Section 5. Component Analysis

5-71

FETCH/Program Manager Work Area (FETWK)
Module IEAVLKOI obtains the FETWK (mapped by DSECT IHAFETWK)
from subpool 253 when a load module is to be fetched into virtual storage. A
pointer to the FETWK is placed in RBCSWORK (at RB + X'74') of the program
manager SVRB. FETWK is logically divided into three areas. The first area, up
to but not including field WKADDR, is used exclusively by FETCH as a work
area. The second area, up to but not including WKPREFX, is used as a work
area by the program manager. Field WKIOADDR and bits WKAUTH and
WKSYSREQ in this area are also addressed by FETCH, as follows:
•

WKIOADDR is always set to zero by the program manager. This instructs
FETCH to do the GETMAIN for the load module.

•

WKAUTH is set to one by FETCH to tell the program manager when a load
module is from an APF-authorized library.

•

WKSYSREQ is set to one by the program manager to tell FETCH that the
requesting program is in supervisor state and/or system key. FETCH uses
this indication to bypass DEB checking.

The third area of the FETWK, starting with WRPREFX, is the BLDL area. This
area contains the directory entry used by FETCH to obtain the requested module.
The directory entry is placed there by the program manager either by moving a
caller-supplied directory entry into the area or by issuing a BLDL.

RB Extended Save Area (RBEXSA VE)
The 48-byte extended save area (RBEXSAVE at RB + X'60') of the program
manager SVRB is used by the program manager as a work area. This area, along
with the FETWK, is a key area in analyzing program manager problems.
RBCSNAME (at RB + X'60') contains the module name requested by the caller,
and RBCSDE (at RB + X'68') points to a copy of the caller-supplied directory
entry if one was supplied. If EP or EPLOC is specified, then this pointer is zero.
Other key areas of the extended save area are RBCSWORK (at RB + X'74'),
which points to the FETWK if FETWK was obtained, and bit RBCSSYSR
(RB + X'70' = X'40'), which is on if the caller is a system program.

CDE Pool Control
Two pools of CDEs are maintained in SQA (one for minor CDEs and one for
major CDEs) from which the program manager obtains the CDEs used to
represent modules on the active LPA queue. A sixteen-byte area is also
maintained in SQA which is used to control access to the CDE pools. This area
is pointed to by CVTCDEQ (CVT + X'3D8'). The format of this control area is
as follows:
+0
+4
+8
+C

5-72

Pointer to next available major CDE in pool (zero if major pool is empty).
Pointer to next available minor CDE in pool (zero if minor pool is empty).
Pointer to first extent ofmajor pool.
Pointer to first extent of minor pool.

MVS Diagnostic Techniques

Each pool is comprised of one or more extents. Each extent consists of a 4K
block of SQA allocated on a 4K boundary. The first four words at the beginning
of each extent contain the following information:
+0 "CDEQ" - identifies this 4K page as a CDE pool.

+ 4 Pointer to next extent of this pool (zero if last or only extent in pool).
+ 8 Count of CDEs from this extent that are in use.

+ C Indicates which pool this extent belongs to (0

= major pool, 4 = minor pool).

The remainder of each extent contains the CDEs which make up the pool. Each
CDE in the pool points to the next CDE in the pool using the CDCHAIN field of
the CDE. The last CDE in each pool contains a zero in the CDCHAIN field to
denote the end of the pool.
CDEs are obtained from the pools by the CELLGET subroutine of IEAVLKOI
and returned to the pools by the CELLFREE subroutine of lEAVLK02.

Section 5. Component Analysis

5-73

Virtual Fetch
Virtual fetch is a system service that reduces the time and channel contention to
locate and bring a load module into storage. This chapter describes virtual fetch
and includes the following topics:
•
•
•
•
•
•

Functional description
Module organization
Functional flow
Control blocks
Recovery processing
Debugging hints

For a description of how to use virtual fetch, refer to OSjVS2 MVS System
Programming Library: Job Management.

Functional Description
Virtual fetch provides the following functions:
Function

Description

Initialization

Establishes the virtual fetch service address space, creates a read-only VIO data set
containing reformatted load modules, creates a hash table of virtual fetch directory
entries (VFDEs) for the modules in the VIO data set, and creates or reactivates the
virtual fetch control block (VFCB) in the CSA.

Refresh

Builds a new VIO data set and hash table to reflect any changes made to the load
modules and updates the VFCB.

Build

Creates, for the named module, the virtual fetch work area (VFWK) in the user's
address space.

Find

Locates, for the named module, the VFDE and copies it into the VFWK in the user's
address space.

Get

Brings a copy of the named module from the VIO data set into the user's address space,
relocates the address constants, passes control to the named module, receives control
back ftom the module, and returns to the user.

Module Organization
Virtual fetch consists of the following modules:

5-74

Module

Primary Function

CSVVFCRE
alias:
CSVVFRSH

Performs the initialization and refresh functions. Contains the cross memory
search routine (CSVVFSCH), which obtains the VFDE; the cross memory
post routine (CSVVFRSH), which initiates refresh processing; and
CSVVFCRl, which reformats load modules to be placed in the VIO data set.

CSVVFGET

Performs the get function. Contains routine CSVVFRM, which is used to free (via
FREEMAIN) local module storage.

CSVVFIND

Performs the build and find functions. Contains routine CSVVFORK, which is
entered via a non space switch PC instruction and which passes control to the
authorized sections in CSVVFIND and CSVVFGET.

MVS Diagnostic Techniques

/

CSVVFMEM

Cleans up the VFCB when virtual fetch terminates. It also clears the pointers to the
virtual fetch data areas in a local address space when the job step task terminates.

CSVVFTCH

Obtains a copy of a named module from the VIO data set and relocates the address
constants in the user's address space.

The modules that are given control by virtual fetch's get function are effectively
nonreusable. Therefore, recursive calls using virtual fetch will fail.
Additional information for the modules is shown in Figure 5-17.
Module
Name

Routines

Residence

External
Entry Points

CSVVFCRE
alias:
CSVVFRSH

CSVVFCRE
CSVVFCRI
CSVVFSCH
CSVVFRSH
CSVVFCES-ESTAE
CSVVFCFR-FRR

Private (virtual
fetch)

CSVVFCRE
CSVVFRSH

CSVVFGET

CSVVFGET
CSVVFGES-ESTAE
CSVVFRR-FRR

Nucleus

CSVVFGET
CSVVFRM

CSVVFIND

CSVVFIND
CSVVFFES-ESTAE

Nucleus

CSVVFIND
CSVVFORK

CSVVFMEM

CSVVFMEM

Nucleus

CSVVFMEM

CSVVFTCH

CSVVFTCH

Nucleus

CSVVFTCH

Figure

5-17.

Virtual Fetch Modules

Functional Flow
Flow of control for the virtual fetch modules and routines are shown in the
following topics.

Section 5. Component Analysis

5-75

Initialization Function
START Command

CSWFCRE
Initialize
function

CSWFCR1
Reformat
modules

Wait for refresh

Refresh Function
EXEC PGM=CSWFRSH

CSWFRSH
Initiate
refresh

CSWFCRE
Refresh
function

Wait for refresh

Exit

Build Function
BALR via CVTVFIND (YFPMFUNC ...VFPMBLD>

CSWFIND
Build
function

--

..

-

LReturn
~

5-76

MVS Diagnostic Techniques

CSWFCR1
Reformat
modules

CSWFORK
Pass
control

CSWFRM
Free storage

Find Function
BALR via CVTVFIND 

~
CSWFIND
Find function

L

-

.

CSWFORK
Pass control

Return

----~

CSWFSCH
Obtain VFDE

CSWFRM
Free storage

Get Function
BALR via CVTVFGET 

~
CSWFGET
GET function

L

-

-

Return

CSWFORK
Pass control

--.

CSWFTCH
Obtain
module

~

CSWFRM
Free storage

-

CSWFRM
Free storage

Termination
Call from RTM

CSWFMEM
Terminate
function

L

Return

Section S. Component Analysis

5-77

Control Blocks
Virtual fetch uses the following control blocks and data areas:
Area

Description

VFCB

Virtual fetch control block - used to access the virtual fetch service address space. The
VFCB is located in the CSA and is pointed to by field CVTVFCB in the CVT.

VFHE

Virtual fetch hash entry - contains the virtual fetch directory entries (VFDEs) for the
modules managed by virtual fetch. VFHEs reside in hash collision queues in a hash
table in the virtual fetch address space. The first elements of the queues are accessed by
the module name.

INFODATA

Contains PDS directory entry data. INFODATA format DEs are accumulated in a
temporary table (INFOTAB), copied into the hash table, and then converted into
VFHEs. INFOTAB is located in the virtual fetch address space.

VFPM

Virtual fetch parameter list - used by the user to request build, find, or get processing.
The VFPM is located in the user's address space. For get processing, virtual fetch sets
flags in the VFPMRTN field if the named module did not receive control or abended.

VFVT

Virtual fetch vector table - controls the build, find, and get requests in the user's address
space. The VFVT is located in the user's address space.

VFWK

Virtual fetch work area - controls the use of a module in a user's address space. The
VFWK is located in the user's address space. VFWKs are in push-down queues
anchored in a 31-way hash table in the VFVT. The hash table is accessed by module
name.

L WK

Local work area - contains dynamic storage for build, find, and get requests. The L WK
is located in the user's address space.

Additional information for these control blocks and data areas is shown in
Figure 5-18.
Area

Mapping
Macro

Size in
Bytes

Subpool
Number

Created By

Deleted By

VFCB

IHAVFCB

32

241 (CSA)

CSVVFCRE

CSVVFCRE (System VFCB
not deleted)

VFHE

IHAVFDE

64

230 (PVT)

CSVVFCRE

CSVVFCRE

INFODATA

IHAVFINF

64

o (PVT)

CSVVFCRE

CSVVFCRE

VFPM

IHAVFPM

88

User key

User

User

VFVT

IHAVFVT

144

254 (LSQA)

CSVVFIND

Job step task termination

VFWK

IHAVFWK

112

254 (LSQA)

CSVVFIND

Job step task termination

LWK

Declares in
CSVVFIND
and
CSVVFGET

276

230 (PVT)

CSVVFIND
and
CSVVFGET

CSVVFIND and
CSVVFGET

Figure 5-18.

5-78

MVS Diagnostic Techniques

Virtual Fetch Control Blocks

Recovery Processing
This topic discusses virtual fetch recovery processing. Also see Appendix C for
diagnostic information for the SVC dumps issued by virtual fetch modules.
Error During Initialization Processing

When entered, the ESTAE routine CSVVFCES (in CSVVFCRE) attempts to
clean up and retry the initialization or refresh request. If retry is not performed,
CSVVFCES requests an SVC dump and writes a software record to
SYSI.LOGREC. (The dump and LOGREC record are not requested when the
abend code is 222, 322, or 522.) VSVVFCES percolates the error under the
following conditions:
•
•
•
•
•
•

There is no SDWA.
The SDWA indicates that a retry is not permitted.
A previous retry attempt was unsuccessful.
The error occurs during initialization before the VFCB is activated.
The error occurs while the VFCB is being updated.
The error occurs while waiting for a refresh request.

If an error occurs while making VIO requests, CSVVFCRE issues abend code
COD to enter its ESTAE routine. Under some conditions, CSVVFCRE will
terminate with a return code. See SPL: Job Management for a description of
these return codes.
If an error occurs during CSVVFCES processing, the FRR routine CSVVFCFR
(in CSVVFCRE) requests an SVC dump and writes a software record to
SYSl.LOGREC.
Debugging Hint - During initialization processing, if an abend 878 occurs or
message CSV119I or CSV113I is issued, increasing the region size for virtual fetch
might correct the problem.
Errors During Build, Find, and Get Processing

The build and find recovery routine (CSVVFFES) and the get recovery routines
(CSVVFGES, ESTAE; CSVVFRR, FRR) clean up and attempt to retry the
request. CSVVFFES requests percolation of the error when the SDW A indicates
that only clean up is permitted, if the abend code is X'x22', or if the previous
retry attempt was unsuccessful. CSVVFGES requests percolation of the error
under the same conditions as for CSVVFFES, but in addition, CSVVFGES
requests percolation for abends that occur in the requested program. CSVVFRR
only requests percolation when the SDWA prohibits retry requests or when the
previous retry attempt was unsuccessful.
Except in the case of an X'x22' abend, the recovery routines request an SVC
dump and write a software record to SYSl.LOGREC. If retry succeeds,
CSVVFIND returns to its caller with a return code X'20', and CSVVFGET
returns to its caller with error information in field VFPMRTN of the VFPM. If
the caller's VFPM is not in storage thctt the caller can store into, a protection or
translation exception results and the VFPM is not altered.

Section 5. Component Analysis

5-79

Debugging Hints
The following conditions can occur during build, find, or get precessing:
•

If an abend occurs in CSVVFSCH (cross memory search routine), the virtual
fetch service address space is flagged as unusable. Recovery routine
CSVVFFES (in CSVVFIND) turns off flag VFCBUILT, issues message
CSV118E, and returns a code of 20 to the caller. In this case, the virtual
fetch service address space should be cancelled, and then virtual fetch should
be restarted.

•

If an abend occurs while virtual fetch is searching the VFWK collision
queues, recovery routine CSVVFFES (in CSVVFIND) or CSVVFGES (in
CSVVFGET) turns off flag VFVTVFUP. Further requests for virtual fetch
processing in this user's address space will result in invalid return codes until
the user's job step task terminates.

•

If an abend occurs while virtual fetch is searching or updating the job pack
queue, the VFWK in the user's address space is flagged as unusable.
Recovery routine CSVVFFES (in CSVVFIND) or CSVVFRR (in
CSVVFGET) turns on flag VFWKBADV in the VFWK containing the CDE
being queued. The associated module is not obtainable via virtual fetch until
the job step task terminates. If the abend occurred while removing the CDE
from the job pack queue after the requested program completed processing,
CSVVFGET returns to the caller with no flags on in VFPMRTN.

•

If either an abend occurred while assigning or page-loading a page for a
module, or lEAVAMSI returns a nonzero return code to virtual fetch, the
associated module is marked unobtainable in the VIO data set. CSVVFTCH
turns on flag VFWKBADM. (The flag is turned off only after an ASSIGN
with PAGELOAD has successfully completed processing or if a cancel abend
occurs during ASSIGN processing.) The module cannot be obtained via
virtual fetch until the virtual fetch service address space is refreshed, or
cancelled and restarted.

•

If a requested program abends, the program is not available via virtual fetch
until a find request is invoked for the program under the TCB under which it
abended. This ensures that any dumps resulting from the abend are able to
include the storage of the requested module.

•

If a GETMAIN macro fails during get processing, CSVVFTCH attempts to
obtain storage by issuing FREEMAIN macros for the storage of inactive
modules, and then retries the GETMAIN macro. Subsequent get processing
will issue GETMAIN macros for any modules whose storage was freed as
they are requested. CSVVFGET turns flag VFPMRESH on if CSVVFTCH
cannot obtain storage. When the find function is invoked and if CSVVFIND
. cannot obtain storage, CSVVFIND returns a code of 16 to the user. If the
find function obtains storage and the get function is reinvoked, and the get
function fails again with VFPMRESH on, then find processing should not be
reinvoked unless storage can be freed by the user.

•

A module is not obtainable from the current generation of virtual fetch in a
user's address space if (1) a page is obtained by CSVVFTCH for a module,
and (2) the page released by CSVVFGET after the module completed

is

5-80

MVS Diagnostic Techniques

execution, and (3) the page is referenced before the next call to IEAVAMSI
by CSVVFTCH. This is because IEAVAMSI is not able to complete an
ASSIGN and PAGE LOAD for the module. CSVVFTCH leaves flag
VFWKBADM on for the module.
•

F or get processing, flag VFPMRESH in the user's VFPM is turned on if any
of the following conditions is encountered:
The virtual fetch service address space is not active.
The VFVT or the required VFWK for the module is not usable.
A find request for a module was not issued after the module had
abended.
A build request and a find request were not issued for a module before a
get request was issued for the module.
Virtual fetch found the job pack queue in error. There are probably bad
pointers in the queue. Recovery routine CSVVFGES or CSVVFRR flags
the VFWK as unusable.
CSVVFTCH encounters an abend during ASSIGN with PAGELOAD
processing. CSVVFGES assumes the module cannot be obtained from
the VIO data set and leaves flag VFWKBADM on.
Get processing was requested after find processing had indicated that the
VFDE was not in the current hash table.
The virtual fetch service address space was refreshed or reinitialized after
the previous find request for the module.
Get processing received a nonzero return code from lEAVAMSl.
CSVVFGET assumes the module cannot be obtained from the VIO data
set ana leaves flag VFWKBADM on.
CSVVFRM abended when called by CSVVFGES. CSVVFRR assumes
the VFWK is invalid and marks it unusable.

Section 5. Component Analysis

5-81

VSM
Virtual storage management (VSM) is responsible for allocating virtual storage,
keeping track of what is allocated and, for certain subpools, recording to whom it
is allocated. These services are performed both for the system and problem
programs. (See Figure 5-19.)
The following are the five basic functions that VSM performs:

Function

Module
Performing
Function

Nucleus initialization (NIP)

IEAVNP08

IPL parameters are: SQA =, CSA =, REAL =,
VRREGN=

Address space initialization

IEAVGCAS

Called by memory create

Step initialization/termination

IEAVPRTO

GETPART/FREEPART

Virtual storage allocation

IEAVGMOO

GETMAIN/FREEMAIN

IEAVGTCL
IEAVFRCL
IEAVBLDP
IEAVDELP

GETCELL (get cell)
FREECELL (free cell)
BLDCPOOL (build cell pool)
DELCPOOL (delete cell pool)

Cell pool management

Comments

The nucleus initialization program (NIP) is not discussed in this book. The
remaining VSM functions, and the related FRRs (functional recovery routines),
are described in the following topics:
•
•
•
•
•

5-82

Address Space Initialization
Step Initialization/Termination
Virtual Storage Allocation
VSM Cell Pool Management
Miscellaneous Debugging. Hints

MVS Diagnostic Techniques

64K boundary

------....
-

Cannot be rele ased
via FREEMAIN
4K boundary

SP 245 -- Key 0, not fetch protect
SOA
Common
Area

LPA

~ SP 231/241/227/228/239

---

CSA

64K boundary

/'

These can be
intermixed
on a 4K ba sis

SP 253 -- Key 0, not fetch protect, not pageable
-- AOE for task
LSOA SP 254 -- Key 0, not fetch protect, not pageable
-- AOE for any job step task
SP 255 -- Key 0, not fetch protect, not pageable
SWA

SP 236, SP 237 -- Key 1. not fetch protect, pageable

SP 229 -- User key. fetch protect, pageable
U key SP 230 -- User key, not fetch protect, pageable
User Area
(Private
Address
Space)

'-

These are not a II owed to cross.

These can be
intermixed

/

{

Top of SP 0-127, 251, 252 is CURRGNTP
in control block local data area -- (LOA)

SP 252 -- Key 0, not fetch protect, pageable
SP 251 -- User key. fetch protect. pageable
SP 0 - SP 127 -- User key, fetch protect, pageable

I-I--

f-

SYSTEM REGION

64K boundary

...

16K chained out of RCT' s TCB (TCBPQE at TCB + X' 98')
NUCLEUS
(FREEMAIN cannot be issued for the NUCLEUS)

Figure 5-19.

}

System
Area

Virtual Storage Management's View of MVS Storage

Section 5. Component Analysis

5-83

Address Space Initialization
The create address space module (lEAVGCAS) initializes the VSM address space.
lEAVGCAS creat~s the local data area (LDA). The LDA is the key anchor
block and VSM save area for space allocation within an address space.
lEAVGCAS builds all the blocks labeled "C" in Figure ~ 5-20. lEAVGCAS also
builds the initial allocation of 16-byte LSQA elements for VSM's local cell pool.
GETMAIN then allocates VSM's internal control blocks from this pool.
IEAVGCAS also contains VSM's task termination and address space termination
resource managers. The task termination routine frees all non-shared space
anchored in the TCB. (See Figure 5-20.) The address space termination routine
frees any WAIT or POST elements of a V = R (virtual = real) job that are
associated with the terminating address space and are chained out of VSM's GDA
(global data area). These V = R WAIT jPOST elements exist only when a job is
waiting for V = R address space.
IEAVGCAS's functional recovery routine (FRR) is IEAVCARR. IEAVCARR is
divided into the following three sections, corresponding to those of lEAVGCAS.
1.

Entry IEAVCARR, which protects the create address space portion of
IEAVGCAS.

2.

Entry IEAVTTRR, which protects the task termination portion of
IEAVGCAS.

3.

Entry IEAVFARR. which protects the address space termination portion of
IEAVGCAS.

lEAVCARR does not place data in the variable recording area of the SDWA
(STAE diagnostic work area). It does invoke SDUMP and either retries at the
beginning of the function that detects the error or continues with termination.

5-84

MVS Diagnostic Techniques

-

Current ASCB

ASCBLDA

I

I'

-j

I

I
1

/
DOE
chain/

SPQEf")
LSOA

-

(C)

(C)

/ ----

FOE
chain

-

r--

(e)

r--

8-byte FOEs

LDA
(C)
LSOAPTR

..,

J./

POE for system
region (16K
except in
(C)
Master
Scheduler's _
address space)

V

LSASRPOE
(Release 3 only)
VSM's pool of
16-byte LSOA cells
for VSM' s internal
control blocks

\.

ASDPQE

-1--

LCLCELL

FBOE
chain
(C)

Dummy POE
PQE for
address
space

FBOE
chain

ee)

(C)

Current TCB

TCBAOE

r

TeBPOE
TCBSWA
TeBMSS

----'
'-----------'

-

exists only for V=R job
POEforV=R I
~
user region /V--

_:J

FBOE
chain

~

-

TCBUKYSP -

r

(e)

I-I--

_ _ _ _ _ --J

r
built on V=R GETPART

SPOE chain
subpools 236
and 237 (SWA)

-

I
AQE chain

~

SPOE chain
subpools
0-127,251,
and 252

1,..--11_ _---.

,

AOE
chain*

I--

1

1
1

-

SPQE chain
subpools 229
and 230
____ ~-

J
1

I

/-

DOE
chain
*AQEs wi II be for SP 254 for a job step task or for SP 253 if not
a job step TCB

1

FOE
chain

-

C=built by lEAVGCAS
Note: Updates of all control blocks and queues in this figure are
serialized by the local lock.

Figure

5-20.

-

16-byte FOEs

Virtual Storage Management's Control Block Usage

Section 5. Component Analysis

5-85

Step Initialization/Termination (lEAVPRTO - GETPART/FREEPART)
IEAVPRTO is invoked by IEAVGMOO (GETMAIN/FREEMAIN) via a branch
entry as a result of a GETMAIN/FREEMAIN request from an initiator for
subpools 242 (V=R) or 247 (V=V). IEAVPRTO does not return to IEAVGMOO;
it returns directly to the initiator.
IEAVPRTO performs four functions, as follows:
1.

2.

For a V=V GETPART request:
•

Sets TCBPQE to point to the dummy address space partition queue
element (PQE) that was created at address space initialization time.

•

Calls the initiator exit routine IEALIMIT in order to establish the
LDALIMIT which is the value used by GETMAIN as an upper limit for
problem program subpool GETMAIN's requests. The OS/VS2 System
Programming Library: Supervisor contains a discussion on LDALIMIT,
REGION =, and variable GETMAIN requests.

For a V=R GETPART request:
•

Performs IEALIMIT processing as described above.

•

Attempts to obtain V = R space by interrogating V = R FBQEs chained
from the GDA.
-

If unsuccessful:
Creates V = R wait element
Chains the V=R wait element from the GDA
Indicates the V = R wait element is waiting for space

-

If successful:
Interfaces with RSM's (real storage manager) IEAVEQR to
obtain real frames
Builds V=R dummy PQE, V=R PQE, and V=R FBQEs, and
updates TCBQE

3.

For a V=V FREEPART request:
•

Frees all task-related space by calling FREEMAIN, and freeing one
subpool at a time.

•

Frees SPQEs and task-related subpools.

•

Sets TCBPQE = O.

(~
5-86

MVS Diagnostic Techniques

4.

For a V=R FREEPART request:
•

Performs the same functions as for V=V FREEPART.

•

Returns space to V=R FBQEs chained from the GDA.

•

Attempts to satisfy V = R waiting requests by posting the waiting
initiator. The waiting initiator reissues the request; IEAVPRTO will move
the WAIT elements to the POST queue anchored in the GDA. This
POST element is freed by GETPART when the initiator's new request is
received.

IEAVPRTO's FRR, IEAVGPRR, does not use the variable recording area of the
SDWA. It attempts a retry back into lEAVPRTO based on footprints set in the
FRR's six-word parameter area. Refer to the IEAVPRTO code (microfiche) for a
detailed description of this FRR parameter area.

Virtual Storage Allocation (GETMAIN/FREEMAIN)
IEAVGMOO, IEAVGM03, and IEAVGM04 satisfy all GETMAINjFREEMAIN
requests. The control block structure they use is shown in Figure 5-20 and
Figure 5-21. All GETMAIN processing for the private area subpools and all
associated control blocks are serialized by the local lock. All common area
subpools and associated control blocks are serialized by the SALLOC lock.
A detailed process flow through GETMAIN for a virtual storage allocation
request can be found in Appendix A in the GETMAIN jFREEMAIN process flow
description.
In debugging GETMAIN, the most important information is contained in the
original request for virtual storage. This information can be obtained from the
trace table, from a parameter list passed by the problem program code, or
sometimes from the LDA (local data area).
The LDA cannot always be relied upon to provide information about the request
unless the system is stopped immediately. Unless you insert a code or SLIP trap
and take a stand-alone dump on error, the LDA is overlaid by another request
during the dumping procedure.
If an immediate stop has been obtained upon encountering an error, the most
useful information in the LDA is obtained from the flags in the LDARQSTA
(LDA + X'10') field. The LDARQSTA contains the current request status.
Compare the flags in this field to the request and determine if the two are
consistent. Then check through the control block chain, the LDA and GDA
chains that are set up when subpools are requested to find out why the abend or
error occurred.

Section 5. Component Analysis

5-87

LDARQSTA (LDA+X'lO')
Offset

0

1. ......
.1. .....
..1 .....
... 1 ....

.... 1. ..
.... .1 ..
...... 1.
...... .1

I .......
.1. .....
.. 1.....
.. .1 ....

.... 1. ..
..... 1..
...... 1.
...... .1

...... 1.
....... 1

5-88

MVS Diagnostic Techniques

4096-byte Request from Subpool 253/254
An AQE is needed
Fetch Protected Subpool
Authorized User Key Subpool
SWA Subpool
LSQA Subpool
CSA Subpool
SQA Subpool
SVC Number

2

3

Subpool 254 Requester has TCBABGM on
Explicit V = V Region reached
Variable Request, Pass 2
SQA or LSQA Expansion
Deferred Error I/O Flag
FMAINB or MRELEASR Request
GETMAINB Request
Branch Entry

Subpool FREEMAIN
Supervisor Mode (if zero)

CVTGDAT

r

GDA

~--------~

~--------~

~--------~

~--------~

CSAPQEP

VRPQEP
PASTART

private area -----+---1 PASIZE
sta rt and size
1------------1
SQASPQEP
SQA space left,
includes CSA
available for
SOA expansion

--------t

V=R
PQE

SQASPLFT

~------I

VRPOSTQ
VRWAITO
SOA
SPOE

PFSTCPAB
CSASPOEP
GLBLCELL
GBLCELCT

FOE

count of
free cells

I~~~~----l"'~
CPAB
anchor for the
permanent
cell pool
CPABs

V=R virtual is
now available;
the initiator is
posted to
re-issue the
request.

jobs waiting
for V=R
virtual space

~

_--'~

,--_d_ra_i_n

I---,J"'~ CPAB
... CPAB
(CPAB Table is shown
in Figure 5-23.)

CSA SPQE
chain

V=R wait
element

(Release 3 only)
VSM's pool of
16-byte SOA
cells for VSM' s
internal control
blocks

Note:

Figure

Updates of all the control blocks and queues in this figure,
except PFSTCPAB, are serialized by the SALLOC lock.
PFSTCPAB is read only after NIP.

5-21.

Virtual Storage Management's Global Data Area (GDA)

Section 5. Component Analysis

5-89

GETMAlN's Functional Recovery Routine - lEAVGFRR
Whenever GETMAIN's FRR (IEAVGFRR) finds an error in a queue, an entry is
made in the SDWA variable recording area, SDWAVRA (SDWA+X'194') to
indicate the error that has been found, its location, and the corrective action
taken. Each entry is added to the next available location and the length of the
user-supplied data is increased (field SDWAURAL, SDWA + X'193'). The
high-order byte (byte 0) of the first word contains FF if the space in the variable
recording area was exceeded and data entries were lost. The low order byte (byte
3) of the first word contains a digit indicating the type of error that caused
lEAVGFRR to get control. This digit comes from FRRBRNDX (branch index
FRR) in the LDA where it is set up by lEAVGMOO, lEAVGM03, or
IEAVGM04. FRRBRNDX is X'IF' into the GETMAIN/FREEMAIN work
area (GMFMWKAR); GMFMWKAR is the portion of the LDA that is used by
lEAVGMOO as a work area. It is mapped at the end of this chapter.
The seco~d word of the SDWA variable recording area contains the LDA field
LDARQSTA at the time of error. The contents of LDARQSTA are described in
the previous topic "Virtual Storage Allocation (lEAVGMOO GETMAIN/FREEMAIN)."
The next 16 words usually contain the registers (order 0-15) at the time
lEAVGMOO was ent.ered. These registers are useful for debugging problems that
occur on branch entry requests. Register 14 contains the caller's return address.
The remaining SDWAVRA entries consist of one to three words each. The first
word of each entry will have a code in the high-order byte and a data length in
the low-order byte. If this length is 0, there is no additional data for this entry.
A length of 4 or 8 indicates one or two additional words of data. These data
words always contain the address of the affected field or control block. These are
all shown in the table in Figure 5-22 Control blocks are checked to determine if
they are in the correct subpool, for example, SQA or LSQA; queues are checked
for validity.
If an error occurs in lEAVGMOO, lEAVGM03, or lEAVGM04, the name of the
module in error is indicated in the SDWA. If recovery percolates to the FRR
routine lEAVGFRR, the SDWA module name in error is indicated as
lEAVGMOO, and the CSECT name is indicated as lEAVGMOO, lEA VGMO I,
lEAVGM03, IEAVGM04, or IEASMFGF.

5-90

MVS Diagnostic Techniques

nata

First

4

Data Addresses
Second
PVTLCSA

Explanation
PVTLCSA is incorrect - it will remain unchanged.

02

4

PASTRT

PASTRT in GOA is incorrect - it is reset using PVT.

03

4

PASIZE

PASIZE in GOA is incorrect - it is reset using PVT.

04

0

05

4

PVTHQSA

PVTHQSA is incorrect - it will remain unchanged.

06

4

Bad TCB
Pointer

TCB pointer is not valid - no queue repairing is attempted.

BI

4

SPQE with
bad pointer

Next SPQE pointer is incorrect - the SPQE queue is truncated
(by setting the bad pointer to zero).

B2

4

SQASPQE

SQA SPQE flagword is incorrect - it will remain unchanged.

B3

4

LSQASPQE

LSQA SPQE flagword is incorrect - it will remain unchanged.

B4

4

SPQE

Next SPQE pointer = 0, but last SPQE flag is not on - the last SPQE flag is set
on.

CI

4

Cell with
bad pointer

Next cell address is incorrect - the cell pool chain is truncated.

01

4

SQA SPQE

First SQA OQE pointer (in SPQE) is incorrect; it points outside SQA so all of
SQA may be lost - it will remain unchanged.

02

8

OQE with bad
pointer

03

4

OQE

04

8

Current
OQE

Overlapped
OQE

Current OQE area overlaps a previous OQE - current OQE is
removed from queue.

05

8

Current
OQE

Previous
OQE

Circular OQE queue - queue is truncated after previous OQE.

06

4

OQE

First SQA OQE area address or length is incorrect - address and length are
corrected.

FI

4

FQE

Incorrect type flag in FQE - the flag is corrected.

F2

4

OQEor FBQE
with bad
pointer

Next FQE pointer is incorrect (if SOA or LSQA, then previous FQE
length could be too large) - FQE queue is truncated (by
setting the bad pointer to zero).

F3

4

FQE

Incorrect (too long) length in FQE - FQE queue is truncated.

Code
01

Figure

Length

5-22.

All three sources of CSA start addresses (GOA, PVT, CSA, PQE) disagree - no
change will be made.

Bad OQE
address

OQE pointer is not in SQA or LSQA - OQE queue is truncated
(by setting the bad pointer to zero).
OQE area address or length is incorrect - this OQE is removed from the queue.

SDW AVRA Error Indicators

Section 5. Component Analysis

5-91

VSM Cell Pool Management
VSM's cell pool· management consists of the following functions:
Module

Macro

Function

IEAVGTCL
IEAVFRCL
IEAVBLDP
IEAVDELP

GETCELL
FREECELL
BLDCPOOL
DELCPOOL

Gets a cell from a preformatted pool of cells
Frees a cell to a preformatted pool of cells
Builds a pool of formatted cells
Deletes a pool of formatted cells

The key to the VSM cell pool management function is the cell pool anchor block
(CPAB). The layout of the cell pools is shown in Figure 5-23. Note that the
permanent cell pools have IDs that are negative, while the dynamic cell pools
have IDs that are the address of the first CPAB divided by 4 (shift right 2).
The four VSM cell pool management modules are small enough that processing
can be determined from studying the CPAB mapping along with the code.

Miscellaneous Debugging Hints
1.

Most common problems with GETMAIN/FREEMAIN occur in the interface
processing. There is usually a bad TCB or ASCB address or the local lock is
not held upon entry. The ASCB is used only to find the LDA which is in the
same location in all address spaces except the master scheduler's.
Note: On a branch entry to GETMAIN, register 7 contains the address of
the ASCB; however, on return from the branch entry, register 7 no longer
contains this address.

2.

A valid GETMAIN/FREEMAIN that is issued for zero bytes is treated as a
no-op.

3.

Good places for GETMAIN/FREEMAIN traps are:

4.

5-92

•

Routine CSPCHK in IEAVGMOO .

•

Routines called from branch tables SPBRTBLG and SPBRTBLF in
IEAVGM03.

GETMAIN makes few queue manipulation errors. If
GETMAIN/FREEMAIN rejects a request, it is usually because the caller
made an error on the interface; the message lEA7001 is issued.

MVS Diagnostic Techniques

Dynamic pools

CVT

X'23)'

CVTGDA

cells

cells

GOA

X'30' PFSTCPAB

Permanent CPAB (Cell
J - - - - - - - i Pool Anchor Block) Table

4 pools are currently

/

//

//
// /

J - - - - - + - I in use:

SRBOO
RM103
RT104
Pointer to next CPAB
for this pool

~_-~f--~

Contains CPID when
cell in use

Pointer to next
.......---'---""'f available cell

Figure 5-23. VSM Cell Pool Management

5.

Subpool queue elements (SPQEs) are not freed even on a subpool
FREEMAIN, and multiple keys for a problem program subpool on the same
TCB are not allowed. This can.result in a problem if a user changes
TCBPFK. The following is an example of such a situation:
Set TCB key

TCBPFK=6
GETMAIN SP 1 Causes SPQE to be built, storage in key 6
FREEMAIN SP 1 SPQE for SP 1 is not destroyed

Change TCB key TCBPFK = 8
GETMAIN SP 1 lEAVGMOO uses old SPQE and assigns storage in key 6

6. On branch entry to GETMAIN, registers are saved at field BRANCHSV in
the LDA and turns on tpe BRENTRY flag at offset X'lO' in LDA. To be
sure these saved registers are for the request in question, it is necessary to stop
the system via a trap. (See "Using the SLIP Command" and the "System
Stop Routine" topics in the chapter" Additional Data Gathering Techniques"
in Section 2.)

Section 5. Component Analysis

5-93

7.

MVS has added a new register type GETMAIN/FREEMAIN SVC and
branch entry. It is SVC 120. The parameters differ from those of SVC 10 as
follows:
Register 1 -

Zero for a GETMAIN; address to be freed fOr FREEMAIN.

Register 15 (SVC only) -

Bytes 0 and 1:

Reserved~

set to O.

Byte 2: Subpool ID
Byte 3: Following flag values:
Bits 0-4
Bit 5

Reserved~

set to 0

=0 Double word boundary
=1 Page boundary
Bit 6
=0 Conditional request
=1 Unconditional request
Bit 7
=0 GETMAIN
=1 FREEMAIN

For the branch entry SVC 120, register 15 contains the entry point address
and register 3 is used for the parameters. Register 3 is set up the same as
register 15 above with one exception: Byte 1 is the protect key for subpools
227-231 and subpool241. The address that was obtained via GETMAIN is
returned in register 1 as in SVC 10.
8.

5-94

Some GETMAIN failures are recorded in an information list·Gontained in the
nucleus. This list is similar to a trace table and is pointed to by the
CVTQMSG (CVT+X'IOC'). Each entry contains data such as: ABEND
code, ASCB address, TCB address, register 14 if GETMAIN was branch
entered, and the parameters passed. Refer to the DSECT INFO LIST in
module lEAVGMOO for additional information.

MVS Diagnostic Techniques

GMFMWKAR (IN LDA AT +X'58')
OFFSET
IN HEX (FROM START OF LOA)
58~--------------------------------------~

ABNDATA (VAR. DATA)

5C~--------~--------~--------~--------~

60.

~

... ~

:t

I

I

I

MSGLEN .L.-_FREESW
LOCKFLAG
FRR~RNDX.
_______
_ _ _ _ _ _..L-_
_ _ _ _ _- ' - _
- " ; '_ _ _ _
REGSAVE SAVE AREA USED
FOR SRM AND RSM
(18 FULL WORDS)

~

-T....

A~~------------M-S-A-V-E-S-A-V-E-A-R-E-A--U-S-ED---------~JL
FOR MRELEASE
(16 FULL WORDS)

-""'"

GNOTSAVE SAVE AREA USED
FOR GNOTSAT
(16 FULL WORDS)

GFSMFSVE/CSPCKSAV
(SMF CORE ROUTINES SAVE AREAl
CSPCHK SAVE AREA)
MPTRS
(PR.EVIOUS AND NEXT PTRS SAVE AREA)

144.
"10....

DUMYDQE
(DUMMY DQE FOR L/SQA EXPANSION)

-10...,

15J[~____________~_(4__FU__LL__W_O_R_D_S_)____________~Jr

:c

164'

_

-~

174

TEMPDQE
(TEMPORARY DQE FOR FMCOMMUN)
(4 FULL WORDS)
DUMFBQE
(DUMMY FBQE FOR MRCLEASE)
(4 FULL WORDS)

FREEMAIN IN PROGRESS
LENGTH HAS BEEN INCREMENTED
ADDRESS HAS BEEN DECREMENTED
NOT 1ST DQE (FOR L/SQA)
FQE WAS BELOW FREED AREA
FURTHER PAGE RELEASE NEEDED

LOCKFLAG
X'02' SALLOC LOCK OBTAINED
X'Ol' SALLOC LOCK ALREADY HELD

LOCKSAVE
(OVERLAPS INTO GFSMFSVE AND MPTRS)

13 C

FREESW
X'SO'
X'40'
X'20'
X'10'
X'OS'
X'04'

REASON CODE AND LENGTH OF VAR.
DATA

-~

128'
130

MSGLEN -

.i
T

FRRBRNDX
X'07' SUBPOOL FREEMAIN, AQE AREA NOT
INDQE
X'06' PAGE RELEASE RETURN CODE OF 1
X'05' SALLOC OBTAIN RETURN CODE NOT
OOR 4
X'04' ON L/SQA EXPANSION, GFRECORE FAILED
X'03' FINDPAGE RETURN CODE NOT 0 OR 4
X'02' CREATE SEGMENT RETURN CODE>O
X'01' SALLOC RELEASE RETURN CODE >0
X'OO' UNEXPECTED ERROR,SEE STATUS

~

-""'"

SAV911
SAVE AREA FOR REGS 9-11
(BRANCH ENTRY)

180
184
18C
190
194

LASTSAVE (LAST LIST ENTRY)
MINMAX
MAX & MIN LENGTH FOR VARIABLE REQUEST
LASTLSTA (LAST LIST ENTRY ADDRESS)
LSTINDEX (INDEX FOR LIST REQUEST)
FMARCAS (PTR TO AREAS TO BE FREEMAINED)

"L....

-

L..o

Section 5. Component Analysis

5-95

OFFSET
IN HEX (FROM START OF LOA)

--

198
PARMLDA
19C

I

CLOSEST (CLOSEST INSIZE FQE)

1A4

LARGESTA (LARGEST AVAILABLE)

1A8

LARGEST (LARGEST AVAILABLE FBQE)

1AC

184

SAVESIZE (SIZE OF MULTIPLE OF 4K CORE)
ENDADD (END ADDRESS)
STRTADD (START ADDRESS)

18C

DIFF/SAVEPQE (DIFFERENCE/PQE PTR IN FBQESPCH)
FIXSTART (STARTING ADDRESS TO CLEAR)

1C4

lC8
lCC
100
104

108
10C

FIXEND (ENDING ADDRESS TO CLEAR)
NOTSATSV (LEN PTR USED BY GNOTSAT)
NOTSATSI (LDARQSTA SAVE AREA FOR GNOTSAT)
SAVESEG (ADDRESS OF MULTIPLE OF 4K CORE)
LARSOFAR (LARGEST AVAILABLE IN FBQE)
RSTRTADD (ROUNDED START ADDRESS)
RENDADD (ROUNDED END ADDRESS)

1EO
lE4
lEC
1FO
1F4

VPFP (FIND PAGE ADDRESS TO BE USED)
DQESAVE
SAVE DQE PTR AND PREVIOUS DQE PTR
FMSAVE (SAVE RETURN REG FOR FREEMAIN)

SPQESAVE (SAVE AREA FOR SPQE)
SVRLB (SAVE AREA FOR RLB)
SVSIZE (SAVE AREA FOR ROUNDED SIZE)
DQESAVEl
SAVE DQE INFO WHEN USING FMAINB

20C
210
214
21 8

FMSAVEl (SAVE RETURN REG IN FMAINB)

PREVFQSl (SAVE PREVIOUS FQEIN FMAINB)
SPQSAVE 1 (SAVE SPQE IN FMAINB)

SVSIZEl (SAVE ROUNDED SIZE FOR FMAINB)
SAVSVTSV (SAVE LDARQSTA IN FMAINB)
FQENXTSV (FQE NEXT SAVE AREA)

22C

23 8
23 C
240
244

5-96

OUTSW - (SWITCH FOR OUT OF REAL/VIRT.)
X'OO' REAL INDICATOR FOR OUTSW
X'FF' VIRT. INDICATOR FOR OUTSW

NEWFQELN (NEW FQE LENGTH)
RQSTSIZE (SIZE OF ORIGINAL REQUEST)
SEGTEST (END SEG TEST AREA)

CODEl

CLEARSW

GMFMSW

FETCH

OUTSW

CODE2

SAVFRESW

SPID

LSPQEKEY.

RQSTRKEY

SAVSPID

SAVSPID2

MVS Diagnostic Techniques

CODE2 - (SAVE AREA FOR OPTION CODE)
SAVFRESW - (SAVE FREESW IN FMAINB)
SPID - (SPID FOR MRELEASE)

OLDFQELN (OLD FQE LENGTH)

230
234

FETCH - (KEY AND FETCH PROTECT)
X'OS' FETCH PROTECT ON

SVRLBl (SAVE RLB FOR FMAINB)

220

228

GMFMSW - (GM/FM SWITCH FOR MRELEASE)
X'04' FIRST TIME SW FOR MRELEASE
X'02'
INDICATES FM FOR FBQE
X'Ol' INDICATES GM FOR FBQE

FQESAVEl (SAVE FQE INFO IN FMAINB)

21C

224

CLEARSW - (CLEARSW FOR GFRECORE)
X'Ol' FQECPB INDICATOR ON IN FQE

FQESAVE (SAVE AREA FOR FQE)

1FC

204

CODEl - (SAVE AREA FOR OPTION CODE)
X'CO' LIST INDICATOR (MIXED IF LIST)
X'20' CONDITIONAL INDICATOR
X'10' MASK FOR PAGE BOUNDARY
X'04' SVC 120 PAGE BOUNDARY REQUEST
X'02' SVC 120 UNCONDITIONAL REQUEST
X'Ol' SVC 120 FREEMAIN REQUEST

PREVFQSV (SAVE AREA FOR PREVIOUS FQE PTR)

1F8
200

PARMLDA
X'SO' GLOBAL REQUEST (GLBRANCH OR
MRELEASE ON GLOBAL REQUEST)
X'4Q' SALLOC LOCK OBTAINED BY GM/FM
X'04' FIRST FLAG BYTE IN FRRPARM
X'OO' -LOA ADDRESS IN FRR PARM

LENSAVE (SAVE AREA FOR LENGTH LIST PTR)

188
1CO

-"'"

CLOP REV (PREVIOUS FQE TO CLOSEST)

1AO

180

FRRPARM (FAR PARM AREA ADD)

LSPQEKEY - (PROTECT KEY FROM CURRENT SPQE)
RQSTRKEY - (REQUESTER KEY OR KEY
SAVSPID - (SAVE SPID FOR FREEMAIN)
SAVSPID2 - (SPID FOR MESSAGES)

= PARM)

Real Storage Manager (RSM)
The real storage manager (RSM) manages the real storage of the system. To do
this, it divides all potentially pageable real storage into 4K-byte frames. Within
RSM, the page frame table entry (PFTE) describes the frame according to type,
current use, or its most recent use.
The current or last state of a request for RSM pageable services is described by
the page control block (PCB) within RSM: the requestor supplies information
about his request and RSM reformats this data into a PCB. As the request is
processed, RSM adds other internal RSM information to the PCB.
RSM is a queue-driven component. Both PFTEs and PCBs are queued based on
their current state. Simply stated, frames that can be used immediately are
queued on the available frame queue; their PFTEs describe the frame's last use.
Similarly, free request elements are queued on the FIFO PCB free queue; these
PCBs describe the final state of previously processed requests. (This historical
nature of PCBs is often useful in problem analysis.) To manipulate these control
blocks and manage the queues, RSM has a PFTE manager (lEAVPFTE) and a
PCB manager (lEAVPCB). Besides being queued, PFTEs are located in a
contiguous table starting at (PVTPFTP) + (pVTFPFN) multiplied by 16) and
ending at (PVTPFTP) + (PVTLPFN multiplied by 16). PCBs, however, are
obtained (via GETMAIN) in groups and are spread out in SQA. They can be
found only by following queue pointers.

Major RSM Control Blocks
RSM's major control blocks are the PFTE, PCB, page table entry (PGTE),
external page table entry (XPTE), paging vector table (PVT), RSM header
(RSMHDR), and swap control table (SPCT). An RSM service routine called find
page (lEAVFP) locates the PGTE and XPTE control blocks. The table in
Figure 5-24 lists the control block functions.
Control Block

Function

PFTE

describes the last use of a frame

PCB

describes the current or last state of a request

PGTE
XPTE

describes the current real frame and virtual
page relationship for a particular virtual
address

PVT

basically these are RSM anchors and work areas

RSMHDR

header information

SPCT

related only to swapping, it describes the RSM requirements necessary to
swap in an address space (the swap out process formats the SPCT)

Figure 5-24.

Major RSM Control Blocks and Their Functions

Only the leftmost 14 bits of a real address (XRBN) or the leftmost 12 bits of a
virtual address (VBN) are needed to ,describe a specific real frame or virtual page
(a modulo 4K-bytes real and virtual addressing scheme). Also, note the
following:

Section 5. Component Analysis

5-97

•

PGTEs contain XRBNvalues in a rearranged format: bits 0 and 1 of the
14-bit XRBN are in bits 13 and 14 of the 16-bit PGTE, and bits 2 through 13
of the XRBN are in bits 0 through 11 of the PGTE.
PGTE

o

11

o
•

12

13

14

15

2

The contents of PVTPFTP plus XRBNO is the address of the PFTE for the
frame whose real address is XRBNOOO through XRBNFFF.

Of all the RSM control blocks, the most critical are the PCB, PFTE and SPCT.
The important fields in each block are described below. Figure 5-25 shows the
relationship among the blocks.
PGT

PCB

XPT
, XPTE

t
XRBN

PGTE
VBNO

the product of XRBN multiplied
by 16 equal the address of the

~VirtualPage Index

PFTE.
AlA

[)------------I

Figure 5-25. Relationship of Critical RSM Control Blocks

5-98

MVS Diagnostic Techniques

:>----i'" VBNO

= 55PO

1..

Virtual Segment Index

PCB (Page Control Block)

Important fields in the PCB are:
+OPCBCQN -

indicates the current queue location of this PCB as follows:
X'10' - PCB is not currently in use. It is queued on the PCB free queue
anchored in the PVT.
X'18' - PCB is currently waiting for frame allocation to occur. It is queued
on the PCB defer queue anchored in the PVT.
X'20' - PCB represents a common area I/O operation. Actual physical I/O
mayor may not be complete. It is queued on the PCB common-I/O
queue anchored in the PVT.
X'88' - PCB represents a private area I/O operation. Actual physical I/O
mayor may not be complete. It is queued on the PCB local-I/O
queue anchored in the RSMHDR for the address space indicated by
PCBASCB; ASCBRSM points to the RSMHDR.
X'FF' - PCB is probably in use. The not-queued state means only that the
PCB is not on the primary forward/backward chain of the above
mentioned major PCB queues. It can be a related PCB, a root PCB,
or an associated PCB.

+8 PCBFLl:
PCBSRBMD = X'20' -

PCBSRB is the address of a page-fault-suspend
SSRB. The use of this address is the only means of
locating page-fault-suspended SRBs.

PCBROOT = X'04' -

PCBRTCA is the address of a root PCB. Root
PCBs are only valid if their PCBCQN field is
X'FF'.

+9 PCBRTPA-

When the PCBROOT bit is on, this contains the address of a PCB that
controls a block page operation.

+X'D' PCBRLPA-

The address of a chain of PCBs for the same PCBVBN/PCBRBN. The
related chain of PCBs are dequeued PCBs that are chained via the PCBRLPA
field (not via PCBFQP/PCBBQP).

+ X' 10' PCBFL2:
PCBRESET=X'IO' -

The function indicated by the PCB has been
suspended for a page fault because no frames were
available or paging I/O had to be completed before
redispatching the page faulter. PCBASCB,
PCBRTPA, and PCBSRB define the ASCB, TCB,
and RB to be RESET when PCBSRBMD is O.
When PCBSRBMD is 1, PCBASCB and PCBSRB
define the ASCB and SSRB that will be RESET.

+X'll' PCBXPTA-

Is either 0 or the address of the XPTE.

+ X'IS' PCBPGTA -

Is either 0 or the address of the PGTE.

+ X'18' PCBXRBN -

This value when multiplied by 16 and added to the address in PVTPFTP
gives the address of the associated PFTE.

+ X'IA' PCBVBN -

This field is often zero; when it is zero, the operation has either been NOPed
with page I/O still in pr,ogress or the I/O is complete and the PCB is only
serving a scheduling/tnlcking function. The operation is considered to be
complete when PCBVBN = 0; 1'10 other paging request should be able to relate
to it; that is, it cannot be found via an equal compare on PCBVBN. When
PCBVBN is zero, its previous value can be determined from the AlARPN
field in the AlA. The AlA is the last 28 bytes of the PCB.

Section 5. Component Analysis

5-99

The following information about roots is useful to the problem solver.
•

Root PCBs can generally be recognized because most of the PCB is still zero.

•

The SPCT points to active roots for SWAP; RSMSPCT in the RSMHDR
points to the SPCT.

•

V=R waits for region roots are queued from PVTVROOT in the PVT.

•

Vary offiine roots are queued from PVTOROOT in the PVT.

•

PAGE FIX and PAGE LOAD roots can only be found via PCBRTPA of the
queued FIX/LOAD PCBs.

For non-root PCBs: PCBCQN, PCBFLI, PCBFL2, and PCBFL3 are the key
fields. They describe the current state of the paging request for which the
non-root PCB was last used.
See the topic "PCB Trace Facility" later in this section for a description of PCB
tracing.
SPCT (Swap Control Table)
The SPCT is mapped in modules IEAVSOUT, IEAVSWIN, IEAVCSEG, and
lEAVITAS. Space for the SPCT is obtained via GETMAIN and is initialized in
lEAVITAS. As segments are created, lEAVCSEG updates the SPCT.
IEAVSOUT initializes the spct with the pages that make up the working set
(such as, LSQA and fixed pages plus recently referenced pages). IEAVSWIN uses
the information lEAVSOUT put in the SPCT in order to start up a previously
swapped-out address space. Note that a one-stage swap permits pageable working
set pages to be written to the swap data set along with the LSQA pages. This
improves response time for swappable address spaces (such as TSO).
The first portion of the SPCT contains the address of the swap root PCB
(SPCTSWRT); the number of fixed, LSQA and pageable page entries in this
SPCT (SPCTFIX, SPCTLSQA and SPCTSIPE); the number of segment entries
and the number of active segment entries (SPCTNSEG and SPCTSSEG); and the
working set size (SPCTWSSZ). The flags at offset X'A' are defined as follows:
X'80'
X'40'
X'20'
X'IO'
X'08'
X'04'

Swap-in in progress
Swap-out in progress
Paging was purged during swap-out
There is at least one fix entry with a fix count greater than 255
Page data set used for LSQA
Swap-out requested by lEA VEQRP

The next portion of the SPCT (SPCTSWAP) is the SPCT extension and is 56
(decimal) bytes long. It contains a maximum of six fix swap entries or eight
LSQA swap entries, or a combination of the two. In a combination, LSQA
entries precede all fix entries. LSQA entries are six bytes each and fix entries are
eight bytes each. Both entries contain the following flags in the first byte:
X'80' LSID in this entry is valid.
X'40' This is an LSQA or pageable page entry.

5-100

MVS Diagnostic Techniques

X'20' This SPCT entry is for a pageable page that should be backed below 16 Mb, if possible, because
it was previously fixed and will probably be fixed again later.
X'IO' The page was flagged defer release at swap time.
X'OS' This SPCT entry is a pageable page. Note that X'4S' indicates a pageable page and X'40'
indicates an LSQA page.
X'04' This SPCT entry indicates a pageable page that was changed during the swap-in interval. On
swap-in the change bit must be turned on in the protect key because a valid auxiliary copy does
not exist.
X'02' This SPCT entry is ignored.

This flag byte is followed by a three-byte LSID and a two-byte VBN. If the entry
is for LSQA or pageable page, there is nothing more, but if the entry is a fix
entry, the next two bytes contain the fix count. The last portion of the SPCT
contains a variable number of six-byte segment entries. The first byte is the
segment number and it is followed by the address of the page table. The next
two-byte field (SPCTBITM) is a 16-bit map indicating which pages are to be
brought in at swap-in time as two-stage pageable working set pages.
PFTE (page Frame Table Entry)
Important fields in the PFTE are:
PFTIRRG -

indicates the format of the first word of the PFTE. This bit is located in PFTFLAG2 at
offset X'D' and is a X'IO'. If it is on, the first word of the PFTE is mapped as
PFTPGID and contains a VIO LGN and RPN. If PFTIRRG is off, the first word of
the PFTE is mapped as PFTASID and PFTVBN. An ASID cfX'FFFF' indicates a
COmmon area page. Note that a VIO LGN can be the same as an address space ASID;
address space ASIDs and LONs are seldom the same but could be.

PFTPCBSI -

indicates there is a PCB on an I/O queue for this page; there can be a string of related
PCBs for this page. This bit is located in PFTFLAG I at offset X'C' and is a X'OS'.
This bit is turned off by the process that validates the page when the I/O completes, or,
for output I/O, after the I/O completes but before the PFTE is sent to the free queue.
Note that I/O queues sometimes contain several "no-op" PCBs; these appear to point
back to a frame and its associated PFTE. When a PCB is made into a "no-op,"
PFTPCBSI is turned off and the association between that PCB and that frame and its
associated PFTE is broken. These "no-op" PCBs are either output PCBs with
incomplete I/O or input PCBs with complete I/O.

PFTSASF -

indicates whether RSM or PF A (page fault assist) allocated the frame. If this bit is on,
the frame was allocated by RSM. If this bit is off, the frame was allocated by PF A.

Page Stealing
Figure 5-26 shows the flow of the page stealing process. The circled numbers in
the figure correspond to the notes below.
If the frame queue is for a private address space that is not the current address space,
lEAVRFR issues CMSET to the private address space.
2

IEAVRFR scans the local frame queue (LFQ) or common frame queue (CFQ); the queue it
scans is determined by the parameter list received from SRM.

3

lEAVRFR checks the hardware reference bits and then updates the unreferenced interval count
(VIC). lEAVRFR orders the LFQ and the CFQ so that the PFTEs with the highest VICs are
at the top of the queue. The queues are in descending order, with zero VICs at the bottom.

Section 5. Component Analysis

5-101

4

Frames are selected to be stolen based on their VIC and pageability; that is, fixed/LSQAjbad
pages, and pages that are V = R allocated cannot be stolen.

5

IEAVRFR calls a common routine, FREEPAGE, to invalidate selected pages and free a frame
(if a page is unchanged), or to build a PCB for the page-out process (if the page is changed).

6

When the scanning of the queue is completed, lEAVRFR calls ASM to start output paging if
any PCBs have been accumulated.

7

lEAVRFR issues CMSET to return to the original address space, if necessary.

IRARMSTM
SR M branches to
IEAVRFR

RFR
parameter list

;

Flags

,

A (ASCB)

IEAVRFR

Flags
For common
area steal

...

A (0)
Flags
A (ASCB)

Parameter list is in
module IRAR MSTM
(Label RFRLSTH

Figure 5-26.

CD

Issues CMSET, if necessary

@

Obtains queue headers

®
0

Selects frames to be stolen

®
®
CD

Stops scanning the frame queue when the UIC is
less than the criteria number
Calls FREEPAGE
Starts accumulated I/O

---

ASM
:..-: ILRIODRV

I

Issues CMSET, if necessary

Page Stealing Process Flow

Reclaim
Reclaim is an RSM function that revalidates a page/real frame pair that was
previously invalidated. IEAVGFA performs the reclaim for the normal case after
a page fault on an address space or common area virtual address. IEAVAMSI
handles the VIO case.
In the virtual address case, lEAVGFA handles work as follows:
1. PCBVBN is used to locate the PGTE.

5-102

2.

The PGTE is used to obtain the last-used XRBN value.

3.

The XRBN is used to address the PFTE.

4.

PFTIRRG is checked to determine if the first word of the PFTE is in
PFTPGID or PFTASID/PFTVBN format.

5.

If PFTIRRG = 0, PFTVBN is compared to PCBVBN.

MVS Diagnostic Techniques

6.

If the VBNs match and the VBN is in th~ common area, the reclaim is:
successful. If the VBN is in the private area and PFTASID matches
ASCBASID (which PCBASCB points to), the private area reclaim is
successful.

In the VIO case, lEAVAMSI handles work as follows:
1.

lEAVAMSI is supplied with both a XRBN and a DSPID.

2.

The XRBN is used to address the PFTE.

3.

PFTIRRG is checked to determine if PFTPGID is in PGID format.

4.

If PFTIRRG= 1, PFTPGID must match the DSPID; if it matches, the
reclaim is successful.

When reclaim fails, normal frame allocation paths are followed just as though the
page had never been in storage.

Relate
Relate is an RSM function that associates independently-generated page requests
(PCBs) for the same virtual address. When the physical action required to satisfy
one of these requests (I/O or frame allocation) is completed, all related requests
are also satisfied. A PCB-related chain is produced for all cases except the VIO
data set. The same modules that do reclaim, lEAVGF A and lEAVAMSI, handle
the relate process, which only follows after a successful reclaim.
In the virtual address case, IEAVGFA handles work as follows:
1.

The relate function is invoked for one of two cases:
•

The reclaim function has successfully completed and PFTPCBSI is on,
indicating page I/O is in progress; a PCB I/O queue is searched .

•

The XPTDEFER bit is on, indicating that the previous PCBs have been
delayed because frames were not available. The GF A defer queue will be
searched to do the relate function.

2.

The search argument is PCBVBN in all cases except that of the GFA defer
queue; in that case PCBASID and PCBVBN are the search arguments.

3.

When the correct queued PCB is located, the current PCB is added to the
rela ted PCB chain. For the defer case, the PCB is added to the head of the
chain; for the I/O case, the PCB is added to the end of the chain.

In the VIO data set case, lEAVAMSI handles work as follows:
1.

The PCB local I/O queue is scanned for a match on PCBRBN because
PCBVBN is always set to 0 for move-out PCBs. If PCBRBN matches,
PCBVAM must be on.

Section 5. COIl}ponent Analysis

5-103.

2.

When the correct PCB is found, it is·updated with the information the I/O
completion portion of RSM needs to place the page of the VIO data set in
the new window location (this is not necessarily a new page).

RSM Recovery
RSM recovery consists of a SETFRR at all major entry points to the RSM:
•

The issuer of the SETFRR places the address of the FRR in PVTPRCA.

•

Each SETFRR returns a six-word parameter list in the recovery
communications area (RCA).

•

RSM has only one FRR - lEAVRCV.

•

The IHARCA macro maps the RCA; this macro can be found in most RSM
modules.

•

lEAVPSI contains the RCA macro in assembler language format.

Whenever an unexpected error or COD abend occurs, the RCA is copied into
SDWAVRA. The CSECT ID and the module-entered flag in the RCA can be
used to determine the path taken through RSM to the point of error. To
determine this path, you must understand the RSM flow and know which module
issues SETFRR. The following RSM modules issue SETFRR at their main entry
point:
IEAVAMSI
IEAVCSEG
IEAVEQR
IEAVIOCP
IEAVITAS
IEAVPIOI

IEAVPIOP
IEAVPIX
IEAVPRSP
IEAVPSI
IEAVRCF
IEAVRCF3
IEAVRCV
IEAVRFR

IEAVSOUT
IEAVSQA
IEAVSWIN
IEAVTERM
IEAVRELS at IEAVRELV (entry point)
IEAVFRSB at IEAVPRSR (entry point)
IEAVSWPP

RSM's FRR does not attempt complex recovery. Its main objective is to record
the error and issue an SDUMP. It has some special logic based on where the
error occurred, as follows:

5-104

Error Occurred In

FRR Action

lEAVEQRI, lEAVRCFI,
or IEAVRF3I

Restore registers for return to lEA VPFTE.

IEAVPIX

Attempt to reset page faulter.

IEAVSIRT

"Memterm" swapping in address space.

IEAVSWIN

"Memterm" swapping in address space.

IEAVPIOI

Retry for cleanup or "Memterm."

IEAVINV

Set "GO" indicator and PTLB or retry to PTLB.

IEAVPSI

If error occurred while checking input parameters, set abend of 171.

MVS Diagnostic Techniques

If error occurred in IEAVPSI at entry point IEAVPSIX, IEAVPSIY, or
lEAVPSIF, ensure that if the SALLOC lock was held, it is released
prior to percolation.
Other

If it is a non-zero retry address, retry; otherwise continue with
termination.

Recursion is not allowed. The PVT and PFTEs are dumped on the SDUMP.
The following reason codes are put into the RCARCRD field when real storage
management issues abend with a code of COD. All COD abends are retried at the
next sequential instruction.
Real Storage Management ABEND Reason Codes
Code

(hex)

Meaning

01

Findpage, translate real to virtual, or the LRA instruction returned an unexpected code for a
segment, page, or frame whose existence was implied by some RSM control block or function.
Findpage, translate real to virtual, or LRA is assumed to be correct.

02

A GETCELL or FREECELL for the RSM cell pool failed. If FREECELL, the error is
ignored; if GETCELL, asynchronous retry is attempted where possible.

03

A FREEMAIN failed for space originally obtained by RSM or VSM using GETMAIN. The
error is ignored.

04

The return code from ASM (ILRSWAP, ILRIODRV, or ILRTRPAG) indicates an invalid
request. The recovery action taken by RSM varies with the type of request, but the RSM
function being performed is usually terminated if ASM resources were being requested, or
continued if ASM resources were being returned.

05

A GETMAIN for RSM control block space was unsuccessful. The function for which the
space was required is terminated.

06

An attempt was made to release a lock which was not held. RSM tables might be damaged
due to the loss of serialization. RSM attempts to continue normal operation.

07

RSM control information indicated a PCB for a page should exist on an 1/0 active queue or
on the defer queue, but searching of the queue(s) failed to find the PCB. It is assumed the
control information is in error and no such PCB exists.

08

The existence of a V = R or offiine root PCB was implied but no appropriate PCB could be
found on the V = R or offiine root queue. The error is ignored and indicators are reset.

09

Swap-in's XMPOST error exit was entered, so restore will not run. The target address space is
terminated.

OA

An incorrect fix count was detected in a PFTE. The count is adjusted to the expected value.

OB

The interprocessor communications service routine (RISIGNL) could not signal another
processor as requested by IEAVINV. The condition is ignored and normal operation
continues.

OC

lEA VPIOP has discovered an undefined combination of I/O completion status flags in the
AlA after a page-in or page-out. The condition is treated as an I/O error.

OD

IEAVDSEG was requested to destroy a non-existent or common area segment. The request is
denied.

OE

A PCB was required but none were available. The routine needing a PCB is terminated.

OF

The attempt to complete processing of a previously deferred FREEMAIN release has failed.

Section 5. Component Analysis

5-105

10

An FOE could not be found on the specified TCB's fix ownership list.

11

An internal RSM invocation of the PGOUT function was unsuccessful. The page remains in
real storage.

12

A swap (in or out) was requested for an address that already has a swap in progress, or no
SPCT exists for the address space to be swapped. The request is denied.

13

Swap-in could not re-establish the address space due to missing or incorrect control
information (SPCT or PCBs). The address space is abnormally terminated.

14

An internal invocation of PGFREE failed. The error is ignored.

15

Swap-out has detected an inconsistency in the SPCT fix entries it has created. The error is
suppressed and recovery attempted.

16

ASCBCHAP could not enqueue or dequeue an ASCB during a swap-in or swap-out operation.
The address space is terminated.

17

Swap-out has detected an error in the allocated frame count (ASCBFMCT) for the address
space. If possible, the count is corrected and the swap-out continued; otherwise, the swap-out
is suppressed.

18

No SPCT segment entry could be found for a segment whose existence was implied by other
RSM control information. The error is ignored and the SPCT update is skipped.

19

An internal RSM function issued a return code which was either invalid or not applicable.
System action depends on the nature of the function.

IA

Swap-in detected a common area page that was not obtained using GETMAIN among the
input working set. The page is not made available to the incoming address space. Some other
address space must have freed the page using FREEMAIN while the current one was'"
swapped-out. Probable user error.

IB

During an attempt to free the frames backing a V = R region, it has been determined that the
virtual space is not backed by real storage, or that the virtual-to-real mapping is not I to I.

IC

lEAVPSI attempted to fix the ECB for a page service that will complete asynchronously, but
lEA VFXLD returned a code indicating the fix was not accomplished.

ID

A PCB marked I/O complete (indicating that it was previously processed by lEAVPIOP) has
been passed to lEA VPIOP by ASM.

IE

A software error has been found in the AlA passed from ASM to RSM for an I/O request.
Possible errors are:
•
•
•
•
•

5-106

The AlA contains data inconsistent with previous AlAs.
The original input chain (to ASM) was invalid.
The LSID in the XPTE was invalid.
The LPID in the XPTE was invalid.
A hardware I/O error occurred on a pageout PCB (this should not occur).

IF

An invalid real storage address was returned to IEAVPRSB at entry point IEAVPRSR.

20

SWAP-out has encountered a bad frame. The page residing in that frame will not be paged
out. If the page is a private area page, it will be "locked" into storage for the duration of the
swap. During this time, V = R allocation and vary omine of storage could be affected. If the
page is an LSQA page, a DONTSWAP sysevent is issued.

21

IEAVPFTE detected a discrepancy in the SQA reserve queue count controls. Use of the SQA
reserve queue is discontinued until after re-IPL RSM attempts to continue normal operation.

22

lEAVTERM has found an FOE fix count that is greater than the fix count in the
corresponding PFTE. The PFTE fix count is not changed, but the FOE is freed.

23

Entry point lEAVREPI in module IEAVPCB was passed a nonzero return code from
IEAVBLDP, which indicates the CPAB for RSM is bad.

MVS Diagnostic Techniques

25

During lEAVSOUT processing, the search for a PCB on a related chain failed.

26

During IEAVRCF processing, using input from PFTASID, the LOCASCB failed.

27

In IEAV AMSI, the ASGNLOAD subroutine found fewer UCBs requiring page-ahead PCBs
than the mainline routine in lEAVAMSI had counted.

28

In IEAVSOUT, a pageable changed page was valid in storage at the time an SPCT entry was
built for it. However, the page was found invalid when an LRA instruction was done while
building a PCB for it.

29

An undefined function code was passed to lEAVPRSB at entry point lEAVPRSS.

2A

In IEAVPREF, an attempt to issue message "IEA9881 PREFERRED AREA EXPANDED.
RECONFIGUREABILITY MAYBE IMPAIRED" failed.

2B

During page fault assist (PFA) processing, the microcode encountered a program check. Code
X'2B' is issued by lEAVPIX upon receiving control from the program check FLIH after PF A
processing issued a X'26' program interruption.

RSM Debugging Tips
1.

Because the PCB free queue is a FIFO queue, it represents recent history in
RSM. Start your search of the PCB free queue with the youngest PCB
(PVTFPCBL) and look for the appropriate VBN in the PCBVBN or
AIARPN. This approach often reveals what has most recently happened to
the page in question.

2.

Whenever the system wants to break the logical connection between the PCB
and the page, it sets PCBVBN to zero. Therefore, look at AIARPN to
determine what VBN the PCB was associated with (AIARPN=PCBVBN/16).

3.

The PVT contains several work/save areas that belong to a unique module.
These are often useful to determine the last thing a module did.

4.

At any time, there should never be more than one input PCB with a given
PCBVBN on the I/O-active or GF A-deferred PCB queues. Output PCB& are
never in a related position. Although, an output PCB for a nondisconnect
VIO moveout might have input PCBs related to it.

5.

The XPTVIOLP flag can be confusing. If it is on, XPTXAV must be on.
XPTVIOLP = 1 indicates that there is an LPID in the XPT, not an LSID.

6.

It is sometimes useful to observe the AIANXAIA pointers in PCBs on the

PCB free queue. These pointers probably indicate the order in which I/O
completed for a group of requests.
7.

To help diagnose a COD abend, the PVTDUMP bit (byte 0, bit 7 of the PVT)
can be turned on (using superzap) to cause the RSM FRR to dump the PVT,
PFT, SQA, and current LSQA data areas.

8.

On a system with page fault assist active, if there is a problem with
RSM-related control blocks, the problem might be caused by an earlier
problem suffered by the page fault assist microcode. The occurrence of a
page fault assist problem is indicated by a program check X'26', which RTM
converts into a X'OD9' abend. The page fault assist microcode alters RSM

Section 5. Component Analysis

5-107

control blocks, and if unable to complete processing, might leave the control
blocks partially updated before generating the program check X'26'.

Converting a Virtual Address to a Real Address
A virtual address contains the segment number in the first byte, the page number
in the next four bits, and the page displacement in the remaining twelve bits (that
is, sspddd - segment, page, displacement). The ASCB for the address space points
to the RSMHD. The first word (RSMVSTO) of the RSMHD is the virtual
address of the segment table (SGT). Multiply the segment number (ss) by the
length of a segment table entry (4) to locate the SGT entry (SGTE). The SGTE
contains the real address of the page table (PGT).
A real address consists of a 14-bit real block number (XRBN) followed by a
12-bit page displacement (that is: rrrrddd-XRBN, displacement). The XRBN
portion of the real address of the PGT is concatenated with zero (XRBNO) to
form an index into the page frame table (PFT). This index is added to the
apparent origin of the page frame table (PVTPFTP) in order to obtain the virtual
address of the page frame table entry (PFTE). The PFTE identifies the frame
that contains the page in which the page table resides.
The second half of the first word of the PFTE is the virtual block number (VBN).
The VBN is concatenated with the displacement portion of the real address of the
page table to form the virtual address of the page table (VBNllddd). Multiply the
page number (p) of the virtual address being converted by the length of a page
table entry (2) to locate the PGT entry (pGTE). The PGTE contains the XRBN
portion of the real address that corresponds with the initial virtual address.
Bits 13 and 14 of the PGTE are concatenated in front of bits 0-11 of the PGTE to
form XRBN, as follows:
11

o

12

13

14

15

2

This XRBN is concatenated with the displacement portion of the initial virtual
address to obtain the desired real address (RBNllddd).
Figure 5-27 shows the relationship of the control blocks used to convert a virtual
address to a real address.

5-108

MVS Diagnostic Techniques

Given a virtual address - find the corresponding real addr...
Definitions: Virtual address =sspddd =VBNllddd
55
- segment number
p
- page number
ddd - displacement within page
VBN - virtual block number
Real address = XRBNllddd
XRBN - real block number:
ddd - displacement within page

r-

G)

-

._--

--

--

--

--

--

--

--

--

---

Find the real address of the page table (RBNlld'd'd').
RSMHD

ASCB
~

______~I

SGT

~ RSMVSTO ~

~

ASCBRSM

L-

+ (4*ss) ......

SGTE

1------1

SGTE contains the real address of the page table
I--

®

-

-- ._- -- -- -- -- -- -- - ----

Convert the real address of the page table to a virtual address (VBNlld'd'd').
PVT

PFT

I

PVTPFTP

.

~--------t
PFTE

~~-+XRBNO----~

L

1 - - - - _... , , -

from SGTE
PFTE contains the VBN portion of the virtual address of the page table.

Find the XRBN portion of the real address.
PGT

VBNlld'd'd'

(m \1._
PFTE

I
i

t®

[+12

ASHMD

Header

0

L~ES{

0

Q)

0:::

•

SRB

DEIB
entry

PARTES

CCW

LGE
ASCB

CCW

•

LGE

CCW

•

ASCB

•

Header

CVT + 2CO

1t*~j
\

Figure 5-28.

5-116

Header

ASMVT

J

Relationship of Important ASM Control Blocks

MVS Diagnostic Techniques

000111
111111
101101

uu

Component Operating Characteristics
The following topics discuss characteristics of ASM's operating environment.
System Mode
ASM uses the SALLOC lock in most page and swap processing in I/O control
modules. I/O control modules interface directly with RSM, the principal user of
the SAL LaC lock. The SALLOC is held throughout processing, including the
calls to the VIa control routines ILRPOS and ILRVIOCM. The local lock is
used during assign and release logical group requests processed by ILRGOS and
ILRRLG.
An ASM class lock exists for each active address space (lockword in ASMHD).
The ASM class lock is used by the VIa control modules. The ILRCMPDI,
ILRCMPCI, and ILRCMPNT entries of ILRCMP run in physically-disabled
mode because they run under the I/O interrupt handler. (ILRCMPNT also runs
under lOS front end processing.) The rest of ASM's modules simply run in task
or SRB mode using compare and swap instructions where necessary.
For additional information on locking, refer to the topic "ASM Serialization"
later in this section.
Address Space, Task, and SRB Structure
The I/O control modules given control from RSM and lOS run in the address
space of the caller. These modules (and entry points) are:
ILRIODRV
ILRSWAP
ILRCMPDI

ILRCMPCI
ILRCMPNT
ILRCPBLD

ILRPAGCM
ILRFRSLT

Note: ILRPAGCM transfers to the correct address space (via CMSET) to
update the external page table entry (XPTE) that is in the LSQA.

The remaining I/O control modules and alternate entry points in other modules
run in SRB mode in the master scheduler's address space.
VIa group operator modules, as well as ILRGOS (VIa control module), are tasks
(locked mode) executing in the address space associated with the VIa requests.
ILRTMRLG runs in task mode, but in the master scheduler's address space.
VIa control modules ILRPOS and ILRVIOCM receive control in the address
space of the caller. ILRSRBC executes in SRB mode in the address space
associated with the VIa requests.
Storage Considerations
ASM maintains three cellpools for its internal control blocks. These cellpools are
pushdown stacks and the elements at the top of the cellpools represent the last
control blocks used by ASM. The cellpools are for work areas, ACEs, BWKs,
and SWKs. These cellpools are expandable. The cellpools are anchored in the
ASMVT and the control blocks reside in SQA. The ASMVT is in the nucleus,
but most of the other ASM control blocks are in SQA. One exception is the
ASPCT, which resides in the LSQA of the associated address space.
Section 5. Component Analysis

5-117

Interfaces With Other Components

Five other components interface with ASM:
•

RSM with I/O control for page and swap I/O requests, .and with VIO control
for transfer page requests.

•

VBP with VIO control for assign, save, activate, and release logical group
requests.

•

lOS with I/O control to process I/O requests.

•

VSAM with VIa group operators to handle I/O to SYSl.STGINDEX. RSM
and VBP call ASM, and ASM calls lOS and VSAM.

•

Contents supervisor with VIO control for XM ASSIGN logical group
requests.

Register Conventions

ASM modules adhere to the following register conventions when calling other
ASM modules. There are some exceptions where certain addresses are not
required.
Register:

0

Parameter register, if required.
Parameter register, if required.

2

RSMHD or ASMHD address for the current address space or the address space
identified by an input parameter in register 0 or 1.

3

ASMVT address.

4

Address of ATA or EPATH currently active for recovery tracking.

13

-

Address of register save area, if required.

14

-

Return address.

15

-

Entry point address.

Footprints and Traces

The most useful traces of ASM processing are its control blocks and queues,
because they document the movement of requests through ASM.
The processor work/save area vector table (WSAVT), which is pointed to by
LCCACPUS, will point to the work/save areas for the last I/O processed on the
processor. WSACASMS points to the l024-byte save/work area used by ASM
routines running as SRBs: ILRSWPDR, ILRCMPAE, ILRCMPNE, and
ILRCMP. WSACASMD points to another l024-byte save/work area for disabled
ASM routines: ILRIODRV, ILRCPBLD, ILRCMPDI, ILRCMPCI, and
ILRCMPNT. WSACASMR points to a 512-byte save/work area used by
ILRIOFRR. ILRPAGCM uses the work area of its caller.
ASMVT contains save areas for ASM's other I/O-related modules. ASMBWKPC
is a pool of work areas used by VIO-related modules (ILRGOS, ILRACT,

5-118

MVS Diagnostic Techniques

ILRSAV, and ILRRLG). Bits in the X'OI' byte ,of the ASMVT indicate whether
the IPL was a cold, quick, or warm start.
The LGE process queues (LGEPROCQ) contain AlAs and ACEs in process, or
AlAs and ACEs waiting for processing of VIO requests.
Field IORNOP (IORB + X'2C') points to the end of the channel program pointed
to by the field IORPCCW. If ASMTMECB (ASMVT+X'AS') is a posted ECB,
ILRTMRLG is or was about to process the task portion of a release logical group
request.
When an ASM-Iocked or SRB-mode routine is processing, its functional recovery
routine is on the current FRR stack. The first word of the parameter area passed
to the FRR contains a one-byte id of the ASM module that established the FRR,
followed by three bytes of flags indicating the ASM module or entry point in
process at the time of the error. The different ids are discussed in "Recovery
F ootprints. "
When ASM's I/O completion module encounters the first bad slot, an error record
is built with its address at X'14' into the ASMVT. It contains the LSIDs of the
unusable slots. The first three bytes in the record are the address of the current
entry filled, beginning address of the record, and ending address of the record.
An entry contains one byte of flags and the three-byte LSID. If bit 0 is on, the
error occurred on a swap data set. If bit 4 is on, there was a read error. I/O
error counts are found in the ASMVT, PART entries and SART entries.
ASMERRS (ASMVT + X'7C') is the total of error slots found on local page data
sets. PARERRCT (PART entry + X'IS') and SRERRCNT (SART entry +
X'IS') are the error slots encountered on the particular data set represented by the
entry.
In the ASMVT there are four counts, ASMIORQR (ASMVT + X'2S') and
ASMIORQC (ASMVT + X'2C'), which contain both the number of paging I/O
requests ASM has received and the number completed; and ASMSWRQR
(ASMVT + X'30') and ASMSWRQC (ASMVT + X'34'), which contain both the
number of SWAP working set requests ASM has received and the number
completed. If more requests have been received than completed and the system is
waiting, there is something wrong with ASM or lOS ..

General Debugging Approach
This description helps isolate paging problems, the most difficult problems to
debug. Paging problems (not all of which are ASM problems) fall into two main
groups - paging interlocks and incorrect or duplicate pages.
Paging Interlocks

Paging interlocks result in an enabled wait state. There are two indicators that
hint that the enabled wait is a paging interlock:
•

The I/O request counts in the ASMVT (ASMIORQR and ASMIORQC, or
ASMSWRQR and ASMSWRQC) are not equal. The PAREREQS field
(PARTE X'3E') in the PART entries indicates which data sets have
uncompleted I/O requests when ASMIORQR is greater than ASMIORQC.

Section 5. Component Analysis

5-119

•

Field ASMPSRB points to an SRB used to redrive work through ASM. The
SRB parameter field points to an 8-byte parameter list that contains the
addresses of the first and l&st requests on the redrive queue. If these are
nonzero, the ASM redrive SRB has been scheduled, but not dispatched. It is
necessary to determine why the SRB has not been dispatched.-

The blocks discussed here are in the Debugging Handbook. To find the I/O
request blocks for a given page space, start with the PART entry. The PART
entry points to the first 10RB.
There is one 10RB for each page data set on a disk, four for each page data set
on a drum, and three for each page data set on a cached auxiliary storage
subsystem. The first bit of the fourth byte indicates whether or not ASM has
passed the 10SB to lOS. If the bit is 0, the 10RB/IOSB is available. If the bit is
1, the 10RB/IOSB is in use. The 10RB contains fields that point to the 10SB, to
the first of a queue of PCCWs, and to the last CCW in the channel program. For
an active I/O request, the third word into the PCCW points to the associated
AlA, and the fourth word points to the next PCCW on the chain.
If the request has been sent to lOS and not returned, it is necessary to trace lOS
processing. If I/O processing has caused a page-fault or a request for an enabled
lock, the interlock is probably explained. Either ASM could not get the resources
to handle the page fault, the page is already in use and this request is backed up
behind the previous one, or the holder of the lock has page-faulted and the page
fault cannot be resolved.

Incorrect Pages
It is almost impossible to determine from a dump what caused the wrong page to
be written or read. At best, a dump provides clues as to which general area is
causing the problem. Intensive code reviews are then necessary to find it.
Frequently, traps must be applied to narrow the area further.

The following paragraphs contain descriptions of how to find various pieces of
useful information. There is no attempt to describe how to use them because
there is no general method.
It is first necessary to determine which page contains bad data and whether the
whole page or only part of it is bad. If possible, also determine which page has
overlaid the bad page. If only part of the page is bad, the error probably
occurred while handling a track overflow record to or from an alternate track.
Check for an invalid first or last part of a page. ASM is unlikely to be the cause
of invalid data in the middle of the page.

Incorrect pages cause a system failure when the page is used by a system task or
by a routine holding a critical system resource. The invalid page is more likely to
cause an address space to fail because of program checks that result from invalid
data. These failures are rarely attributed to invalid pages.
Scan the SYS1.LOGREC data set for any improbable program checks and obtain
any associated dumps. Multiple versions of the same problem are helpful in
suggesting a pattern for the error. For example, the error might only occur for
the second page ofLSQA or only on a page associated with an overflow record.

5-120

MVS Diagnostic Techniques

Finding the LSID for a Given Page
A virtual address contains the segment number in the first byte, the page number
in the next four bits, and the page displacement in the remaining bits in the form
sspddd (segment, page, displacement). The ASCB for the address space points to
the RSMHD. The first word of the RSMHD is the virtual address of the segment
table. Multiply the segment number (ss) by the length of the segment table entry
(4) to locate the correct entry. It contains the real address of the page table
(pGT). Convert this address to a virtual address. Then locate the correct
external page table entry (XPTE) by adding 16 times the length of the page table
entry (2), and adding the page number (p) times the length ofaXPTE (12).
The XPTE contains information about the status of this page on auxiliary
storage. If either the XPTVALID or XPTVIOLP flag is on, there is a slot
assigned to this page. If XPTVALID is on, the LSID (slot identifier) is in the
XPTE. If the page is duplexed, two LSIDs are in the XPTE (one for each slot).
If XPTVIOLP flag is on, an LPID instead of an LSID is in the XPTE. To relate
the LPID to an LSID, see the following topic "Finding LSIDs of VIO Data Sets."
Finding LSIDs of VIO Data Sets
The ASPCT is used to record the auxiliary storage locations (LSIDs) of VIO data
set pages. Only a 1088 byte base ASPCT is created at ASSIGN LGN time. This
ASPCT can handle up to 1 megabyte of VIO data set space. If more than 1
megabyte of VIO space is used, the ASPCT is expanded as follows:
1.

For each 256 megabytes of space up to 1 billion bytes, an ASST extension is
built.

2.

For each megabyte of space, a LMPE extension is built.

Each ASST or LPME extension requires 1088 bytes of storage. Each ASST
extension contains a vector table of LPME extension addresses. The ASPCT
(base and all extensions) resides in the LSQA of the associated address space.
The LPID is eight bytes. The first four bytes contain an LGID, logical group
(VIO data set) identifier. The second four bytes contain a relative page number
(RPN).
When given an LGID, there are two methods to locate an ASPCT:
1.

The ASCB (of the desired address space) points to the ASMHD. ASHLGEQ
in the ASMHD is the queue of LGEs (active VIO data sets) related to this
address space. Searching through the address space's ASHLGE queue, one of
the LGEs will have an LGELGID field that matches this LGID. This same
LGE has the address of the needed ASPCT (LGEASPCT).

2.

Another way to locate an ASPCT from an LGID is to follow the CVT to the
LGVT (CVTASMVT, ASMLGVT). Using the LGID as an index, locate the
appropriate LGVT entry. The LGVT entry contains the address of the LGE
that contains the address of the needed ASPCT.

Note: The second method must be used to locate the ASPCT of a cross-memory
assigned VIO data set.

Section 5. Component Analysis

5-121

With the appropriate ASPCT, now use the RPN portion of the LPID as an index
to locate the LPME containing the associated LSID.
Figure 5-29 shows the pointers and control blocks described in the following
paragraphs.
If A' and AA are both zero, use the LL to index ASPLPMES in the ASPCT base
for the LPME containing the LSID.
Otherwise, use A' to index ASPASSTP for the address of the appropriate ASST
extension. Use AA to index the ASPSECTA of the ASST extension for the
address of the appropriate LPME extension. And use LL to index the
ASPSECTA of the LPME extension for the LPME containing the LSID.
The LSID is the slot identifier for this page of the VIO data set. This LSID can
be related to the ASM control blocks PART and PAT and to the actual paging
device. See the following topic "Locate PART and PAT Bit."
LPID:

RPN:

o

3

2

indexes the base ASPCT, ASPASSTP.
indexes the ASST extension, ASPSECTA.
indexes the LPME extension, ASPSECTA.

+A'

ASPCT Base

ASPCT ASST
Extension

ASPCT LPME
Extension

Header

Header

Header

(
ASPASSTP

1

+AA

(

+LL
ASPSECTA

I

ASPLPMES

Figure 5-29.

5-122

MVS Diagnostic Techniques

Locating An LSID From An LPID

(
ASPSECTA

I

Locate PART and PAT Bit
Suppose LSID 000403BD was found in the XPTE that represents the sample
address 07 AI2C:
PART entry index is 04.
Relative slot number is 03BD.
The PART has one entry for each page data set, each having a pointer to its
PAT. The PAT is a cylinder bit mapping of this page data set. PATCYLMW is
the number of words that map a cylinder. PATCYLS, slots per cylinder, is the
number of significant bits in each cylinder mapping.
For device 2305-2:
PATCYLMW is 1
P ATCYLS2 is (A26).
To locate the bit in the PAT map for slot 03BD(957):
1.

address of map word = (address of PATMAP) + 147 = (address of
PATMAP) + (957/26) x PATCYLMW x (bytes in a word))

2.

bit in the map word (origin 0) = 957/26 = 21.

Section 5. Component Analysis

5-123

Figure 5-30 shows the control blocks involved in relating a virtual address to the
PART and PAT.
PSA

~

~

+10

FLCCVT

+224

PSAAOLD

CVT

+2CO

ASMVT

CVTAS_MVT

V

ASMPART

)

PAT
(PART
Header

PARTE

••
•

~

•
•••

~

•

______

ASCB

~
+34

PAREPATP
PAREDEIB

~

PAT
BIT
MAP

~DEIB

.-.... RSMHD

~/+O

Header

.-----_
PGT

.- SGT

RSMVSTO

V

1---------4:

ASCBRS'M

SGTE

I-------~

••
••

....

PGTE

•
•
•
•
•

>-16 PGTEs

PGTE

16XPTES1:~______

X_P_i_E_ _ _ _ _

~

140 lao
1 1 100 100 1_____ '---------1
----~----------------~------~----XPTE

1 00 1 04 1 E3 (BO

00

00

12-byte XPTE

Figure 5-30. Relating the Virtual Address to the PART and PAT

Converting a Slot Number to Full Seek Address
The full seek address can be used to read the record from the disk and determine
exactly what it does contain.
The PART entry points to the data set extension information block (DEIB) for
the data set. The DEIB describes the page data set on the device. The DEIB
consists of an 8-byte header followed by entries, one for each extent. The second

5-124

MVS Diagnostic Techniques

word of the header contains the number of entries in this DEIB and the length of
each entry.
The relative .cylinder and the slot number within the cylinder that the slot is on is
calculated by dividing the relative slot number by the number of slots in a
cylinder. The ext~nt containing this relative slot is found by comparing the
relative cylinder found previously to the low and high relative cylinders in each
extent. The physical cylinder (CC portion of MBBCCHHR) is found by
obtaining the relative cylinder within the extent and adding it to the real starting
cylinder of the extent (also found in the DEIB entry). The head and record
(HHR portion of MBBCCHHR) is found by indexing into the physical
characteristics table (PCT) of the page data set using the slot number within the
cylinder found previously.
For example, when given a relative slot number of 03BD(957), calculate the
MBBCCHHR for device 2305-2.

M = extent number
BB = 00
relative cylinder

=

0

relative slot number/cylinder size
957/26 = 36

slot within cylinder = relative slot number
- (relative cylinder x slots per cylinder)
957 - (36 x 26)
957 - 936 = 21
CC

HHR

(relative cylinder - DEILOCYL + DEISTCYL)
(36 - 0 + 0) assuming the page data set starts on physical cylinder O.
36 (X'24')
(pCTHHR (slot within cylinder + 1)) assumes one origin table
(PCTHHR(22))
000604
head 6, record 4
=

Therefore: MBBCCHHR

= X'0000000024000604'

Unusable Paging Data Sets
Certain types of I/O errors received at completion of I/O indicate that ASM is
either unable to, or would be ill-advised to access a particular auxiliary storage
data set any longer. ILRCMPAE, an entry in ILRCMP, receives these errors and
marks the data set as unusable. For page data sets, the DSBD flag in the PART
entry is turned on and the PART entry is removed from the circular queue of
entries. For swap data sets, the DSBD flag in the SART entry is turned on.
Both flags are X'OA' into the respective entries, and are set to X'04'. ILRMSGOO
is then called to determine whether ASM can continue processing without the
data set.
If ASM is unable to continue processing, ILRMSGOO issues message ILR008W
and terminates the system with a X'02E' wa~t state.

Secti0n 5. Component Analysis

5-125

At this point, a stand-alone dump should be taken to determine which of the
above conditions occurred. The console sheet,· if available, might also help
because ASM may have previously issued message(s) ILR009E.
If ASM is able to continue processing without the unusable data set, message
ILR009E is written to the operator. This message indicates which volume
contains the unusable data set. If this message occurs, use the DUMP command
to take an SVC dump of master's address space to determine what error occurred.
The options specified should include NUC and SQA.
To determine from the dump what error occurred, the PART or SART entry for
the unusable data set and the IOSB for the failing request must be located. Use
the AMDPRDMP service aid (print dump) with ASMDATA control statement to
print the dump. One of the following conditions occurred on the data set to
make it unusable:
•

If the number of write errors (X'18' into the entry: PARERRCT or
SRERRCNT) is 175, ASM has stopped using the data set because it has
incurred too many write errors (one way for this to happen is if the data set
was not formatted).

•

If the completion code (X'OD') in the IOSB is a X' 51', ASM has stopped
using the data set because there is no longer a path to the device (this could
happen as a result of an ACR condition), or there is an excessively high
channel rate on the path to the data set.

•

If the completion code in the IOSB is a X'6D', ASM has stopped using the
data set because the channel or the device has become non-operational.

•

If the completion code in the IOSB is a X'41', the device status in the IOSB
(offset X'18') is X'02' and the sense data in the IOSB (offset X'2A') is
X'IOOO', ASM has stopped using the data set because an equipment check
occurred.

•

If the completion code in the IOSB is a X'41' and the channel status in the
IOSB (offset X'19') is X'08', X'04', or X'02', ASM has stopped using the data
set because a channel check occurred.

The system is terminated only if this unusable data set (or several unusable data
sets) caused one of the following conditions:

5-126

•

The unusable paging data set contains PLPA pages and the duplex data set, if
any, is already unusable or full.

•

The unusable paging data set is the duplex data set and not all PLPA pages
are accessible (that is, the PLPA paging data set or a data set containing
PLPA pages is unusable).

•

The unusable paging data set is the last local paging data set.

MVS Diagnostic Techniques

Page/Swap nata Set Errors
Figure 5-31 shows the messages issued and the actions taken by the ASM 1/0
subsystem for various error conditions with the page and swap data sets.
Message(s)

Duplex
Status

Issued

Error Conditions
PLPA Full

ASM Action Taken

ILROO51

Spill to Common

ILROlOI

Duplex Only

PLPA Bad

ILROO9E,
ILROlOI

Duplex Only

Common Full PLPA Available

ILROO61

Spill to PLP A

ILROIOI

Duplex Only

ILROO9E,
ILROIOI

Duplex Only

PLPA or Common Available

ILROO7I

Suspend Duplexing

PLPA and Common
Unavailable

ILROO8W Wait X'03C'

PLPA and Common Available
PLPA or Common Full

ILROO7I
ILROO7I

PLPA or Common Bad

ILROO8W Wait X'02E'

PLPA and Common
Unavailable

ILROO8W Wait X'02E'

Common • Available
Common ··Unavailable

PLPA Unavailable
Common Bad
Duplexing
Active
Duplex Full

Duplex Bad

Suspend Duplexing
Suspend Duplexing

PLPA Full
PLPA Bad

ILROO51
Spill to Common
ILROO8W Wait X'02E'

Common Full

ILROO61

Common Bad

ILROO8W Wait X'02E'

PLPA and Common Full

ILROO8W Wait X'03C'

Local Bad

ILROO9E

In Either

Last Local Bad

ILROO8W Wait X'02E'

Case

Swap Bad

ILROO9E

Stop Swap-outs to
Bad Data Set

Last Swap Bad

ILROO9E

All Swap-outs Done
to Page Data Sets

Last Local Full

none

Wait X'03C'

Last Page Data Set
Eligible for VIa Bad

ILROllE

Spill to NONVIO
Page Data Sets

Duplexing
Not
Active

Spill to PLP A

Stop Writes to Bad
Data Set

·Available - Data Set Neither Full Nor Bad
"Unavailable - Data Set. Either Full or Bad

Figure 5-31. Page/Swap Data Set Error Action Matrix

Error Analysis Suggestions

The following are some guidelines for determining ASM problems:
•

Print the dump specifying ASMDATA as a control statement to
AMDPRDMP.

•

Check SYS 1. LOG REC and the LOG REC buffer to see if ASM's mainline
has abended. If it has, a request might have been lost or mishandled.

•

Check the trace table for recent ASM activity. The key trace table entries are
SRB dispatches for ILREDRV (address of SRB in ASMPSRB, X'58' into
ASMVT), ILRSIO (address of SRB in IORSRBP, X'34' into IORB), or
Section 5. Component Analysis

5-127

ILRSWPDR (address of SRB is SARSRBP, X'30' into SART). Also look for
schedules of the post status SRB closely following an interrupt for ASM I/O
(CSW points to the nucleus area), which could be temporary or permanent
I/O errors coming to ILRCMP or one of its entry points.
•

Check for outstanding I/O requests and determine the status of the I/O by
looking at the UCB and 10SB.

•

Check for I/O errors on the paging packs, either on the error record (X'14'
into the ASMVT), or on SYSI.LOGREC.

•

Scan the ASMHD's LGE process queues (LGEPROCQ) for current VIO
activity. Determine the extent of ASM processing for these LGEs.
Determine the logical group for which a VIO group operator has been
requested.

•

Check the PART no-PCCW queue for requests waiting to be redriven
through ASM; Also scan the SART for the SRELOCK flag indicating that
ILRSWPD R should be processing.

•

If you are interested in a specific request, find the request on ASM queues
and determine the extent of ASM processing for the request .. For an I/O
request, convert the virtual page number to an LSID.

•

Scan the BWK. and SWK cell pool for a work area that Js not chained to
another work area (offset 0). An unchained work area indicates current ASM
processing or a lost work area.

•

Check for suspended ILREDRV or ILRSWPDR SRBs by scanning the PCB
I/O queues (pointed to by the RSMHD and the PVT) for a suspended SRB
whose address matches ILREDRV, ILRSIO, or ILRSWPDR SRB's address.
Although this situation should not occur, it does occur occasionally.

Validity Checking
ASM is a nucleus-resident, performance-oriented component. For this reason,
there is minimal validity checking in mainline code. In addition, few of ASM's
problems can be attributed to invalid control blocks; this is probably because
ASM communicates only with other system components. In both mainline and
recovery code, critical global control blocks such as the ASMVT, PART, and
SART, are used without any validity checking. ASM's recovery routines do
validity check control blocks (and queues of these control blocks) that represent
work to be processed by ASM. Some of these control blocks are the ACE, AlA,
LGE, and PCCW. In most cases, if a control block fails the validity check, it is
no longer used by ASM. The only exception is the 10RB-IOSB-SRB-SRB
combination, which is refreshed.

5-128

MVS Diagnostic Techniques

ASM Serialization
Serialization of ASM processing is done using the SALLOC and ASM global
locks, the local lock of the current address, compare-and-swap (CS) logic and
control block queueing.
SALLOC Lock
ASM uses the SALLOC lock to serialize most page and swap processing in I/O
control. The I/O control modules interface directly with RSM, the principal user
of SALLOC, either as the called routine or the calling routine. The SALLOC is
held throughout processing including calls to the VIO ILRPOS and completion
routines. The SALLOC is used to serialize most processing of:
lORDs
XPTEs
PCD/A1As
SPCTs
SART
SATs
PATs

- complete coverage, except as noted below.
- complete coverage.
- complete coverage, except AlA noted below.
- complete coverage.
- complete coverage, except where noted below.
- complete coverage.
- complete coverage.

Specific areas of other control blocks serialized by the SALLOC lock are:
ASMVT - Work save areas.
I/O control section fields.
Flags ASMDUPLX
ASMNPRIM
ASMCALLQ
ASMNODPX
ASMPLPAF
ASMCOMMF
- LGVT pointer
- Error record pointer.
- ASMCOMDS - index into PART entries for common area writes.
- Request counts.
- Available PCCW queue.
- Non-VIO slot allocated count.
Expansion of ASM pools.
ASMHD - I/O control flags.
Swap and page counters.
Swap queue.
ASCD

- Non-VIO slot allocated count.

LGVT

- Available LGVTE queue.
Expansion of the LGVT.
Creation/deletion of LGE.

PART

- Count of local page data sets.
Circular queue pointers.

Modules whose processing is serialized by the SALLOC lock are:
ILRIODRV

complete coverage, held by caller on called entries, obtained on SRD entries.

ILRPAGCM

complete coverage~ held by caller.

ILRFRSLT

complete cqverage, held by caller.

ILRSWAP

complete coverage: held by caller.

Section 5. Component Analysis

5-129

ILRCPBLD

dcomplete coverage, except ILRSIO entry point. When held, the lock is held by the
caller.

ILRCMP

complete coverage, obtained at entry.

ILRMSOOO

complete coverage for main entry point, held by caller.

ILRPOS

complete coverage, held by caller (except for ILRTRANS entry point).

ILRVIOCM

complete coverage, held by caller.

ILROOS

only obtained for LOVT processing and OETMAIN/FREEMAIN requests.

ILRPOEXP

only obtained to adjust the SART to reflect addition of a new swap data set and update
the count of local page data sets and new page data sets on the PART.

ILRTERMR

obtained when referencing above control blocks.

ILRPEX

obtained when expanding an ASM pool.

ASM Class Locks
The ASM lock is a global spin class lock. A lockword must be provided when
obtaining or releasing an ASM class lock. A class lock exists for each active
address space. The lockword is in the ASMHD. It is used by the VIO controller
modules. The address space class locks serialize processing of the following
control blocks:
AlA

VIO controller flags, LPID field.

ASMHD VIO controller flags, LOE queue base pointer.
ASCB

VIO slot allocation count.

LOE

complete coverage, except creation/deletion (SALLOC).

ACE

complete coverage.

ASPCT

complete coverage while group operations are in progress. Oroup operations and page
operations can be executed in parallel. VIO controller processing of the LOE process queue
provides this serialization.

The address· space class locks serialize processing in the following modules:
ILROOS
ILRPOS
ILRSRBC
ILRVIOCM
ILRJTERM

partial, obtained where processing above control blocks.
complete coverage.
partial, obtained when searching LOE queue and LOE process queues.
complete coverage.
partial, obtained when adding ACEs to LOE process queue.

Local Lock of Current Address Space
The local lock is used by VIO controller and VIO group operator modules to
serialize certain VIO related operations. It is used by ILRGOS (held on entry)
and ILRJTERM (obtained) to serialize release LG requests with the internal
ASM deactivate function used to clean up VIO logical groups for a terminating
job. The local lock is also used by most VIO-related modules to allow use of
branch entry GETMAIN, rather than the SVC route.

5-130

MVS Diagnostic Techniques

Compare and Swap (CS) Serialization
Certain modules of ASM run without locks, requiring CS serialization of pointers,
,flags, and counts. Where routines running with the locks change fields used by
unlocked routines,CS must be used. VIO group operators run unlocked and are
the principal users of compare and swap. Control blocks serialized via CS
include:
ASMVT - group operator sections.
pool controllers.
VIO slot count.
SART -

A special CS lock exists in each SARTE to serialize swap driver processing of the swap
data sets. Other fields updated by the swap driver are updated with CS.

The ASM modules that run without locks, using CS to serialize control block
fields are:
ILRSWPDR
ILRSAV
ILRACT
ILRRLG
ILRTMRLG
ILRVSAMI

Serialization via Control Block Queues
Certain ASM control blocks are serialized via their available queues. The blocks
are kept on available queues and removed when needed. While in use the block is
so marked and associated with a specific operation and/or control block. Control
blocks included in this category are PCCWs, IORBs for swap data sets, and
SCCWs.
The ASPCT is a special case. VIO control enforces the rule that page and group
operations cannot be performed in parallel for a given logical group and its
ASPCT. This is controlled by the LGE process queue. While paging operations
are being performed, the ASPCT is serialized via the ASM class lock of the
owning address space. While a group operation is in progress, ASPCT
serialization is maintained by the ACE for the group operation that is on the
LGE process. This ACE prevents any other processing of ASPCT until the group
operation completes.

Recovery Considerations
The philosophy of ASM's recovery is to allow the system and ASM to continue
processing. To accomplish this, the first step in ASM's recovery routines is to
validity check any control block or queue that might have been affected by the
error. This is to allow future ASM processing to proceed without error. The
second step in ASM's recovery is to notify ASM's caller that an error has
occurred. In a few instances where ASM is directly invoked by RSM (such as
ILRIODRV or ILRSWAP), ASM recovery attempts retry to return to RSM with
a failing return code. When an error occurs during ASM processing that runs
asynchronously, ASM recovery queues the failing request for eventual return to
RSM. When an error occurs during ASM processing of a VIO group operator
request, ASM recovery cleans up its resources and allows the associated task to
terminate.

Section 5. Component Analysis

5-131

Recovery Traces

A dump of SYSl.LOGREC is a prerequisite to debugging ASM problems.
ASM's recovery always records the SDWA to the SYSl.LOGREC data set. It is
the most convenient way of determining that recovery has been invoked. The
recovery routine ID in the SDWA indicates which recovery routine was invoked.
ASM has a number of system abend completion codes ('08x' series) that are
always set up for retry. The purpose of these ABENDs is to record to
SYSl.LOGREC logical errors that have occurred in ASM'smainline or VIO
processing.
Recovery Structure

ASM has eight recovery routines for ASM mainline:
•

ILRIOFRR is an FRR that provides recovery for ILRPAGCM, and
ILRYIOCM. It also acts as a router, giving control to the routines in
ILRSWPOI and to ILRPOSOI.

•

ILRSWPOI contains recovery routines for ILRSWPDR and ILRSWAP.

•

ILRDRVOI is an FRR that provides recovery for I/O driver (ILRIODRV)
and channel program build (ILRCPBLD), and also routes control to
ILRPOSOI.

•

ILRCMPOI is an FRR that provides recovery for the I/O completion routine
(ILRCMP).

•

ILRGOSOI is both an FRR and an ESTAE that provides recovery for
ILRGOS, for the group operators ILRSAV, ILRACT, and ILRRLG, and for
ILRVSAMI.

•

ILRTMIOI is the ESTAE that provides recovery for ILRTMRLG and for its
path through ILRVSAMI.

•

ILRSRBOI is an FRR that provides recovery for ILRSRBC.

•

ILRFRROI is a validity check routine called by most of the recovery routines.

Additional recovery routines are:

5-132

•

TERMRFRR is an FRR that is an entry point into and provides recovery for
ILRTERMR.

•

ILRJTMO 1 is an FRR that is an entry point into and provides recovery for
ILRJTERM.

•

ILRMSGOI is an FRR that is an entry point into and provides recovery for
ILRMSGOO.

•

ILRPOSOI is an alternate entry in ILRIOFRR and provides recovery for
ILRPOS.

MVS Diagnostic Techniques

•

ESTAER is an EST AE that is the entry point into and provides recovery for
ILRPGEXP.

•

ESTAEXIT is an EST AE that is an entry point (nto and provides recovery
for ILRPREAD.

Recovery As a Debugging Tool

Recovery has a beneficial effect on problem solving primarily because having it
invoked isolates the problem to a specific area of ASM. If there is a paging
interlock or duplicate page problem subsequent to an abend in ASM, the two are
probably related and the first error provides information useful in debugging the
second problem.
Recovery ignores invalid control blocks and truncates some of ASM's internal
queues in order to allow ASM to continue processing. Therefore, recovery will
cover up valid problems that cause code overlays in ASM and other system
components.
The primary culprit in covering up errors is the non-historical nature of ASM
resource queues that results in rapid reuses of critical control blocks. The only
valuable information left by the recovery is the SOW A with its variable recording
area in the SYSl.LOGREC data set. At the very least, this record provides
sufficient information to trap the problem when it recurs.
Recovery Footprints
FRR/ESTAE Work Areas

ILRATA and ILREPATH are mapping macros that define the areas required by
ASM modules to provide tracking information for the FRRs and EST AEs.

•

•
~

ILRAT A defines the six-word parameter area passed to the ASM routine
issuing the SETFRR macro, or it defines the parameter area passed to the
ASM routine issuing the EST AE macro. It contains a module ID in the first
byte, flags in the next three bytes, and four words which have
module-dependent contents. The IDs of the ASM modules are:
ID

Module

Entry

ID

Module

Entry

X'Ol'
X'02'
X'03'
X'04'
X'OS'
X'06'
X'07'
X'OS'
X'09'
X'OA'
X'OB'
X'OC'

ILRIODRV
ILRPAGCM
ILRSWAP
ILRTRPAG
ILRSWPDR
ILRGOS
ILRIODRV
ILRSRBC
ILRCMP
ILRCMP
ILRCMP
ILRCMP

ILRIODRV
ILRPAGCM
ILRSWAP
ILRTRPAG
ILRSWPDR
ILRGOS
ILRIODR
ILRSRBC
ILRCMPDI
ILRCMPNE
ILRCMPAE
ILRCMP

X'OD'
X'OE'
X'OF'
X'lO'
X'II'
X'I2'
X'l3'

ILRIODRV
ILRCMP
ILRCMP
ILRIODRV
ILRIODRV
ILRIODRV
ILRCPBLD

ILREDRV
ILRCMPCI
ILRCMPNT
ILRSWLlO
ILRSWPIN
ILRSWAPO
ILRSIO

ILREPATH defines a variable-length area containing any additional recovery
audit-trail data required for recovery by ASM recovery routines. The address
of the EP ATH, if present, is in the ATA. There are four variations of the
EPATH area.

Section 5. Component Analysis

5-133

The formats of ILRATA (ASM tracking area - ATA) and ILREPATH (recovery
audit trail area - EPATH) are described later in this chapter in the topic "ASM
Recovery Control Blocks."
SDWA Variable Recording Area
ASM uses the SDWA variable recording area (SDWAVRA) to save the contents
of the ATA (and EPATH, if present) upon entry to some of the recovery routines.
This preserves the original state of the error before recovery took place.
ILRIOFRR and ILRCMPOI save the ATA. ILRGOSOI and ILRDRVOI save
the ATA and EPATH. ILRTMIOI saves only the EPATH.

ASM Diagnostic Aids
This section contains diagnostic aids that are helpful in debugging problems in
ASM. Topics included are:
•
•
•

COD ABEND Meanings for ASM
ASM Recovery Control Blocks
Additional ASM Data Areas

COD ABEND Meanings for ASM
An ASM routine has found one of the following conditions which should not
occur and has set the appropriate return code in the ASM tracking area (ATA):
RC 4 -

The count of available swap sets for a specific swap data is non-zero but no available swap
sets could be found.

RC 8 -

The total count of available swap sets is non-zero but none of the swap data sets contain
available swap sets.

RC 12 - The group operations starter has returned from one of the group operators but the ACE is
not the first one on the LGE queue.
RC 16 - The memory termination resource manager for ASM has found that LSQA is not available
for an address space that is abnormally terminating for one of the following reasons:
1.
2.
3.

address space is not swapped in
address space is in process of being swapped in
RSMLSQA frame queue is unusable.

RC 20 - The ASM SRB controller has found an AlA or ACE on the LGE process queue which does
not have the LPID converted flag on.

A software error record is written to SYSl.LOGREC and recovery processing
continues.

5-134

MVS Diagnostic Techniques

ASM Recovery Control Blocks

During error recovery and cleanup processing, the ASM recovery routines
communicate with other routines by using the ASM tracking area (ATA) and
recovery audit trail area (EPATH).
ASM Tracking Area (ATA)

The ATA contains information necessary for the recovery or cleanup processing
performed by the ASM recovery routines. The ATA is mapped to the six word
. work area returned by SETFRR when an FRR is established. For task mode
routines, the ATA is mapped to the parameter area that is passed via the EST AE
macro.
The mapping macro name is: ILRATA.
Disp

Name

Size

Description

0
0

ATA
ATAMODID

24
1

ASM Tracking Area
ID of module establishing recovery routine. (See the previous
topic "Recovery Foot- prints" for module IDs.)

ATASFLGS

3

ATAIOPPR
ATASLSQA
ATASCOMP
ATAVIOCM
ATAPCOMP
ATAPOS
ATAIOBSL
ATAPAGCM
ATASWAP
ATATRPAG
ATASWPDR
ATACPBLD
ATAIOSSL
ATAIOSCM
ATAIOMXA
ATAIOPF

800000
400000
200000
100000
080000
040000
020000
010000
008000
004000
002000
001000
000800
000400
000200
000100

Bit map representing logical sections of ASM routines; set to 1 on
entry, set to 0 on exit.
PROCPARE subroutine ofILRIODRV flag.
ILRSLSQA flag.
SWAPCOMP flag.
ILRVIOCM flag.
PAGECOMP flag.
ILRPOS flag.
BLOCKSEL subroutine of ILRIODRV flag.
ILRPAGCM flag.
ILRSWAP flag.
ILRTRPAG flag.
ILRSWPDR flag.
ILRCPBLD flag.
SLOTSEL subroutine of ILRIODRV flag.
STARTCOM subroutine of ILRIODRV flag.
MIXAIA subroutine of ILRIODRV flag.
PGFLT subroutine of ILRIODRV flag.

The remaining flags are reserved:
4

ATARFLGS
ATASGNST
ATASCCWP
ATABADPK
ATAPGVIO

2
8000
4000
2000
1000

Other recovery flags.
ILRSLSQA flag-in ASSIGNSET subroutine.
ILRSLSQA flag-in SCCWPROC subroutine.
ILRCMPAE flag-in BADPACK subroutine.
VIO flag.

The remaining flags are reserved:
6

7

ATARCRSN
ATARCRF1
ATARCRF2
ATARCRF3
ATARCRF4
ATARCRF5
ATARCRF6
ATARCRF7
ATARCRF8
ATARCODE

1
80
40
20
10
08
04
02
01

Recursion
Recursion
Recursion
Recursion
Recursion
Recursion
Recursion
Recursion
Recursion

flags.
flag-function
flag-function
flag-function
flag-function
flag-function
flag-function
flag-function
flag-function

1.
2.
3.
4.
5.
6.
7.
8.

Reason code for ASM-issued ABEND's.

The mapping of the remaining four words is dependent on the recovery routine involved.

Section 5. Component Analysis

5-135

For the recovery routine ILRIOFRR:
8
8
8
C
C
C

ATACLEAR
ATAAIA
ATAACE
ATAASCB
ATALGE
ATAAIAQ

16
4

4
4

4
4

Maximum size of four-word area.
Address of in-process AlA.
Address of in-process ACE.
Address of in-process ASCB, or TRAS'd-to address space.
Address of in-process LGE.
Address of AlA queue.

For the recovery routine ILRSWPOI:
8

8
C
10
14

ATACLEAR
ATAAIA
ATASARTE
ATASCCW
ATAIORB

16
4
4

4
4

Definition allowing next four words to be cleared.
Address of in-process AlA.
Address of SART entry.
Address of in-process SCCW.
Address of in-process IORB.

For the recovery routine ILRGOS01:
8
C

ATAWORKA
ATAEPATH

4
4

Address of work-area cell.
Address of EPATH.

For the recovery routine ILRDRVOl:
8
C
10

ATAAIAQ
ATAIOSB
ATAEPATH

4
4
4

Address of AlA queue to be processed.
IOSB checkpointed by ILRSIO.
ADDRESS of EPATH.

For the recovery routine ILRSRBOI:
8
C
10
14

ATAAIACE
ATAAIAQ
ATAACEQ
ATAEPATH

4
4
4
4

Address
Address
Address
Address

of in-process AlA/ACE.
of AlA queue.
of ACE queue.
of EPATH.

For the recovery routine ILRCMPOl:
8
C
10
14

ATAIOSB
ATAPCCWQ
ATACOMPQ
ATACPCCW

4
4
4
4

Address of in-process IOSB.
Queue of PCCWs to be put back on PCCW available queue.
Queue of AlAs to be returned to ILRPAGCM.
Address of in-process PCCW, not on IORB queue and not on
ATAPCCWQ.

For the recovery routine ILRJTM01:
8
8

ATASAVE
ATAACEQ

4
4

Address of register save area.
Address of ACE queue.

For the recovery routine TERMRFRR:
8
C

ATARMPL
ATAWORKA

4
4

Address of RMPL, resource manager parameter list.
Address of work area.

Recovery Audit Trail Area (EPATH)
The EPATH is a communication area between the mainline routine and its
corresponding recovery routine. The EPATH is necessary when the 6-word ATA
is not large enough to accommodate the data to be tracked. The mapping of the
EPATH is dependent on the recovery routine or mainline routine including the
macro.

5-136

MVS Diagnostic Techniques

EPATH for ILRIODRV, ILRCPBLD, and recovery routine ILRDRVOl:
Disp

Name

Size

Description

0
4
S
C
10
14
18
18
IC
20
24
28
2C
30
34
38

EPAAIAI
EPAAIA2
EPAAIA3
EPAAIA4
EPAAIAS
EPAAIA6
EPACPBLD
EPACPAIA
EPACPENQ
EPACPIOR
EPACPI02
EPACPWKA
EPABITSI
EPACPRSI
EPABITS2
EPACPRS2

4
4
4
4
4
4
36
4
4
4
4
4
4
4
4
4

Input AlA chain.
PROCPARE AlA chain.
PARTESEL AlA chain.
STARTCOM AlA chain.
New NN VIO read AlA.
Reserved.
Channel program build input.
Start of AlA input to ILRCPBLD.
Last AlA on ILRCPBLD AlA chain.
Primary IORB address.
Duplex IORB address.
Address of ILRCPBLD work area.
Used by ILRCPBLD.
Used by ILRCPBLD to build primary channel program.
Used by ILRCPBLD.
Used by ILRCPBLD to build duplex channel program.

EPATH for VIO group operators and their recovery routines - ILRGOS,
ILRSAV, ILRRLG, ILRACT, ILRVSAMI, ILRGOSOl, ILRTMRLG,
ILRTMIOO, ILRTMIOl, ILRSRBC, and ILRSRBOI. ILRGOSOI is the recovery
routine for ILRGOS which calls ILRSAV, ILRRLG, and ILRACT which call
ILRVSAMI. ILRTMIOI is the recovery routine for ILRTMRLG which calls
ILRVSAMI and ILRTMIOO. ILRSRBOI is the recovery routine for ILRSRBC
which calls ILRRLG. The first section is common because of the use of
ILRVSAMI. The second section is dependent on the recovery routine involved.
Disp

Name

Size

DescriptioD

o

C
10
10

EPAOWKA
EPAVWKA
EPATMWKA
EPASWKA
EPAAASP
EPADSLST
EPABASP
EPATMIBA
EPARASP
EPATMACB

4
4
4
4
4
4
4
4
4
4

14

EPARTYRG

4

14

EPABKSLT

4

Group Operator's or ILRTMRLG's workarea address.
ILRVSAMI workarea address also points to RPL in workarea.
ILRTMIOO workarea address.
ILRSRBC workarea address.
Address of active ASPCT.
Address of data set name list storage.
Address of buffer ASPCT.
Base address value for ILRTMlOO.
Address of retrieved ASPCT.
Address of storage used to build ACB for STGINDEX in
ILRTMIOO.
Address of IS-word save area containing retry registers RO-R14
for record-only abends.
Backing slots, only used for assign processing.

18

EPAFLAGI

4
4

4
8

8
C

Recovery flags.

EPAVSAMI
EPAGRPOP
EPARLG
EPASAVE
EPAACT
EPAACASR
EPAASGN

X'SO'
X'70'
X'40'
X'20'
X'IO'
X'08'
X'04'

EPAUNSAV
EPARPLB

X'02'
X'OI'

ILRVSAMI currently processing.
One of group operators processing.
ILRRLG is currently processing.
ILRSAV is currently processing.
ILRACT is currently processing.
Activate or assign request.
Assign processing - backing slots count (ASMBKSLT) has been
updated.
Mark slots unsaved in active ASPCT.
RPL has been built.

Section 5. Component Analysis

5-137

19

Recovery flags.

EPAFLAG2
EPATMXIT
EPAWARM
EPACOLD
EPABUILD
EPAMAST
EPATMI
EPARECUR

*

X'80'
X'40'
X'20'
X'lO'
X'08'
X'04'
X'02'
X'Ol'

ILRTMIOO completed processing.
ILRTMIOO warm start is processing.
ILRTMIOO CVIOS'FRT is processing.
ILRTMIOO BUILDSNL is processing.
Master scheduler initialization has been posted.
ILRTMIOO is currently processing.
Recursion indicator for retry into mainline ILRTMRLG.
Reserved.

For ILRGOSOl, ILRSAV, ILRACT, ILRRLG, ILRSRBC, and ILRSRBOl:
Disp

Name

Size

Description

lA
IC
20
24
28
2C
30
32
34

EPALSIZE
EPALGVTP
EPALGEP
EPASRB
EPAACE
EPARBASP
EPARSIZE

2
4
4
4
4
4
2
2
4

Size of LGVT expansion~
New LGVT address for LGVT expansion in ILRGOS.
Logical group entry for request being processed.
Address of SRB for SRB controller.
Address of current ACE being processed.
Address of rebuilt ASPCT (LSQA).
LSQA block storage size for rebuilt ASPCT.
Reserved.
Queue of AlAs to be passed to ILRPAGCM.

*

EPAERAIA

For ILRTMIOI and ILRTMRLG, and ILRTMIOO:

5-138

Disp

Name

Size

Description

lA
IC
IC
20
24
24
28

*

2
4
4
4
4
4
4

Reserved.
Address of ACE currently being processed.
Address of master scheduler initialization ECB.
Address of ILRTMRLG save area.
Retry address for record-only abends.
Current retry address for failure in ILRTMIOO.
Address ofTPARTBLE while in ILRTMIOO.

EPAACE
EPAMSECB
EPATMRSV
EPAABEND
EPATMIRT
EPATPART

MVS Diagnostic Techniques

Additional ASM Data Areas
The following four ASM data areas (BSHEADER,BUFCONBK, DSNLIST, andMSGBUFFER) are not contained in Data A.reas. For debugging AS~
BSHEADER (bad slot record) may be especially helpful.
BSHEADER
Acronym:

BSHEADER.

Full Name:

ASM error record (bad slots).

Macro ID:

None.

Size:

1024 bytes.

Function:

Trace table of the last 253 slots that ASM has found to be bad. Patterns of bad LSIDs
can indicate where and what paging data sets are having difficulties.

Location:

Pointed to by ASMVT (ASMEREC).

Offset

Length

Name

Description

0(0)
4(4)
8(8)

4
4
4

12(C)

1012

BSCURR
BSFIRST
BSLAST
BSLIST

Current bad slot entry filled.
Beginning address of table.
End address of table.
253 four-byte bad slot identifiers (LSIDs).

BSLIST entry
0(0)

1
1. ..... .

BSFLAG

.... 1. ..
1(1)

3

BSTABNTY

BSSPLSID if 1, LSID entry is swap.
if 0, LSID entry is page.
BSRDLSID if 1, LSID entry is for a read error .
if 0, LSID entry is for a write error.
LSID that is bad.

BUFCONBK
Acronym:

BUFCONBK.

Full Name:

VSAM buffer control block.

Macro ID:

None.

Size:

12 bytes.

Function:

Queue VIO group operation for later processing until VSAM resources are available.

Location:

Pointed to by ASMVT (ASMGOSQS).

Offset

Length

Name

Description

0(0)

4
4
4

BUFCHAIN
BUFASCB
BUFACE

Pointer to next BUFCONBK.
Pointer to ASCB.
Pointer to ACE.

4(4)
8(8)

Section S. Component Analysis

5-139

DSNLIST
Acronym:

DSNLIST.

Full Name:

Data Set Name List (ASM).

Macro ID:

None.

Size:

44 times number of possible page/swap data sets. There are two DSNLISTs, one for
page data sets and one for swap data sets.

Function:

Make data set names available in non-fixed (pageable) storage.

Location:

Pointed to by PART (PARTDSNL) for page data sets, and by SART (SARDSNL) for
swap data sets.

Offset

Length

Name

Description

0(0)

44

DSNENTRY

Data set name left-justified and padded with blanks.

MSGBUFER
Acronym:

MSGBUFER.

Full Name:

ASM message buffer.

Macro ID:

None.

Size:

5-140

.376 bytes.

Function:

Ensure that WTOR with LOGREC request.will have a buffer to use.

Location:

Pointed to by ASMVT (ASMMSGBF).

Offset

Length

Name

Description

0(0)
4(4)
8(8)
12(C)
16(10)
256(100)

4
4
4

MSGCURR
MSGFIRST
MSGLAST
MSGTERM
MSGBFRS
MSGTBFR

Pointer to current buffer used.
Pointer to first buffer.
Pointer to last buffer.
Pointer to special termination buffer.
Three SO-byte buffers.
Special termination buffer.

MVS Diagnostic Techniques

4

240
120

System Resources Manager (SRM)
The system resources manager (SRM) is a component of the MVS control
program. It determines which, of all active address spaces should be given access
to system resources, and the rate at which each address space is allowed to
consume the resources.
An installation controls the MVS system primarily through the SRM. The
evaluations and resulting decisions made by the SRM are dependent on the
constants and parameters with which it is provided. The reader should
understand the philosophy inherent in the use of these constants and parameters,
so that their use will produce the desired effect. The OS/VS2 System
Programming Library: Initialization and Tuning Guide provides the background
information necessary to understand the controls available through the SRM, and
the implementation of these controls.

SRM Objectives
The SRM bases its decision on two fundamental objectives:
1. To distribute system resources among individual address spaces in accordance
with the installation's response, turnaround, and work priority requirements.
2.

To achieve optimal system-throughput through use of system resources.

An installation specifies its requirements for the first objective in members of
SYSl.PARMLIB called th~ installation performance specification (IPS) and the
installation control specification. Through the IPS, the installation divides its
types of work into distinct groups called domains, assigns relative importance to
each domain, a~d describes sets of performance groups. Through the installation
control specification, the installation can assign the correct performance
characteristics to each address space. Another input to the SRM is the OPT
member of SYS1.PARMLIB. Through a combination of the installation control
specification, IPS, and OPT parameters, an installation can exercise a degree of
control over system throughput characteristics.
When the need arises, trade-offs can be made between SRM's objectives. That is,
the installation can specify whether, and under what circumstances, throughput
considerations take priority over turnaround requirements. The SRM attempts to
ensure optimal use of system resources by periodically monitoring and balancing
resource utilization. If resources are under-utilized, the SRM attempts to increase
the system load. If, on the other hand, resources are over-utilized, the SRM
attempts to reduce the system load or to shift commitments to low-usage
resources such as the processor, logical channels, auxiliary storage, and pageable
real st{)rage.

)
Section S. Component Analysis

5-141

Address Space States
The SRM recognizes address spaces as being in one of three general states. Each
state corresponds in concept to a queue on which SRM places the SRM user
control block (OUCB) which describes the address space. These three states are:
1.

In - The working set of an address space in this state occupies real storage.

2.

Wait - The working set of an address space in this state mayor may not
occupy real storage. If the address space is logically swapped, the working set
pages remain in reaJ storage. If a physical swap takes place, the working set
pages reside on auxiliary storage. An address space in this state has no ready
work, is therefore incapable of executing, and not considered for swap-in.

3.

Out - The working set of an address space in this state mayor may not
occupy real storage. If the address space is logically swapped, the working set
pages remain in real storage. If a physical swap takes place, the working set
pages reside on auxiliary storage. However, the address space is capable of
executing and can be considered for swapping-in. For a logically swapped
address space, the swap-in is reduced to a restore operation by RCT because
no physical transfer of pages has occurred.

It is important to recognize that the correspondence between these states and

presence on the associated queue is not precise; an address space can be in transit
between two states (for example, it may be in the process of being swapped-out).
Thus, the presence on a particular queue might not exactly mirror the physical
state of affairs. Further, these classes are necessarily broad, and SRM recognizes
subclasses; this is especially true among address spaces belonging to the "In" class.
The use of the swap transition flags, in conjunction with the presence of an
OUCB on a particular queue, mirrors the exact physical state of an address space.
For wait state analysis, the exact state of given address spaces is important. If
you can determine precisely what state SRM considers the various address spaces
to be in, and the reasons why, you will gain insight for further analysis. The
OUCB is the primary address-space-related control block in which much of the
above information can be found.
OUCBs on the above three queues can be formatted via the SRMDATA format
control statement of AMDPRDMP. The domain table (DMDT) is also
formatted by SRMDATA and indicates the swapping status of the system.
In the OUCBQFL field (OUCB+X'OI'), when the OUCBGOB bit is on, the
SRM's OUCB repositioning routine is to be invoked. The destination of this
pending OUCB repositioning is indicated by the following bit settings:
I.

OUCBOUT = 'O'B - The OUCB will be placed on the "In" queue.

2.

OUCBOUT='I'B and OUCBOFF='I'B - The OUCB will be placed on the
"Wait" queue.

3.

OUCBOUT = 'I 'B and OUCBOFF = 'O'B - The OUCB will be placed on the
"Out" queue.

When the repositioning is completed, the OUCBGOB bit is turned off; the setting
of the OUCBOUT and OUCBOFF bits indicates the location of the OUCB.

5-142

MVS Diagnostic Techniques

A logically swapped address space can be identified by the OUCB being on the
wait queue or the out queue and OUCBLSW = 'l'B.
The setting of the swap transition flags for swap-out processing occurs in the
following order:
1.
2.
3.

If swap-out is initiated successfully, the OUCBGOO bit is set.
At quiesce-complete time, the repositioning of the OUCB takes place.
At swap-out-complete time, the OUCBGOO bit it turned off.

The setting of the swap transition flags for swap-in processing occurs in the
following order:
1. If swap-in is initiated successfully, the OUCBGOI bit is set.
2.

At swap-in status II time, the repositioning of the OUCB takes place and the
OUCBGOI bit is turned off.

SRM Indicators
I t is helpful to understand how SRM views the total MVS system, as well as the
individual address spaces. This understanding can assist you in further problem
analysis, especially of enabled wait state situations. A disc~ssion of some of the
SRM system and individual user indicators follows. Figure 5-32 shows the
relationships among important SRM control blocks and queues.
A study of several counters and flags aids in further understanding of SRM
processing. The counters and flags that pertain to the entire system are located in
the SRM constants module (lRARMCNS), which resides in the nucleus. The
counters and flags that pertain to a specific user are found in that user's OUCB.
System Indicators

The SRM control table (RMCT) is located at the start of module lRARMCNS.
This address is found in field CVTOPCTP of the CVT + X'25C'. Generally, when
SRM is in control, the address of the RMCT is contained in register 2. In the
module IRARMCNS, the following fields provide information concerning SRM's
current processing:
MCT AVQ 1

This bit indicates that the count of available pages has fallen below the PVT AFCLO
value, so the real storage manager (RSM) has called SRM to steal pages in order to
increase the count of available pages. If this bit is on, it could indicate a normal
condition.

MCTSQAl

This bit indicates that the number of available SQA pages is critically low. If
MCTSMSI is 1, the operator was notified of this situation.

MCTSQA2

This bit indicates that the number of available SQA pages has fallen below a second,
more critical threshold than the one noted above. If MCTSMS2 is 1, the operator was
notified of this situation.

MCTASMI

This bit indicates that the SRM has detected that less than 30% of all local slots are
available. The SRM has informed the operator of this fact and has taken appropriate
action to relieve the sl1ortage.

MCTAMS2

This bit indicates that the SRM has detected that less than 15% of the total local
auxiliary storage slots are available. The SRM has informed the operator of the slot
shortage, and has taken appropriate action to relieve the shortage.

Section 5. Component Analysis

5-143

MCTFAVQ

When this bit is on, a pageable storage shortage condition has been detected by SRM or
RSM. If bit MCTPHPSS is also on, the shortage was detected by RSM because the
count of fixed frames (PVTCNTFX) exceeded the threshold in PVTMAXFX. If bit
MCTLGPSS is on, the shortage was detected by SRM because the sum of the count of
fixed frames and the number of page I/Os in progress to the page data sets exceeded the
threshold in MCCMAXFX.

MCTLGAVQ If this bit is on, SRM has increased the thresholds in PVTAFCLO and PVTAFCOK in
order to cause the frame stealing necessary to swap-in an address space. This bit
indicates that SRM has initiated the steal processing rather than waiting for an
ANQLOW SYSEVENT from RSM.
MCVTWSS

This halfword contains the target working set size for the common area. SRM attempts
to keep this minimum number of frames assigned to the common area.

RCVUICA
RCVCPUA
RCVDPR
RCVMSP

These halfword values are the system contention indicators that the resource monitor
examined for the last interval. They represent, in the order given: the average high
referenced interval count (UIC), the average processor utilization, the demand paging
rate, and the page delay time (in milliseconds). Based on these values, the target
MPL for a domain might be altered.

RCVFXIOP

This halfword contains the average percent of frames that are fixed or used for page
I/O.

RCVMFXA

This halfword contains the average percent of frames eligible to be fixed that are fixed.

RMCAINUS This halfword indicates the count of address spaces currently residing in storage. This
count includes non-swapp able address spaces. If this count is high, look at the next
field.
CCVENQCT This halfword indicates the count of address spaces currently residing in storage and
marked non-swappable because they are holding ENQ resources that other address
spaces want.
LSCTCNT

This fullword contains a count of the number of address spaces currently in the
logically swapped state and swapped for terminal wait.

LSCTCNTW This halfword contains a count of the number of address spaces currently in the
logically swapped state and swapped for a long or detected wait.

5-144

.MVS Diagnostic Techniques

f/i:\

IRARMCNS

CVT

~RMCT
(SRM Tables and Entry Points)

--

~CCT

••
••
+
••
•+

25C

ICT

MCT
RMPT
RMCA

4

,

~

--.@

WMST liPS Information)
RLCT (Logical Channel
Information)

OUCBs

RMEX
RMSB

~--

• RMCT

rl ~eferred

1

OUCBs

for RMEPs in
the EPAT. EPDT

EPAT

OUCBs

+ LSCT

I

'Wait'
OUCBs

+
(Workload Activity
+WAMT
I nformation for M F /1)
WAST (Workload Activity
Specifications)

•
•
••
•

WTQE

RMEPs

TMQE

~ ~

TMQE

Timed
Actions

Entry Point
Descriptions

1

OTQE

-1 + I
Wait I
Queue

OTQE
• Out
Queue

nI

--

V

OUCBs

I

ACTION QUEUE

WTQE

~

Action

Anchor Queue,

EPDT

'Out'
OUCBs

~

INQE

~I +~ueue}..

INQE

OUCBs

I

I

Algorithm Request Bits
Immediate Algorithm
Request Bits

'In'
OUCBs

W

Request Service Work
+ Area
(RQSV)
DMDT (Domain Descriptor
+ Table)

•+

DMDT (Last Entry)
RCT (Resource
Control Table)

ICST (Installation Control
+ Specification
Table)

~

Basic Reporting
+ Available
Queue

t

t

~~

-..

Extended Reporting
Available Queue

ICSC
• RPVT
Subsystem Tables
RPVT (Report Performance
Group Vector Table)

~~

-{CCT

i

Update Reporting
Queue

I/O Usage Information
Storage Usage Information
Res6ur ce Control
Inform ation

RCT
RMPT

Swap A nalysis Parameters
Swap A nalysis Variables
Logical Swap Control
Variabl es
Externa I Entry Point
Descrip tors

RMCA
LSCT

List)
RSPL (Report Service
Parameter List)

RMEX

+EPL (ENF
Parameter List)

t Nucleus Patch
"Area CSECT

End of RMCT
I...-

CPU Us age Information

ICT
MCT

t Specification
ICSP (Installation Control
Parameter

t

~oJ

1"'-'

~

Subrou tine Entry Points

RMSB
EPAT

EPDT
EPST

Algorit hm Entry POint
Descrip tors
Serializ ed Action Entry
Point D escriptors

---

Scanne d Action Entry
Point D escriptors

Figure 5-32 (Part 1 of 2). SRM Control Block Overview

Section 5. Component Analysis

5-145

SRM Registers

3

+RRPA

I'

2

.RMCT

~

RRPA (Recovery Parameters)
Register 0 Contents on Entry
(ASIO, PGI'J, SYSEVENT Code)
Register 1 Contents on Entry
(I nput Parameter Address)

RMEP

~

t RMEP

B

Entry point descriptor
of routine most
recently entered

WMST

+PGVT
~------t]
• PGOT
POVT

Pointer to and indexes into performance group descriptor table
(entry location similar to that for domain descriptor table)

Pointer to and indexes into performance objective table
+
(entry location similar to that for domain descriptor table)
~]
+POOT
.OMDT
~----------------------------------~~ OMOT
~-------I
(domain descriptor table)
.OMVT

'
I

Pointer to and index into the time slice table
(entry location similar to that for domain
.
descriptor table).
• TSGT
I-----:~---~
l' . Pointer to and index into the rotate table entry
RTVT
(entry location similar to that for domain
descriptor table).
• ROTT

• TSPT
I---~
_ _ _--I

4

+

~ Entry for i th domain

x

---

ASCS

(

IMCS

+OUCS
+OUXS
+ASXS

OUCS

J
./

+OUSB

SRM User

'---

5-146

OUXS

SRM Control Block Overview

MVS Diagnostic Techniques

Statistics

~ t~;~:

SRM User
Statistics
(Temporary)

Figure 5-32 (Part 2 of 2).

I

'\

.( ASXB

\

~

j

~,O__U_SS~___
SRM User
Statistics
(Swapped)

I/O
Measurement
Information

Individual User Indicator.s
The register conventions generally used by SRM to process individual user
functions can help you locate important SRM control blocks:
Register
2
3
4
5

Contents
Address
Address
Address
Address

of the RMCT
of the RRPA
of the OUCB
,
of the ASCB (if used by the requested SYSEVENn

The SRM user control block (OUCB) contains flags and counters to provide
information about a specific user. There is one OUCB for each address space,
pointed to by ASCBOUCB (ASCB + X'90').
The following fields help in the understanding of specific user characteristics.
OUCBLSW

When this bit is on, the address space is in the logically swapped state.

OUCBMWT

If this bit is on, the SRM has detected that this user has not been dispatched, but was
occupying storage for at least delta seconds. This interval is processor-model
dependent. The user will be swapped-out until the dispatcher informs SRM that the
address space has work to do.

OUCBAXS

When this bit is on, the user has been swapped-out of storage because the user's
address space was obtaining auxiliary storage slots at the fastest rate in the system
when an ASM slot shortage occurred.

OUCBENQ

This bit indicates that a different address space has tried to ENQ on a resource held by
this address space. This user is treated as non-swappable for an installation-defined
time period.

OUCBYFL

See specific bit designations below:
•
•
•

Bit 1 - indicates that the user was created via a START command.
Bit 2 - indicates that the user was created via a TSO LOGON command.
Bit 3 - indicates that the user was created via a MOUNT command.

OUCBCSFS

If this bit is on, the user is being delayed. Either swap-in has failed for this address
space due to a lack of available storage, or the user was swapped because of a pageable
frame shortage.

OUCBFXS

This bit indicates that the address space was selected for swap-out in order to relieve a
pageable storage shortage condition. If bit OUCBLGFX is also on, the address space
had more frames allocated to it than any other swapp able address space when SRM
detected the pageable storage shortage. If OUCBLGFX is off, the address space had
more fixed frames than an average address space when RSM detected the shortage.

OUCBDFSW

If this bit is on, swap-in has been delayed. The PVTAFCLO and PVTAFCOK fields
have been increased by the number of frames needed to complete the swap-in.

OUCBJSAS

When this bit is on, it indicates that, at the time of job select processing for this user,
there was an auxiliary slot shortage. This user's initiation is being delayed until the
shortage is relieved.

OUCBJSFS

When this bit is on, it indicates that there was a pageable frame shortage at the time of
job select processing for this user. This user's initiation is being delayed until the
shortage is relieved.

Section '5. Component Analysis

5-147

OUCBSRC

This field contains a code describing why this user was last swapped-out. The codes
are:
01 02 03 04 05 06 07 08 09 OA -

Terminal output wait
Terminal input wait
Long wait
Auxiliary storage shortage
Real storage shortage
Detected wait
Reqswap SYSEVENT issued
ENQ exchange by swap analysis
Exchange based on recommendation values by swap analysis
Unilateral swapout by swap analysis.

OUCBRDY

This bit indicates that ready work became available for this address space which was
swapped-out due to a wait. The address space is now capable of executing and is a
candidate for swap-in.

OUCBTWSS

This halfword contains the target working set size for the address space. SRM
attempts to keep this minimum number of frames assigned to the address space.

OUCBHOLD

This fullword contains a count of outstanding "Hold" sysevents issued by this address
space. A non-zero count will result in quiesce turning the swap-out around and
restoring the address space.

Other Indicators
The SRM domain descriptor table can be useful in pinpointing a problem
involving SRM's MPL control. Mapping of the table can reveal why a user is
kept out of main storage, why erratic response time occurs, and other user and
system information.

SRM Error Recovery
SRM maintains two functional recovery routines (FRRs) that are located in
IRARMERR. One FRR (recovery routine 1 - RRI) gets control whenever errors
occur after SRM is branch-entered by a routine that holds a lock higher in the
lock hierarchy than the SRM lock. The other FRR (recovery routine 2 - RR2)
gets control whenever errors occur and SRM is running with the SRM lock.
If it is suspected that SRM is entering error recovery and a stop is necessary at
the time of error, RMRR2INT is a subroutine common to both RRI and RR2.
Recovery routine I (RRI) retries if a retry routine exists. If no routine exists, or
if the error recurs, RRI percolates the error.
With recovery routine 2 (RR2), many special situations such as the following are
first checked:
•
•
•

Is RMF active and should it be terminated?
Is SET IPS active and should abend code be converted?
Is OUCB valid and should abend code be converted?

Then RR2 retries if a retry routine exists. If no retry routine exists, or if the error
recurs, RR2 percolates the error.

5-148

MVS Diagnostic Techniques

SRM SDWA Data
When either FRR is entered, the FRR fills in the SOWA fields prior to
scheduling the SVC dump so that the dump matches the SYSl.LOGREC entry.
However, in some cases, note that the FRR changes the abend code or reason
code after the dump is scheduled and before the LOGREC entry is written, which
results in the LOGREC entry reflecting a different code than the dump.
The FRR also puts problem determination data into the SOWA variable
recording area (SOWAVRA) in key-length-data format using standard keys. (See
the SOWAVRA area in the Debugging Handbook for a description of the keys.)
Additional information is provided for several of the fields as follows:
Key

Contents

VRAEBC The EBCDIC message "IRARMCNS OFFSET TO CURR RTNE PTR IS xxx," where xxx
is the hexadecimal offset into the nucleus module IRARMCNS that contains the entry
point address of either the SRM routine that was in control at the time of the error, or, if a
subroutine was in control, the routine that called the subroutine.
VRARRP A copy of the recovery routine parameter area (RRPA). The RRPA contains status
information used on exit from the SRM and during SRM recovery processing. Note that
the low-order byte in the first word in the RRPA contains the SYSEVENT code of the
original entry to SRM. The format of the RRPA can be found in the IRARRPA mapping
macro.
VRAFP

A copy of the RRPA (as in field VRARRP» but with several entries cleared. Entries are
cleared because they can be different for different invocations of the same function. The
VRAFP is SRM's footprint area used for recognizing duplicate problems.

Module Entry Point Summaries
For a description of SRM modules and entry points, refer to OSjVS2 System
Logic Library.

Section 5. Component Analysis

5-149

VTAM
Note to· Readers
Component information for MVS VTAM is deleted from this book because it is
obsolete.
For diagnostic information for ACF/VTAM, see the following:

5-150

•

ACF/VTAM Diagnosis Guide

•

ACF/VTAM Diagnosis Reference

MVS Diagnostic Techniques

VSAM
The virtual storage access method (VSAM) consists of three major
subcomponents:
•
•
•

Record management
OpenJc1ose/end-of-volume
I/O manager

Record Managemen,t
Record management processing produces no messages. Problem determination
normally begins with an examination of the request parameter list (RPL). If a
physical error occurs and the user has provided a large enough message area
(pointed to by RPLERMSA), VSAM (IDA019R5) builds a SYNADAF-type
record in that area for the user to examine. For both logical and physical errors,
VSAM sets return codes in the RPL.

RPL
Three fields in the RPL are used to indicate an error:
1. RPLERREG-

(RPL + X'D') a one-byte value which is also returned in register 15 after a
request:

o - request completed normally
S - a logical error occurred
12 - a physical error occurred.
2. RPLCMPON -

3. RPLERRCD -

(RPL + X'E') a one-byte value that indicates which component was being
processed at the time of the error if the request involved alternate indexes. This
value also indicates whether upgrading was valid or was incorrect because of the
error.
Code

Component

Status of Upgrade

0
I
2
3
4
5

base cluster
base cluster
alternate index
alternate index
upgrade set
upgrade set

valid
might be incorrect
valid
might be incorrect
valid
might be incorrect

(RPL + X'F') a one-byte value describing the error (see the Diagnostic Aids
section of OS/VS2 VSAM Logic).

Other important fields in the RPL are:
RPLREQ RPLPLHPT RPLECB RPLDACB RPLAREARPLARG RPLOPTCD RPLDDDD-

( + X'02') request type
( + X'04') pointer to the PLH
( + X'OS') ECB or pointer to the ECB
(+ X'IS') pointer to the ACB

( + X'20') pointer to the user's record area
( + X'24') pointer to the user's search argument
( + X'2S') two bytes of option flags
(+ X'40') last successful request's RBA value (returned to user by VSAM).

Section 5. Component Analysis

5-151

PLH
Once the information in the RPL has been evaluated, the next block to examine is
the placeholder (PLH). The PLH contains current information about the'request,
including positioning and pointers to associated control blocks such as buffer
control blocks (BUFCs) and the I/O management block (IOMB).
The following fields are important for understanding the request:
PLHFLG 1 -

( + X'02') status flags

PLHFLG2 -

( + X'03') status flags

PLHEFLGS -

( + X'04') two bytes of exception flags

PLHFLG3 -

(+ X'06') status flags

PLHAFLG3 -

(+ X'07') status flags

PLHCRPL -

(+ X'14') pointer to the current RPL

PLHDBUFC -

( + X'34') pointer to the current data BUFC

PLHDIOB -

( +X'4C') pointer to 10MB

PLHRETO -

(+ X'74') halfword offset into register 14 pushdown save area. If the halfword at
+ X'76' is zero, PLHRETO is an offset from + X'7S' into a 14-word save area and
points to the next available word. If the halfword at + X'76' is not zero, then it is the
offset from + X'7S' to the beginning of a 20-word save area at the end of the PLH,
and PLHRETO is an offset from + X'7S' into that save area.

PLHIBUFC -

( + X'BC') pointer to the current index BUFC

PLHIXSPL -

( + X'CS') 32-byte index search parameter list (IXSPL) containing information about
the results of the last index search.

PLHKEYPT -

( + X'FS') pointer to the current key value or relative record number.

BUFC
The buffer control block (BUFC) contains function codes, status indicators, and
relative byte address (RBA) values describing the associated buffer.
( + X'OI') BUPC status flags
BUFFLG1BUFCIOFL - ( + X'02') I/O status flags
BUFCDDDD - ( + X'OS') RBA for input if BUFCVAL is on
BUFCORBA - ( + X'OC') RBA for output if BUFCMW is on
(+ X'14') pointer to associated buffer
BUFCBAD -

During record management processing, register usage is as follows:
Rl R2 R3 R4 -

RPL pointer
PLH pointer
pointer to the access method block (AMB) of the component being processed
BUPC pointer

Use the register 14 save area in the PLH to find the path taken by a request
through record management.

5-152

MVS Diagnostic Techniques

Record Management Debugging Aids
It is not always desirable to cause program checks as a method of getting dumps,

because some applications have sophisticated error recovery routines that can
possibly change the environment. It is preferable to get documentation of the
error before such routines get control, and then allow these routines to do their
cleanup function after the dump is taken. The following code is an example of a
console-activated communications vector table (CVT) trap for record management
errors that causes the failing application to loop, allowing a console dump to be
taken. Following the dump the trap can be deactivated, allowing the application
to continue processing. The code can be inserted into CSECT IDA019Rl at label
'POSTRPL', label 'POSTRPL2', and the patch area at the end of the module.
NAME IDA019Ll

IDA019Rl

VER POSTRPL'

950C,lOOD

VER POSTRPL2'

1851,9101,1028

VER PATCH

0000,0000

X'54' bytes of patch area

REP POSTRPL'

45EO,Bxxx

to PATCHI

REP POSTRPL2'

1851,45EO,Bxxx

to PATCH2

REP PATCHI

58FO,0010,

point to CVT

LOOPI

9102,FI08,
4780,Bxxx,
D500,FIOA,100D,
4770,Bxxx,
D500,FIOB,lOOF,
4770,Bxxx,
47FO,Bxxx,

is trap activated?
no, go to EXITI
compare error type
no, go to EXITI
compare error code
no, go to EXITI
yes, go to LOOPl. Loop until trap bit in CVT is
turned off.

EXIT 1

950C,100D,
07FE,

restore instruction
branch back inline

PATCH2

58FO,0010,

point to CVT

LOOP2

9102,FI08,
4780,Bxxx,
D500,FI0A,I00D
4770,Bxxx,
D500,FI0B,lOOF,
4770,Bxxx,
47FO,Bxxx,

is trap activated?
no, go to EXIT2
compare error type
no, go to EXIT2
compare error code
no, go to EXIT2
yes, go to LOOP2. Loop until trap bit in CVT is
turned off.

EXIT2

9101,1028,
07FE

restore instruction
branch back inline

To activate the trap, set CVT + X'lOA-IOB' to logical error (X'()8xx') where xx is
the error code (RPLERRCD), or to physical error (X'OCOO'). Then 'OR' on bit 6
(X'02') in CVT+ X'108' taking care to leave the other bits in that byte
undisturbed. After the loop occurs and a console dump of the failing address
space has been taken, tum off bit 6 in CVT + X'108' to deactivate the trap and
allow the application to continue processing. Be sure that the dump taken
includes the region, SQA, and CSA. Note that when using the trap for physical
errors the RPLERRCD is X'OO' at the point of the trap because VSAM has not
yet gone to IDA019R5. Physical errors caused by unit check (for example Section 5. Component Analysis

5-153

incorrect length, no record found on a search id, require that the I/O supervisor
block (lOSB) be examined. To get a dump with the 10SB still valid, a trap can
be inserted into nucleUs CSECT IDA121A4 (abnormal end appendage) at label
'PERM ERR' . Since this is in the nucleus, the trap can be set from the console.
(See I/O Manager Debugging.)
Record management error codes (RPLERRCD) are described in the Diagnostic
Aids section of OS/VS2 VSAM Logic. It is useful to know which module sets
each error and the name of each error, so that you can. find where it is set in the
module via the cross reference.
Error Code (hex)

Symbolic Name

Module (lDAOl9xx)

RPLEODER
RPLDUP
RPLSEQCK
RPLNOREC
RPLEXCL
RPLNOMNT
RPLNOEXT
RPLINRBA
RPLNOKR
RPLNOVRT
RPLINBUF
RPLNOPLII
RPLINACC
RPLINKEY
RPLINADR
RPLERSER
RPLINLOC
RPLNOPTR
RPLINUPD
RPLKEYCH
RPLDLCER
RPLINVP
RPLINLEN
RPLKEYLC
RPLINLRQ
RPLINTCB
RPLSRLOC
RPLARSRK
RPLSRISG
RPLNBRCD
RPLNXPTR
RPLNOBFR
RPLIRRNO
RPLRRADR
RPLPAACI
RPLPUTBK
RPLINVEQ

RD, RR, RY, R2, R4, R8
RA,RQ,RX,R4
RA, RR, RX, R4
RA,RR,RY
RF, RY, R2, R8
RW, RY, R2, R5
RE, RF, RM, R5, R8
RA,R8
RM
RG,RU,RX
RR, RT, RY, R4, R8
RU, RX, RI
RQ, R4, R8
RI, R8
RI, R8
RL,RX,R8
RQ, RI, R4, R8
RD, RR, R4, R8
RQ, RX, R4, R8
RL,RX
RL,RQ
RA, RR, RY, RX, RI, R4, R8
RL, RQ, RU, R4, R8

RPLRDERD
RPLRDERI
RPLRDERS
RPLWTERP
RPLWTER!
RPLWTERS

R5
R5
R5
R5
R5
R5

Logical

04
08

OC
10
14
18
IC
20
24
28
2C

40
44

48
4C
50
54
58
5C
60

64
68
6C
70

74
78
84
88
8C

90
94

98

CO
C4
C8

CC
DO

Rl
RR, R4, R8
RP
RT
RT
R4
RX
RU
RY
RQ,RR
Rl
RX
RQ,R4
RP

Physical

04
08

OC
10
14

18

Record management processing sometimes requires serialization of internal
resources. When the needed resource can be acqwred, processing proceea~

5-154

MVS Diagnostic Techniques

normally. However, when another request has control of the resource the request
is deferred. As each request completes, a scan is made for requests which have
been deferred. If the resource has become available, the deferred request is
restarted. While a request is deferred, PLHD RPND is set in the PLH and
PLHDRRSC points to the resource byte to be tested for availability.

Open/Close/End-Of-Volume
OjCjEOV documents errors by means of error messages and access method
control block (ACB) return codes. The codes returned in the ACB (ACBERFLG)
are explained in the Diagnostic Aids section of OSjVS2 VSAM Logic, along with
an indication of the modules that set each error. In the cross reference of the
modules, these error codes have the symbolic name of OPERRddd, where ddd is
the decimal error code. The most significant problem determination feature of
OjCjEOV however, is its message facility. The following messages are issued:
MSGIEC0701
MSGIEC161I
MSGIEC2511
MSGIEC2521

- END OF VOLUME
- OPEN
- CLOSE
- CLOSE (TYPE=T)

The messages contain both problem codes (symbolic PPddd) and function codes
(symbolic PDFddd). The problem codes that describe the error are explained
with each message in System Messages. The function codes are described best in
the Diagnostic Aids section of OSjVS2 VSAM Logic, along with the module that
was performing the the function at the time of the error.

O/C/EOV Debugging Aids
There is a built-in trap for OjCjEOV (see the Caution later in this topic). There
are two bits involved. Bit 4 (X'08') at CVT+ X'I08' can be OR/d on (being
careful to leave the other bits in that byte undisturbed) to cause an abend dump
(U888) when the message is issued. Bit 6 (X'02') at CVT+ X'IOA' when turned
on prevents the freeing of module work areas. When both these bits are on, the
U888 dump produced contains the module work area for every module gone
through in the open path. There is a discussion in the Diagnostic Aids section of
OSjVS2 VSAM Logic on finding the work areas in the dump and a diagram
showing how the work areas are chained together.
GTF trace is also available for debugging. If GTF is active for TRACE = USR at
the time of the error, VSAM Open (IDA0192P) writes user records FFF and FF5
containing the VSAM control blocks at the time of the failure. The standard
OPEN work area trace is also available by coding AMP = 'TRACE' on the DD
statement.

Section 5. Component Analysis

5-155

The following ENQs areissued by O/C/EOV:
Major Name

Minor Name
(Note 1)

Modules

Reasoo

SYSVSAM

NNNCCCCB

IDAO1 92A
IDA0200T
IDA0231T
IDA0557A

The 'B' or busy ENQ is used to serialize
the modification of the control block
chains by allowing only one of the
functions (OPEN, CLOSE, TCLOSE, or
END of VOLUME) to process the data set.
This resource is held for the life of the
function.

SYSVSAM

NNNCCCCI

IDA0192A

The 'I' ENQ is issued for each component of a
data set being opened for input processing. DEQ
is issued when the data set is closed.

SYSVSAM

NNNCCCCO

IDA0192A

The '0' ENQ is issued for each component of a
data set being opened for output processing. DEQ
is issued when the data set is closed.

Note: If the data set is opened for both input and output, both the 'I' and '0'
resources will be held for each component.
Note 1: In the minor name, NNN
CCCC

= the 3-byte CI number of the component's catalog record
= the 4-byte catalog ACB address.

When a VSAM (non-catalog) ACB is opened, data extent blocks (DEBs) are
constructed and chained as follows:
•

A DEB containing the data set ACB address at DEB+X'lS' is chained on
the DEB chain of the current TCB. This DEB is referred to as the 'dummy'
DEB. Its purpose is to allow abend to close the VSAM data set if abnormal
termination occurs.

•

A DEB containing the component access method block (AMB) address at
DEB + X'lS' is chained on the DEB chain of the jobstep TCB for each
component being opened. These are the 'real' DEBs and are the ones actually
used by VSAM processing.

When an ACB is being opened for DSNAME or DDNAME sharing and the data
set is already open, the ACB is just connected to the existing control block
structure and only the 'dummy' DEB is built and chained on the current TCB.
Caution: When using the O/C/EOV trap be aware that:

5-156

•

If the bit is turned on to prevent the freeing of work areas and the job causes
many calls to O/C/EOV, the region size may have to be increased to prevent
ABENDSOA.

•

JOBCATs and STEPCATs are opened under the initiator TCB. The work
area core is owned by the initiator TCB. If this core is not freed because the
CVT debug bit is on, the initiator tnay get an ABEND20A when it issues
FREEMAIN for subpool 247 at job termination.

MVS Diagnostic Techniques

1/0 Manager
I/O management includes the following modules:
IDA019R3
IGC121
IDA121A2
IDA121A3
IDA121A4

Problem state I/O driver; a CSECT of LPA load module IDA019L1
Supervisor state I/O driver (SIOD); a CSECT in the nucleus
Actual block processor (ABP); a CSECT in the nucleus
Channel end appendage; a CSECT in the nucleus
Abnormal end appendage; a CSECT in the nucleus

The drivers and the ABP translate requests for access to the contents of control
intervals into requests for reading and writing physical records. They also build
the channel program to be passed to lOS.
I/O Manager Debugging
The combination of the I/O management block (10MB), the I/O supervisor block
(IOSB), and the service request block (SRB), is used by I/O management to
control the processing of a request. The PLH (PLHIOB) points to the 10MB.
The 10MB points to the 10SB (IOMIOSB), which in tum points to the SRB
(IOSSRB).
For debugging unit checks (for example: no record found, incorrect length,
channel program check, channel protection check) the best place to trap for a
dump is at label 'PERMERR' in nucleus csect IDAI21A4.

Section 5. Component Analysis

5-157

Catalog Management
Catalog management manages system requests for references and updates to the
master catalog. The following description of catalog management includes these
topics:
•
•
•
•

Major Registers and Control Blocks
Module Structure
VSAM Catalog Recovery 'Logic
Debugging Hints

Major Registers and Control Blocks
This section describes the major catalog management registers and control blocks,
shows how each can be located, and describes those control block fields and flags
that have proven to be useful in debugging.
How to Find Registers

Catalog management runs under control of an SVRB. The registers are saved
across supervisor-assisted linkages and interruptions in the standard ways.
Depending upon the nature of the problem, the registers can usually be found in
one of the following areas:
•

For abends, registers are stored in RTM's SVRB and SDWA.

•

For program checks, registers are stored in RTM's SVRB, the SDWA, and
the LCCA.

•

For catalog-management-issued type 2, 3, and 4 SVCs, registers are stored in
the successor SVRB.

•

For waits, registers are stored in the TCB.

The registers stored in any of these areas will be the registers that existed when
the code that was running under a catalog SVRB gave up control. These registers
will either be the registers of one of the three catalog management routines or the
registers of a routine that was branch-entered by catalog management. If register
II points to the CCA (identifiable via a X' ACCA' in the first word), the registers
probably belong to IGGOCLAI; register 12 will be the base register for the
CSECT last in control. Otherwise, if register II is a base register, the code that if
references may be inspected to determine the routine in control. If the routine in
control is one that was branch-entered by catalog management, then catalog
management's registers may have been saved in a standard area pointed to by
register 13.

5-158

MVS Diagnostic Techniques

Major Registers
IGC0002F
Register 11 Register 12 -

Base register
Work area pointer

IGCOCLAl
Register 11 Register 12 Register 13 -

CCA pointer
Base register (current CSECT)
Register save push down list pointer (see CCAREGS) or standard save area pointer

IGGOCLCA
Register 11 Register 12 -

Base register
Work area pointer

Major Control Blocks

The control blocks described in this section (AM CBS, PCCB, ACB, CAXWA,
CTGPL and CCA) are those that are most useful from a debugging standpoint.
The AMCBS and PCCB are useful in locating the control block structures for
open catalogs. The ACB and CAXWA relate to a particular catalog or catalog
recovery area (CRA) data set. The CTGPL and CCA relate to a particular
catalog request.
AMCBS

The AMCBS (access method control block structure) is essentially a VSAM
vector table. It is constructed within the SQA during early NIP processing
(lEAVNPll) and resides there throughout the life of the system. The AMCBS is
found through CVT+ X'IOO' (field CVTCBSP). Major fields in the AMCBS are:
Field

Description

CBSACB

Pointer to the master catalog'S ACB.

CBSCMP

Pointer to the IGGOCLAlload module.

CBSCAXCN

CAXWA chain pointer. The CAXWAs of all currently open VSAM catalogs are
included in this chain. The master catalog's CAXWA is the last CAXWA in this chain.

PCCB

A PCCB (private catalog control block) connects a VSAM user cat~log to a
particular initiator or job step. A PCCB is constructed (in SWA) for each user
catalog opened during the life of a job step. PCCBs are chained together to form
an initiator or job-step-oriented PCCB chain. Generally, PCCBs are freed by step
termination. A PCCB is not required for the master catalog.
PCCBs are located through the TCB: TCB + X'B4' (field TCBJSCB) points to the
JSCB; JSCB + X'l5C' (field JSCBACT) points to the active JSCB; the active
JSCB + X'CC' (field JSCBPCC) points to the first PCCB. PCCBs are chained via
PCCNEXTP.

Section 5. Component Analysis

5-159

Major fields in a PCCB are:
Field

DescriptioD

PCCACRO
PCCNEXTP
PCCACBP
PCCDSNAM
PCCTGCON

PCCB identifier ('PCCB').
Pointer to the next PCCB. This field is 0 if it is the last PCCB.
Pointer to the catalog's ACB.
Catalog's name.
Catalog's alias name.

Major flags in a PCCB 'are:
Flag

DescriptioD

PCCSTEPC

The catalog was specified to the job step through the use of a JOBCAT or STEPCAT
DD card.

PCCACTIV

The catalog is allocated and active.

PCOSCVOL

The catalog is an OS CVOL.

ACB
There is one ACB (access method control block) for each open VSAM catalog or
CRA. The ACB is created by the routine that opens the data set. Catalog and
CRA ACBs generally reside in the CSA.
An ACB can be located in the following ways:
1.

The master catalog's ACB can be located from the AMCBS (CBSACB).

2.

A particular user catalog's ACB can be located either via the CAXWA chain
or via the PCCB chain. To locate the ACB via the CAXWA chain, inspect
the CAXCNAM field of each CAXWA in turn until the desired catalog name
is found. The first CAXWA is pointed to by the AMCBS (CBSCAXCN).
The CAXWAs are chained via CAXCHN. When the desired CAXWA is
found, it points to the desired ACB (CAXACB).
To locate the ACB via the PCCB chain, inspect the PCCDSNAM and
PCCTGCON fields of each PCCB in turn until the desired catalog name or
alias name is found. The first PCCB is pointed to by the job step's active
JSCB (JSCBPCC). The PCCBs are chained via PCCNEXTP. When the
desired PCCB is found, it points to the desired ACB via PCCACBP.

3.

5-160

A particular CRA's ACB can be located as follows:
a.

Find the owning catalog's ACB (via steps 1 or 2).

b.

Find the owning catalog's CAXWA (pointed to by ACBUAPTR).

c.

Find the first CRA's ACB (pointed to by CAXCRACB).

d.

Find the first CRA's CAXWA (pointed to by the CRA ACB's
ACBUAPTR field at- ACB+ X'40').

e.

Inspect the CAXVOLID field for the desired CRA volume serial number.

MVS Diagnostic Techniques

~

f.

If the desired CRA's ACB has not yet been found, then search the
remaining CAXWAs in the CRA CAXW A chain. Inspect the
CAXVOLID field of each remaining CRA CAXWA in tum until the
desired CRA volume serial number is found. The remaining CRA
CAXWAs are chained to the first CRA CAXWA (and to each other) via
CAXCHN. When the desired CRA CAXWA is located, it points to the
desired CRA ACB via CAXCRACB.

4.

The ACB representing the VSAM catalog that is currently being processed by
a particular catalog request can be located via the CCA (CCAACB).

5.

The ACB representing the CRA that is currently being processed by a
particular catalog request can be located via the CCA (CCARAACB).

Major fields in the ACB are:
Field

Description

ACBID

Control block identifier (X'AO').

ACBAMBL

Pointer to the VSAM record management control block structure. This set of control
blocks is built at OPEN time, resides in CSA, and consists of those control blocks
required to support a KSDS (catalog) or an ESDS (CRA).

ACBERFLG Error code stored by OPEN or CLOSE when the operation is unsuccessful.
ACBUAPTR Pointer to the CAXWA.

Major flags in the ACB are:
Flag

Description

ACBCAT

ACB represents a catalog.

ACBSCRA

ACB represents a CRA that has been opened for catalog management use.

ACBUCRA

ACB represents a CRA that has been opened for use by an access method services
(AMS) utility function.

CAXWA
There is one CAXWA (catalog ACB extended work area) for each open catalog
or CRA. The CAXWA is created during the OPEN process (either before the
OPEN or by the catalog OPEN routines). CAXWAs generally reside in the CSA.
The CAXWA is pointed to by the ACB (field ACBUAPTR). See step 3 for
locating the ACB under the heading "ACB" earlier in this chapter. Major fields
in the CAXWA are:

~

Field

Description

CAXID

Control block identifier (X'CA').

CAXCHN

Pointer to the next CAXWA in the CAXWA chain. This is 0 if it is the last CAXWA in
the chain.

CAXACT

Count of the number of job steps for which this catalog is currently open.

CAXACB

Pointer to the catalog ACB.

CAXUCB

Pointer to the catalog's or CRA's UCB.

Section 5. Component Analysis

5-161

CAXRPL

Pointer to a pool of RPLs. This pool is obtained at OPEN time and resides in CSA.
(Note: This field is not used in CRA CAXWAs. CRA RPLs are included within the
owning cat\llog's RPL pool.)

CAXCNAM

Catalog name (for catalog CAXWA only).

CAXVOLID

CRA volume serial number (for CRA CAXWA only).

CAXCRACB Fora catalog CAXWA: pointer to the ftrst CRA ACB. For a CRA CAXWA: pointer
to the CRA ACB.

Major flags in the CAXWA are:
Flag

Deseription

CAXBLD
CAXOPN
CAXCLS
CAXEOV
CAXMCT
CAXF2DT
CAXF2NDD
CAXF2NCR
CAXF210E
CAXF2REC

The catalog or CRA is in the process of being created.
The catalog or CRA is being opened.
The catalog or CRA is being closed.
The catalog or CRA is being extended.
The CAXWA represents the master catalog.
The catalog has been deleted.
Unable to OPEN or CLOSE - DDNAME not found.
Unable to OPEN or CLOSE - insufficient main storage.
Unable to OPEN or CLOSE - I/O error.
The catalog is a recoverable catalog (catalog CAXWA only).

CTGPL
The CTGPL (catalog parameter list) is built by the routines that issue SVC 26 to
represent the desired catalog management request. The storage area where this
block resides varies and is controlled by the building routine. When a caller
issues SVC 26, the caller's registers are saved in the SVRB under which catalog
management operates. Register 1 of this SVRB's register save area points to the
CTGPL. The CTGPL may also be located via the CCA (CCACPL).
Note: At times, catalog management processing uses CCACPL as a pointer to an
internal CTGPL. Therefore, you should be careful when you use this pointer to
locate the caller's CTGPL.

Major fields in the CTGPL are:

5-162

Field

Description

CTGOPTI
CTGOPT2
CTGOPT3
CTGOPT4
CTGOPTNS
CTGTYPE

These ftelds contain the codes and flags that indicate the type of function
requested.

CTGENT

Pointer to the entry name or CI number (for types of requests other than DEFINE or
ALTER).

CTGFVT

Pointer to the field vector table (FVT) for DEFINE and ALTER requests.

CTGCAT

Pointer to an area that indicates the speciftc catalog (if any) to be used in processing
this request. The area may contain either the catalog name or a pointer to the
catalog's ACB. If no speciftc catalog is indicated, CTGCAT will be O.

CTGWKA

Pointer to the work area. In general, catalog management stores the requested
information into this area.

CTGNOFLD

Number of FPL pointers in CTGFIELD.

CTGFIELD

An array of 4-byte RPL pointers. The FPLs,.describe the data ftelds· that the request is
to process.

MVS Diagnostic Techniques

CCA

The CCA (catalog communications area) is the main VSAM catalog work area.
It is built upon entry to the VSAM catalog processor and freed just before exit.
The CCA resides in subpool 252 of the caller's address space. Register 11 points
to the CCA.
Major fields in the CCA are:
Field

Description

CCAID

Control block identifier (X'ACCA').

CCAPROB

Error data - consists of a CSECT ID (2 bytes), reason code (1 byte), and error code (1
byte).

CCATCB

Pointer to the caller's TCB.

CCACPL

Pointer to the CTGPL.

CCAACB

Pointer to the ACB of the catalog that is currently being processed.

CCAURAB

Pointer to the record area block (RAB) of the record area currently in use.

CCASRCH

Search argument for I/O requests.

CCARxREC

Pointer to record area x. (There are six record areas, record area·.() through record area
5; x indicates the number of the record area in question.)

CCARPLl

Pointer to the RPL that is currently assigned to this request.

CCAEQDQ

An ENQ/DEQ parameter list that is used when VSAM catalog management issues the
RESERVE macro.

CCAMSSPL

A GETMAIN/FREEMAIN parameter list that the VSAM catalog processor uses for
most GETMAIN/FREEMAINs.

CCACMS

Pointer to the catalog management services work area (CMSWA); it is used only for
DELETE, ALTER, DEFINE, and LISTCATALOG requests.

CCAREGS

An array of small (12-byte) register save areas. When a VSAM catalog processor
routine calls a lower level (nested) routine, the contents of registers 12-14 are saved in
the next save area by the routine that is called. Registers 12 and 14 contain the calling
routine's base address and return address, respectively. Register 13 is used to maintain
position within the array. Each time register 13 is saved, it points to the preceding save
area. During a lower level routine's processing, register 13 points to the current save
area (that is, the area containing the caller's registers). When a lower level routine exits,
registers 12-14 are restored which causes register 13 to be automatically switched (the
preceding save area becomes the current save area). Whenever VSAM catalog processor
routines branch-enter external routines, they pass a standard. 72-byte save area to the
external routine. This is accomplished by increasing register 13 by 12 during the process
of setting up the linking conventions for the branch and link. (The 72 bytes that follow
the current save area are used as the standard save area. Note: The register contents
stored within this array can be used in debugging to identify predecessor routines and
modules.)

CCARAACB Pointer to the ACB of the CRA that is currently being processed, or zero.
CCARARPL Pointer to the RPL that is currently assigned to this request for CRA I/O use.

Section 5. Component Analysis

5-163

Major flags in the CCA are:
Flag

Description

CCAFLG 1-4

Miscellaneous processing control flags.

CCARPLX

I/O option flags:
00 .....0
00 .... .1
01......
1......0
1.. .... 1
..0.....
.. 1.....

...0....
... 1....

....0...
.... 1...
.....0..
..... 1..
...... 0.
...... 1.

PUT direct
PUT sequential
ERASE
GET direct
GET key equal to or greater than
Use the record area pointed to indirectly by CCAURAB
Use record area 0
Addressed or CI operation
Keyed operation
Update operation
Non-update operation
Check for errors
Bypass error checking
50S-byte low-key range record
47-byte high-key range record

CCAFLG9

Miscellaneous CRA processing flags

CCARVFGI

Miscellaneous recovery (ESTAE) control flags

Module Structure
Catalog management is packaged into three load modules. These modules are the
following:
I.
2.
3.

IGC0002F - Catalog Controller
IGGOCLAI - VSAM Catalog Processor
IGGOCLCA - CVOL Processor

This set of modules resides within SYS1.LPALIB and can be viewed as a type 4
SVC routine consisting of three load modules. Catalog management receives
control via SVC 26 and operates under an SVRB. Control is passed between the
three load modules via XCTL. Each load module establishes its own ESTAE
routine. A brief description of each load module follows.
I.

IGC0002F - Catalog Controller

The function of this module is to translate (map) interfaces. The module
logically processes from a front end and a back end.
The front end receives control from the SVC SLIH whenever SVC 26 is
issued. Register 1 points either to an OS CAMLIST or a VSAM CTGPL. If
register 1 points to an OS CAMLIST, the OS request is translated into an
appropriate VSAM request (a CTGPL is constructed). Control is then passed
to IGGOCLAI.
The back end receives control (at EP IGGOI02F) from IGGOCLAI upon
completion of a VSAM request for a VSAM catalog. It determines if the
original request was an OS CAM LIST request and if so, it translates the
CTGPL output and the IGGOCLAI return code into appropriateCAMLIST

5-164

MVS Diagnostic Techniques

format. It then returns control to the issuer of SVC 26. For a more detailed
description of this module, see OS/VS2 Catalog Management Logic.
2.

IGGOCLAI - VSAM Catalog Processor

IGGOCLAI is a large load module that consists of many CSECTs and
procedures. Control is passed between the various procedures via CALLs.
This module relates a request to a specific catalog and also determines the
catalog type. If the catalog is an OS CVOL, IGGOCLAI passes control to
the CVOL processor (IGGOCLCA). Otherwise, IGGOCLAI accesses the
VSAM catalog and performs the function indicated by the CTGPL. When
the function is completed, IGGOCLAI exits by passing control to the back
end of IGC0002F. For a detailed description of VSAM catalog management,
see OS/VS2 Catalog Management Logic.
3.

IGGOCLA - CVOL Processor

IGGOCLCA is a load module that consists of several CSECTs and
procedures. Control is passed between the various procedures via CALLs.
This module translates CTGPL requests into OS catalog requests and accesses
OS CVOLs to perform the indicated function. Upon completion of
processing this module returns control to the issuer of SVC 26. For a detailed
description of this module, see OS/VS2 CVOL Processor Logic.

VSAM Catalog Recovery Logic
This section describes how mainline VSAM catalog management supports
recovery and also how its recovery routine works.
Mainline VSAM catalog management does the following:
•
•
•
•

Establishes/releases the recovery environment
Maintains a pushdown list end mark
Tracks GETMAIN /FREEMAIN activity
Maintains a CMS (catalog management services) function gate

Establishing/Releasing a Recovery Environment

To establish or release a recovery environment, the following actions occur:
1.

Subfunction BLDCCA in module IGGOCLC9 issues a branch entry to
ESTAE to establish the recovery environment. This is done immediately after
storage has been obtained for the CCA via GETMAIN.

2.

When BLDCCA completes the initialization of the CCA, it sets RVCCAV to
indicate that the CCA is now valid.

3.

Subfunction IGGPRCLU (request cleanup) in module IGGOCLC9 performs
the following:
•
•
•

Indicates that the CCA is no longer valid (RVCCAV = off)
Frees any GETMAIN/FREEMAIN tracking spill blocks that may exist
Branch enters EST AE to remove the recovery environment

Section 5. Component Analysis

5-165

Maintaining a Pushdown List End Mark

A pushdown list end mark is maintained so that the ESTAE recovery routine can
reliably locate the last pushdown list entry. This enables the recovery routine to
determine:
1.
2.

The address at which the last call to a nested subfunction was issued.
The routine to which this call was directed.

There is an instruction in the exit procedure code contained within each CSECT
to insure that the first byte following the last active entry contains an end-of-list
marker. (Note that X'OO' and X'FF' are considered end-of-list markers.)
Tracking GETMAIN/FREEMAIN Activity

GETMAIN/FREEMAIN tracking provides the recovery routine with the
information it needs to automatically issue FREEMAINs against those areas of
main storage that have been acquired and not yet freed by VSAM catalog
management. The GETMAIN/FREEMAIN tracking function is implemented as
follows:
1.

A 256-byte contiguous area is defined in the CCA. The area consists of:
a.

A 248-byte tracking buffer.

b. A single entry GETMAIN/FREEMAIN length list (four bytes) with the
high-order byte initialized to X'80' and the low-order three bytes defined
as CCAMNLEN.
c.
2.

The GETMAIN/FREEMAIN address word (CCAMNADR).

The ?GETMS and ?FREEMS macros generate code that:
a.

Track the operation. This is accomplished by an MVC instruction that
traces the GETMAIN/FREEMAIN length and address by pushing it
(shifting it left) to the bottom (low address) of the 248-byte tracking area.

b. Check for full tracking buffer. If the buffer is full, a spill routine
(lGGPARFS) is called before the tracking MVS instruction is issued.
This spill routine:
1) Issues GETMAIN to obtain a 256-byte spill buffer.
2) Chains this buffer to the end of the spill buffer chain. (Note:Chain
anchor words are located in the CCA.)
3) Copies the CCA tracking buffer into the new spill buffer.
4) Clears the CCA tracking buffer.
c.

5-166

MVS Diagnostic Techniques

If the ?GETMS macro call is specified with CLASS(S) for storage
(global), a flag (MNATSCLS) is set in the first byte of the two-word trace
entry to indicate this. Refer to the description of CCAMNCAT, a work
area that is located at CCA + X'308', contained in OS/VS2 Catalog
Management Logic.

,4
~

eMS Function Gate
The CMS function gate assists the recovery routine in determining if DEFINE or
DELETE backout action is required. This gate is represented by a bit
(RVCMSFG) in field CCARVFGl. The bit is turned on by the CMS driver
(IGGPCDVR in module IGGOCLAT) immediately after a successful return from
the check authorization function. The bit is reset upon entry to the CMS cleanup
function (IGGPCCLN in module IGGOCLAT).

Recovery Routine Functions
VSAM's catalog processor recovery routine is labelled IGGPCMRR (CSECT
IGGOCLA9). This recovery routine is entered from MVS's recovery termination
manager (RTM) whenever an error or interruption occurs either in VSAM catalog
management or in any successor routine that VSAM catalog management can
cause to receive control. A pointer to the ST AE diagnostic work area (SDW A) is
passed as input to IGGPCMRR. IGGPCMRR performs the following functions.
(Functions 2-13 are performed only when the CCA is marked valid, that is,
RVCCAV=ON.)
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

Retrieves the CCA pointer from the SDW A and puts it into register 11.
Saves the RTM return address in CCARI4S.
Saves the SDWA pointer in CCASDWAP.
Produces diagnostic output.
Initializes register 13 to point to the first register save area.
Cleans up RPLs (if required).
Determines if backout is to be performed.
Checkpoints the CCR (if required).
Drops catalog orientation.
Frees storage (using GETMAINJFREEMAIN tracking information).
Frees GETMAINJFREEMAIN tracking spill blocks (if any exist).
Performs DEFINE/DELETE backout (if applicable).
Restores the RTM return address and the SDWA pointer.
Frees the CCA.
Returns to RTM indicating that RTM should continue with termination.

The following sections describe the more complex of these recovery routine
functions in greater detail.
Diagnostic Output (Function 4)

Diagnostic output is produced except in those situations where the recovery
routine is invoked only for clean up type functions, such as CANCEL.
Diagnostic output can be produced in two forms:
1.

Information is placed in a variable recording area (SDWAVRA) within the
SDWA. This data is written to the SYSl.LOGREC data set as part of an
entry describing the error.

Section 5. Component Analysis

5-167

This variable data is formatted as follows:

2.

Byte

Length

Description of Data

0(0)
8(8)
I 1(B)
19(13)
22(16)
30( 1E)
33(21)
37(25)

8
3
8
3
8
3
4
28

VSAM catalog processor module name - 'IGCOCLA1'
IGGOCLA1's entry point address
Procedure name of the last-called routine
Address of the last-called routine
Procedure name of the routine that called the last-called routine
Address of the CALL to the last-called routine
The characters 'CPL = '
A copy of the user's CTGPL

An SDUMP is taken (if allowed by the system).

Backout (Function 7)
Backout is performed for DEFINE or DELETE requests (except for DEFINE or
DELETE catalog requests) when the eMS function gate is active (RVCMSFG =
ON). When backout is to be performed, a switch (RVESBOR) is set. The
backout function (Function 12) is described later in this chapter.
Drop Catalog Orientation (Function 9)
This function uses the normal IGGPRPLF subfunction to perform the RPL
freeup/DEQ functions.
Storage Freeup (Function 10)
This function frees all the storage (with the exception of the CCA and any
existing tracking spill blocks) that has been acquired and is still owned by the
current VSAM catalog management request. Storage freeup is done as follows:
1.

The GETMAINJFREEMAIN tracking data is scanned starting at the first
spill block (if any) and following the chain of spill blocks. When the last spill
block has been processed, the scan continues with the first valid entry in the
CCA tracking buffer. This first scan selects and eliminates paired entries; a
paired entry consists of two entries with matching storage addresses, which
indicate that the storage area in question has already been freed.

2.

The tracking data is scanned again. During this second scan, each valid
remaining entry is processed as follows:
a.

The length and address of the storage to be freed are extracted from the
entry.

b. The subpool is determined from a switch setting within the entry.
c.

5-168

MVS Diagnostic Techniques

A ?FREEMS macro is issued to free the main storage. This macro
specifies "RFR (NO)" to prevent recursive tracking.

DEFINE/DELETE Backout (Function 12)
This function attempts to preserve catalog integrity by cleanup up
partially-completed DEFINE or DELETE operations. It uses the normal
DELETE function to accomplish this. The switch indicating that backout is
required is tested. If this switch is on, the following actions are performed:
1.

A backout work area is obtained.

2.

A DELETE CTGPL is constructed in the backout work area. This CTGPL
is set up to cause a DELETE of the object that was being defined (with
DEFINE) or deleted (with DELETE) whenever the error occurred.

3.

The CCA is rebuilt as follows:
a.

CCACPL, CCASZ, CCATCB, CCASDWAP, CCARI4S, and
CCARVFGI are saved (in the backout work area).

b.

The complete CCA is cleared.

c.

The previously-saved fields (with the exception of CCACPL) are restored.

d.

CCAPCL is initialized to point to the CTGPL, which was built into the
backout work area.

e.

CCAID, CCAURAB, CCAROREC through CCAR5REC, CCAEDXFF,
CCAMNPTR, CCAMNLLP, CCAMNLL, and register 13 are
reinitialized to their original values.

f.

CCAF2SYS is set on.

g.

RVESBO is set on to indicate that backout is in control.

4.

The CMS driver (IGGPCDVR is invoked which then invokes the DELETE
function; when the DELETE action is complete, control is returned to the
recovery routine.

5.

The CCR is checkpointed (if required).

6.

Catalog orientation is dropped (via a call to IGGPRPLF).

7.

CCACPL is restored.

8.

The backout work area is freed.

9.

Any spill blocks acquired during the backout process are freed.

Section 5. Component Analysis

5-1'69

Debugging Aids
The control block structures for the VSAM catalog reside in the CSA. There is a
built-in communications vector table (CVT) debug word which allows you to get
a console dump at the time of the failure. This word is located at CVT+ X'108'
and is examined by module IGGOCLC9 at the end of each catalog request.
Following are the contents of the CVT debug word:
Byte 0 (X'IOS')

bits 0-3

must remain unchanged.

bit 4

not used by catalog.

bit 5 = 1 causes message IEC3311 to be issued when condition specified in byte 1
(X'109') is met. IEC3311 contains the name of the catalog module which
detected the error.

Byte I (X'109')

bit 6

not used by catalog

bit 7 = I

prevents catalog FRR (IGGOCLA9) from freeing the catalog
communications area (CCA) so that it is available in the dump.

Condition for which action specified at location X'IOA-IOB' is to be taken.
X'OI' -

take action at end of every catalog request

X'02' -

take action for any non-zero catalog return code

X'03' -

take action for return codes other than those considered to be
"normal." (The following are considered to be normal return
codes - X'OO, 08, 24,28, 2C, 4C, 8C' and reason codes X'28, BC,
and FO'.)

X'04' to X'FF' -

take action only when catalog return code equals value in this
byte.

Bytes 2 and 3 (X'IOA-IOB')
Action to be taken on above condition:
X'07FE' - return immediately to in line catalog code and continue processing. This·
setting, in conjunction with bit 5 of byte 0, causes no action other than
message IEC33 II.
X'07FF' - will cause loop here at CVT + X' lOA' to allow console dump of failing
ASID. To break job out of loop, either cancel the job or set these bytes
to X'07FE' to continue processing.

When message IEC331I appears by itself, use the above CVT trap to get a dump
of the failure. When messages IEC3311, IEC3321, and IEC3331 appear together,
the error is the result of a call to record management. Message IEC3331 contains
the record management return code in the form Lxxx (for logical error) or Pxxx
(for physical error) where xxx = decimal return code. In these cases use the CVT
trap discussed earlier in the Record Management Debugging Aids section of
VSAM component analysis.
In situations where an attempt to open a VSAM catalog results in message
IEC1611 004-080, it is difficult to determine the exact nature of the problem
because there are many conditions which can cause this error. The best place to
trap dump. is at label 'CAPERR' in modules IFG0191X and IFG0191Y. Register
14 at that point will be in the calling routine which detected the failure.

5-170

MVS Diagnostic Techniques

It is sometimes necessary to examine the records in the catalog as part of the

problem analysis. The following is an example of the access method services job
necessary for this.
EXEC PGM=IOCAMS
//PRINT
00 OSN=catalognarne,OISP=SHR
//STEPCAT
00 OSN=catalognarne,OISP=SHR
//001
00 SYSOUT=A
//SYSPRINT
//SYSIN
00 *
PRINT INFILE (001)

/*
The following ENQs are issued for catalog processing:
Major Name

Minor Name

Modules

Reason

SYSIGGVl

MCATOPEN

IGGOCLAC
IGGOCLAD

Open master catalog

SYSIGGV2

catalogname

IGGOCLA3

Assign RPL processing

SYSVTOC

volser

IGGOCLBU

Read/Write format 4 DSCB

SYSZCAXW

CAXW

IDACATII
IDACAT12
IGGOCLBG

Open, close, or delete
Catalog request

SYSZPCCB

PCCB

IGGOCLA3

While building PCCB for catalog open

SYSZTIOT

asid

IDACATII
IDACAT12
IGGOCLAD

Open and close of catalog
Component recovery area (CRA) orientation

IGGOCLA3

While Caxwa RPL count is being altered.

IEZIGGV3

addr of caxwa

Section 5. Component Analysis

5-171

Allocation/Unallocation
This section is divided into four parts. Part one provides a description of the six
major functional areas of allocationjunallocation and the way in which they
interrelate. Parts two, three, and four contain general debugging aids, debugging
hints, and reason codes.

Functional Description
Figure 5-33 illustrates the control-flow discussion that is presented in the
following paragraphs.

JFCB
Housekeeping

Figure 5-33.

Relationship of the Six Major Functions of Allocation/Unallocation

Allocation

The flow through allocation following either batch initialization or dynamic
initialization is the same:

5-172

•

Batch/dynamic initialization and control invokes JFCB housekeeping.

•

Batch/dynamic initialization and control then invokes common allocation.

•

Common allocation invokes volume mount and verify (if volume unloading or
mounting is needed):

MVS Diagnostic Techniques

Unallocation
At batch/dynamic unallocation, the control flow is as follows:
•

Batch/Dynamic initialization and control invokes common unallocation.

•

Common unallocation invokes volume mount and verify (if any volume
unloading is needed).

•

Batch initialization and control invokes volume mount and verify (if volume
unloading is needed).

Batch Initialization and Control
Batch initialization and control uses the following control blocks:
•
•
•
•

Job control table (JCT)
Step control table (SCT)
Linkage control table (LCT)
Job step control block (JSCB)

The SCT is needed to locate the chain of step I/O tables (SlOTs) and job file
control blocks (JFCBs) in the scheduler work area (SWA). A SlOT and its
corresponding JFCB are constructed by the converter/interpreter for each DD
statement in a job step's JCL. Allocation allocates one step at a time. The SlOTs
and JFCBs for a step are read by batch initialization and control when initialifing
for the allocation or unallocation of a step. At step initiation, space for the task
I/O table (TIOT) ;s obtained, and the JSCB is initialized to point at the top of the
chain of data set association blocks (DSABs), which are actually constructed by
common allocation. At job step allocation, the SlOTs and JFCBs are passed as
the main input, first to JFCB housekeeping, and then to common allocation. At
job step unallocation, the SlOTs and JFCBs are passed as the main input to
common unallocation. At the end of the job, batch initialization and control uses
a volume unload table (VUT) to determine those private volumes that belong to
the ending job and that are to be unloaded. Unloading is done by volume mount
and verify (VM&V).

Dynamic Initialization and Control
When dynamic initialization and control is invoked, the job step's SlOTs and
JFCBs must be read. This is done only for the first dynamic allocation during a
given job step. The caller's parameters are syntax- and validity-checked and used
to build a SlOT and JFCB, just as in a DD statement. Existing allocations
(represented by an existing DSAB and TlOT entry) are used where possible to
satisfy the request. If the requested data set is already allocated, certain
information is copied from the SlOT and JFCB of the existing allocation to those
of the new allocation. By using the existing allocation, invocation of JFCB
housekeeping and common allocation is avoided. If an existing allocation cannot
be used to satisfy the dynamic request, the SlOT and JFCB built by dynamic
initialization and control are used, first as input to JFCB housekeeping, then to
common allocation. After common allocation completes, the SIOT(s)
representing the request is chained to the step's other SlOTs.

Section 5. Component Analysis

5-173

If dynamic unallocation is being requested, the parameters must be syntax- and
validity-checked. The correct SlOT is located and passed to common
unallocation.
JFCB Housekeeping

The major input to JFCB housekeeping is the SlOT chain, each SlOT having an
associated JFCB. JFCB housekeeping completes needed information about either
batch or dynamic allocation requests that was not placed in SlOTs and JFCBs by
the converter/interpreter. Allocation parameters that JFCB housekeeping
completes are the name, volume, unit, DCB, and disposition of the data set.
Before processing these parameters, JFCB housekeeping, using dynamic
allocation, allocates to the initiator's task control block (TCB) any STEPCAT
DD or JOBCAT DD statements. A private catalog control block (PCCB) is built
for each such catalog allocated, and all SlOTs are processed, one at a time. This
JOB CAT/STEPCAT processing takes place in a batch environment only.
Information for a request is placed in the JFCB housekeeping work area as a
SlOT/JFCB pair, is processed and reinitialized for each SlOT. If volume
information was not specified for an old data set, the passed data set information
(PDI) is searched (only in a batch environment) in the SWA to locate volume and
unit information. If not found, or if the data set name is a generation data group
(GDG) single name, a catalog LOCATE is issued to obtain the volume and unit
information. If volume reference is specified in the SlOT, either the data set
referenced is located in the PDI or via catalog LOCATE, or the SIOT/JFCB of
the referenced DD statement is found. The source of volume and unit
information is recorded in the JFCB housekeeping work area; the information is
then retrieved and placed into the SlOT/JFCB being processed. A DCB reference
to a cataloged data set is resolved by LOCATE and OBTAIN. A DCB reference
to a DD statement is resolved by going to the JFCB of the referenced DD
statement and then issuing an OBTAIN. Finally, disposition-related information
is entered into the SIOT/JFCB.
Common Allocation

Common allocation receives as input the SlOTs and JFCBs of allocation requests.
For requests that do not require a unit to be allocated, namely, DUMMY, VIO,
and subsystems, DSAB and TIOT entries are built and the SlOT is marked
"allocated." For each request requiring units, a list of eligible devices called the
eligible device list (EDL) is constructed, and pointed to by the requestor's SlOT.
An entry is built into the volunit table representing each volume/unit required.
Inter-DD relationships are represented primarily by setting fields in the VU table
for use by the remainder of common allocation.
The remainder of common allocation is divided into:
•
•
•
•

Fixed Device Allocation
TP Allocation
Generic Allocation
Recovery Allocation

Common allocation control invokes each of these functions in the order indicated.
If all requests have been allocated, any requests needing volumes mounted have
volume mount and verify (VM&V) RBs chained to their SlOTs. These VM&V

5-174

MVS Diagnostic Techniques

RBs are chained to each other and sent to VM&V on input. VM&V mounts the
necessary volumes.
Fixed Device Allocation

Allocation for any request that can be allocated to a volume on a
permanently-resident or reserved DASD uses fixed device allocation. The
allocation of a request (VU entry) involves:
•
•
•
•
•

The selection of the device
The building of the DSAB (pointed to by a SlOT)
The building of a TIOT entry (pointed to by a DSAB)
Setting indicators in the unit control block (UCB) of the selected device
Issuing DADSM commands

TP Allocation

This is a small specialized operation for teleprocessing lines. TP lines, once
allocated, remain allocated whether online or not, and cannot be reallocated.
Generic Allocation

Generic allocation attempts to allocate the remaining requests that were not
allocated by previous processes. Requests for tapes, demountable direct access
volumes, graphics devices, and unit record devices are not considered until generic
allocation. A special set of tables, the generic allocation tables are built to
represent the units eligible for each request (VU entry). These tables are used
throughout generic and recovery allocation. Generic allocation processes requests
not sequentially but on the basis of generic device type. The order in which
generic device types are chosen is determined by a table, built at SYSGEN time,
called the device preference table.
Recovery Allocation

Requests left unallocated by previous steps are allocated by recovery allocation.
The main functions of recovery allocation are to interface with the operator to
request that offline devices be brought online, and, once online, to allocate these
devices to unallocated VU entries.
Common Unallocation

The input to common unallocation is a chain of RBs, each of which points to a
SlOT to be unallocated. Disposition processing uses the SlOTIJFCB and
common unallocation RB to give the data set a disposition. Units allocated to
each SlOT are unallocated by using the TIOT entry. Private tape volumes are
unloaded and the VUT is updated with volume serials to indicate which of the
job's volumes were left mounted at unallocation time, but need demounting by
batch initialization and control at end of job. Data sets are released (dequeued)
by using the data set enqueue table to determine if the data set's last use in the
job is in the current step. All volumes used by a step are released by a generic
dequeue if unallocation is for a step. In the dynamic unallocation environment,
only the subject request's volumes are dequeued.

Section 5. Component Analysis

5-175

Volume Mount and Verify

Volume mount and verify (VM&V) mounts, verifies, and unloads volumes.
VM&V is driven by a chain ofVM&V request blocks. A VM&V count table is
built in which the numbers of mount, verify, and unload requests are maintained.
In mounting and verifying direct access volumes, VM&V builds a mount
verification communication area (MVCA) in CSA. This contains a pointer to an
MVCA extension (MVCAX), which VM&V builds in the user region. The
MVCAX contains a device-end ECB and UCB pointers for each device for which
a mount has been issued. After issuing mounts and building the MVCA/MVCAX
blocks, VM&V waits for the device-end ECB in the MVCAX. Whenever a
device-end occurs on a unit that VM&V is waiting for, a nucleus routine
(IEFDPOST) posts the device-end ECBs in all MVCAXs. Any VM&V that is
waiting looks at all UCBs being waited for. Volume serials for DASD are read
and verified when the devices become ready.
Volume unloading is accomplished for DASD by signaling a volume unload event
to the event notification facility (ENF), issuing an unload message to the
operator, and clearing volume-related data from the UCB. For tape volume
unloading, a physical rewind/unload operation is also performed. Virtual volume
unloading is accomplished by signaling a volume unload event to the event
notification facility (ENF), issuing an unload SVC (SVC 126), and clearing
volume-related data from the UCB.

General Debugging Aids
Described here in general terms are the following:
•
•
•
•

Allocation Module Naming Conventions
Registers and Save Areas
Common Allocation Control Block Processing
ESTAE Processing

Allocation Module Naming Conventions

All Allocation module names have the following format:
IEF B4
IEF indicates the module is a scheduler module. The fourth character has the
following meaning:
•

If A, the module is part of common allocation, common unallocation, JFCB
housekeeping, or volume mount and verify.

•

If B, the module is part of batch allocation or batch unallocation.

•

If D, the module is part of dynamic allocation or dynamic unallocation.

•

If E, the module is part of an externally available allocation service.

•

If H, the module uses cross memory operations.

B4 identifies the module as a part of allocation. The last two
unique module identifier.

5-176

MVS Diagnostic Techniques

c~racters

are a

Registers and Save Areas

Allocation follows standard register saving and usage conventions. Register 13 is
used as a save area pointer, register 14 as a return address, and register 15 as a
branch address. Register save areas are chained in the standard manner.
Since allocation is coded completely in top-down fashion, it is a simple matter to
find the flow of control leading to the current point of processing by tracing back
through the save areas. All allocation modules have identifiers just after the
beginning of the module, which contain the module name in EBCDIC. A graphic
representation of control flow can be found under "Allocation/Unallocation" in
"Module-to-Module Control Flow" of OS/VS2 System Logic Library.
Space for the allocation save areas is obtained in a unique manner, which can be
of help in debugging. On entry to allocation, a 4K block of space is obtained
from subpool 230. This block is used to contain the save area and data area for
each module called, until the block is full, at which time another 4K block is
obtained. Save areas of modules that had been given control but then returned
are still valid, that is not freed, if the 4K block in which they had been placed has
not been freed. Allocation does not keep the address of a control block in any
particular register. Register 13 always points at the save area of the module incontrol. Register 12 is usually the base register of the module in control.
Common Allocation Control Block Processing

This section graphically describes the control blocks used by common allocation
and explains how these control blocks reflect allocation processing. Figure 5-34
shows the control blocks which are input to common allocation. Data set
association blocks (DSABs) and their associated task input/output table (TIOT)
entries are shown as input. Note that DSABs exist only if common allocation
was called by dynamic allocation. When batch allocation calls common
allocation, there are no DSABs, but there is a DSAB queue descriptor block
(QDB).
The first major step in common allocation processing is the construction of the
allocation work area (ALCWA). Following this, requests that do not require
units, such as DUMMY and SYSOUT DD requests, are allocated. A DSAB and
TIOT entry are built for each of these requests as they are allocated. SIOTETIO
is initialized to point to the DSAB whenever it is created for a given SlOT. Bit
SlOTALCD is set to 1 whenever a request (SlOT) is fully allocated.
After allocating these requests, the volunit table (VU table) is created to represent
the unit requirements of remaining (unallocated) SlOTs. In addition, an eligible
devices list (EDL) is created for each remaining SlOT. The EDL contains the
unit control block (UCB) pointers to all UCBs representing devices eligible for
allocation to the SlOT. (A device is "eligible" at this point whether on or offline,
either logically or physically.) Figure 5-35 shows the relationship of the
ALCWA, SlOTs, etc., after the VU table and EDLs are built. The first SlOT on
the chain (SlOT A) represents a SYSOUT DD statement that has already been
allocated. The second SlOT on the chain (SlOT B) represents a SlOT that
requires one or more units. It is shown to have 2 volunit entries, which indicates
the total number of units that can be allocated to that SlOT. SVOLUNNO in the
SlOT contains the number of VU entries for a SlOT. (Note that the total
number of units allocated to a request can exceed the number of units requested.
Section 5. Component Analysis

5-1 77

This happens, for example, if a specifically requested volume was found to be
mounted with the permanently-resident mount attribute.}

Problem Program
JSCB

DSAB ODB

DSAB (0)

TIOT

DSOFRSTP
DSOLASTP

+X'S'

TIOENTRY

JSCDSABO

+X'140'

+X'10'

DSABTIOT

UCB
TIOENTRY

r
+X'S'
DSABTIOT

Virtual Address of 1st SlOT to Allocate

JFCB

+X'9S'

1-------1'}{

+X'9C'
+X'AO'

SIt..

JFCB

JFCB>"

Figure 5-34.

5-178

Common Allocation Input

MVS Diagnostic Techniques

I

SlOT 'A' (SYSOUT)
+ X'2B' (SIOTAlCD) • X'02'
TJOT
DSABTIOT
+X'98'

AlCWA

+X'S'

SIOT1 P ( • 1st SlOT)

+X'50'

VOlUNPTR

+X'88'
+X'SC'

+X'98'

+X'AS'

I

:J

TIOENTRY

~==~

(

SIOTEDLP

1-------1

SVOLUNAD
1-------.
..
SIOTNPTR

t--------t

EDl
+X'8S'

SIOTEDlP

+X'8C'

SVOlUNAD

+X'98'

SIOTNPTR (=0)

VU entry no. 1 for SlOT 'B'
VU entry no. 2 for SlOT 'B'

Figure 5-35.

Common Allocation Control Blocks After Construction of Volunit Table and EDLs

Section 5. Component Analysis

5-179

Common allocation processing is reflected by the status of request's SlOT and
VU entries. As each VU entry requiring a unit is allocated, bit VOLALOC (bit 0
(X'80') at + 7 into the VU entry) is set on. Bit VDEVREQD (bit 2 (X'20') at + 7
into the VU entry), if on, indicates that the VU entry requires a unit. Once all
VU entries with VDEVREQD = 1 for a given SlOT are allocated and
VOLALOC= I, the SlOT is marked allocated by setting on SIOTALCD (bit 6
(X'02') at X'2B' into the SlOT).
As each unit is allocated to a request, that allocation is reflected in (I) the unit's
UCB by setting UCBALOC (bit 4 (X'08') at + 3 in the UCB) on, and in (2) the
request's TIOT entry by placing the UCB pointer into field TIOUCBP in the
TIOT entry. (TIOUCBP is at a X'lO' into a TIOT entry for the first unit
allocated, at + X'14' for the second, etc.) The first time a VU entry for a SlOT is
allocated, a DSAB and TIOT entry are created. For subsequent VU entries
allocated to a SlOT, the DSAB and TIOT entries are updated.
ESTAE Processio2

All of allocation is protected from abends by ESTAE processing. Only one
ESTAE is issued during allocation. The batch allocation ESTAE exit routine,
IEFAB4E4, performs a retry, causing routine IEFAB4E3 to get control.
IEF AB4E3 returns to the initiator with a failure return code, causing the initiator
to fail the job. All other ESTAE exit routines percolate to the next higher level of
ESTAE protection. In a batch unallocation environment, this causes the initiator
to terminate.
When an abend occurs in a batch environment, message IEF1971 "SYSTEM
ERROR DURING ALLOCATIONjUNALLOCATION" is issued to SYSOUT
by ESTAE processing. If the abend occurs in batch allocation or a routine called
by batch allocation, such as JFCB housekeeping, message IEFI971 is issued to the
job's SYSOUT. If the abend occurs during batch unallocation, the same message
goes to the initiator's SYSOUT.
An SVC dump is always taken if an abend occurs when allocation is in control.

Unit Allocation Status Recording
Unit allocation status recording uses the control blocks in the allocation address
space (ALLOCAS) to record the use count of all units that are allocated to all
address spaces. (The count is kept in the DALTUSE fields in the DALTs.) Each
time that a unit is allocated to an address space, the use count is increased by one;
and each time that the unit is unallocated from the address space, the use count is
decreased by one. The value in the DALTUSE field represents the number of
times that a unit is currently allocated to a given address space.
By keeping count of each time that a unit is allocated to each address space:

5-180

•

When the DISPLAY U"ALLOC operator command is issued, message
IEEI061 displays allocation information which includes the jobnames and
ASIDs of each job to which the unit is allocated.

•

I( an address space is abnormally terminated, allocation can unallocate shared
units from the terminating address space. (Without unit allocation status

MVS Diagnostic Techniques

recording, allocation does not unallocate shared units from an abnormally
terminating address space.)
The control blocks in the allocation address space are created and initialized by
the allocation module IEFHB4I1 during system initialization. The control blocks
are:
ADB -

Allocation descriptor block - anchors the other control blocks in the allocation address
space.

DAIT -

Display allocation index table - contains an array of eight-byte entries starting at offset X'8'.
An entry contains an index value into the DALTs for each unit defined during system
generation and the address of the UCB for each unit. A unit address, which is the same as
the UCBNAME field in the unit's UeB, is used as the index to the unit's entry in the DAIT.
Note: If the unit address in the UCBNAME name field does not equal the unit address that
was used to index into the DAlT, then a DDR swap has occurred. In this case, the unit
address in the located UCBNAME field is used to index into the DAIT to locate the proper
entry for the unit.

DALT - Display allocation lookup table (one for each ASID) - contains an array of two-byte entries
starting at offset X'8'. An entry contains the use count for each unit that is allocated to an
address space. The index value found in the DAIT for a given unit address is used to index
into the DALT to locate the use count for the unit. Index values are used (in the DAIT) so
that the DALTs only need to contain as many two-byte use count entries as there are units
defined during initialization (rather than a maximum number of entries, 4096).
DVT -

Display allocation vector table - contains an array of four-byte entries starting at offset X'8'.
An entry contains the address to the DALT for each possible ASID in the system. An ASID
+ 1 value is used as the index into the DVT to locate the address of the DALT for a given
ASID. The DALT for ASID 000 is used by allocation to associate a use count of those units
for which allocation could not determine the ASID that allocated the unit (such as those
units that are allocated during IPL before unit allocation status recording is initialized).

Important fields in these control blocks are:
DAITUNIT DAlTUCB DVTDALT DALTUSE -

two-byte field containing the index .value into the DALTs for each unit.
four-byte field containing the pointer to the UCB for each unit.
four-byte field containing the pointer to the DALT for each ASID.
two-byte field containing the use count for each unit allocated to each ASID.

Figure 5-36 shows the control block structure of the control blocks in the
allocation address space (ALLOCAS).

Section 5. Component Analysis

5-181

Allocation address space (ALLOCAS)
JESCT

CVT'

UCB

'JEST

X'128'

CVTJESCT

X'D'

X'48'

JESALLOP

Nucleus
Private area
DAIT

ADB
'ADS'
X'4'

ADBDAIT

X'8'

ADBDVT

ma

Unit

000

~------------~

F~f

T...._____T

T'-___--'

T

T

Figure 5-36. ALLOCAS Control Block Structure

5-182

MVS Diagnostic Techniques

UCBNAME

Important fields in the JES control table (JESCT) related to allocation -status
recording are:
Offset

Length

Name

Description

X'48'

4

JESALLOP

Contains the address of the allocation descriptor block (AOB).

X'4C'

2

JESALLOA

Contains the ASIO value of the allocation address space
(ALLOCAS).

1
10 ......

JESALLOF
JESUASR

01.. ....

JESUASF

ALLOCAS flags:
Indicates that unit allocation status recording was initialized
successfully and is active.
Indicates that unit allocation status recording has failed and is
not active.

X'4E'

X'54'

4

JESAUCBS

Contains the total number of UCBs in the system.

ALLOCAS Recovery Considerations

If the allocation address space (ALLOCAS) abnormally terminates, module
IEFAB4E6 sets bit JESUASF on, sets bit JESUASR off, records the error to
SYS1.LOGREC, issues message IEFI00I, and takes an SVC dump. In this case,
allocation continues to process requests but without unit allocation status
recording.
ALLOCAS Debugging Hints

To help you debug problems with unit allocation status recording, this topic
contains procedures to determine:
•
•
•
•
•

The
The
The
The
The

UCB address corresponding to a DALTUSE field
ASID corresponding to a DALTUSE field
DAIT entry for a unit address
DVT entry for an ASID
DALT entry {DALTUSE field) for an ASID and unit address.

In the procedures that follow, use Figure 5-36 to determine the location of the
DAIT and DVT control blocks.
Figure 5-37 (5 parts) shows a sample dump of the ALLOCAS address space. The
following procedures, formulas, and examples refer to the circled letters shown on
the ALLOCAS dump. (Note that the examples indicate that a DDR swap has
occurred between unit 351 and 354.)
1.

Determining the UCB address corresponding to a DALTUSE field.

a.

Determine the address of the two-byte DALTUSE field (circle A) in the
dump. The DALTUSE field contains the use count (0005) for the unit
and begins on a halfword boundary.

b.

Determine the beginning address of the DALT (circle B) that the
DALTUSE field is part of. To do this, locate the acronym DALT
(X'C4CID3E3') that precedes the DALTUSE field.

Section 5. Component Analysis

5-183

c.

Find the index value of the DALTUSE field into the DALT by using the
formula:
Index value =

A ..(B+8) + 1
2

Where:
A is the address of the DALTUSE field
B is the address of the DALT
Example:

A71C7E-(A71918 +8) + 1
2

=

OlBO

The index value into the DALT is OlBO.
d.

Scan the DAIT (circle C) to find the DAIT entry containing the index
value (OIBO) found on step c. Find the index value of the DAIT entry
into the DAIT by using the formula:
Index value =

D-(C + 8)
8

Where:
D is the address of the DAIT entry
C is the address of the DAIT
Example:

A68190-(A666E8 + 8) = 354
8

The index value into the DAIT is 354.

Note: The index value into the DAIT is usually equal to the
UCBNAME field of the UCB representing the unit.
e.

The fullword (circle E) after the DAIT index value is the pointer to the
UCB (circle F) for the unit. In the example, the UCBNAME field (at
X'D') indicates the unit address (circle G) is 351.

Note: In th~ example, because the UCBNAME field (351) is not equal to
the index value into the DAIT (354), a DDR swap has occurred between
units 351 and 354. In the example, the DALTUSE field (at circle A)
represents the use count for unit address 351.
2.

5-184

Determining the ASID corresponding to a DALTUSE field.
a.

Determine the beginning address of the DALT (circle B) that the
DALTUSE field (circle A) is part of.

b.

Scan the DVT (circle H) to locate the entry that contains the address
(circle I) of thejDALT found on step a.

MVS Diagnostic Techniques

c.

Find the index value of the DALT entry into the DVT by using the
formula:
Index value =

I-(H + 8)
4

Where:
I is the address of the DALT entry
H is the address of the DVT
Example:

A6E714-(A6E6FO+8) = 7
4

The index value into the DVT represents ASID 7.
3.

Determining the DAIT entry for a unit address.

a.

Determine the beginning address of the DAIT (circle C).

b.

Find the address of the eight-byte DAIT entry (for an example unit
address of 354).
Entry address =,C+8+(Ux8)
Where:
C is the address of the DAIT
U is the unit address
Example: A666E8 + 8 + (354 x 8) = A68190
The address of the DAIT entry (for unit 354) is A68190.

c.

The first halfword of the DAIT entry (circle D) is the index value (OIBO)
into the DALT for the given unit address 354.

d. The second fullword of the DAIT entry (circle E) is the pointer to the
corresponding UCB (circle F) for the unit.
e.

The UCBNAME field (at X'D') in the UCB contains the UCB's unit
address.

Note: In the example, the unit address (circle G) in the UCBNAME field is
351. Because the UCBNAME field does not equal the unit address used on
step b, a DDR swap has occurred between units 354 and 351. To find the
proper DAIT entry for unit 354, repeat the procedure and use the
DDR-swapped unit address of 351 in the formula on step b. (If the
UCBNAME field is still not equal to 354, then more than one DDR swap has·
occurred; in this case, repeat the procedure again.)

Section 5. Component Analysis

5-185

4.

Determining the D VT entry for an ASlD.

a.

Find the address of the DVT entry in the DVT (circle H) for a given
ASID (for example, ASID 7) by using the formula:
Entry address = H + 8 + (Sx4)
Where:
H is the address of the DVT
S is the ASID value
Example: A6E6FO + 8 + (7 x 4)

b.

5.

= A6E714

For ASID 7, the DVT entry is at A6E714 (circle I) which contains the
DALT address A71918 (circle B).

Determining the DALT entry for an ASID and unit address.

a.

Find the DALT address for a given ASID (for example, ASID 7). See
procedure 4.

b.

Find the DALT index value into the DAIT for a given unit address (for
example, 351). See procedure 3. (Be aware of a DDR swap.)

c.

Find the address of the DALT entry (DALTUSE field) by using the
formula:
DALTUSE address = B+8+(Lx2)-2
Where:
B is the address of the DALT
L is the DALT index value
Example: A71918 + 8 + (OIBO x 2) - 2 = A71C7E

d.

Address A71C7E (circle A) is the DALTUSE field.

Note: In the examples, a DDR swap has occurred. Refer to the notes on
procedures I and 3 for additional information about howto use these procedures
when a DDR swap has occurred.

5-186

MVS Diagnostic Techniques

~

ia
u.

~
-;:a
lID

:l
too6

C>

""'"
~

>

8
(")

Fn
~

i

CIl

2
.....

o·

=
~

n

~=
(1)

=

.....

~
~
~.

fIl

Vl
I

.......
00
-l

CR1

DUMP OF ALLOCATION ADDRESS SPACE (ALLOCAS)

V005lJlJO
V005lJ60
VOOslJ80
VOOslJAO
VOOslJCO
VOOslJEO
VOOSSOO
VOOss20
VOOs540
VOOSS60
VOOss80
VOOssAO
voossco
V005sEO
VOOs600
V005620
V005640
VOOs660
VOOs680
V0056AO
VOOs6CO
VOOs6EO
VOOs700
VOOS720
V005740
V005760
VOOS780
V0057AO
VOOs7CO
V0057EO
VOOS800
V005820
VOOs8lJO
V005860
V005880
V0058AO
V0058CO
V0058EO
VOOs900
VOOs920
VOOS9lJO
VOOs960
V005980
V0059AO
V0059CO
V0059EO
VOOsAOO
VOOsA20
VOOSA40
VOOsA60
V005A80
V005AAO
VOOsACO
VOOsAEO
VOOsBOO
V005B20
VOOsB40
VOOsB60

•

-

CD -

00000000
00010100
70000700
00000000
00000000
00000700
00000000
00000000
00000600
00000000
00000000
00000600
00000000
00000000
00000600
00000000
00000000
00000600
00000000
40000000
00000500
00000000
40000000
00000500
00000000
40000000
00000500
00000000
00000000
00000500
00000000
40000000
00000500
00000000
40000000
00000500
00000000
40000000
00000500
00000000
lJOOOOOOO
00000500
00000000
40000000
00000500
00000000
00000000
00000500
00000000
00000000
00000500
00000000
00000000
00000500
00000000
00000000
00000500
00000500

Start of the UCB
UCBNAME field

00FF6808 0089FF88
F3F3F3F;l0fOF10800
00F3F5F
30502009
00FF67B, 0089FFOO
00000
00000000
04F3F
30502009
00FF67B8 0089FFOO
00000000 00000000
04F3F6F1 3050200D
00FF67B8 0089FFOO
00000000 00000000
04F3F6F3 3050200D
00FF67B8 0089FFOO
00000000 00000000
OlJF3F6F5 3050200D
00FF67B8 0089FFOO
00000000 00000000
04F3F6F7 30S0200D
00FFG7B8 OOOOFFOO
00000000 00000000
04F3F7F1 12401009
00FFG7B8 OOOOFFOO
00000000 00000000
04F3F7F3 12401009
00FF67B8 OOOOFFOO
00000000 00000000
04F3F7FS 12401009
00FF67B8 OOOOFFOO
00000000 00000000
04F3F7F7 12001008
00FF67B8 OOOOFFOO
00000000 00000000
OlJF3C1F1 12501009
00FFG7B8 OOOOFFOO
00000000 00000000
,04F3C1F3 12501009
00FF67B8 OOOOFFOO
00000000 00000000
OlJF3C1F5 12501009
00FF67B8 OOOOFFOO
00000000 00000000
04F3C1F7 12501009
00FF67B8 OOOOFFOO
00000000 00000000
04F3C2F1 11001009
00FF67B8 OOOOFFOO
00000000 00000000
04F3C2F3 12001009
00FF67B8 OOOOFFOO
00000000 00000000
04F3C2F5 12001008
00FF67B8 OOOOFFOO
00000000 00000000
OlJF3C2F8 115C1003
00FF67B8 OOOOFFOO
00000000 00000000
OlJF3C3FO 10000822
04F3C3Fl 10000822

03510000
00000500
0000E04C
03564002
00000000
0000E08C
0360lJ002
00000000
OOOOEOCC
03624002
00000000
0000E10C
03644002
00000000
0000E14C
03664002
00000000
0000E18C
03700002
00000000
0000E1CC
03720002
00000000
0000E20C
03740002
00000000
0000E24C
03760002
00000000
0000E28C
031\00002
00000000
0000E2CC
03A20002
00000000
0000E30C
03A40002
00000000
000 OE 3 f lC
03A60002
00000000
0000E38C
03A80002
00000000
0000E3CC
03B20002,
00000000
0000E40C
03B40002
00000000
0000E44C
03860002
00000000
0000E48C
03B90002
00000000
0000E4CC
0000E4EC

70000700
00000000
00010100
00000700,
00000
00000
OOOOObUO
00000000
00000000
00000600
00000000
00000000
00000600
00000000
00000000
00000600
00000000
00000000
00000500
00000000
40000000
00000500
00000000
40000000
00000500
00000000
40000000
00000500
00000000
00000000
00000500
00000000
40000000
00000500
00000000
40000000
00000500
00000000
40000000
00000500
00000000
40000000
00000500
00000000
00000000
00000500
00000000
00000000
00000500
00000000
00000000
00000500
00000000
00000000
00000500
00000000
00000000
00000000

OO'~~~~~J
F3FOD7
'04F3F5F6
00FF67B8
00000000
04F3F6FO
00FF67B8
00000000
04F3F6F2
00FFG7B8
00000000
04F3F6F4
00FF67B8
00000000
OlJF3F6F6
00FF67B8
00000000
04F3F7FO
00FF67B8
00000000
OlJF3F7F2
00FF67B8
00000000
04F3F7F4
00FF67B8
00000000
04F3F7F6
00FF67B8
00000000
04F3ClFO
00FF67B8
00000000
OlJF3ClF2
00FF67B8
00000000
OlJF3C1FlJ
00FF67B8
00000000
OlJF3C1F6
00FF67B8
00000000
04F3C1F8
00FF67B8
00000000
04F3C2F2
00FF67B8
00000000
OlJF3C2FlJ
00FF67B8
00000000
OlJF3C2FG
00FF6788
00000000
04F3C2F9
00FF67B8
00FF67B8
00F:r67B8

30502009
0189FF88
C1D20801
30502009
0089FFOO
00000000
3050200D
0089FFOO
00000000
3050200D
0089FFOO
00000000
3050200D
0089FFOO
00000000
3050200D
0089FFOO
00000000
12lJ01009
OOOOFFOO
00000000
12lJ01009
OOOOFFOO
00000000
12401009
OOOOFFOO
00000000
1200100B
OOOOFFOO
00000000
12501009
OOOOFFOO
00000000
12501009
OOOOFFOO
00000000
11501009
OOOOFFOO
00000000
12501009
OOOOFFOO
00000000
12501009
OOOOFFOO
00000000
1200100A
OOOOFFOO
00000000
12001009
OOOOFFOO
00000000
1100100A
OOOOFFOO
00000000
115C1003
OOOOFFOO
OOOOFFOO
OOOOFFOO

0000E02C
03550000
00000100
0000E06C
0357lJ002
00000000
OOOOEOAC
03614002
00000000
OOOOEOEC
03634002
00000000
0000E12C
03654002
00000000
0000E16C
0367lJ002
00000000
0000E1AC
03710002
00000000
0000E1EC
03730002
00000000
0000E22C
03750002
00000000
0000E26C
03770002
00000000
0000E2AC
03A10002
00000000
0000E2EC
03A30002
00000000
0000E32C
03A50002
00000000
0000E36C
03A70002
00000000
0000E3AC
03B10002
00000000
0000E3EC
03B30002
00000000
0000E42C
03B50002
00000000
0000E46C
03880002
00000000
0000E4AC
03C00002
03Cl0002
03C20002

PAGE 00013

* ..................... 351.&' . . . . . . *
* .... 333001 . . . . . . . . . . . . . . . . . . . . . . *
* ..... 355.&. . . . . . < .... U30PAK . . . . . . *
* .................... 356.&. . . . . . "-*
* ............................... *
* ..... 357.& . . . . . . . . . . . . . . . . . . . . . . *
* ............. - ...... 360.& . . . . . . *
* ............................. / .*
* ..... 361.&. . . . . . . . . . . . . . . . . . . . . . . *
*..............

. . . . . . 362. &. . . . . . . *

* ............................... *

* ..... 363.&. . . . . . . . . . . . . . . . . . . . . . . *
* .................... 36lJ.&. . . . . . . *
* ............................... *
* ..... 365.&. . . . . . < . . . . . . . . . . . . . . . . *
* .................... 366.&. ..... "-*
* ............................... *
* ..... 367. &. . . . . . . . . . . . . . . . . . . . . . . *
* ..................... 370 . . . . . . . *
* ............................... *
* ..... 371. . . . . . . . . . . . . . . . . . . . . . *

* ..................... 372 . . . . . . . *
* ............................... *
* . . . . . 373 . . . . . 5 . . . . . . . . . . . . . . . . *
* ............................... *
* ..... 375 . . . . . 5< . . . . . . . . . . . . . . . *
* ..................... 376 . . . . . . 57.*
* ................................ *
* ..... 377 . . . . . . 5 . . . . . . . . . . . . . . . . . *
* ..................... 3AO.& .... 5.*
* ............................... *

* ..................... 374 . . . . . 5.*

* . . . . . 3A1.&. .... 5 . . . . . . . . . . . . . . . . *
* . . . . . . . . . . . . . . . . . . . . . 3A2.&. .... 5.*
* ............................... *
* . . . . . 3A3.& .... T . . . . . . . . . . . . . . . . *
* ..................... 3AlJ.&. .... T.*
* ............................... *
* ..... 3A5.&. .... T< . . . . . . . . . . . . . . . *
* ..................... 3A6.&. .... T"-*
* ............................... *
* ..... 3A7.&. .... T . . . . . . . . . . . . . . . . *
* ..................... 3A8. &. .... T. *

* ............................... *
* ..... 3B1 . . . . . . T . . . . . . . . . . . . . . . . . *

* ..................... 3B2 . . . . . . T.*
* ................................ *
* . . . . . 3B3 . . . . . . U . . . . . . . . . . . . . . . . . *
* ..................... 3BlJ . . . . . . U.*
* ................................ *

* ..... 3B5 . . . . . . U< . . . . . . . . . . . . . . . . *
* . . . . . . . . . . . . . . . . . . . . . 3B6 . . . . . . U"-*
* ................................. *
* ..... 3B8.* .... U . . . . . . . . . . . . . . . . . *
* . . . . . . . . . . . . . . . . . . . . . 3B9.* .... U.*

* ................................ *

* . . . . . 3CO . . . . . . U . . . . . . . . . . . . . . A .. *
* ..... 3C1 . . . . . . U . . . . . . . . . . . . . . B .. *

R005lJ40
R005lJ60
ROOSlJ80
ROOS4AO
R005lJCO
ROOS4EO
ROOSSOO
R005520
ROOSS40
ROOS560
R005580
R0055AO
R0055CO
ROOS5EO
R005600
R005620
ROOS6lJO
ROOS660
R005680
R0056AO
R0056CO
ROOS6EO
R005700
ROOS720
R005740
ROOS760
ROOS780
ROOS7AO
ROOS7CO
ROOS7EO
R005800
R005820
ROOS840
ROOS860
R005880
ROOS8AO
ROOS8CO
ROOS8EO
ROOS900
R005920
R005940
ROOS960
ROOS980
R0059AO
ROOS9CO
ROOS9EO
R005AOO
R005A20
R005AlJO
ROOSA60
R005A80
ROOSAAO
ROOSACO
R005AEO
R005BOO
ROOSB20
R005BlJO
ROO~B60

06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
04
04
04
OlJ
OlJ
OlJ
04
OlJ
04
OlJ
OlJ
04
04
04
04
OlJ
OlJ
OlJ
04
OlJ
OlJ
04
04
04
OlJ
OlJ
OlJ
OlJ

Vt

='':;:

I
......

00
00

u.

~

a::

~

~

~

~

i'

N

S.

'CIl

.....

O·

~

~

§
n

~.
CIl

~

j'

PAGE TABLE FOR SEGMENT

A6

0008
0008
0008
0008
0008
0008
13Dl
30C9
lDFl
1321
2E29
3389
2B49
32F9
13El
32C1
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
08004080000301C400000000
08004080000301Dl00000000
080040800003018AOOOOOOOO
080040800003018BOOOOOOOO
VA66000

00000000 00000000 00000000 00000000

VA666CO
VA666EO
VA66700
VA66720
VA66740
VA66760
VA66780
VA667AO
VA667CO
VA667EO
VA66800
VA66820
VA66840
VA66860
VA66880
VA668J1.0
VA668CO
VA668EO
VA66900
VA66920
VA66940
VA66960
VA66980
VA669AO
VA669CO
VA669EO
VA66AOO
VA66A20
VA66A40
VA66A60
VA66A80
VA66AAO
VA66ACO
VA66AEO
VA66BOO
VA66B20
VA66B40
VA66B60
VA66B80
VA66BAO
VA66BCO
VA66BEO
VA66COO
VA66C20

00000000
00A6E6FO
00020000
00060000
000]1.0000
OOOEOOOO
00120000
00160000
001AOOOO
00000000
00210000
00250000
00290000
002DOOOO
00310000
00350000
00390000
003DOOOO
00410000
00450000
00490000
004DOOOO
00510000
00550000
00590000
00500000
00610000
00650000
00690000
006DOOOO
00710000
00750000
00790000
007DOOOO
00810000
00850000
00890000
008DOOOO
00910000
00950000
00000000
00000000
009AOOOO
009EOOOO

e-

~

PAGE 00006

DUMP OF ALLOCATION ADDRESS SPACE (ALLOCAS)

0005

Start of the DA IT

00000000
80A8CC FO
00001030
000010D
00001
00001
00001£/v
00001300
000013BO
00000000
000014BO
00001530
000015BO
00001630
000016BO
00001730
000017BO
00001830
000018BO
00001930
000019BO
00001A30
00001ABO
00001B30
00001BBO
00001C30
00001CBO
00001D30
00001DBO
00001E30
00001EBO
00001F30
00001FBO
00002030
000020BO
00002130
000021BO
00002230
000022BO
00002330
00000000
00000000
00002300
00002450

00000000
r4C1C9E3
00030000
00070000
OOOBOOOO
OOOFOOOO
00130000
00170000
001BOOOO
001EOOOO
00220000
00260000
002AOOOO
002EOOOO
00320000
00360000
003AOOOO
003EOOOO
00420000
00460000
004AOOOO
004EOOOO
00520000
00560000
005AOOOO
005EOOOO
00620000
00660000
006AOOOO
006EOOOO
00720000
00760000
007AOOOO
007EOOOO
00820000
00860000
008]1.0000
008EOOOO
00920000
00960000
00000000
00000000
009BOOOO
009roooo

i1

00000000
00000000
00001058
000010r8
00001188
00001208
00001290
00001330
000013EO
00001450
000014DO
00001550
000015DO
00001650
000016DO
00001750
000017DO
00001850
00001800
00001950
00001~DO

00001A50
00001ADO
00001B50
00001BDO
00001C50
00001CDO
00001D50
00001DDO
00001E50
00001EDO
00001F50
00001FDO
00002050
000020DO
00002150
000021DO
00002250
000022DO
00002350
00000000
00000000
000023FO
00002470

000000000000000000000000
08004080000301DOOOOOOOOO
080040800003018800000000
08004080000301C800000000

00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000 00000000 C1C4C240 00A666E8
00000000 00000000 00010000 00001008
00040000 00001080 00050000 000010A8
000800'00 00001120 00090000 00001148
OOOCOOOO 000011A8 00000000 000011C8
00100000 o 0 0 0 1 2 3 0 0 0 1 1 0 0 0 0 0 0 0 0 1 2 5 0
00140000 000012BO 00150000 000012EO
00180000 00001350 00190000 00001380
001COOOO 00001410 001DOOOO 00001430
001FOOOO 00001470 00200000 00001490
00230000 000014FO 00240000 00001510
00270000 00001570 00280000 00001590
002BOOOO 000015FO 002COOOO 00001610
002FOOOO 00001670 00300000 00001690
00330000 000016FO 00340000 00001710
00370000 00001770 00380000 00001790
003BOOOO 000017FO 003COOOO 00001810
003FOOOO 00001870 00400000 00001890
00430000 000018ro 00440000 00001910
00470000 00001970 00480000 00001990
004BOOOO 000019FO 004COOOO 00001A10
004FOOOO 00001A70 00500000 00001A90
00530000 00001AFO 00540000 00001Bl0
00570000 00001n70 00580000 00001B90
005BOOOO 00001BFO OOSCOOOO 00001Cl0
005FOOOO 00001C70 00600000 00001C90
00630000 00001CFO 00640000 00001Dl0
00670000 00001D70 00680000 00001090
006BOOOO 00001DFO 006COOOO 00001El0
006FOOOO 00001E70 00700000 00001E90
00730000 00001EFO 00740000 00001Fl0
00770000 00001F70 00780000 00001F90
007BOOOO 00001FFO 007COOOO 00002010
007FOOOO 000020700080000000002090
00830000 000020FO 00840000 00002110
00870000 000021JO 00880000 00002190
008BOOOO 000021FO 008COOOO 00002210
008FOOOO 00002270 00900000 00002290
00930000 000022FO 00940000 00002310
00970000 000023700000000000000000
00000000 00000000 00000000 00000000
00980000 00002390 00990000 000023BO
009COOOO 00002410 009DOOOO 00002430
00]1.00000 00002490 00A10000 000024BO

000000000000000000000000
080040800003017800000000
080040800003018900000000
08004080000301A400000000

* ................................ *

R13DOOO 08

* . . . . . . . . . . . . . . . . . . . . . . . . ADB ... y*
* .. WO ... ODAIT . . . . . . . . . . . . . . . . . . . . *
* ................................ *
* ............... 8 . . . . . . . . . . . . . . . . *
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . H*
*....... Y . . . . . . . . . . . . . . . . . . . . . . . t *
* ................................ *

R13D6CO
R13D6EO
R13D700
R13D720
R13D740
R 1 3 D7 6 0
R13D780
R13D7AO
R13D7CO
R13D7EO
R13D800
R13D820
R13D840
R13D860
R13D880
R13D8AO
R13D8CO
R13D8EO
R13D900
R13D920
R13D940
R13D960
R13D980
R13D9AO
R13D9CO
R13D9EO
R13DAOO
R13DA20
R13DA40
R13DA60
R13DA80
R13DAAO
R13DACO
R13DAEO
R13DBOO
R13DB20
R13DB40
R13DB60
R13DB80
R13DBAO
R13DBCO
R13DBEO
R13DCOO
R13DC20

* ....................... t ........ *

* ................................ *

* ............... t ................ *
* ....................... 0 ........ *
* ............... f:. . . . . . . . . . . . . . . . . *
* ....................... 0 . . . . . . . . *
* ............... f:. . . . . . . . . . . . . . . . . *
* ....................... 0 . . . . . . . . *
* ............... E:. . . . . . . . . . . . . . . . . *
* ....................... 0 . . . . . . . . *
* ............... f:. . . . . . . . . . . . . . . . *
* ....................... 0 ........ *

* ............... f:. . . . . . . . . . . . . . . . . *
* ....................... 0.< . . . . . . *
*.< ....... + ..... f:.. I ....... E:. •••••• *
* ....................... 0 . . . . . . . . *
* ............... E:. •••••••••••••••• *
* .................•..... 0.* . . . . . . *

*.) .......•..... f:..~ ••••••• - •••••• *
*./ ..................... 0 . . . . . . . . *

* ............... f:. •••••••••••••••• *
O.~ . . . . . . *
*._ ....... > ..... E:..? ••••••••••••• *
* ....................... 0 . . . . . . . . *
* ............... t . . . . . . . . . . . . . . . . *
* ......... : ....... t ..... O.~ . . . . . . *
*., ....... =..... t." . . . . . . . . . . . . . . *
* ....................... 0 ........ *
* ............... t . . . . . . . . . . . . . . . . *
* ....................... 0 ........ *
* ................. , .....

* . . . . . . . . . . . . . . . E:. •••••••••••• , ••• *
* ....................... 0 ........ *
* . . . . . . . . . . . . . . . E:. . . . . . . . . . . . . . . . . *
* ................................ *

* ................................ *

* ............... 0 . . . . . . . . . . . . . . . . *
* . . . . . . . E:. . . . . . . . . . . . . . . . . . . . . . . . . *

08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
oS"
08
08
08
08
08
08
08
08
08
08
08
08
OS
08
08
08
08
08
08
08
08

~:::J'

~

i!.
~
UII

~

.....J

-;a
flO

~
~

C)

"""

~

~

t-C

0

n

>-

00
~

c:

i

til

(D
(')

.-+

O·

::s

~

('i
0

,g
0

::s
::s.-+
(D

>
::s
~

'<
rJ)

(;;.

Vl

......
I

00

\.0

0005

DUMP OF ALLOCATION ADDRESS SPACE (ALLOCAS)

VA66C40
VA66C60
VA66C80
VA66CAO
VA66CCO
VA66CEO
VA66DOO
VA66D20
VA66D40
VA66D60
VA66D80
,VA66DAO
VA66DCO
VA66DEO
VA66EOO
VA66E20
VA66E40
VA66E60
VA66E80
VA66EAO
VA66ECO
VA66EEO
VA66FOO

00A20000
00A60000
00A80000
OOACOOOO
OOBOOOOO
00B40000
00B80000
OOBCOOOO
OOCOOOOO
00C40000
00C80000
OOCCOOOO
00000000
00D40000
00D80000
OODCOOOO
OOEOOOOO
00E40000
00E70000
OOEBOOOO
OOEFOOOO
00F20000
00000000

VA68000
VA68020
VA68040

019EOOOO 000050E8
01A20000 000051A8
00000000 00000000

VA680EO
VA68100
VA68120
VA68140
VA68160
VA68180
VA681A0
VA681CO
VA681EO
VA68200
VA68220
VA68240
VA68260
VA68280
VA682A0
VA682CO

00000000
01A60000
00000000
01AAOOOO
00000000
"AEOOOO
01B20000.
00000000
00000000
01B60000
01BAOOOO
00000000
00000000
01BEOOOO
01C20000
00000000

00000000
00005268
00000000
00005328
00000000
00005'E.
000054A8
00000000
00000000
00005568
00005628
00000000
00000000
000056E8
000057A8
00000000

VA683EO
VA6840Q
VA68420
VA68440
VA68460
VA68480
VA684AO
VA684CO
VA684EO
VA68500
VA68520

00000000
01C60000
01CAOOOO
00000000
00000000
01CEOOOO
01020000
00000000
00000000
01D70000
00000000

00000000
00005868
00005928
00000000
00000000
000059ES
00005AA8
00000000
00000000
00005B78
00000000

VA68560

00000000 00000000

e-

a-

DAIT entry
Pointer to UCB

000024DO
00002550
00002590
00002610
00002690
00002710
00002790
00002810
00002890
00002910
00002990
00002Al0
00002A90
00002Bl0
00002B90
00002Cl0
00002C90
00002Dl0
00002D78
000020F8
00002E78
00002EFO
00000000

00A30000
00A70000
00A90000
OOADOOOO
00B10000
00B50000
00B90000
OOBDOOOO
00C10000
00C50000
00C90000
OOCDOOOO
00D10000
00D50000
00D90000
OODDOOOO
00E10000
00E50000
00E80000
OOECOOOO
OOFOOOOO
00F30000
00000000

000024FO
00002570
000025BO
00002630
000026BO
00002730
000027BO
00002830
000028BO
00002930
000029BO
00002A30
00002ABO
00002B30
00002BBO
00002C30
00002CBO
00002D30
00002098
00002E18
00002EAO
00002F18
00000000

00A40000
00000000
OOAAOOOO
OOAEOOOO
00B20000
00B60000
OOBAOOOO
OOBEOOOO
00C20000
00C60000
OOCAOOOO
OOCEOOOO
00D20000
00D60000
OODAOOOO
OODEOOOO

00002510 00A50000 00002530
00000000 00000000 00000000
000025DO OOABOOOO 000025FO
00002650 OOAFOOOO 00002670
000026DO 00B30000 000026FO
00002750 00B70000 00002770
000027DO OOBBOOOO 000027FO
00002850 OOBFOOOO 00002870
000028DO 00C30000 000028FO
00002950 00C70000 00002970
000029DO OOCBOOOO 000029FO
00002A50 OOCFOOOO 00002A70
00002ADO 00D30000 00002AFO
00002B50 00D70000 00002B70
00002BDO OODBOOOO 00002BFO
00002C50 eODFOOOO 00002C70
OOE~OOOO 00002CDO 00E30000 00002CFO
OOE60000 00002D50 00000000 00000000
00E90000 00002DB8 OOEAOOOO 000020D8
OOEOOOOO 00002E38 OOEEOOOO 00002E58
00F10000 00002EC8 00000000 00000000
00F40000 00002F40 00F50000 00002F68
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
019FOOOO 00005118
01AOOOOO 00005148 01A10000 00005178
01A30000 000051D8
00000000 00000000 00000000 00000000
00000000 00000000
0000000000000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000 00000000
01A40000 00005208 01A50000 00005238
01A70000 00005298
00000000 00000000 00000000 00000000
00000000 00000000
01A80000 000052C8 01A90000 000052F8
01ABOOOO 00005358
00000000 00000000 00000000 00000000
00000000 00000000
01ACOOOO 00005388 01ADOOOO 000053B8
01AFO'00 .0.05~01.00~000544. 0,.,0000 0000547.
01B30000 000054D8
0000000
00000000 00000000 00000000
000000000000000
ooooorA 0000000000000000 00000000
00000000 00000 1 •
01B40'
00005508 01B50000 00005538
01B70000 00005
01B80vvv 000055CS 01B90000 000055F8
01BBOOOO 000056~8
00000000 00000000 00000000 00000000
00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000
01BCOOOO 00005688 01BDOOOO 000056B8
01BFOOOO 00005718
01COOOOO 00005748 01Cl0000 00005778
01C30000 000057D8
00000000 00000000 00000000 00000000
00000000 00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000 00000000
01C40000 00005808 01C50000 00005838
01C70000 00005898
01C80000 000058C8 01C90000 000058F8
01CBOOOO 00005958
01CCOOOO 00005988 0000000000000000
00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000
00000000 00000000 01CDOOOO 000059B8
01CFOOOO 00005A18
01DOOOOO 00005A48 01D10000 00005A78
00000000 00000000
01030000 00005AD8 01D40000 00005B08
00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000
01D50000 00005B38 01D60000 00005B58
01D80000 00005B98
01D90000 00005BB8 01DAOOOO 00005BD8
00000000 00000000
00000000 0000000000000000 00000000
ABOVE LINE IS REPEATED
00000000 00000000
01DBOOOO 00005BF8 01DCOOOO 00005C28

* ............... 0 ................ *
* . . . . . . . t ...................... .. *
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0*
* . . . . . . . . . . . . . . . . . . . . . . . t ........ *
* ... : . . . . . . . . . . . . . . . . . . . . . . . . . . . 0*
* . . . . . . . . . . . . . . . . . . . . . . . t .... .... *
* .. : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0*
* . . . . . . . . . . . . . . . . . . . . . .. t ..... ... *
* . . . . . . . . . A . . . . . . . B . . . . . . . C . . . . . O*
*.D . . . . . . . E . . . . . . . F ..... e.G . . . . . . *
*.H . . . . . . . I . . . . . . . . . . . . . . . . . . . . . 0*
* . . . . . . . . . . . . . . . , ..... .. e . ....... *
* . . . . . . . . . J • . . . • . . K . . . . . . . L . . . . . 0*
*.M . . . . . . . N . . . . . . . o ..... e.p . . . . . . *
*.2 . . . . . . . R . . . . . . . . . . . . . . . . . . . . . 0*
* . . . . . . . . . . . . . . . . ; ..... . e ...... .. *
* . . . . . . . . . . . . . . . . . S . . . . . . . T . . . . . 0*
*.U . . . . . . . V . . . . . . . w.... . e ........ *
*.X . . . . . . . Y . . . . . . . Z . . . . . . . . . . . . . 2*
* ....... 8 ........................ *
* ......... 0 . . . . . . . 1 ..... H . . . . . . . . *
*.2 . . . . . 0.3 . . . . . . . 4 ..... .5 . . . . . . *
* ................................ *

PAGE 00007
R13DC40
R13DC60
R13DC80
R13DCAO
R13DCCO
R13DCEO
R13DDOO
R13DD20
R13DD40
R13DD60
R13DDSO
R13DDAO
R13DDCO
R13DDEO
R13DEOO
R13DE20
R13DE40
R13DE60
R13DE80
R13DEAO
R13DECO
R13DEEO
R13DFOO

08
08
08
08
08
OS
08
08
OS
OS
08
OS
OS
OS
OS
OS
OS
OS
08
08
08
OS
OS

* . . . . . . eY . . . . . . . . . . . . . . . . . . . . . . . . * R1DFOOO OS
* . . . . . . . . . . . . . . . 2 . . . . . . . . . . . . . . . . * R1DF020 OS
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R1DF040 08
* .. '" . . . . . . . . . . . . . . . . . . . . . . . . . . . *
* ................................ *
* . . . . . . . . . . . . . . . . . . . . . . . H . . . . . . . 8*
* ................................ *
* ................................ *

* ............... 2 ................ *
* . . . . . . . . . . . . . . . . . . . . . . . . . '" .... *
* ................................ *
* . . . . . . . . . . . . . . . . . . . . . . . H . . . . . . . 8*
* ................................ *
* ................................ *
* ................................ *
* ....... Y . . . . . . . . . . . . . . . . . A . . . . . . *
*.B . . . . . . . C . . . . . 2 . . . . . . . . . . . . . . . . *
* ................................ *

R1DFOEO
R1DF100
R1DF120
R1DF140
R1DF160
"DF'.'
R1DF1AO
R1DF1CO
R1DF1EO
R1DF200
R1DF220
R1DF240
R1DF260
R1DF280
R1DF2AO
R1DF2CO

08
08
08
08
08
O.
08
08
08
08
08
08
OS
OS
08
08

* . . . . . . . . . . . . . . . . . D. . . . . . . E . . . . . . *
*.F . . . . . . . G . . . . . . . H ..... H.I ..... S*
* ................................ *
* .................. , ............. *
* .................. , ............. *
* . . . . . . . Y. . . . . . . . . . . . . . . . . J . . . . • . *
*.K . . . . . . . . . . . . . . . L ..... 2.M .... $.*
* ................................ *
* . . . . . . . . . . . . . . . . . N .... $ .. 0 .... $.*
*.P .... $ .. 2 .... $ .. R .... $ . . . . . . . $2*
* ................................ *

R1DF3EO
R1DF400
R1DF420
R1DF440
R1DF460
R1DF480
R1DF4AO
R1DF4CO
R1DF4EO
R1DFSOO
R1DF520

08
08
08
08
08
08
OS
08
08
08
08

* ...................... $S . . . . . . *.*

R1DF560 08

* ....... 1 . . . . . . . . . . . . . . . . . . . . . . . . •

~

VI

I
1--0

(JQ

\0
0

=
~

~

......

VA69A60
VA69A80
VA69AAO
VA69ACO
VA69AEO
VA69BOO
VA69B20
VA69B40

00000000
021.40000
02A80000
00000000
00000000
02ACOOOO
02BOOOOO
00000000

e
....

VA69CEO
VA69DOO

00000000 00000000 00000000
00000000 00000000 00000000

.

-<

~
SID

...

tJ

~.

(JQ

~

::s
0
fI)

g.

DUMP OF ALLOCATION ADDRESS SPACE (ALLOCAS)
021.00000 000080CO 021.10000 000080FO
00000000 00000000 00000000 00000000

Yl
W

CI'.l

0005
VA69AOO
'VA69A20

00000000
00008190
00008270
00000000
00000000
00008350
00008430
00000000

00000000
02A50000
02A90000
00000000
00000000
02ADOOOO
02B10000
00000000

Yl

~

~

VA69EEO
VA69FOO

00000000 00000000 00000000
00000000 00000000 00000000

0

>
~

VA69FEO
VA6EOOO

00000000 00000000 00000000
00000000 00000000 00000000

0

VA6E6EO
VA6E700
VA6E720
VA6E740
VA6E760
VA6E780
VA6E7AO
VA6E7CO
VA6E7EO
VA6ESOO

00000000
00A6F604
00A72E2.
001.76644
00A79E64
00A7D684
001.80E1.4
00AS46C4
00AS7EE4
00000000

VA6EC40
VA6EC60

00030000 00000000 00000000
00000000 00000000 00000000

VA6ECCO
VA6ECEO

00000000 ·00000000 00000000
00000000 00000000 00000000

VA6EFOO
VA6EF20

C4C1D3E3 00000000 00000000
00000000 00000000 00000000

VA6FOOO

00000000 00000000 00000000

VA6F240
VA6F260

00000000 00000000 00000000
00000000 00000000 00000000

VA6F3CO
VA6F3EO

00000000 00000000 00000000
00000000 OOOOOOO~ 00000000

VA6F600
VA6F620

00000000 C4C1D3E3 00000000
00000000 00000000 00000000

VA6FSOO

00000000 00000000 00000000

VA6FDOO
VA6FD20

00000000 00000000 C4C1D3E3
00000000 00000000 00000000

CD

=-

::s
.0'
s=
CD

~

n
>
r:n

fI)

t::I

=
a

~

.. -

o-

....

00000000
00A6FD08
OOA73528
00A76D48
00A7A568
00A7DD88
00A815A8
00AS4DCS
00A8S5ES
00000000

Start of the DVT
Address of the DA L T

00000000
00A7040C
00.73e2e
00A7744C
00A7AC6C
00A7E48C
001.81C1.C
00A854CC
001.S8CEC
00000000

00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000
02A20000 00008120 02A30000 00008158
000081C8
021.60000 00008200 02A70000 00008238
000082A8
00000000 00000000 00000000 00000000
00000000
00000000 00000000 00000000 00000000
00000000
02AAOOOO 000082EO 02ABOOOO 00008318
00008388
02AEOOOO 000083CO 02AFOOOO 000083F8
00008468
00000000 00000000 00000000 00000000
00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000
02B20000 000084AO 00000000 00000000
00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000
00000000 00000000 02B30000 000084C8
00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000
02B40000 000084FO 02B50000 00008520
00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000~e.E5E3.0 00000000 00A6E7Fe 00'6EFOO
00A70B10
001.71214 00A71918 00A7201C 00A72720
00A7.330
00'7'A~OOA75138 00A7583e 00A75F'0
001.77.
00A787."
00A78958 00A7905C 00A79760
00A7B
00A7BJ
00A7C178 00A7C87C 00A7CF80
00A7EB90
00A7F:
00A7F998 00A8009C 00A807AO
00A823BO
00A82AB4 00A831B8 00A838BC 00A83FCO
00AS5BDO
00AS62D4 00AS69DS 00AS70DC 001.877EO
00A893FO
00A89AF4 00ASA1F8 00A8A8FC C4C1D3E3
00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000
00000000 00000000 00000000 00000000
00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000
00000000 00020000 00000000 00000000
00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000
00000000 00000000 00000000 00000000
00000000
00000000 00000000 00000000 00000000
ABOVE ~INE IS REPEATED
00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000 00000000 00000000 00000002
00000000
00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000
00000000 00000000 00020000 00000000
00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000
00000000 00000000 00000000 00000000
00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000 00000000 00000000 00000000
00000000
ABOVE LINE IS REPEATED
00000000
00000000 00000000 000'00000 00000000
00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED

* ............... 0 . . . . . . . . . . . . . . . . *
* ................................ *
* ................................ *

* . . . . . . . . . . . . . . . H. . . . . . . . . . . . . . . . *
* . . . . . . . . . . . . . . . . . . . ., . . . . . . . . . . . *
* ................................ *
* ................................ *
* . . . . . . . e. ..........•.••........ . 8*
* ................................ *
* ................................ *

PAGE 00010
R132AOO 08
R132A20 08
R132A60
R132A80
R132AAO
R132ACO
R132AEO
R132BOO
R132B20
R132B40

08
08
08
08
08
08
08
08

* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R132CEO 08
R132DOO. 08

* ................................ *
* ............... ~ ............... H*
* ................................ *

R132EEO 08
R 132FOO 08

* ....................... 0 . . . . . . . . *

R132FEO 08
R13EOOO 08

• . . . . . . . . . . . . . . . . DVT . . . . . . X ..... *
* .. 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
•.............................. - *
* .... "_" .. < .. ie. ........... * ... -*
* . . . . . . . . . . . %. . . . . . . . . . A ... H~ .... *
* .. 0 . . . . . . . U . . . . . . . 2 ... 9 . . . . . . . . . *

08
08
08
08
08
08
08
08
08
08

* ................................ *

"3E6EO
R13E700
.,3E720
R13E740
R13E760
R13E780
* ................................ * R13E7AO
* ... D .. (H . . . . . . $ . . . . M... Q . . . . . . . . * R13E7CO
* .. =U ... Y . . . . . . . 0 ... 4 ... 8 .... DALT* R13E7EO
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R 13E800

* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R 13EC40 08
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R13EC60 OS
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R13ECCO 08
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R 13ECEO 08
*DALT . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R13EFOO 08
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R13EF20 08

* ................................ *

R32COOO 08

* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R32C240 08
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R32C260 08
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R32C3CO 08
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R32C3EO 08
* .... DALT . . . . . . . . . . . . . . . . . . . . . . . . * R32C600 08
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R32C620 08
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R32C800 08
* . . . . . . . . DALT . . . . . . . . . . . . . . . . . . . . * R32CDOO 08
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R32CD20 08

~,

~

"
~

0005

DUMP OF ALLOCATION ADDRESS SPACE (ALLOCAS)

PAGE TABLE FOR SEGMENT

3391
1331
3541
3209
32B9
2CC9
32A9
23D9
36C9
3849
2B29
34E9
3219
3809
36F9
3709
0800408000030111.500000000
08004080000301CAOOOOOOOO
08004080000301AFOOOOOOOO
08004080000301C500000000
08004080000301C600000000
08004080000301C700000000
08004080000301B200000000
08004080000301A60000000~

u.

~

~
::l
u.
~

VA70000

00000000 00000000 00000000 00000000

U.

VA70400
VA70420

00000000 00000000 00000000 C4C1D3E3
00000000 00000000 00000000 00000000

VA70800

00000000 00000000 00000000 00000000

VA70BOO
VA70B20

00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000

VA71000

00000000 00000000 00000000 00000000

VA71200
VA71220
VA71240

00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000

VA71560
VA71580

00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000

VA716EO
VA71700

00000000 00000000 00000000 00040000
00000000 00000000 00000000 00000000

I"'tt

':-'

~

o
n
~
~

,g

VA71800

00000000 00000000 COOOOOOO 00000000

VA71900
VA71920

00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000

VA71C60
VA71C80
VA71CAO

00000000 00000000 00000000 00000000
00010000 00000000 00000000 00000000
00000000 00000000 00000000 00000000

VA72000
VA72020

00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000

VA72720
VA72740

C4C1D3E3 00000000 00000000 00000000
00000000 00000000 00000000 00000000

U'l

VA72800

00000000 00000000 00000000 00000000

.....
o·
::s

VA72E20
VA72E40

00000000 C4C1D3E3 00000000 00000000
00000000 00000000 00000000 00000000

g

~
(j

~o

g

::s
.....

i

f!f.
~

VI
I

~

100
~

e-

DALTUSE field

G- Start of the DALT

PAGE 00011

A7

08004080000301ADOOOOOOOO
08004080000301BOOOOOOOOO
0800408000030111.300000000
0800408000030111.700000000

00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
C4C1D3E3 00000000 00000000 00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000 C4C1D3E3 00000000 00000000
00000000 00000001 00000000 00000001
00000000 00000000 0000000000000000
ABOVE LINE IS REPEATED
00000002 00000000 00000000 00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000 00000000 C4C1D3E3 00000000
oa 0 a a a 0 0 a 0 0 0 0 0 ~O 0 0 0 0 0 0 0 0 0 0 0 00 0 0
ABOVE TT E IS REPEATED
00000000 000000. 00000000 ~0005
00000000 oooooe· 00000000 000 0000
00000000 00000000 00000000 00
0000
ABOVE LINE IS REPE.II~·D
00000000 00000000 00000000 I. lD3E3
00000000 00000000 00000000
_00000
ABOVE LINE IS REPEATED
0000000000000000 00000000 00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
ABOVE LINE IS REPEATED

08004080000301AEOOOOOOOO
080040800003018100000000
08004080000301ACOOOOOOOO
080040800003018300000000

* ................................ *
* ............ DALT . . . . . . . . . . . . . . . . *
* ................................ *
* ................................ *
* ................ DALT . . . . . . . . . . . . *
* ................................ *
* ................................ *
* .................... DALT . . . . . . . . *
* ................................ *

* ................................ *

R339000 08
R339400 08
R339420 08
R339800 08
R339800 08
R339B20 08
R 133000 Oil.
R133Z00 OA
R133220 OA
R133240 Oil.

* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R133560 Oil.
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * R 133580 0)\

* ................................ *
* ................................ *
* ................................ *

R1336EO Oil.
R133700 Oil.
R133800 OA

* ........................ DALT .... * R133900 Oil.

*................. ............... *

R 1 33920 0 A

• . . . . • . . . . . . . • . . . . . . • • . . . . • . . . . • . • • ,33C60 01
* ................................ * R133C80 Oil.
* ................................ * R133CAO Oil.

* ............................ DALT*
* ................................ *
*DALT . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
* ................................ *
* ................................ *
* .... DALT . . . . . . . . . . . . . . . . . . . . . . . . *
* ................................ *

R354000 Oil.
R354020 OA
R354720 OA
R354740 Oil.
R354800 08
R354E20 08
R354E40 08

Debugging Hints
Hints for debugging specific problem areas are described here including:
•
•
•
•
•
•
•

Allocation Serialization
Subsystem Allocation Serialization
Device Selection Problems (Non-Abend)
Address Space Termination
OBO Abend
OC4 Abend in IEFAB4FC
Volume Mount and Verify (VM&V) Waiting Mechanism

Allocation Serialization
Allocation serializes on several types of resources. This has resulted in deadlocks
between job steps when a programming change caused incorrect serialization.
Both dynamic allocation and JFCB housekeeping enqueue on data set names.
Dynamic allocation enqueues on non-temporary data set names before calling
JFCB housekeeping. JFCB housekeeping enqueues on real data set names when
it finds via LOCATE, that the specified data set name is an alias; the
fully-qualified names of GDG single requests (found via LOCATE); the individual
names in a generation data group; and the data set names of temporary, non-VIO
data sets. (The initiator enqueues all non-temporary names of JCL-specified data
sets before a job starts.) Data set names are dequeued by unallocation, either
batch or dynamic, in the last step in which the data set is referenced.
Common allocation enqueues on volume serials of all specific volume requests
except for direct-access volumes, which are either permanently resident or
reserved. This is done after the allocation of permanently resident or reserved
direct-access volumes, that is, following fixed device allocation. The volume
serials of demountable volumes allocated to non-specific volume requests are
enqueued either when the volume is allocated (if the volume is already mounted)
or when the volume is mounted (if allocation mounts and verifies it). (When
there is a nonspecific request for tape, OPEN enqueues the tape-volume serial
numbers because allocation only waits for direct-access volumes to be mounted.)
Before actually allocating a device, common allocation serializes the status of
devices by enqueuing on several resources all with the major name SYSIEFSD.
The minor names and functions serialized are as follows:

5-192

1.

Q4 - to serialize device allocation with VARY offline processing, which is
actually done by common allocation

2.

CHNGDEVS - to serialize device allocation with device unloading done by
the UNLOAD operator command and JES3

3.

DDRDA - to serialize device allocation with dynamic device reconfiguration
(DDR) processing of direct access devices and

4.

DDRTPUR - to serialize device allocation with DDR processing of tape and
unit record devices

MVS Diagnostic Techniques

These four resources are enqueued for shared use by allocation and for exclusive
use by the other functions. Within common allocation, these resources, with the
exception of Q4, are dequeued when allocation must wait on an allocation
recovery WTOR or on an allocation group.
Allocation serializes, via an internal mechanism, the processing of all devices
except direct access devices containing non-demountable (permanently mounted or
reserved) volumes. The serialization unit is an allocation group. This
serialization is done to serialize the device allocation in one address space with
that in another. Group serialization is exclusive, that is, it prevents an allocation
in a given address space from considering the same device that an allocation in
another address space is considering. All allocations serialize on groups in the
same order; this order is specified at sysgen and is represented in the csect
PREFT AB, which is part of the load module IEFEDTTB. PREFT AB is simply a
list of generic device types.
To serialize changes to a specific UCB, allocation and unallocation always obtain
the local and CMS locks before setting fields in the UCB.
Dynamic allocation serializes with itself so that only one dynamic allocation may
proceed in an address space. This is done by an enqueue for exclusive use on
major name SYSZTIOT, the minor name consisting of the 2-byte ASID and
4-byte address of the DSAB QDB.
Subsystem Allocation Serialization

Allocation does not serialize when processing subsystem data set requests, but
provides the capability whereby a subsystem may serialize its own requests if it so
desires. The mechanism to do this is the subsystem allocation sequence table
(SAST). A skeletal SAST is built during subsystem interface initialization to
define the order in which subsystems are to be invoked for the allocation of
subsystem data sets. During common allocation processing the subsystem
requests are sorted by subsystem. Using the sequence defined by the SAST, all
requests for a given subsystem are passed to that subsystem for allocation before
the next subsystems requests are processed. Thus a subsystem can serialize its
alloca tion processing in order to prevent deadlocks.
Device Selection Problems (Non-Abend)

The device selection logic of common allocation is heavily dependent on the
eligible devices table (EDT) which is built at SYSGEN. The EDT describes the
unit eligibility of any unit name that may be specified either via JCL or dynamic
request. Users have in the past tried to modify the EDT without doing either a
full or an I/O SYSGEN. Modification of the EDT can result in incorrect
allocation, for example, allocation of a 3330 request to a 2314, or failure of a .
request or job step with no error indicated. If such a device selection error occurs
after modification of an EDT, the modification is suspect and should be carefully
verified by consulting the EDT descriptions in the OS/VS2 System Logic Library
section on Data Areas, and/or EDT mapping in Data Areas (microfiche), via
mapping macro IEFZB421.

Section 5. Component Analysis

5-193

EDT Verification Routine

The eligible device table (EDT) can be verified by using the EDT verification
routine IEFEB400. This module compares the EDT against the DCBs for a given
system. The routine must execute on the system with the DCBs to be compared.
For teleprocessing devices, only the device class is verified. For additional
information about the EDT verification routine, refer to Job Management and

System Generation.
Address Space Termination

When an address space is being abnormally terminated, the allocation
end-of-memory resource manager, IEFAB4E5, gets control. This routing releases
any allocation groups held by the address space and unallocates any units
allocated to the address space. In the case where the allocation address space
(ALLOCAS) is not active at the time IEFAB4E5 gets control, allocation cannot
unallocate shareable, direct access units because they might be allocated to more
than one address space.
The DCBASID field (at offset X'E') in the common DCB extension contains:
•

The ASID of the address space that is allocated to the unit, or

•

In the case of shareable direct access units, the ASID of the last address space
that allocated the unit.

Cleanup: When an allocation routine abnormally terminates, the ESTAE routine
IEFAB4ED receives control. Abnormal termination can result from an abend,
cancel, or machine check. In each case, IEFAB4ED performs recovery
processing, takes a dump (if there is a possibility that the error occurred in
allocation), and routes control to other exit routines for more specific error
recovery. If a cancel is issued during dynamic allocation, a dump is always taken
and an X'x22' or X'x3E' abend occurs.
OBO Abend

OBO abends have occurred in allocation more than once. The code is issued by
the SWA manager, which handles the reading, writing, and assigning of SWA
records. Allocation requests all these functions of the SWA manager. Two
situations cause allocation to receive a OBO abend from the SWA manager:

5-194

1.

The address of a SWA record to be read or written, in behalf of allocation,
has been overlaid. Allocation usually obtains a SWA virtual address (SVA)
to read or write from another SWA record. When such an SVA has been
overwritten by a scheduler sub-component, a OBO abend may occur.

2.

A OBO abend will occur when allocation assigns an SVA for a record and then
uses the SVA to attempt to read the record without first having written the
record.

MVS Diagnostic Techniques

OC4 Abend in IEFAB4FC

This error always occurs when the device type in a UCB is changed from one
generic type to another, and when a JCL statement or dynamic request specifies
that particular unit. This error is usually the result of an improper IOGEN or the
zapping of the EDT or UCB.
This error can be diagnosed by running the EDT verification routine (IEFEB400).
//EDT JOB
//VERIFY EXEC PGM=IEFEB400
//EDT DD DSN=SYS1.LPALIB,DISP=SHR
//SYSPRINT DD SYSOUT=A
Volume Mount and Verify (VM&V) Waiting Mechanism

Volume mount and verify must wait for direct access volumes to be mounted so
that the labels can be verified, and so that allocation can enqueue the volume
serials for non-specific volume requests and obtain space (for new data set
requests). In order to allow for several allocations to be waiting simultaneously,
the control block structure shown in Figure 5-38 is set up by VM&V.
Each address space waiting for at least one direct access volume to be mounted
has its own mount verification control area (MVCA), MVCA extension
(MVCAX), one or more mount entries, and, in each mount entry, one or more
UCB entries. Each MVCAX contains an ECB. When an allocation is waiting for
a direct-access volume to be mounted, VM&V waits for this ECB in behalf of the
allocation. The MVCA chain is anchored in the allocation/termination
communication area (ATCA) in the nucleus. The ATCA is pointed to by location
CVTQMWR in the CVT. All devices on which allocation waits for a device end
(volume mount), will have the scheduler attention table index placed in their
UCBs (at + 3 in the common UCB extension). The index is X'OC'.
Any destruction of the MVCA/MVCAX structure causes one or more allocations
to wait "permanently." The wait is not truly permanent, however, because VM&V
also waits for (in a batch environment) the cancel ECB (in the CSCB-command
scheduling control block), which is posted when the operator cancels a job. In a
dynamic environment, VM&V waits for a WTOR ECB, in which case the
operator can, via reply, cancel the single mount but not the job.

Section 5. Component Analysis

5-195

ATCA

Nucleus

Memory A (Subpool 230)

o

Dev End DCB

4

8

....--------t

1-------1
C

Device Entries

o

Device Entries
1-------1

4

8

1------.. .
t-------V'

C

Mount Entry

ot - - - - - - - - t
4
8

t--------t
t--------I

C

Figure

5-196

5-38.

VM& V Control Block Structure

MVS Diagnostic Techniques

Allocation/Unallocation Reason Codes
The reason codes listed here are divided into three groups:
•

Reason codes set by batch and common allocation modules and by JFCB
housekeeping modules.

•

Reason codes set by unallocation modules.

•

Reason codes set by dynamic allocation modules.

Common and Batch Allocation and JFCB Housekeeping Reason Codes
The reason codes set by common and batch allocation and by JFCB housekeeping
are divided into step-related reason codes and DO-related reason codes.
The following are DO-related error reason codes set by allocation and JFCB
housekeeping modules and placed in the SIOTRSNC field of the SlOT. The
reason codes serve as an index into message module IEFBB4M3. The prologue of
IEFBB4M3 lists the modules which detect the error conditions.
Reason
Code
1
2
3
4
5
6
7
8
9
10

~

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

Error
Reason Code
1700
0244
0210
020C
0458
0214

*
021C
0480
0224
0398
4714

*
*
*

47A8
47AC

*

reserved
039C
0228
4704
4708
470C
4710
4714
4718

*
*
*
*
*

4734
4838
reserved
4740

Message

Meaning

IEF2l21
IEF3711
IEF2lll
IEF21 11
IEF365I
IEF7021
IEF221I
IEF210I
IEF195I
IEFt921
IEF1941
IEF2461
IEF72l1
IEF3721
IEF3181
IEF719I
IEF720I
IEF6881

Data set not found.
Telecommunication device is not accessible.
Unable to .ENQ on data set name.
Unable to ENQ on data set name.
Referenced data set name is GDG ALL.
Unable to allocate.
Invalid backward reference to a step.
Invalid UNIT parameter.
Maximum number of devices for statement exceeded.
Not enough eligible devices.
Volume sequence number incorrect.
Insufficient space on storage volumes.
Protection conflict in ISAM requests (SU 32 only).
VOL = REF to unresolved DD.
UNIT = AFF to new direct access data set.
Data set previously defined (SU 32 only).
User not authorized to define this data set (SU 32 only).
Nullfile and DSNAME conflict in ISAM concatenation.

IEF2451
IEF4741
IEF2531
IEF2S41
IEFI93I
IEF2561
IEF2571
IEF258I
IEF260I
IEF2611
IEF262I
IEF2631
IEF2641
IEF266I
IEFI40I

Inconsistent unit name and volser.
Unit or volume in use by system task.
Duplicate data set name on direct access volume.
Insufficient space in VTOC.
Space not obtained because of I/O error.
Absolute track not available.
Space requested not available.
Invalid record length in SPACE parameter.
Incorrect DSORG or DISP.
No prime area request for ISAM data set.
Prime area must be requested before overflow area.
Space request not on cylinder boundary.
Duplication of DSNAME element.
Invalid JFCB or partial DSCB pointer.
Directory space request too large.

IEF273I

Invalid user label request.

* ~ means that the error cannot be set in dynamic allocation.
Section 5. Component Analysis

5-197

37
38

reserved
474C

39
40
41
42
43
44
45
46
47
48

*
*
*
*
*
*
*

476C

*

4780

49
50
51
52
53
54
55
56
57
58

*
*
*

035C
0390
0394

*

0218
0494
022C

59
60
61
62
63
64

0214
0220
4794
4798
479C

*

IEF127I
IEF128I
IEF129I
IEF130I
IEF1311
IEF132I
IEF133I
IEF134I
IEF135I
IEF136I
IEF267I
IEF145I
IEFI411
IEF143I
IEF366I
IEF219I
IEF286I
IEF466I
IEF704I
IEF475I
IEF467I
IEF710I
IEF476I
IEF477I
IEF478I
IEF479I

65
66

0230

*

IEF4811
IEF482I

67
68
69

0488
048C
47A4

IEF217I
IEF218I
IEF703I

70
71
72
73
74
75
76
77
78
79
80
81
82
83

0214
0240
04B8
04BC
0234

0490
17FF
022C

IEF480I
reserved
IEF7011
IEF213I
IEF687I

84
85
86
87
88
89

024C
0250
03AO
04A4
0484
7700

IEflS21
IEF752I
IEF752I
IEF752I
IEF752I
IEF752I

90

04A8

IEF753I

91

04AC

IEF754I

*
*
*

0470
046C

*

No SPACE parameter or zero space request at ABSTR
O.
Invalid request for ISAM index;
Multivolume index request.
DSNAME element wrong.
Multivolume OVFLOW request.
CYL and ABSTR conflict in SPACE parameter.
CYL and CONTIG conflict in SPACE parameter.
Subparameter wrong in SPACE parameter.
Zero primary space request.
Index area requested twice.
Space request for directory larger than primary space
request.
Space request not ABSTR for DOS volume.
Index request did not precede prime request.
Last concatenated DD card unnecessary or invalid.
Relative ODO generation number contains syntax error.
ODO group name exceeds 35 characters.
DISP field incompatible with data set name.
Unable to recover from DADSM failure.
Mounting required but not allowed.
Can't access SYSCATLG data set on CVOL.
Volume on ineligible permanently resident or reserved
device.
Units required not available - waiting not allowed.
Volumes required not available - waiting not allowed.
Data sets overlap in VTOC.
DOS split cylinder data sets overlap.
Possible VTOC error.
VTOC error on second or later volume of ISAM prime
data set.
Same unit request twice - conflicts exist.
Permanently resident or reserved volume on requested
unit.
Volume containing pattern DSCB not mounted.
Pattern DSCB record not found in VTOC.
New data set requested on DOS stacked pack format
volume.
Can't wait for offiine devices.
Requested device is a console.
MSS not initialized.
MSS select error.
More units required for demand request.
Invalid JOBCAT or STEPCAT parameters.
Invalid data set name for JOBCAT or STEPCAT.

IEF483I
IEF726I
IEF725I
IEF484I
IEF493I
IEF492I
reserved

Unauthorized requestor of subsystem data set.
Invalid destination requested.

1

Error changing allocation assignments.
Error processing cataloged data set.
Requested volume mounted on JES3-managed unit.

The req1,1est for a subsystem data
set was failed by the subsystem
attempting to allocate the request.
A SUBSYS parameter specified a subsystem which does
not support the allocation of subsystem data sets.
The subsystem requested on a SUBSYS parameter was
not operational.

* - means that the error cannot be set in dynamic allocation.

5-198

MVS Diagnostic Techniques

92

04BO

IEF7551

93

7704

IEF7561

94
95

reserved
04B4

IEF740I

96

03A4

IEF7411

97

04CO

IEF74 11

98

0258

IEF1981

99
100

47BO
47B4

IEF2741
IEF2751

101
102

025C
47B8

IEF4641
IEF2761

The subsystem requested on a SUBSYS parameter does
not exist.
A system error occurred in allocating a subsystem data
set.
Data set/volume could not be RACF protected - RACF
not active.
Protect request failed - invalid data set/ volume
specification.
Data set/volume could not be RACF protected - user
not defined to RACF.
There are not enough unrestricted devices to satisfy the
request. (Restricted devices are defined in OS/VS2
System Programming Library: System Generation
Reference.)
A request for space was rejected by the installation exit.
A request for space cannot be satisfied on any eligible
volume(s).
The device is boxed and cannot be allocated.
RACF DEFINE request with modeling and the required
model could not be found.

The following are step-related error reason codes set by allocation and JFCB
housekeeping modules in an area pointed to by the allocatiqp. work area
(ALCWA) .. With the exception of reason code l, the reason codes serve as an
index into message module IEFBB4M2. The prologue of IEFBB4M2 lists the
modules which detect the error condition. Reason code 1 is set by IEF AB469 and
is returned to dynamic allocation.
Reason
Code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

)

Error
Reason Code

023C
0204
0220

Message

0498
04AO

IEF180I
IEF7131
reserved
IEF25 11
IEF240I
IEF4851
IEF714I
IEF4731
IEF7161
IEF4911
IEF3631
IEF3641
IEF367I
IEF4651
IEF456I
IEF700I
IEF7011
IEF3611
IEF3621
IEF2021
IEF2021
IEF715
IEF7171

25

•

IEF7181

26
27
28
29
30

024C
0250
03AO
04A4
7700

IEF751I
IEF7511
IEF7511
IEF751I
IEF751I

•

0484
0238
0220
049C
0474
0248
0450
172C
1718
670C
0478
047C
0214
0490
0468

•
•
•

Meaning

Catalog not mounted.
GETMAIN error.
MSS volume not available.

I

Job cancelled.
No space in TIOT or in TCTIOT.
Volumes not available and waiting not allowed.
MSS volume not defined.
System Resources Manager error.
Unable to mount MSS volume.
Number of DDs exceeds 1635.
Not enough storage for processing cataloged data set.
Permanent I/O error processing cataloged data set.
I/O error obtaining pattern DSCB.
Unable to allocate subsystem data set.
Error issuing ESTAE macro.
Environment changed - no longer able to allocate.
Error changing allocation assignments.
Unable to allocate private catalog.
Unable to unallocate private catalog.
Step not run because of condition codes.
Step not run because of condition codes.
MSS volume inaccessible.
Specified virtual volume group (MSVGP) name does not
exist.
Space or virtual volume group (MSVGP) required for
nonspecific MSS request
The job was failed in
allocation by a subsystem
processing a request to
allocate one or more
subsystem data sets.

• - means that the error cannot be set in dynamic allocation.

Section 5. Component Analysis

5-199

Common and Batch Un allocation Reason Codes

The following reason codes are set by common and batch unallocation modules.
Reason codes 1: 2, and 4 serve as an index into message module IEFBB4M5.
Reason code 3 does not result in a message; it is returned to dynamic allocation.
Reason Code Message

2

Meaning

Module Setting

IEF468I

GETMAIN error.

IEFBB410,IEFBB414,
IEFBB416, IEFAB4AO

IEF469I

Data sets not released.

IEFAB4AO, IEFAB4A6

Volumes not released.
(Dynamic allocation only).
Step catalogs not allocated.
(Warm start only).

IEFAB4AO, IEFAB4A8

Error issuing ESTAE macro.

IEFBB410, IEFAB4AO

3
IEF724I

4

IEF456I

IEFAB4A2

In addition, IEFAB4A2 (disposition processor) receives return codes returned by
the data management catalog and scratch functions (called by IEFAB4A2 to
perform disposition processing). If the allocation is dynamic, these return codes
are returned to dynamic allocation as reason codes in a field in the unallocation
request block. For batch allocation, the return code is converted to a code for a
disposition message.
Dynamic Allocation Reason Codes

For a description of dynamic allocation reason codes, refer to the topics
"Informational Reason Codes" and "Error Reason Codes" in OSjVS2 System
Programming Library: Job Management.

5-200

MVS Diagnostic Techniques

JES2
Note to Readers
Component information for JES2 is deleted from this book because it is
duplicated in the JES2 logic book.
See the J ES2 Logic book for diagnostic information for JES2.

Section 5. Component Analysis

5-201

Subsystem Interface (SSI)
In the course of HASP/ASP installation, hooks were put into OS and SVS
operating systems to establish an interface. With the job entry subsystem (JES),
an interface was designed to eliminate the need for these hooks.
The subsystem interface (SSI) is primarily used to communicate with the job entry
subsystem (either JES2 or JES3), but is flexible enough to communicate with any
subsystem.

System Initialization Processing
At system generation, the name of the primary job entry subsystem and secondary
subsystems are listed on the SCHEDULR macro and put in the job entry
subsystem names table (CSECT IEFJESNM). Subsystems may be specified in the
subsystem names table (load module IEFJSSNT), and also, you can specify
subsystems in the IEFSSNxx members of SYSl.PARMLIB. The PARMLIB
suffixes are specified at IPL.
The master scheduler base initialization module (IEEVIPL) gives control to the
subsystem interface initialization module (IEFJSINT). IEFJSINT calls the
subsystem service routine (lEFJSBLD) to:
•

Build a subsystem communication vector table (SSCVT) for each unique
name in the JES names table and in the subsystem names table.

•

Build and initialize. the subsystem vector table (SSVT) for the master
subsystem.

•

Build the subsystem allocation sequence table (SAST) for later use in
allocating subsystem data sets.

IEFJSINT then returns control to IEEVIPL.
The job entry subsystem builds and initializes its own SSVT when the system is
initialized. All other subsystems must do likewise. A subsystem can be initialized
as follows:
•

By being started (for example: START JES2) or,

•

By having an initialization routine specified in the subsystem names table, or
in the IEFSSNxx SYSl.PARMLIB record.

Additional subsystem initialization is performed by module IEFJSIN2, which is
invoked by IEEMB860. IEFJSIN2 calls the PARMLIB read routine (IEEMB878)
to read each record from the IEFSSNxx members. All records read are passed to
the positional parse routine (IEEMB882). IEFJSIN2 also calls IEFJSBLD to
perform the following:
•

5-202

Link to the subsystem initialization routines specified in the subsystem name
table.

MVS Diagnostic Techniques

•

Build a SSCVT for each unique subsystem specified in the IEFSSNxx
members and link to the initialization routine if any is specified on the
PARM LIB- record.

•

Build a hash table containing SSCVT addresses for use in processing SSI
requests.

•

Rebuild the SAST if additional subsystems were defined in SYSI.PARMLIB.

IEFJSBLD and IEFJSIN2 call the subsystem initialization message writer
(IEFJSIMW) to issue operator messages. The text of the messages is contained in
IEFJSIMM. The following messages are detected by IEFJSBLD:
•

Message IEE7301 indicates that a duplicate subsystem was specified for an
SSCVT request.

•

Message IEE8591 is issued for each subsystem initialization routine that could
not be found.

•

Message IEF7591 indicates that a GETMAIN failed, or that an abend
occurred.

Note: It is the responsibility of the subsystem initialization routine to inform the
operator of errors and to recover from errors in the initialization routine. If the
subsystem initialization routine fails to recover from an error, message IEF759I is
issued to indicate the abend and the next subsystem is processed. The failing
subsystem might not be completely initialized.

The following messages are detected by IEFJSIN2:
•

Message IEF7581 is issued if the subsystem names table (IEFJSSNT) could
not be found, and it is issued if any IEFSSNxx members could not be found
in SYSl.PARMLIB. Message IEF7581 is also issued to indicate an abend in
IEFJSIN2 processing.

•

Message IEF7601 is issued when IEEMB882 (parse routine) finds a syntax
error in a subsystem SYS1.PARMLIB record or when IEFJSIN2finds an
invalid subsystem name.

Subsystem Interface Major Control Blocks
Subsystem interface's major control blocks are the JES control table (JESCT), the
subsystem allocation sequence table (SAST), the subsystem hash table (SHAS),
the subsystem communications vector table (SSCVT), the subsystem vector table
(SSVT), the subsystem information block (SSIB), the subsystem options block
(SSOB), and the extension to the SSOB or function dependent area. The
following table summarizes each of these control blocks.

Section 5. Component Analysis

5-203

Control
Block

Created By

Subpool

Key

Size

Pointed
ToBy

JESCT

SYSGEN

NUCLEUS

0

108 bytes

CVT

Contains information needed by
the Subsystem Interface and
addresses of Scheduler routines.

IEFJESCT

SAST

IEFJSBLD

241

0

Note 1

JESCT

Defines the order in which
subsystems will be invoked
to allocation subsystem
data sets.

IEFJSAST

SHAS

IEFJSBLD

241

0

76 bytes

JESCT

Contains a hash table of SSCVT
addresses, used by subsystem
interface to locate a specific
subsystem.

IEFSSHSH

SSCVT

IEFJSBLD

241

0

36 bytes

JESCT

Identifies each subsystem defined
to the system and 'points to the
SSVT for each subsystem.

IEFJSCVT

SSVT

Subsystem
owning the
SSVT, at
Initialization
of subsystem.

Any - determined
by the subsystem

Any

Note 2

SSCVT

Contains the indication of
functions of a subsystem and
the addresses of the routines
that perform those functions.

IEFJSSVT

SSIB

The user of
Subsystem
Interface

User's Subpool

Any

36 bytes

SSOB,
JSCB

Identifies the subsystem to the
Subsystem Interface and passes
information between the
subsystem and its caIler.

IEFJSSIB

SSOB

The user of
Subsystem
Interface.

User's Subpool

Any

20 bytes

SSWA,
IEL

The parameter for the
Subsystem Interface.

IEFJSSOB

Function
Dependent
Area

The user of
Subsystem
Interface

User's Subpool

Any

Variable

SSOB

Passes information to the function
of the subsystem the user wishes to
invoke.

IEFJSSOB

Function

Mapping
Macro

Notes:
1.

The SAST size is 8 bytes plus 12* (the number of subsystems in the SSCVT chain).

2.

The SSVT size is 260 bytes plus 4* (the number offunctions supported by the subsystem). Minimum size is 264 bytes, maximum 1284 bytes.

Control Block Usage is shown in Figure 5-39, Figure 5-40, and Figure 5-41.

5-204

MVS Diagnostic Techniques

LOC X'10'
JESCT

r
CVT

V:
X'18'

X'128' CVT JESCT-

X'1C'

'JEST'
JESSSREQ
JESSSCT
JESPJESN
,~

~-::

X'30'
X'40'

-

I------

JESSASTA f---."
JESHASH

(_ SSCVT

I)

SSCVT

l(

SSCVT

V

'SSCT'

X'O'

'SSCT'

X'4'

SSCTSCTA

X'8'

SSCTSNAM

SSCTSNAM

SSCTSNAM

X'10'

SSCTSSVT

SSCTSSVT

SSCTSSVT

C

'SSCT'
SSCTSCTA

SSCTSCTA

,SSVT

SSVT

SSVTCOD 256-byte
Function Matrix

1
X'104' SSVTRTN

]

Function Pointer
Matrix can be
Maximum 256 Words

-

SSVTRTN

SSVTRTN

~

'SHAS'
Length
of table

'SAST'
1---

Number of
slots in
table

..L

.J"

lSubsystem
Name

~

1

'MSTR'

~~

Size ofl Number of-t
SAST Entries

~

SSCVT

~~ . addresses

I I I
I
0

0

0

I

r

~

Figure 5-39. Subsystem Interface Control Block Usage

Section 5. Component Analysis

5-205

Because the hashing algorithm can produce synonyms, a synonym chain exits as
shown in Figure 5-40. Field SSCTSYN is a synonym pointer.
JESCT
'JEST'

I

JESSSCT
~~

~

JESHASH

[

-..

:1
V

~~

~~

SSCVT
SSCTSCTA

~

~
5-40.

'SSCT'
SSCTSCTA

SSCVT

SSCVT

SSCVT

'SSCT'

Figure

'SHAS'

V

8

'SSCT'
SSCTSCTA

/'
;~

~~
SSCTSYN

'SSCT'

8

~

Control Block Usage With Synonyms

Requesting Subsystem Services
To request subsystem services, a system routine enters the correct function code
(see Subsystem Interface Summary in OSjVS2 System Logic Library) in the
subsystem options block (SSOB), and the name of the desired subsystem in the
subsystem information block (SSIB). The IEFSSREQ macro is then issued,
causing control to pass to the subsystem interface routine IEFJSREQ. The
specified function code and subsystem name indicates to the interface routine the
subsystem routine to receive control.
Invoking the Subsystem Interface
Storage is acquired for the SSIB, the SSOB, and the function dependent area of
the SSOB if required. The following entries are made in the SSOB header:
SSOBID -

'SSOB'.

SSOBLEN -

The length of the SSOB header.

SSOBFUNC - The function ID of the function to be invoked.
SSOBSSIB -

The address of the SSIB or zero. Zero means that the life-of-job SSIB is to be used. Its
address is in the active JSCB, field JSCBSSIB. The request will thus be directed to the
subsystem that started the initiator under which the job is running. (See Figure 5-42).

SSOBINDV - The address of the function dependent area, or if not needed by the function, zero.

5-206

MVS Diagnostic Techniques

The following entries are made in the SSIB:
SSIBID -

'SSlB' .

SSIBLEN -

The length of the SSIB.

SSIBFLGI -

The no-SVC flag (SSIBNSVC) must be set when SVCs cannot be issued by the
subsystems invoked (such as SRB mode).

SSIBSSNM - The name of the subsystem to which the request is being made.
SSIBJBID -

(If the function requires this field.)

SSIBDEST -

(If the function requires this field.)

The entries made in the function dependent area are:
length -

The length of the function dependent area (first halfword).

*

Any fields required by the function.

Register 1

SSOB Header
'SSIB'

X'O'
X'4'

X'4'

X'S'

X'S'

X'C'

SSOBRETN

X'10'

SSOBINDV

SSIBLEN

SSIBFLG1

SSIBSSNM

}

Function
Dependent

Function Dependent Area (SSOB Extension)

1-------.. . .
1-------.. . .
Figure 5-41.

Jl ~:;:. ~.\:.

on

Type of Function

Control Block Structure for Invoking Subsystem Interface

Section 5. Component Analysis

5-207

TCB

X'B4'

TCBJSCB

JSCB

(-

X'15C' JSCBSACT X'13C'

JSCB

JSCBSSIB

~SSIB
X'O'
X'4'

Note: The active JSCB may be the
same as TCBJSCB.

X'S'

'SSIB'
SSIBlEN

I

SSIBSSNM

Figure 5-42. Finding the SSIB for a Job When SSOB Pointer is Zero

Register 1 points to a one-word parameter list which points to the SSOB. (See
Figure 5-41).
Macro IEFSSREQ is invoked which passes control to routines which handle the
Subsystem Interface request. The communications vector table (CVT) and the
JES control table (JESCT) must be mapped if IEFSSREQ is invoked.
The subsystem interface returns a code in register 15. Possible return codes are:
o4812-16 20 -

Successful completion - request went to subsystem
Subsystem does not support this function
Subsystem exists, but is not active
Subsystem does not exist
Function not completed - disastrous error
Logical error (such as invalid SSOB format, incorrect length)

The field SSOBRETN in the SSOB contains a return code from the subsystem if
the request was successful. The return code depends on the function being
invoked (see the SSOB description in the Debugging Handbook.

Logic Flow Examples
This section provides an overall logic flow from a task making a request, through
the subsystem interface to the subsystem, and then back to the task. Two
examples are described.
Notifying a Single Subsystem

1.

A task (TSOjcancel) wants to inform JES2 that a job is to be canceled.

2.

The task creates an SSOB, SSIB, and a function dependent area.
a.

5-208

MVS Diagnostic Techniques

The SSOB is filled in. A function code of 2 is used. (See OSjVS2 System
Logic Library, for a complete function code list.

b.

The SSIB is filled in. The subsystem name is JES2.

c.

The function dependent area is filled in with the necessary information
that the subsystem needs for this type of request.

3.

Macro IEFSSREQ is invoked which branches to module IEFJSREQ
(IEFJSREQ's address is in the JESCT). Register 1 points to a parameter list
which points to the SSOB.

4.

IEFJSREQ checks:
a.

Are the pointers to the SSOB and SSIB valid? No, then return with a
return code of 16 in register 15.

b. Are the formats of the SSOB and SSIB correct? No, then return with a
return code of 20 in register 15.
c.

Find the requested subsystem's SSCVT. If not found, return with a
return code of 12 in register 15.

d. Find the requested subsystem's SSVT. If not found, return with a return
code of 8 in register 15.

5.

e.

Is the requested function code valid? No, then return with a return code
of 16 in register 15.

f.

Is the requested function code supported by the requested subsystem?
No, then return with a return code of 4 in register 15.

g.

Index into the SSVT and get the address of the function routine.

h.

Branch to the function routine. Register 0 = Address of the SSCVT,
register 1 = Address of the SSOB.

Module HASPSSSM at label HOSCANC receives control. It is the function
routine" for JES2 for function code 2 (CANCEL request).
a.

Process the request and place a return code in the SSOB (SSOBRETN).

b.

Return codes for this function code are as follows:
o4812 20 24 28 -

6.

CANCEL completed.
Job name not found.
Invalid JOBNAMEjJOB ID combination.
Job not canceled - Duplicate jobnames and no job ID given.
Job not canceled - Job is on output queue.
Job ID with invalid syntax for subsystem.
Invalid CANCEL request. Cannot cancel an active TSO user or a started task.

Control is then returned to the requesting task directly from the function
routine. The task then examines register 15 and SSOBRETN and acts
accordingly.

)
Section 5. Component Analysis

5-209

Notifying All Active Subsystems

1.

A task wants to notify all active subsystems of a WTO message.

2.

The task creates an SSOB and a function dependent area. No SSIB need be
created if the task's life-of-job SSIB has the master subsystem's name (MSTR)
in it. If it does not, and that SSIB is used,· only one subsystem would be
notified. The SSOB and the function dependent area are filled in. A function
code of 9 is used. (A list of all function codes is in OSjVS2 System Logic
Library.)

3.

Macro IEFSSREQ is invoked which branches to IEFJSREQ (address is in the
JESCT). Register 1 points to a parameter list which points to the SSOB.

4.

IEFJSREQ checks:
a.

Are the pointers to the SSOB and SSIB valid? No, return with a return
code of 16 in register 15.

b. Are the formats of the SSOB and SSIB correct? No, return with a return
code of 20 in register 15.
c.

Find the requested subsystem's SSCVT. If not found, return with a
return code of 12 in register IS.

d.

Find the requested subsystem's SSVT. If not found, return with a return
code of 8 in register IS.

/
\

5.

5-210

e.

Is the requested function code valid? No, return with a return code of 16
in register 15.

f.

Is the requested function code supported? No, return with a return code
of 4 in register 15.

g.

Index into the SSVT and get the address of the function routine.

h.

Branch to the function routine. Register 0 = address of the SSCVT.
Register I = address of the SSOB.

If the SSIB contains the name of the master subsystem and the function code
is defined as a broadcast code in the master scheduler's SSVT, then module
IEFJRASP is the function routine that receives control.
a.

IEFJRASP makes a copy of the SSIB.

b.

F or each SSCVT, IEFJRASP determines if the subsystem is active by
checking for a nonzero subsystem vector table pointer (SSCTSSVT). For
each active subsystem except the master subsystem, IEFJRASP copies the
name of the subsystem into the SSIB copy and then invokes IEFSSREQ.

c.

The highest return code from the subsystems is placed in the requesting
task's SSOB, and the lowest return code from the subsystem interface is
put in register 15.

MVS Diagnostic Techniques

(

6.

Control is then returned to the requesting task directly from the function
routine. The task then examines register 15 and SSOBRETN and acts
accordingly.

•

Paging must be possible at the time subsystem interface is entered because the
code for subsystem interface may not already be paged in at the time the can
is made.

•

For the same reason, the processor must not be physically disabled.

•

The mapping macro IEFJSSVT maps the SSVT. Only the master subsystem's
SSVT matches the mapping exactly. JES2 and JES3 SSVTs have additional
material appended to the end of the area mapped by IEFJSSVT. For JES3,
the mapping macro is IATYSVT. For the contents of the JES2 SSVT, refer
to OSjVS2 JES2Logic.

•

Some functions requested at the master subsystem cause the function to be
broadcast to every active subsystem. These function codes are:

Debugging Hints

48910 14 32 50 63 -

Notify the subsystem of end-of-task.
Notify the subsystem of end-of-address space.
Notify the subsystem of a WTO message.
Notify the subsystem of an operator command.
Notify the subsystem of a delete operator message (DOM).
Notify the subsystem of a failing START command.
Notify, early, the subsystem of end-of-task.
Notify the subsystem of service processor damage.

•

If the WTO broadcast count (field UCMBRDST in the UCM) is greater than
zero, functioncodes 9 and 14 use an SSOB with the SSIB pointer containing
the address of the SSIB for the master subsystem. Otherwise, the pointer to
the SSIB is set to zero, causing the SSIB pointer in the JSCB to be used. If
the resulting SSIB is for the master subsystem, the request is given to every
active subsystem. If the SSIB is not for the master subsystem, the request is
given to only the subsystem named in the SSIB.

•

If a subsystem verification request (function code 15) is made to the master
subsystem, (field SSIBSSNM in the SSIB contains 'MSTR'), and the name in
the SSIBJBID field of the SSIB is not that of a job entry subsystem, then
upon return from the subsystem interface, field SSIBSSNM will contain the
name of the primary job entry subsystem. A job entry subsystem is defined as
a subsystem that can provide its own sysout services. This is indicated by bit
SSCTUPSS being off in the subsystem's SSCVT.

Section 5. Component Analysis

5-211

Event Notification Facility (ENF)
The event notification facility (EN F) provides a service for MVS system routines
that allows them to:
•
•
•

Signal the occurrence of an event
Listen for the occurrence of an event
Delete the listen request

A system routine that has detected a condition or performed a function (the
signaller) signals the event to ENF. Other system routines (the listeners) can
request that they receive control (at an exit routine) from ENF when the event
has occurred. A routine that is listening can also delete the request to listen.
The events that are signalled and can be listened for are:
Event

Code

Description

I

A vary online of a device is being performed.
A vary offline of a device is being performed.
A removable volume is being unloaded.
Free SQA storage that is not currently in use.
The communications task and TOD clock initialization completed.
A device pending is offline.

2
3
4
S
12

The system components (and modules) that signal and listen for these events are:
Event

Code

Signallers

Listeners

Command Processing (lEE3103D)
AJlocation (IEFAB488)

lOS (lECVDPTH)

2

AJlocation (IEFAB429)

lOS (lECVDPTH)

3

AJlocation (lEFAB494)

IXVTOC/CVAF

4

SRM (IRARMSRV)

Media Manager

S

IEEVIPL

Global resource serialization

12

AJlocation (IEF AB429)

Global resource serialization

To help you diagnose ENF problems, the following topics describe how system
routines request ENF services, the ENF control blocks, and ENF initialization
and processing.

Requests for ENF Services
A system routine makes a request to ENF by building an event parameter list

(ENFPM), calling the ENF request router (IEFENFFX), and passing the address
of the ENFPM to IEFENFFX. The address of IEFENFFX is contained in field
ENFCFMOD in the ENF control table (ENFCT).
In the ENFPM, the requesting routine specifies the type of request (signal, listen,
or delete listen), the event code, synchronous or asynchronous processing, the
address of the exit routine to receive control, and other information.

5-212

MVS Diagnostic Techniques

The format of the ENFPM is shown in Figure 5-43; a description of the fields
follows the figure.
Register 1

J
(Parameter

J
(

ENFPM

X'O

ENFPLEN

X'4

ENFPCODE

X'8

ENFPFLG

X'C
X'1 0'

ENFPQUAL

X'1 4'

ENFPSPRM

X'1 8'

ENFPTOK

X'1 C'

ENFPFLEN

1 ENFPACT
I ENFPQMSK 1 ENFPKEY I

ENFPSPL

ENFPEADR

Figure 5-43. ENF Event Parameter List (ENFPM)

The fields in the event parameter list (ENFPM) are:
Offset

Length

Name

Description

0(0)

2

ENFPLEN

Length of the parameter list

2(2)

2

ENFPACT

Request:
X'OOOl' - Signal request
X'OOO2' - Listen request
X'OO03' - Delete listen request

4(4)

4

ENFPCODE

Event code:
X'OOOOOOOl'
X'00000002'
X'000OOO03'
X'OOOOOOO4'
X'00OO0005'

A vary online of a device is being performed.
A vary offline of a device is being performed.
A removable volume is being unloaded
Free SQA storage that is not currently in use.
Communications task and TOD clock
initialization completed.
X'OOOOOOOC' - A device pending is offiine.
8(8)

lxxx xxxx
Oxxx xxxx
xxxx lxxx
9(9)

ENFPFLG
ENFPASN
ENFPFREE
ENFPQMSK

-

Flag field:
Asynchronous processing
Synchronous processing
Free signal parameter list
Qualifier mask field:
For a listen request, specifies which bytes in the qualifier field
(ENFPQUAL) are to be used during listen processing to filter
the event:
X'08'
X'04'
X'02'
X'O l'
X'OO'

- First byte
- Second byte
- Third byte
- Fourth byte
- No filtering

10(A)

ENFPKEY

Key of signal parameter list to free.

11 (B)

ENFPSPL

Subpool of signal parameter list to free.

Section 5. Component Analysis

5-213

12(C)

4

ENFPQUAL

Qualifier field:
For a signal request, ~.pecifies the qualifier bytes aSsociated
with the event.
For a listen request, specifies the qualifier bytes that must
match with the signaller's qualifier bytes in order for the
listener's exit routine to receive control. The listener
specifies which qualifier bytes are to be matched via the
ENFPQMSK field.

16(10)

4

ENFPEADR

Exit routine address:
For a listen request, specifies the address of the listener's
exit routine that is to receive control when the event is
signalled.
For a signal request, specifies the address of the signaller's
exit routine that is to receive control when all listeners of an
event have been notified and have completed processing.

20(14)

4

ENFPSPRM

For a signal request, specifies the address of a parameter list
that the signaller passes to all listeners.

24(18)

4

ENFPTOK

Token value:
For a signal request, specifies the token value to be passed
to the signaller's exit routine.
For a synchronous listen request, contains the token value
returned by ENF for the event listener element (ENFLS).
For a delete listen request, specifies the token value of the
event listener element (ENFLS) to be deleted.

28(1C)

4

ENFPFLEN

Length of signal parameter list to free.

Note: The system routines that use ENF services have agreed to pre-defined
values for some fields in the ENFPM. These are the qualifier bytes used in the
ENFPQUAL field and the content of the parameter list pointed to by the
ENFPSPRM field. To determine these values, refer to the module listings of the
signallers and listeners of events. The topic "ENF Logic Flow Examples" shows
an example of how the qualifier bytes are used.

Listen and Signal Exit Routines
When a system routine makes a listen or signal request, the routine specifies the
address of an exit routine to receive control in the event parameter list (field
ENFPEADR). ENF mainline module IEFENFNM passes control to a listen exit
routine when the specified event is signalled. When all listeners of the event have
been notified and have completed processing, and if the signaller has specified the
optional signal exit routine, IEFENFNM passes control to the signal exit routine.
ENF passes the following to a listen exit routine:

5-214

•

Register 0 contains the event code.

•

Register 1 contains the address of a fullword parameter, which contains the
address of the parameter list passed by the signaller to the listeners of the
event.

•

Register 13 contains a save area address.

•

Register 14 contains the return address.

MVS Diagnostic Techniques

ENF passes· the following to a signal exit routine:
•

Register 1 contains the address of a fullword parameter, which contains the
address of the token value specified by the signaller on its signal request.

•

Register 13' contains a save area address.

•

Register 14 contains the return address.

Exit routines are entered enabled, in system key 0, supervisor state, and with no
locks held.

ENF Control Blocks
The following control blocks are used during ENF processing. For the format of
these control blocks, refer to the Debugging Handbook, Volume 2.
ENFCT ENF control table - contains ENF-related data and addresses of ENF routines and control
blocks.
ENFVT ENF vector table - contains a pointer to the queue of listener elements (ENFLSs) for each
event code.
ENFDS ENF process table - contains the event parameter lists (ENFPMs) to be processed for
asynchronous requests.
ENFLS

ENF listener element - contains the listener's exit routine address and optional qualifying
(filtering) information for the listen request. For each listen request, ENF builds an ENFLS
on the ENFLS queue of the specified event.

Figure 5-44 summarizes the ENF control blocks and Figure 5-45 shows the
structure of the ENF control blocks.
Control
Block

Created by

Subpool

Key

Size in
Bytes

Pointed
to by

Mapping
Macro

ENFCT
ENFVT
ENFDS
ENFLS

SYSGEN
IEAVNPA7
IEAVNP47
IEFENFNM

Nucleus
231
239
241

0
0
0
0

44

Note 1
1604
28

CVT
ENFCT
ENFCT
ENFVT
ENFLS

IEFENFCT
IEENFVT
IEFENFDS
IEFENFLS

Note 1. Four bytes plus eight bytes for each event code.

Figure 5-44.

ENF Control Block Summary

Section 5. Component Analysis

5-215

CVT
CVTENFCT
Module
IEFENFFX

ENF request
router routine

'ENFC'
ENFCFMOD
50 slots for
event parameter
lists (ENFPMs)
for asynchronous
requests

ENFCVT
ENFCDS

'ENFV'
ENFVPTR

}

~------f

'ENFL'
ENFLRTN

Field repeated for
each defined event code

-..-----~

Listen
exit
routine

ENFLPTR
Next ENFLS on the
queue for this event

Figure

5-45.

ENF Control Block Structure

ENF Initialization
Module IEAVNP47 initializes ENF during nucleus initialization (NIP) processing,
which includes:
•

Initializing the ENF control table (ENFCT)

•

Creating the ENF vector table (ENFVT) for the event codes specified in the
ENFCT.

•

Creating the ENF process table (ENFDS), which is used for asynchronous
requests.

Also, the master scheduler region initialization module (IEEMB860) attaches the
ENF wait routine (IEFENFWT), which waits to process asynchronous requests.

5-216

MVS Diagnostic Techniques

ENF Processing
When a request is made for ENF services, module IEFENFFX (request router)
pre-processes the request.
If synchronous processing is requested in the event parameter list (ENFPM),
IEFENFFX calls the ENF mainline module (lEFENFNM) to process the
request.
If asynchronous processing is requested in the ENFPM, IEFENFFX stores the

ENFPM in the ENF process table (ENFDS) and posts the ENF wait routine
(IEFENFWT). IEFENFWT runs in the master address space and calls
IEFENFNM to process the request.
For a description of the program logic for the ENF modules, refer to OSjVS2
System Logic Library.
The following topics describe the return codes returned by ENF to the caller, and
show examples of logic flow.
ENF Return Codes
ENF returns the following return codes in register 15 to its caller.
Return Code
(Hex)
Dec

0
4
8
12
16
20
24
28
32
44

(0)
(4)*
(8)
(C)
(10)
(14)
(18)*
(IC)*
(20)*
(2C)

Description

The request was processed successfully.
A duplicate listen request was detected.
The ENFDS control block is full (ENF cannot process the asynchronous request).
An error was detected in the caller's event parameter list (ENFPM).
ENF is not available.
ENF is not initialized.
Storage cannot be obtained for the listen request.
An invalid token value was detected on a delete listen request.
An error occurred in the signal exit routine for a signal request.
The freemain for the signal parameter list failed.

*Returned for synchronous requests only. (For asynchronous requests, these conditions result in a zero
return code because the conditions have not yet been checked by ENF.)

ENF Logic Flow Examples
Examples of the logic flow for a signal, listen, and delete listen request are
described in the following topics.
Listen for an Event
A system routine (for example, lOS initialization) needs to listen for the "vary
online" event, and wants to limit the listen request to tape devices.
1.

The routine builds an event parameter list (ENFPM) and fills in the following
fields:
ENFPLEN

X'OOIC' (28 bytes)

ENFPACT

X'OO02' (listen request)

Section 5. Component Analysis

5-217

ENFPCODE

X'OOOOOOOI' (vary online event)

ENFPFLG

X'OO' (synchronous processing)

ENFPQMSK

X'02' (qualifier mask)

ENFPQUAL

X'00008000' (qualifier field)

ENFPEADR

address of the listen exit routine that is to receive control when the event (vary
online) occurs

ENFPSPRM

zero

ENFPTOK

zero (ENF returns the ENFLS token value in this field)

2.

The routine calls the ENF request router (IEFENFFX) with register 1
pointing to a full word parameter which points to the event parameter list
(ENFPM).

3.

IEFENFFX checks the validity of the ENFPM and, if valid, calls the ENF
mainline routine (IEFENFNM).

4.

IEFENFNM adds a listener element (ENFLS) to the listen queue for the vary
online event.

5.

IEFENFNM returns to IEFENFFX, which returns to the caller and passes
back the listen token value for the ENFLS in field ENFPTOK of the caller' s
ENFPM.

The listen exit routine (specified in field ENFPEADR) will receive control when a
vary online event occurs and the third byte of the signaller's qualifier field
matches the third byte of the listener's qualifier field (X'80'). As shown in the
next example, the signaller of the vary online event puts the UCBTYP field in its
qualifier field (where X'80' indicates a tape device). Therefore, the listen exit
routine is entered for a vary online of tape devices.
Signal an Event

A system routine (for example, vary device processing) is performing a vary online
function and signals the event to ENF. In this example, the routine puts the
UCBTYP field in the ENFPQUAL field. This allows listeners to filter their listen
requests to specific device types or characteristics.
1.

5-218

The routine builds an event parameter list (ENFPM) and fills in the
following fields:
ENFPLEN

X'OOIC' (28 bytes)

ENFPACT

X'OOOI' (signal request)

ENFPCODE

X'OOOOOOOOI' (vary online event)

ENFPFLG

X'OO' (synchronous processing)

ENFPQMSK

zero (not u.sed)

ENFPQUAL

X'02208001' (qualifier field)

MVS Diagnostic Techniques

ENFPEADR

optional (address of a signal exit routine to receive control when alllisteners
have been notified and have completed processing)

ENFPSPRM

optional (address of a parameter list to be sent to al1listeners)

ENFPTOK

optional (the token value to be passed to the signal exit routine)

2.

The routine calls the ENF request router (IEFENFFX) with register 1
pointing to a fullword parameter which points to the event parameter list
(ENFPM).

3.

IEFENFEX checks the validity of the ENFPM and, if valid, calls the ENF
mainline routine (IEFENFNM).
Note: For asynchronous processing, IEFENFFX. stores the ENFPM in the
ENFDS (process table) and posts the ENF wait routine (IEFENFWT), which
calls IEFENFNM.

4.

IEFENFNM processes the request as follows:
a.

Searches the listen queue (ENFLSs) of the vary online event and, if the
listener had specified qualifier bytes, looks for a match of the signaller's
qualifier bytes to the listener's qualifier bytes.

b. Calls each listener's exit routine and passes to each exit the event code
and, if specified, the address of the signaller's parameter list
(ENFPSPRM).

5.

c.

If a signal exit routine address was specified in field ENFPEADR of the
signaller's ENFPM, passes control, with the token value, to the signaller's
exit routine.

d.

Returns control to IEFENFFX.

IEFENFFX returns to the caller.

Delete a Listen Request

A system routine that has been listening for a specific event (such as vary online
processing) no longer needs to know when the event occurs.
1. The routine builds an event parameter list (ENFPM) and fills in the following
fields:
ENFPLEN
ENFPACT
ENFPCODE
ENFPFLG
ENFPQMSK
ENFPQUAL
ENFPEADR
ENFPSPRM
ENFPTOK

2.

X'OO 1C' (28 bytes)
X'0003' (delete listen request)
X'OOOOOOOOl' (vary online event)
X'OO' (synchronous processing)
zero
zero
zero
zero
token value of the ENFLS that ENF returned on the listen request for the event.

The routine calls the ENF request to router (IEFENFFX) with register I
pointing to a fullword parameter which points to the evetlt parameter list
(ENFPM).

Section 5. Component Analysis

5-219

3.

IEFENFFX checks the validity of the ENFPM and, if valid, calls the ENF
mainline routine (IEFENFNM).

4.

IEFENFNM processes the delete listen request as follows:

5.

a.

Searches the listen queue (ENFLS) for a matching token value for the
event code specified.

b.

Deletes the appropriate listener element (ENFLS) by marking the ENFLS
available for reuse. (See Note).

c.

Returns control to IEFENFFX.

IEFENFFX returns to the caller.
Note: If the ENFLS is in use, indicated by a use count of one or more in
field ENFLUSE, ENF sets the high-order bit (ENFLDEL) of field
ENFLUSE to one to indicate that a delete request is pending. ENF does not
call the listen exit routine for any additional signal requests to this ENFLS.
After any existing listen exit routines that are in process are serviced, ENF
marks the ENFLS available for reuse when the next signal request for the'
event is processed.

The ENFLUSE field has the following meaning:
High-order
Bit (ENFLDEL)
1
I

o
o

Remainder
ofField

o
>0
>0

o

Me~

The ENFLS has been deleted and is available for reuse.
A delete request is pending for the ENFLS.
The ENFLS is active and is in use.
The ENFLS is active but not in use.

ENF Recovery Routines
If an error occurs during ENF processing, ENF recovery routines issue the
SETRP macro (with RECORD = YES) to record errors to the SYSl.LOGREC
data set and issue the SDUMP macro to dump virtual storage.
The FRR and ESTAE recovery routines (FRRRTN and ESTAERTN) in modules
IEFENFFX and IEFENFNM put the following data in the variable recording
area (SDWAVRA) of the SDWA in a key-length format:
•
•
•
•

Component ID (BB 131)
Product level
Module footprints (FOOTPRNT)
ESTAE or FRR parameter list

The ESTAE recovery routine (ESTAEXIT) in module IEFENFWT does not put
data in theSDWAVRA.

5-220

MVS Diagnostic Techniques

Recovery Termination Manager (RTM)
The recovery termination manager (RTM) cleans up system resources when a task
m. address space terminates, either normally or abnormally.

Functional Description
Logically, RTM consists of four related processes.
1.

RTMI attempts recovery for software ,or hardware errors; it is entered via the
CALLRTM macro instruction issued by supervisory routines. Functional
recovery routines (FRRs) are processed in this logical phase.

2.

RTM2 performs normal and abnormal task termination for both system and
problem program routines. The ABEND macro (SVC 13) requests RTM2
services.

3.

Address space termination provides normal and abnormal address space
termination for supervisory routines. The CALLRTM macro instruction is
used to request this function.

4.

RTM support functions such as error recording, formatting of dumps (see
note), and creating recovery control blocks for- error exit processing.

Note: RTM generates an error id that ensures that information recorded in
SYS1.LOGREC concerning a problem, can be readily correlated with SVC dump
information concerning the same problem. See 'Error ld' later in this topic.

Work Areas
For details of RTM work areas see "Use of Recovery Work Areas for Problem
Solving" in Section 2.
Major RTMModules
RTM1, which is part of the nucleus, comprises seven modules:
1.
2.
3.
4.
5.
6.
7.

IEAVTRTI - RTM entry point processor
lEAVTRTM - RTMI mainline
lEAVTRTS - system recovery manager
lEAVTRTR - RTMI recovery routines
lEAVTRSO - RTMI subroutines
lEAVTSRI - ITERM processor
IEAVTRMC - RMGRCML preprocessor

RTM2, which resides in the link pack area (LPA), is entered via SVC 13. The
mainline for RTM2 comprises the following three modules:
1. lEAVTRT2 - initialization
2. lEAVTRTC - controller
3. IEAVTRTE - exit handler

Section 5. Component Analysis

5-221

Other important RTM2 modules are:
•
•
•
•
•
•

lEAVTAS 1 - pre-exit processing
lEAVTAS2 - post-exit processing
lEAVTAS3 - control recovery
IEAVTSKT - task termination purges
lEAVTMRM - RTM2 resource manager
lEAVTRML - installation resource manager list

Process Flow
The following charts depict the process flow for:
•
•
•
•
•
•
•

Hardware error processing
Normal end-of-task termination
Abnormal end-of-task termination
Retry
Cancel
Address-space termination
PER activation/deactivation

Hardware Error Processing
Depicted in the following diagram is the processing for a hard type machine check
in a global routine that has FRR recovery. It shows the interfaces and control
flow between the machine check handler and RTMI for both hardware error
processing and the resulting software recovery attempt by the FRR. It indicates
that software recovery continues in task mode because, in this example, the FRR
does not recover the error.
The use of extended error descriptors (EEDs) allows the LOGREC buffer to be
available for further possible machine checks and is the mechanism for passing
information to RTMI and RTM2. The information in the global system
diagnostic work area (SDWA) used by RTMI recovery was obtained from the
EEDs. RTM2 obtains an SDWA, but also uses the EEDs as its source of error
data to be passed to recovery routines.
RTMI uses the RTM processor-related work save area (WSACRTMK) to alter
the registers and the PSW that MCH reloads, thereby determining whether MCH
resumes the interrupted process (soft error), or reenters RTMI for software
recovery (or hard error).

5-222

MVS Diagnostic Techniques

Legend:

Logrec Buffer
MCH
• ProC8lling a storage
check in a global
routine that hes
esubllshad an FRR •
• Invokes RTM1 for
software repair:
CALLRTM
TYPE-MACHCK

____ Pointer

Information
about
hardware
error

_ _ ContrOl flow

~Dataflow

,

RTM1

~IEAVTRT1

01EAVTRTM

. . • Sets up environment for MACHCK
entry.

~

0.IEAVTRTH
~ • Preserve hardware
data in EED's
(RTM's internal
control blocks).

• Calls IEAVTRTH
(Hardware error
proc:euor).

EED
General purEED
pose registers,
control registers
Repair
3 and 4, and
status
PSW at time of
informaMACHCK
tion

..

.,.

I

• Call appropriate
repair routine.
• Record hardware
error to lagrec.
• Returns to caller
(MCH) with pointer
to WSACRTMK.

• Passes back pointer
to re-entry data
(stored in·

...

.........J
,.....,

W5ACRTMK).

• Establish
environment for
re~ntry to RTM in
WSACRTMK.

WSACRTMK

...

.

Registers
and PSW for
re~ntry to
RTM1

I
WSACRTMK

EEDs

~

regs and
PSW
MCH
altered
by RTM1

SDWA
,.-J\, MACHCK
rV Information

~J~=_ ~_i~;6;i~I;E;A;VT;;R;T;1;;;;;;;;=~~7~-7~~~I-E-A-v-T-R-T-M-----~~~8~-~-A-V-T-R-T-S------~
PSWfrom
WSACRTMK (causing
re-entry to RTM1 _
type MACHCK _
RE-ENTRY) for
software recovery

r

• Sets up environment
for MACHCK
re~ntry.

..

• Exits to the
dispatcher.

• Attempt system
recovery since error
(MACHCK) occurred
in a globa! routine.

FRR

.l1.

PerCOlates

• Records the error .
• Returns with a
'Continue-withtermination'
indicator

• Sets up talk for
entry to RTM2 by
altering RBOPSW.

DISPATCHER
The task is
dispatched eventually
and execute the SVC
13 which causes
RTM2 task
recovery I termination
services to be invoked.

• Routes to FRR to
_- .-.,.
attempt recovery fOr
,.
routine that suffered . . _
MACHCK.

.

~

~------------------------~~
TCB
TCBRTM12 •

SDWA

EEDs
RB

Continuewith·term.

• SVC 13

~-

Section 5. Component Analysis

5-223

Normal Task Termination

EXIT and parts of RTM2 make up this function as shown in the following
diagram. The flow shows how EXIT is entered and then reentered to complete
task termination; it also provides a perspective of RTM2 functions related to
normal termination of a task.

Legend:

Task issues SVC 3

- - - . Pointer

~---v~:J--r:J=====~A

IGC003 - EXIT

ASXB

2

\A

. . . . Control Flow

~DataFlow

a"IA.XSTCS. ~

Determine task's
eligibility for normal
task termination .
• EXit'w8s Issued by
last RB on RB queue .
• TCBEDT = zero.

\DISP

SVRB

PRB

V.,SP

Issue SVC 13 to pass
control to RTM2.

RTM2

RTM2WA
Communications are
for processing within
the RTM2 load
module.
RMPL
IEAVTSKT

1

Pass control to task termination
processor.

2

If ASXBTCBS indicates' l' task is left
in the memory - then address space
termination Is necessary. Set the task
non·dlspatchable and issue CALL RTM

Free resources via Link to ); TM2 and
user defined resource managers,
passing resource managers parameter
list (RMPL).

TYPE=MEMTERM~SCHEDULEan

SRB which Initiates address space
termination processing.

3
4

If only normal task termination, then
branch to exit prolog to get rid of
SVRB.
Free the RTM2 work area.

2

Set PRB resume psw to point to an
SVC 3 Instruction.

3

Set end-of·task indicator for exit in
TCB (TCBEOT).

4

Indicate proper control flow in RTM2
work area.
• If last task in memory, indicate
address space termination
processing.
• Not last task.

• LINK. To all Resource Managers
defined in IEAVTRML

lI_iii" To
System Resource
Managers
"'II

PRS

BRANCH

Prolog deletes SVRB

~

DISP

\
IGCOO3 - EX IT

1

IEAQSPET - IEAVGCAS

1 ... BALR
Free storage

I

BALR
IGC062Rl - IEAVEEDO

..

..

...
" 2

Since the end·of·task indicator
has been set (TCBEOT) BALR to
resource manager for cleanup of
task.

CD

CD

0
0

TRAM

•

Schedule end·of·task exit
routine for task.

•

PGM
DET

Exit to dispatcher.

SR 14
II'

Post mother task if attached
w/ECB operand.

5-224

MVS Diagnostic Techniques

..

Normal Task Termination
is Complete

..
,-

I

BALR

"

VSM

Free TCB & RB core.
• Dequeue
•EITHER TCB.
OR

..

BALA

"I

IEAVTSBP
Dequeue/Free SCB's owned by RS or
task.

I

I

IEAPPGMX

1

Free programs

1

Abnormal Task Termination

Shown in the following diagram is the logic flow during abnormal termination of
a non-critical nature. If the error is not recoverable at a particular task level, that
task and its subtasks are removed. If the scope of the abend is "Step," then the
entire job step is removed. Optionally, serviceability information (dumps and
software error records) is supplied to the user.

ABEND
TCB

(Recoverv processing

1----.J,'tt.~oObbtUaJ.ln;:.'7inniiittiialize and Queue
the RTM2 work area •
• Save a copy of the trace

t!!J11!:.... _
IEAVTRTC

RTM2WAL:::::~{f~or~f~agil~in~g~t~al~kf.)~::~
__~~
1=
IEAVTASl
PI . .ii""""~~~~-'

~-

• Valid ltv check and process
the dump options.

Contrails
returned from
IEAVTASl
optiOns.

Recorder

IEAVTRT2

resource managers •
• Update the RB queue
for exit.

normal exit

Legend
~Pointe'

. . . . . . Conlrol Flow

c::::::::::>

Data F low

Section 5. Component Analysis

5-225

Retry
Shown in the following diagram is the flow through RTM2 when processing a
potentially recoverable error. The recovery exit is supplied environmental data
that describes the error (for example, completion code, register contents, PSW,
system state at time of error) to aid in diagnosing the error. To retry, the resume
PSW in each request block (RB) up to and including the retry RB is modified.
The retry address supplied by the exit is placed in the resume PSW field of the
retrying RB, and all RBs between the retry RB and the RTM2 RB have their
resume PSW set to either exit prologue or SVC 3. To ensure that the retry
routine runs in the hoine address space, the RBOPSW S-bit is zeroed and the
ASIDs of the primary and secondary address spaces in the XSB of the retrying
RB are set to the ASID of the home address space. When R TM2 eventually
returns to the system, supervisor-assisted linkage will cause the retry address in
the retry RB to be given control.

~"~ ~J~~~r~_3_VI_.~~~~~
~D

TeB

~

- --

Legend:
• Select an exit (SCB).
• ODtain and Initiailze the SOWA.
• Perform 110 requests and block
asynchronous exits If requested.
•

~:'C~t:"EXI~ t- ----IEAVTAS2

--....Polnt.r
User exit

~ Control flow

~Dataflow

• Track the SOWA.
• Record. if requested.
• Save the dump opt/ons.

XSB
XSBSASID=home
address space ASID
XSBPASID=home
address space AS I 0

• Free the saved copy of the trace
table if available. (RTM2TRTBI'O).
• Free the RTM2 work area.
• Clear the TCB flags.
• Branch to the exit prologue.
Abnormal
exit

EAVTR T 2
Branch to
disp.tcher

'

5-226

MVS Diagnostic Techniques

Cancel

Shown in the following diagram is the flow of control through RTM when a job
is cancelled. The CANCEL request is indicated by specific completion codes set
in the TCB by RTMI (code = 'X22'). The CANCEL process is distinctive in that
it is considered a strictly unrecoverable situation. Normal termination procedures
are abandoned in favor of creating an express path through termination.
However, term exits are given control.

Lagend:
_Pointer

-+

RTM1

......... , r - - - - - - r - - - - - - ,

~

Control Flow

~DataFloW

IEAVTRT2
• Obtain, initialize and queue the
work area.
• Save a COpy of the trace table if
available.
• Process the EED's.
• SDUMP/SLIP considerations.
IEAVTRTC

• Determine tne type of dump
(SYSABEND or SYSMDUMP).
• Process tne dump data set for
current & SNAP.
• Find tne daugnters & SNAP if
not SYSMDUMP.
• Reset tne TeB flags In current
and daugnters.

~

• Set the subtasKs nondispatch able.
• Process tne subtasks and current
task. Setting abend bits,
nalting I/O and purging
resources.

IEAVTRTC
.Initialize term exit processing
until all term exits have been
entered_

_ ____ Jiiiiiiiiilliiiiiiitl1..---_...
Resource managers

• Find tne deepest subtask.
• Detacn tne subtask.
• Initiate task termination until

••••••••• :

L-~e:ac~n~su~b~ta~s~k~h~a~s~'e~x~it~e~d~'.____~............

~U;~;t~htn:e~O~~~;~e for

• Installation resource
managers.
• IBM resource
managers .

~_e_x_it_.__________________~

• Free tne.saved trace table
If available.
Exit prologue
(lEAVEEXP)
Normal exit

Section 5. Component Analysis

5-227

FORCE Command
The FORCE command is designed to remove ajob or TSO user from the system
after the CANCEL command has failed to do so. For example, a job is writing
to a DASD unit when the unit is suddenly made unavailable to the system; in this
case, the CANCEL command is frequently unable to remove the job. If
CANCEL does fail to remove the job, then FORCE can be used. However,
FORCE does not use normal termination or normal cleanup routines, and is
intended to be used only as an alternative to another IPL.
When FORCE is issued, the job's address space is terminated and any task
running in the address space is terminated. If a job is running under an initiator,
the initiator is also terminated.
FORCE processing is dependent on the recovery termination manager (RTM),
and on the command scheduling control block (CSCB), which contains a new bit
definition in CHAFORCE. When the FORCE command is entered on a console
having system authority, control is given to the CANCEL-FORCE processor
which verifies that the command syntax is correct. The processor then scans the
CSCB chain to see if the job exists and is cancelable. A bit in the job's CSCB is
then checked to see if a CANCEL has been issued for this job. If not, a call is
made to the message module to issue message IEE838I - 'CANCELABLE ISSUE CANCEL BEFORE FORCE', and control is returned to the system. If
CANCEL has been issued, a CALLRTM TYPE = MEMTERM is issued. The
message module is called to issue message IEE301I - 'FORCE COMMAND
ACCEPTED', and control is then returned to the system. If an error is found in
the command syntax, or the job was either not found or was non-cancelable, the
message module issues an appropriate message and control is returned to the
system.
The FORCE processor uses the current CANCEL serialization code. The CSCB
chain resource is serialized via ENQUEUE on SYSIEFSD QI0. Because the
holder of CSCB QIO must be non-swappable while holding the resource, the
FORCE command processor issues a SYSEVENT DONTSWAP before issuing
the ENQUEUE on QI0.
For additional information concerning the use of FORCE, see Operator's Library:
System Commands.

5-228

MVS Diagnostic Techniques

Address-Space Termination

The process of terminating an address space (memory) is one that cannot be
isolated to one task, module, or logical unit of code. The many parts of the
process, depicting control flow and data flow, are shown in the following
diagram.

BALR

Since the MEMTERM prc.c'!ss circumvents all TASK recover { and
T ASK resource manager processing.
its USe is restricted to a select group
of routines which can determine that
task recovery and resource manager
clean up is either not warranted or
will not successfully operate in the
address space being terminated.
It therefore is restricted to the
following users:
1)

PaginC) Supervisor when it detel mines th.t it cannot swap in the
LSQA for an address space.

2)

Address sPace create when It

CALLRTM
TYPE=MEMTERM
ASIO=
COMPCOO=O (normal)
+0 (abnormal)

~-"

' - -_ _..1
....\\

t:::==:J

RTCTFASB~ ASIO

7)

address space,
The RTM2 when it determines
that task reco .... ery and termination

a)

cannot take place in the current
address space;

6)

The RCT when It determines that

the address space IS permanently
deadlocked.
The RTM2 when all tasks In the
address space have terminated
(tEAVTRTE). This IS the only
requestor of normal address space
termination (that IS COMPCOD '0)

9)
10)

The auxiliary storage manaqement
recovery rout me when it suUers an
Indeterminate error from which It
cannot rec.over, while handling a
swap·ln or swap·out reQuest.
The aUXiliary storage manaqement
recovery r
WOE (fint>
WOELKPA

~

WOE

·WOETXT
(message)

r---rRE

ORE
ORELKP

hast)

~Next

I

ORE

OR EWOE
(address of
associated
WOE)

UCME (first)
UCMXB

I~

WOETXT
(message)

~Next

UCMOUTO

\

ORERPVor
OREOPBUF
(reply
buffer)

L-

.1-

UCME (last)

.... CaE
COEWQEA

••

RDCM
DCMADTRN

(

Pointan to
associated WOEs

(word 51)
COE

TDCM
DCMCXSVE

~

CXSA

1
Figure 5-47. Communications Task Control Block Structure

Section 5. Component Analysis

5-247

Debugging Hints
Hints for debugging various problems are described in this topic.
Console Not Responding to Attention
If a console is not responding to an attention interrupt, check the following:
•

The console attention processor (lEAVVCRA) may not be posting the
attention ECB (UCMAECB) in the UCM. The communications task will not
process the attention interrupt until the attention ECB is posted. This
normally occurs when the console is inactive (UCMUF indicator in the
UCME is off), a CLOSE is pending for the device (UCMCF indicator in the
UCME is on), or the device does not support interrupts (UCMIF indicator in
the UCME is off).

•

The attention processor may not be setting the attention pending indicator
(UCMAF in the UCME) on for the console causing the interrupt. It is
turned on when the attention ECB (UCMAECB) is posted.

•

If the attention pending (UCMAF) and busy (UCMBF) indicators in the
UCME are both on, the attention interrupt will not be processed until an I/O
processing complete interruption is received from the console. I/O processing
is performed by a specific device support processor (DSP). The busy
indicator (UCMBF) is turned on while the console is waiting for the
completion of an I/O operation and is turned off when the I/O completion
operation is processed.

Enabled Wait State
If the communications task is in an enabled wait state, check the following:

Normal Case: The communications task has no work to do; that is, no
communications task ECBs have been posted. Check the following ECBs (see
Figure 5-46 for descriptions and locations of the ECBs).
UCMXECB
UCMAECB
UCMOECB UCMDECB
UCMARECB UCMNPECB UCMECB

WQE Limit Reached: The system limit for WQEs or OREs has been reached
(indicated by message IEA404A).
•

Check the following fields in the UCM:
UCMWQNR - indicates the current number of WQEs in the system.
UCMWQRSV - indicates how many WQEs are reserved for WTOs being built.
UCMWQLM - indicates how many WQEs can be built.
UCMRQNR - indicates the current number of OREs in the system.
UCMRQLM - indicates how many OREs can be built.

•

Check the following indicators in the. UCM prefix:
UCMSYSI -

5-248

MVS Diagnostic Techniques

indicates that cleanup of the WQE chain is needed; that is, eliminate WQEs
marked for deletion. This indicator is checked by the'wait service
(lEAVMQWR) and device service (lEAVMDSV) routines; and it is set on by the
DOM processing (IEAVMDOM), wait service (lEAVMQWR), console queueing

fltl

~

(IEAVMWSV), multiple-line processing (IEAVMWTO), and WTO/WTOR
processing (lEAVVWTO) routines.
UCMSYSJ -

indicates that at least one message needs to lie sent to the hardcopy log.
Possibly, the WQE space is filled with WQEs (messages) that need to be sent to
the hardcopy log. This indicator is referenced by the wait service (IEAVMQWR)
and device service (lEAVMDSV) routines, and it is set on by the wait service
(lEAVMQWR) .and console switching (lEAVSWCH) routines.

UCMSYSM -

indicates a failure in a composite console. This indicator is used by the console
switching (lEAVSWCH) routine.

UCMSYSO -

indicates a dummy attention interrupt. This indicator is checked by the wait
service (IEAVMQWR) routine. It is set on by the WTO/WTOR processing
(lEAVVWTO) routine when the system log is not available and a WTL
(write-to-log) is changed to a WTO macro.

Disabled Wait State
The communications task issues only one wait state code, code 007. this code is
issued during nucleus initialization when a master console is not available to the
system. See wait state code 007 in OSjVS2 System Initialization Logic.
Messages or Replies Lost

Messages and replies can be lost or routed incorrectly if the WQE, ORE, or CQE
control blocks are not chained correctly.
•

To ensure that the WQE chain is intact, check the fOllowing:
In the UCM, check fields:
UCMWTOQ - points to the first WQE on the chain.
UCMWQEND - points to the last WQE on the chain.

In each WQE, check:
WQELPKAWQEORE-

•

points to the next WQE on the chain.
indicates that an ORE exists for this WQE.

To ensure that the ORE chain is intact, check the following:
In the UCM, the UCMRPYQ field points to the first ORE.
In each ORE, check:
ORELKPORERWQE-

•

points to the next ORE on the chain.
points to the WQE associated with this ORE.

To ensure that the CQE chain is intact, check the following:
In the UCME (for each console), the UCMOUTQ field points to the first
group of 51 CQEs.
In each group of CQEs, the CQEWQEA field in the last CQE points to
the next group of CQEs on the chain.

Section 5. Component Analysis

5-249

Note: Each CQE is one word; one byte for control bits, and three bytes
for a pointer. The CQEs are built in groups of 51. The first 50 CQEs
point to WQEs and the last points to the next group of CQEs.
In each group of CQEs, the CQEWQEA field in the first 50 CQEs point
to their associated WQEs.
In each CQE, the CQEFLAG byte contains the control bits.
No Messages on One Console
If messages are not being received on a specific console, check the following:
•

The device busy indicator (UCMBF) in the failing console's UCME may be
on. A message is not processed until an I/O processing complete interruption
is received from the console. I/O processing is performed by a specific device
support processor (DSP). The busy indicator (UCMBF) is turned on while
the console is waiting for the completion of an I/O operation and is turned
off when the I/O completion operation is processed.

•

If the console is not busy, ensure that the CQE chain for the console is intact.
(Refer to the previous topic "Messages or Replies Lost.")

•

If the CQE chain is valid, then check for unusual status in the failing
console's UCME and UCB.

Messages Routed to Wrong Console
The console queueing routine (lEAVMWSV) queues messages for specific
consoles and builds the CQE chain. If messages are routed to the wrong console,
then:
•

Ensure that the CQE chain is correct for the failing console. (Refer to the
previous topic, "Messages or Replies Lost.")

•

Check the routing codes for each console. The UCMRTCD field in each
consnWs-UCME defines the routing codes for the respective consoles.

•

Check the routing codes for the messages that are being incorrectly routed:
-

In the WTO/WTOR WQE, the WQEROUT field contains the routing
codes for the message.

-

In a major multiple-line WQE (for MLWTO), the WMJMRTC field
contains the routing codes.

Truncated Messages
If message text is being truncated (the length of the message text is shortened),
then:
•

5-250

The message may' exceed the maximum allowable bytes for console messages.

MVS Diagnostic -Techniques

•

The console operator may have requested that time stamps and/or job names
appear with the messages. Check the following indicators in the UCME for
the failing console:
UCMDISPI UCMDISPJ -

indicates 'that messages are to appear with both time stamps and job names.
indicates that only job names are to appear with messages.

Console Switching

Console -switching is performed by the lEAVSWCH routine for the following
error conditions:
•

An 1/0 error occurs on a console. The failing console's function is
automatically switched to its alternate (or, if none available, to the master
console). Check the I/O interrupt ECB (UCMECB) in the failing console's
UCME. Note that successful I/O completion is indicated by X'7F' in the first
byte of the ECB.

•

An abnormal termination in the device support processor (DSP) that services
the failing console. The failing console's function is automatically switched to
its alternate (or, if none available, to the master console). Check the
appropriate DSP in load module IGC0007B.

•

A processor failure in a multiprocessing environment as a part of alternate
CPU recovery (ACR). Consoles are switched as required. Check the
alternate CPU recovery ECB (UCMARECB) in the UCM.

Action Message Retention Facility Debugging Aids

If an error occurs in the action message retention facility, pointers to queues and
other fields are saved before they are cleared. In the UCM, the following fields
and bits are helpful in diagnosing problems.
If zero, use
this field

Meaning

UCMPAMRQ

UCMFAMRQ

Pointer to the retained message queue.

UCMPIAMQ

UCMFIAMQ

Pointer to the retained immediate action message queue.

UCMPEAMQ

UCMFEAMQ

Pointer to the retained eventual action message queue.

UCMPAMRN

UCMFAMRN

Number of messages that have been retained.

UCMPRQSD

UCMFRQSD

If on, the retained message queue was successfully scanned
before the error occurred.

UCMPIQSD

UCMFIQSD

If on, the retained immediate action message queue was
successfully scanned before the error occurred.

UCMPEQSD

UCMFEQSD

If on, the retained eventual action message queue was
successfully scanned before the error occurred.

Field at time
of error

or

UCMAMRFF

If on, the action message retention facility suffered an
error.

UCMAMRFS

If on, the action message retention facility was active at
the time of error_and an attempt to restart the facility
should be made.

Section 5. Component Analysis

5-251

UCMAMRFR

If on and -another errol' occurs in the action message
retention facility, the fields are not copied again and the
facility is not restarted.

UCMAMRFA

If on, the action message retention facility is active.

DIDoes Trace Table
A DIDOCS-trace table exists in the pageable DCM (display control module
IEETDCM) beginning at field DCMTRACE. The trace table contains the
identifiers of up to 16 of the last DIDOCSmodules to receive control on the
console represented by the pageable DCM.
After each DIDOCS module receives control, it places a two-byte identifier in the
trace table. The first byte of the identifier states whether the module is. an "E"
module such as IEECVEfA) or aIi "F" module (such as IEECVrFTA). The
second byte of the identifier is the last character in the module name. For
example, the identifier for IEECVETA is "EA" and the identifier for IEECVFTI
is "FI." (An exception to this rule occurs during DIDOCS recovery processing.
Entries to the ESTAE routine in IEECVETI are indicated by the identifier "ES.")
When DIDOCS is entered for the first time to perform an operation, the first
DIDOCS module to receive control (module IEECVETl) places two bytes of
asterisks in the trace table before it stores its identifier. The asterisks signal the
beginning of a DIDOCS operation.
DIDOeS-In-Operation Indicator
At offset X'IIF' in a console's pageable DCM (display control module
IEETDCM) is a field labeled DCMMCSST. When DIDOCS is processing, bit
DCMUSE (X'80') in DCMMCSST is set on. This bit remains on during any
SVC processing initiated by DIDOCS (SVC34, GETMAIN, FREEMAIN, and
EXCP). DIDOCS turns the bit off when DIDOCS exits (via BR14).
DIDoes Locking
DIDOCS uses two fields (CSAXB and CSAXC) in the communications extended
save area (CXSA) to control locking during DIDOCS operations.
The two fields are used as follows:
•

When the lock is available:
Field CSAXB contains the address ofthe subroutine that obtains the
lock.
Field CSAXC contains the address of a BR14 instruction.

•

After a DIDOCS module obtains the lock, the subroutine that obtains the
lock:
Sets field CSAXB to the address of a BR14 instruction.
Sets field CSAXC to the address of the subroutine that releases the lock.

5-252

MVS Diagnostic Techniques

•

After the DIDOeS module releases the lock, the subroutine that releases the
lock:
Resets field eSAXB to the address of the subroutine that obtains the
lock.
Resets field eSAXe to the address of a BRl4 instruction.

When the lock is already held by a DIDOeS module (field eSAXB contains the
address of a BRI4), any attempt by another DIDOeS module to obtain the lock
results in a no-operation (NOP).
K Q Command Debugging Aids

The K Q command processor (IEE8B03D) provides the following debugging aids
to assist you in diagnosing problems in the command processor.
FRR Work Area
The FRR work area is initialized after syntax processing is complete and
IEE8B03D is starting to execute the K Q command. The FRR work area is
initialized as follows:
4 bytes 4 bytes S. bytes 1 byte -

Module base register.
Dynamic work area of the module.
Name of the procedure in control.
ID of the last function that has executed within the procedure.

The last two items are a footprint that identifies the last function that has
executed before the error occurred. This information helps to lead you to where
the error occurred. Refer to the IEE8B03D module listing for the definitions of
the IDs and their use.
Module/Function Trace

The module dynamic area contains procedure/function trace bits. This area is
prefixed with 'TRACEBIT' in the dynamic area. Refer to the IEE8B03D module
listing for a definition of these bits and their use.
The trace bits are associated in pairs. The first bit indicates if a function was ever
entered and the second bit indicates if the function is actively being used. Both
bits are turned on when a function is entered and the second bit is turned off on
exit from it.
SYSl.LOGREC Data
When an error occurs, the SYS1.LOGREC entry is initialized with data from the
variable recording area (SDWAVRA). The data identifies the entry and locates
information contained in the module's (lEE8B03D) dynamic area. The
information is:
S bytes 8 bytes S bytes 4 bytes 4 bytes 1 byte 3 bytes -

Load module name IGCOOOJD.
Module name IEESB03D.
Footprint procedure name.
Footprint ID in the procedure.
Character header 'UCM'.
UCMFLGI flags from UCM at time of error.
Reserved (initialized to blanks)"

Section 5. Component Analysis

5-253

4 bytes 1 byte 1 byte 2 bytes 4 bytes 4 bytes 4 bytes 4 bytes 4 bytes 4 bytes 4 bytes 4 bytes 4 bytes 4 bytes 4 bytes 4 bytes 4 bytes 4 bytes -

Character header 'UCME'.
UCMSTS flag from UCME at time of error.·
UCMSDS5 flags from UCME at time of error.·
.Reserved (initialized to blanks).
UCMWLAST pointer from UCME at time of error.·
UCMMLAST pointer from UCME at thne of error.·
Character header 'LCON'.
Pointer to L = console UCME.
Character header 'RCON'.
Pointer to R = console UCME.
Character header 'MeON'.
Pointer to master console UCME.
Character header 'ICON'.
Pointer to issuing console UCME.
Character header 'CQE'.
Pointer to CQE in process.
Character header 'DBUG'.
Pointer to module trace bits.

*These fields contain Xs if cleanup had already occurred which initialized the fields.

Master Trace Debugging Aids
The master trace facility (modules IEEMB808, IEEMB809, and IEEMB816)
provides the following debugging aids to assist you in diagnosing problems in
master trace.
Copy of Master Trace Table
The communications task maintains a copy of the master trace table header in the
CSA (subpool 231). It builds a new table entry and updates the header in this
copy. Then the updated header and entry are copied into the master trace table
located in the master scheduler's address space.
MSRDAArea
The master scheduler resident data area (MSRDA) contains three bytes of status
flags that indicate checkpoints in master trace processing. The CVTMSER field
points to this data area. The fields are:
BAMTCNTL - Indicates module in control.
BAMTRECF - Notes possible error recursion.
BAMTITFL - Master trace processing flags.

FRR Work Area
Each master trace module contains data in the FRR work area. The data consists
of pointers and individual module processing flags.
Each module has two flags associated with a major function. When a major
function is entered, a flag is set on. On exit from the function, another flag is set
on. This pair of flags indicates the functions that are invoked and executed.
For IEEMB808, the FRR work area contains:
4 bytes - Pointer to the caller's parameter list.
4 bytes - Pointer to the caller's save area.

5-254

MVS Diagnostic Techniques

The module processing flags are contained in the master trace table in field
MTIPFLAG (at X'20').
For IEEMB809, the FRR work area contains:
4 bytes 4 bytes 4 bytes' S bytes -

Pointer to the caller's parameter list.
Pointer to the caller's save area.
Pointer to the module's dynamic work area.
Processing flags.

For IEEMB816, the FRR work area contains:
4 bytes
4 bytes
4 bytes
4 bytes
3 bytes

- Pointer to the caller's parameter list.
- Pointer to the caller's save area.
- Pointer to the IEEMB809 dynamic work area.
- Processing flags.
- MSRDA processing flags (described earlier).

SDWAVRA Area

In the event of an error in master trace processing, module IEEMB816 (FRR
routine) supplies the following data for the variable recording area (SDWAVRA)
in the SDWA. The information is:
•

Header for master scheduler's resident data area information - 'IEEBASEA'

•

Address of IEEBASEA.

•

Return code to be passed to the caller of master trace.

•

Reason code to be passed to the caller of master trace.

•

ComponentID - 'SCIB8'.

•

Copy of the FRR parameter area passed by the CSECT in error. (For a
description of the area, see the previous topic "FRR Work Area.")

•

Function in error - 'MTRACE'.

•

FMID.

•

Header for master trace table data area - 'IEEZB806'.

•

Address of the master trace table.

•

Address of the old master trace table.

•

Header for master trace table entry work area - 'IEEZBS06'.

•

Address of master trace table entry work area.

Section 5. Component Analysis

5-255

Recovery Management Support (RMS)
This section is divided into five parts. They contain diagnostic aids information
for the following components of recovery management support (RMS).
•

The machine check handler (MCH) - which alerts the control program of
hardware failures that affect system operation. MCR analyzes machine check
interruptiQns and provides RTM with a diagnostic record describing the
hardware failure.

•

The Power Warning Feature (PWF) Support - which, along with its supporting
hardware, prevents the loss of data in real storage when a utility power
disturbance occurs by dumping real storage to disk.

•

The channel check handler (CCH) - which supports lOS in handling channel
errors. When a channel error occurs, lOS invokes CCR to aid in the
recording of the error.

•

Dynamic device reconfiguration (DDR) - which supports I/O processing by
making data on a malfunctioning device available to processing programs.
DDR responds to operator- and system-initiated requests for device swapping.

•

The missing interruption handler (MUI) - which monitors UCBs at
installation-specified time intervals for pending mounts, device swaps, and I/O
interruptions.

MCH Diagnostic Aids
This topic contains the following diagnostic aids information that can be used to
diagnose problems in the machine check handler (MCH).
•
•

A list of return codes set by MCH modules
An explanation of the processor work area (PWA)

For additional information related to machine checks, refer to the topic
"Debugging Machine Checks" in Section 2 of this publication.
MCH Return Codes
Return codes are set by:
IGFPMMSG IGFPMPFX -

which schedules error messages.
which converts a failing address to an absolute address.

The MCR return codes are:
Module

Location

Code Meaning

IGFPMMSG

register 15

0

IGFPMPFX

5-256

MVS Diagnostic Techniques

register 15

4

Indicates a message is scheduled.
Indicates the message buffer is full. (The message is lost.)

0
:PO

The failing storage address is returned.
The failing storage address is invalid).

Processor Work Area (PWA)
When MCH receives control it stores the contents of storage location 0 through
231 in the PWA field PWASFLC. The MCH register save areas are PWA fields
PWASA1, PWASA2, PWASA3, and PWASA4. An explanation of the PWA can
be found in Data Areas.
When a machine check, program check, or restart interruption occurs in MCH,
the following PWA fields are used:
•

PWASOSW holds the PSW at the time of the interruption.

•

PW AINTC holds the machine check or program interruption code.

•

PWAFRRCD holds one of the following codes indicating the type of
interruption.
X'OOOOOOOI'
X'OOOOOO23'
X'OOOOOO24'
X'OOOO0025'
X'OO000026'

-

recursive machine check or threshold exceeded.
program interruption.
restart interruption.
system damage.
a zero machine check interrupt code.

PWF Diagnostic Aids
This topic contains the following information that can be used to diagnose
problems in the Power Warning Feature (PWF) Support.
•
•
•
•
•

A list of return codes set by PWF
A description of the data areas that PWF uses
A dump footprint table
An appendage footprint table
A description of LOGREC recording

PWF Return Codes
The PWF return codes are:
Module

Location

Code

Meaning

ICFBDFOO

register 15

0

Power warnings are to be disabled on the MCH exit.

User-written
routines

register 15

0
4

Continue executing with PWF.
Return to the MCH.

PWF Data Areas
This sectiQn describes the major data areas used by the Power Warning Feature
Support. These data areas include:
•
•
•

Unit control block (UCB), one byte at offset 17.
Communications vector table (CVT), one word .at offset: 244.
PWF communications area.

Section 5. Component Analysis

5-257

For description of other fields in the UCB and in the CVT see:
•
•

Data Areas
Debugging Handbook

UCB Unit Control Block
Offset

17(11)

Size/BUs
Length

Name

1
...... 1.

UCBTBYT2
UCB20PT6

...... .1

UCB20PT7

Description

Volume attribute. This volume must be mounted on a
device supported by UPS.
Device attribute. This is a device supported by UPS, and
is turned on at SYSGEN by specifying AP = YES in the
IODEVICE macro.

CVT Communications Vector Table
Offset

Size/Bils
Length

244(F4)

4
I
1. .....

Name

Description

CVTVOLM2
CVTVOLF2
CVTVOLl2

Address of the PWF communications area
PWF Flag
PWF not initialized
Reserved, set to zero
PWF time delay parameter. This field is set with the
WARN = parameter in the CTRLPROG MACRO (0 is
the default).

.xxx xxx
CVTVOLT2

3

PWF Communication Area
Common Name: PWF Communications Table
Macro ID: ICFWORK
Created by: ECFBIFOO
Size: 2048 Bytes
Pointed to by: CVTVOLM2 field of the CVT data area
Function: To provide common information required by the Power Warning
Feature Support routines.
Offsels

5-258

Length

Name

Description

0(0)

4

ICFADRI

Pointer to footprint table

4(4)

4

ICFADR2

VS2-2 - real address of PCCA vector table

8(8)

4

ICFADR3

VS2-2 - real address of CSD

12(C)

4

ICFADR4

Pointer to ICFBIEOO

16(10)

8

ICFSEKOO

Seek CCW track 00

24(18)

8

ICFSRCOO

Search for track 00

32(20)

8

ICFICOO

TIC CCW track 00

40(2~)

8

ICFWRDOO

Write data track 00

48(30)

8

ICFSEKOI

«Seek CCW track 01

MVS Diagnostic Techniques

~

~

~'

S6(38)

8

ICFSRCOI

Search for track 01

64(40)

8

ICFTICOI

TIC CCW track 01

72(48)

8

ICFWRDOI

Write data track 01

80(SO)

8

ICFSEK02

Seek CCW track 02

88(S8)

8

ICFSRC02

Search for track 02

-96(60)

8

ICFTIC02

TIC CCW track 02

104(68)

8

ICFWRD02

Write data track 02

112(70)

8

ICFSEK03

Seek CCW track 03

120(78)

8

ICFSRC03

Search for track 03

128(80)

8

ICFTIC03

TIC CCW track 03

136(88)

8

ICFWRD03

Write data track 03

144(90)

8

ICFSEK04

Seek CCW track 04

IS2(98)

8

ICFSRC04

Search for track 04

160(AO)

8

ICFTIC04

TIC CCW track 04

168(A8)

8

ICFWRD04

Write data track 04

176(BO)

8

ICFSEKOS

Seek CCW track OS

184(B8)

8

ICFSRC05

Search for track OS

192(CO)

8

ICFTICOS

TIC CCW track OS

200(C8)

8

ICFWRDOS

Write data track 05

208(DO)

8

ICFSEK06

Seek CCW track 06

216(D8)

8

ICFSRC06

Search for track 06

224(EO)

8

ICFTIC06

TIC CCW track 06

232(E8)

8

ICFWRD06

Write data track 06

240(FO)

8

ICFSEK07

Seek CCW track 07

248(F8)

8

ICFSRC07

Search for track 07

256(100)

8

ICFTIC07

TIC CCW track 07

264(108)

8

ICFWRD07

Write data track 07

272(110)

8

ICFSEK08

Seek CCW track 08

280(118)

8

ICFSRC08

Search for track 08

288(120)

8

ICFTIC08

TIC CCW track 08

296(128)

8

ICFWRD08

Write data track 08

304(130)

8

ICFSEK09

Seek CCW track 09

312(138)

8

ICFSRC09

Search for track 09

320(140)

8

ICFTIC09

TIC CCW track 09

328(148)

8

ICFWRD09

Write data track 09

336(150)

8

ICFSEKI0

Seek CCW track 10

344(158)

8

ICFSRCI0

Search for track 10

352(160)

8

ICFTICI0

TIC CCW track 10

360(168)

8

ICFWRDI0

Write data track 10

368(170)

8

ICFSEKll

Seek CCW track 11

376(178)

8

ICFSRCII

Search for track 11

384(180)

8

ICFTICII

TIC CCW track 11

392(188)

8

ICFWRDII

Write data-track 11

400(190)

8

ICFSEK12

Seek CCW track 12

Section 5. Component Analysis

5-259

408(198)

8

ICFSRC12

Search for track 12

416(IAO)

8

ICFTIC12

TIC CCW track 12

424(IA8)

8

ICFWRD12

Write data track 12

432(lBO)

8

ICFSEK13

Seek CCW track 13

440(1B8)

8

ICFSRC13

Search for track 13

448(1 CO)

8

ICFTIC13

TIC CCW track 13

456(lC8)

8

ICFWRD13

Write data track 13

464(1 DO)

8

ICFSEK14

Seek CCW track 14

472(1D8)

8

ICFSRC14

Search for track 14

480(1 EO)

8

ICFTIC14

TIC CCW track 14

488(1E8)

8

ICFWRD14

Write data track 14

496(IFO)

8

ICFSEK15

Seek CCW track 15

504(lF8)

8

ICFSRC15

Search for track 15

512(200)

8

ICFTIC15

TIC CCW track 15

520(208)

8

ICFWRD15

Write data track 15

528(210)

8

ICFSEK16

Seek CCW track 16

536(218)

8

ICFSRC16

Search for track 16

544(220)

8

ICFTIC16

TIC CCW track 16

552(228)

8

ICFWRDI6

Write data track 16

560(230)

8

ICFSEKI7

Seek CCW track 17

568(238)

8

ICFSRC17

SRC FOR TRK 17

576(240)

8

ICFTIC17

TIC CCW track 17

584(248)

8

ICFWRDI7

Write data track 17

592(250)

8

ICFSEK18

Seek CCW track 18

600(258)

8

ICFSRC18

Search for track 18

608(260)

8

ICFTICI8

TIC CCW track 18

616(268)

8

ICFWRD18

Write data track 18

624(270)

8

ICFSEKl9

Seek CCW track 19

632(278)

8

ICFSRC19

Search for track 19

640(280)

8

ICFTICl9

TIC CCW track 19

648(288)

8

ICFWRDI9

Write data track 19

656(290)

4

ICFWADEV

Device address of primary data set

660(294)

4

ICFWAUCB

UCB address of primary data set

7
I

ICFWACHR
ICFFLAGA
ICFINOP
ICFCMTDM
ICFUSRC4

Start of primary extent
Flag A field
PWF function inoperative
Commit to dump
User set return code of 4
Reserved, set to zero

672(2AO)

4

ICFWBDEV

Device address of alternate data set

676(2A4)

4

ICFWBUCB

UCB address of alternate data set

680(2A8)

7

ICFWBCHR

Start of alternate extent

664(298)
671 (29 F)
I .......
.1. .....

.. 1.....
... x xxxx

5-260

MVS Diagnostic Technique:;

687(2AF)

... 1 ....
... 1 .. 1.

... 1 .. 11
.. 1. .. 1.

ICFFLAGB
ICFMVT
ICFSVM
ICFMVM
ICFVSI

Flag B field
System type - MVT
System type - VS2 RI
System type - VS2 R2
System type: - VS 1 R3
Reserved, set to zero

ICFTRSIZ

Number of bytes per track

Xx .. xx ..

~

r

688(2BO)

4

692(2B4)

4

ICFTPC

Number of tracks per cylinder

696(2B8)

8

ICFCHROO

Seek/search address for track 00

704(2CO)

8

ICFCHROI

Seek/search address for track 01

712(2C8)

8

ICFCHR02

Seek/search address for track 02

720(2DO)

8

ICFCHR03

Seek/search address for track 03

728(2D8)

8

ICFCHR04

Seek/search address for track 04

736(2EO)

8

ICFCHR05

Seek/search address for track 05

744(2E8)

8

ICFCHR06

Seek/search address for track 06

752(2FO)

8

ICFCHR07

Seek/search address for track 07

760(2F8)

8

ICFCHR08

Seek/search address for track 08

768(300)

8

ICFCHR09

Seek/search address for track 09

776(308)

8

ICFCHRIO

Seek/search address for track 10

784(310)

8

ICFCHRll

Seek/search address for track 11

792(318)

8

ICFCHR12

Seek/search address for track 12

800(320)

8

ICFCHR13

Seek/search address for track 13

808(328)

8

ICFCHR14

Seek/search address for track 14

816(330)

8

ICFCHRl5

Seek/search address for track 15

824(338)

8

ICFCHRl6

Seek/search address for track 16

832(340)

8

ICFCHR17

Seek/search address for track 17

840(348)

8

ICFCHR18

Seek/search address for track 18

848(350)

8

ICFCHR19

Seek/search address for track 19

856(358)

4

ICFSTSIZ

Storage size

860(35C)

4

ICFTMEOO

Original time value (in MSEC)

864(360)

8

ICFTMEOI

Original time in TOD units

872(368)

8

ICFTODOO

Time at entry to MCH appendage

880(370)

8

ICFTODOI

Time at inner warning signals

888(378)

8

ICFTOD99

Time to commit to dump

896(380)

4

ICFLRDAT

Date of dump for LOGREC

900(384)

4

ICFLRTIM

Time of dump for LOGREC

904(388)

8

ICFLRCPU

Processor ID for LOGREC

912(390)

8

ICFLRCHA

Channel assignment for LOGREC

920(398)

16

ICFRSVDI

Reserved

936(3A8)

4

ICFPXREG

Prefix register contents at dump time

940(3AC)

4

ICFTRMSA

Trace flags for MSJ appendage

944(3BO)

4

ICFTRMCA

Trace flags for MCH appendage

948(3B4)

4

ICFTRDMP

Trace flags for dump

952(3B8)

72

ICFIOMAP

Work area for IOSGEN

1024(400)
1024(400)

512
4

JCFCNTRK
ICFCnD

Buffer for control record
Control track identifier

Section 5. Component Analysis

5-261

1028(404)

128

1156(484)
I .......
.... I. ..
1.. .. 1..

5-262

ICFCTCF

Cylinder flags for 128 cylinders

ICFCTFLA
ICFCTEMP
ICFCTFUL
ICFCTINV
ICFCTFBT

Control track flag A
Data set is empty
Data set contains valid dump
Data set contains invalid dump
Data set contains valid dump but one PWF or more
tracks gave I/O errors - PWF alternate track(s) are in
use

1160(488)

4

ICFCTTS

Number of bytes per track

1164(48C)

4

ICFCTAWA

Address of PWF work area

1168(490)

4

ICFCTB11

Start of storage block address

1172(494)

4

ICFCTBI2

Track addr at which storage blk begins

1176(498)

4

ICFCTB13

End of storage block address

1180(49C)

4

ICFCTB14

Track addr at which storage block ends

1184(4AO)

4

ICFCTB21

Start of storage block address

1188(4A4)

4

ICFCTB22

Track addr at which storage blk begins

1192(4A8)

4

ICFCTB23

End of storage block address

1196(4AC)

4

ICFCTB24

Track addr at which storage block ends

1200(4BO)

4

ICFCTB31

Start of storage block address

1204(4B4)

4

ICFCTB32

Track addr at which storage blk begins

1208(4B8)

4

ICFCTB33

End of storage block address

1212(4BC)

4

ICFCTB34

Track addr at which storage block ends

1216(4CO)

4

ICFCTB41

Start of storage block address

1220(4C4)

4

ICFCTB42

Track addr at which storage blk begins

1224(4C8)

4

ICFCTB43

End of storage block address

1228(4CC)

4

ICFCTB44

Track addr at which storage block ends

1232(4DO)

4

ICFCTB51

Start of storage block address

1236(4D4)

4

ICFCTB52

Track addr at which storage blk begins

1240(4D8)

4

ICFCTB53

End of storage block address

1244(4DC)

4

ICFCTB54

Track addr at which storage block ends

1248(4EO)

4

ICFCTB61

Start of storage block address

1252(4E4)

4

ICFCTB62

Track addr at which storage blk begins

1256(4E8)

4

ICFCTB63

End of storage block address

1260(4EC)

4

ICFCTB64

Track addr at which storage block ends

1264(4FO)

4

ICFCTB71

Start of storage block address

1268(4F4)

4

ICFCTB72

Track addr at which storage blk begins

1272(4F8)

4

ICFCTB73

End of storage block address

I 276(4FC)

4

ICFCTB74

Track addr at which storage block ends

1280(500)

4

ICFCTB81

Start of storage block address

1284(504)

4

ICFCTB82

Track addr at which storage blk begins

1288(508)

4

ICFCTB83

End of storage block address

1292(50C)

4

ICFCTB84

Track addr at which storage block ends

1296(510)

8

ICFCTST

TOD at entry to MCH appendage

1304(518)

8

ICFCIED

TOD at end of dump

1312(520)

4

ICFCTTPC

Number tracks per cylinder

1316(524)

4

ICFCTRDA

Device address for restore

MVS Diagnostic Techniques

conten~

1320(528)

4

ICFCTPXR

Prefix register

1324(52C)

4"

ICFCTSTS

Highest storage address for LOGREC

1328(530)

4

ICFCTDAT

Date of dump for LOGREC

1332(534)

4

ICFCITIM

Time of dump for LOGREC

at dump time

1336(538)

8

ICFCTCPU

Processor ID for LOGREC

1344(540)

8

ICFCTCHA

Channel assignment for LOGREC

1352(548)

184

ICFCTRSV

Reserved

1536(600)

16

ICFRSVD2

Reserved

'Jj

1552(610)

64

ICFSAVE

Register save area for user ~xit

1616(650)

8

ICFSNMCP

SA for his MCNPSW

1624(6~8)

8

ICFMCOPS

SA for his MCOPSW

1632(660)

160

ICFDMPWA

Work area for dump routine

256

ICFRSVD3

Reserved

1792(700)

Section 5. Component Analysis

5-263

Name

Offsets/EQU Value

Name

Offsets/EQU Value

Name

Offsets/EQU Value

ICFADRI
ICFADR2
ICFADR3
ICFADR4
ICFCHROO
ICFCHROI
ICFCHR02
ICFCHR()3
ICFCHR04
ICFCHR05
ICFCHR06
ICFCHR07
ICFCHR08
ICFCHR09
ICFCHRIO
ICFCHRll
ICFCHR12
ICFCHR13
ICFCHR14
ICFCHR15
ICFCHR16
ICFCHRl7
JCFCHRI8
ICFCHR19
ICFCMTOM
ICFCNTRK
ICFCTAWA
ICFCTBll
ICFCTB12
ICFCTB13
ICFCTB14
ICFCTB21
ICFCTB22
ICFCTB23
ICFCTB24
ICFCTB31
ICFCTB32
ICFCTB33
ICFCTB34
ICFCTB41
ICFCTB42
ICFCTB43
ICFCTB44
ICFCTB51
ICFCTB52
ICFCTB53
ICFCTB54
ICFCTB61
ICFCTB62
ICFCTB63
ICFCTB64
ICFCTB71
ICFCTB72
ICFCTB73
ICFCTB74
ICFCTB81
ICFCTB82
ICFCTB83
ICFCTB84
ICFCTCF
ICFCTCHA
ICFCTCPU
ICFCTDAT
ICFCTED
ICFCTEMP
ICFCTFBT

0(0)
4(4)
8(8)
12(C)
696(2B8)
704(2CO)
712(2C8)
720(2DO)
728(2D8)
736(2EO)
744(2E8)
752(2FO)
760(2F8)
768(300)
776(308)
784(310)
792(318)
800(320)
808(328)
816(330)
824(338)
832(340)
840(348)
848(350)
271 X'40'
1024(400)
1164(48C)
1168(490)
1172(494)
1176(498)
1180(49C)
1184(4AO)
1188(4A4)
1192(4A8)
1196(4AC)
1200(4BO)
1204(4B4)
1208(4B8)
1212(4BC)
1216(4CO)
1220(4C4)

ICFCTFLA
ICFCTFUL
ICFCTID
ICFCTINV
ICFCTPXR
ICFCTRDA
ICFCTRSV
ICFCTST
ICFCTSTS
ICFCTTIM
ICFCITPC
ICFCTTS
ICFDMPWA
ICFFLAGA
ICFFLAGB
ICFINOP
ICFIOMAP
ICFLRCHA
ICFLRCPU
ICFLRDAT
ICFLRTIM
ICFMCOPS
ICFMVM
ICFMVT
ICFPXREG
ICFRSVDl
ICFRSVD2
ICFRSVD3
ICFSAVE
ICFSEKOO
ICFSEKOI
ICFSEK02
ICFSEK03
ICFSEK04
ICFSEK05
ICFSEK06
ICFSEK07
ICFSEK08
ICFSEK09
ICFSEKIO
ICFSEKll
ICFSEK12
ICFSEK13
ICFSEK14
ICFSEK15
ICFSEK16
ICFSEK17
ICFSEK18
ICFSEK19
ICFSNMCP
ICFSRCOO
ICFSRCOI
ICFSRC02
ICFSRC03
ICFSRC04
ICFSRC05
ICFSRC06
ICFSRC07
ICFSRC08
ICFSRC09
ICFSRCIO
ICFSRCII
ICFSRC12
ICFSRC13
ICFSRC14
ICFSRC15

1156(484)
1156 X'80'
1024(400)
1156 X'08'
1320(528)
1316(524)
1352(548)
1296(510)
1324(52C)
1332(534)
1312(520)
1160(488)
1632(660)
671(29F)
687(2AF)
671 X'80'
952(3B8)
912(390)
904(388)
896(380)
900(384)
1624(658)
687 X'13'
687 X'IO'

ICFSRC16
ICFSRC17
ICFSRC18
ICFSRC19
ICFSTSIZ
ICFSVM
ICFTICOO
ICFTICOI
ICFTIC02
ICFTIC03
ICFTIC04
ICFTIC05
ICFTIC06
ICFTIC07
ICFTIC08
ICFTIC09
ICFTICIO
ICFTIC11
ICFTIC12
ICFTIC13
ICFTIC14
ICFTIC15
ICFTIC16
ICFTIC17
ICFTIC18
ICFTIC19
ICFTMEOO
ICFTMEOI
ICFTODOO
ICFTODOI
ICFTOD99
ICFTPC
ICFTRDMP
ICFTRMCA
ICFTRMSA
ICFTRSIZ
ICFUSRC4
ICFVSl
ICFWACHR
ICFWADEV
ICFWAUCB
ICFWBCHR
ICFWBDEV
ICFWBUCB
ICFWRDOO
ICFWRDOI
ICFWRD02
ICFWRD03
ICFWRD04
ICFWRD05
ICFWRD06
ICFWRD07
ICFWRD08
ICFWRD09
ICFWROIO
ICFWRD11
ICFWRDl2
ICFWRD13
ICFWRD14
ICFWRD15
ICFWRD16
ICFWRD17
ICFWRD18
ICFWRD19

536(218)
568(238)
600(58)
632(278)
856(358)
687 X'12'
32(20)
64(40)
96(60)
128(80)
160(AO)
192(CO)
224(EO)
256(100)
288(120)
320(140)
352(160)
384(180)
416(IAO)
448(1 CO)
480(1 EO)
512(200)
544(220)
576(240)
608(260)
640(280)
860(35C)
864(360)
872(368)
880(370)
888(378)
692(2B4)
948(3B4)
944(3BO)
940(3AC)
688(2BO)
671 X'20'
687 X'22'
664(298)
656(290)
660(294)
680(2A8)
672(2AO)
676(2A4)
40(28)
72(48)
104(68)
136(88)
168(A8)
200(C8)
232(E8)
264(108)
296(128)
328(148)
360(168)
392(188)
424(lA8)
456(IC8)
488(1E8)
520(208)
552(228)
584(248)
616(268)
648(288)

5-264

1224(4C8)

I 228(4CC)
1232(4DO)
1236(404)
1240(408)
1244(4DC)
1248(4EO)
1252(4E4)
1256(4E8)
1260(4EC)
I 264(4FO)
1268(4F4)
1272(4F8)
1276(4FC)
1280(500)
1284(504)
1288(508)
1292(50C)
10281(404)
1344(540)
1336(538)
1328(530)
1304(518)
1156 X'OO'
1156 X'84'

MVS Diagnostic Techniques

936(3A8)

920(398)
1536(600)
1792(700)
1552(610)
16(10)
48(30)
80(50)
112(70)
144(90)
176(BO)
208(DO)
240(FO)
272(110)
304(130)
336(150)
368(170)
400(190)
432(1BO)
464(1 DO)
496(1FO)
528(210)
560(230)
592(250)
624(270)
1616(650)
24(18)
56(38)
88(58)
120(78)
152(98)
184(B8)
216(08)
248(F8)
280(118)
312(138)
344(158)
376(178)
408(198)
440(IB8)
472(1D8)
504(IF8)

~

Dump Footprint Table

The dump footprint table is a 4-byte record of the steps performed by the dump
routine. In case the dump routine fails, a printout of this table will aid in
diagnosing the failure. This table is located in the PWF communication area. If
the dump routine is in control, register 14 contains the address of the footprint
table for the WARNA data set. The footprint table for WARNA is located at
ICFTRDMP, and the footprint table for WARNB is located at ICFTRDMP+2.
First Byte
1... ....
. 1.. ....
.. 1. ....
.. .1 ....
.... 1...
.... . 1..
.... .. 1.
.... .. .1

Dump routine was started .
Initialization (PWF) complete.
Control track read and erased .
Storage scan complete.
One or more cylinders written from real storage .
Transfer of real storage complete .
Control track written .
Storage protect keys read: transfer from real storage completed.

SeeondByte

1... ....
.1.. ....
.. 1. ....

... 1 ....
.... 1...
.... . 1..

.... .. 1.
.... ... 1

One or more unit checks occurred .
One or more uncorrectable storage errors validated .
Retrying write using spare track .
Retrying write while in I/O subroutine.
Retrying write while in sense subroutine .
Two track errors occurred on one cylinder .
Failed to write on control track .
Channel checks or device was inoperative.

Appendage (ICFBDFOO) Footprint Table

The machine check appendage footprint table is a 4 byte record of the steps
performed by the machine check appendage. In case of a failure within this
routine, a storage print out of this table will aid in diagnosing the failure. This
table is located in the PWF communications area with register 14 containing the
address when this routine is in control.
First Byte
1... ....
.1.. ....
.. 1. ....
... 1 ;...
.... 1...
.... .x..
.... .. 1.
.... .. .1

Function entered .
Function inoperative bit is set.
Function is operative.
First store clock is successful.
Dump immediate flag is not set .
Reserved .
The power disturbance was transient .
Normal return to machine check handler after transient warning.

Second Byte

1...... .
. 1. .... .

.. 1. ... .
... 1 ... .
.... 1. ..
.... .xxx

Commit to dump, power disturbance is not transient.
Commit to dump, user routine has been entered .
User routine returned control with a code of 0 (go dump) .
Control has been transferred to dump routine .
User routine returned control with a code of 4 (return to system) .
ReserVed, set to zero .

Section 5. Component Analysis

5-265

Third Byte

(This byte relates to the availability of WARNA)
I .......

IOSGEN map complete (information to provide the online paths

to the device);
. 1. ... ..
.. 1. .. ..
... 1 .. ..
.... 1.. .
.... . 1..
.... .. 1.
.... .. .1

At least one path is online .
At least one path is clear.
Path check routine has been entered .
At least one path is available after clear.
Sense I/O has been accepted (code 0 was returned).
CE/DE (channel end/device end) returned form sense I/O .
WARNA processing complete.

Fourth Byte

(This byte relates to the availability of WARNB.) Same as the third byte.

LOGREC Recording
During initialization of Power Warning Feature Support an indication that a
power disturbance has occurred is placed in SYSI.LOGREC. When
SYSl.LOGREC is printed, the indication of a power disturbance will appear as
the first of two IPL records. The format of the IPL record is shown in OSjVS2
System Programming Library: SYS1.LOGREC Error Recording

CCH Diagnostic Aids
This topic contains the following information that can be used to diagnose
problems in the channel check handler (CCH).
•
•

CCH message IGF002I information
PCCA fields used to trace the activity of CCH

Message IGF002I
There is one message issued by CCH:
IGF0021

CHANNEL DETECTED ERROR ON ddd, pa, err, op, stat

The variable fields of the message (ddd, pa, err, op, stat) are put into the channel
data area (CDA) by IGFCCHCR. The following chart shows what CDA fields
are used and where IGFCCHCR obtains the information.

5-266

CDA Field

Contents

Obtained from

CDACCHBL

Error indicator

PCCACHBL

CDACCHOP

CCW operation code

LRBCFCCW

CDACCHPA

Channel set ID

LRBCMPPA

CDACCHRn

Message statistics and static message field

Dummy module

CDACCHST

Unit and channel status

LRBCFCSW

CDACCHUA

Unit address

LRBCCUA2

MVS Diagnostic Techniques

IGFCCHCR formats the message in one of the CCH message buffers:
CDACCHMI or CDACCHM2. The recovery termination manager (RTM) issues
the message through a RECORD macro instruction. After the message is issued,
IGFCCHCR sets the record buffer (CDACCHRn) to o.
PCCA Fields Showing CCH Footprints

The following fields in the PCCA (starting atX'134') may be used to trace the
action of CCH.
PCCACHFI

CCH footprint byte 1

1. ..... .

..... 1..
...... 1.
....... 1

PCCACFll
PCCACFI2
PCCACF13
PCCACFI4
PCCACFI5
PCCACFI6
PCCACFI7
PCCACF18

PCCACHF2,

CCH footprint byte 2

1...... .
.1. .... .
.. 1. ... .
.. .1 ... .
.... 1. ..
..... 1..
....... 1

PCCACF21
PCCACF22
PCCACF23
PCCACF24
PCCACF25
PCCACF26
PCCACF27
PCCACF28

PCCACHF3

CCH footprint byte 3

1. ..... .
.1. .... .

PCCAISRB
PCCASLCK

.1. .... .
.. 1. ... .
... 1 ... .

.... 1. ..

...... 1.

.. xx xxxx

I/O supervisor registers have been saved
UCB address supplied by I/O supervisor is 0
ERPIB already exists
IGFCCHSI entered
ICFCCHII entered
IGFCCHFE entered
IGFC60 entered
IGFC70 entered

IGFC80 entered
IGFCIC entered
IGFCCHRD entered
IGFCCHMP entered
IGFCCHUC entered
IGFCCHAS entered
IGFCCHIO entered
IGFCCHEX entered

SRB for IECVIRST scheduled
Space allocation lock held by CCH
Reserved

PCCACHSI

CCH internal switch 1

1. ..... .
.1. .... .
.. 1.... .
... 1 ... .
.... 1.. .
..... 1..
...... 1.

PCCACCMP
PCCACNRE
PCCACFRR
PCCACNLS
PCCACAND
PCCACIBC
PCCACUCB

....... x

Command register parity is valid
No recording to be done by CCH
CCH FRR is in the stack
Record only; ERPIB not put in EWA
Attention has been presented
ERPIB already created for this error
UCB is invalid
Reserved

PCCACHS2

CCH internal switch 2

1. ..... .
.1. .... .
.. 1. ... .
... 1 ... .
.... 1. ..
..... 1..

PCCACIOR
PCCACALT
PCCACMOD
PCCACNLG
PCCACURC
PCCACCRA

...... xx

I/O restart is required
Use the alternate return to I/O supervisor
Module required to analyze channel logout is unavailable
Channel failed to log or store an LCL
CAT entry is valid, but channel type is not recognized
Channel reconfiguration hardware active
Reserved

Section-5. Component Analysis

5-267

DDR Diagnostic Aids
This topic contains the following information that can be used to
problems in dynamic device reconfiguration (DDR).
•
•
•
•
•
•

diagno~

A description of the DDR task
An explanation of the DDRCOM
A mapping of the DDR error recovery parameter list (DERPLIST)
The return codes set by DDR modules
An explanation of DDR software recording
A description of a DDR storage dump

DDR Tasks
There are several DDR tasks: a DDR task for DASD swaps, a DDR task for
tape and unit record swaps, and a separate DDR task for each tape swap when a
tape is being repositioned on a new tape drive.
The DDR tasks are created via ATTACH macro instructions as subtasks of the
master scheduler task. The DDR tasks are in the master scheduler's address
space only when the DDR swaps are active. When all swaps are complete, the
DDR tasks terminate. The tasks are identified by the TCBTID field being 252
(X'FC').
Tape, disk, and unit record swaps are performed in the master scheduler address
space (ASID = 1). When a tape is swapped, part of routine IGFDTI is executed
in the user's address space to obtain information about the tape. This address
space is pointed to by the UCBASID field of the UCB for the tape.
DDR Communication Table (DDRCOM)
There is a DDRCOM for each DDR request. There are three DDRCOM chains,
pointed to from the CVT, for the following:
•
•
•

DASD swaps
Tape and unit record swaps
Tape swaps in the repositioning phase

A DDRCOM for a tape request is moved from the DDRCOM chain (pointed to
by CVTTPUR) to the DDRCOM chain (pointed to by CVTTRPOS) when the
tape enters the repositioning phase.

5-268

MVS Diagnostic Techniques

The format of the DDRCOM is described in the Debugging Handbook.
Figure 5-48 shows typical DDRCOM chains.
CVT
DDRCOM
OORCOM
CVTOPUR

OASDSwaps

DDRNXT
OORNXT

CVTTPUR
OORCOM
CVTTRPOS

DORNXT

Tape and Unit
Record Swaps

5.aooRCOM
DORNXT

Figure

Tape Swaps
(Repositioning)

5-48. Typical DDRCOM Chains

DDR Error Recovery Parameter List (DERPLIST)

The DDR error recovery parameter list is used by a DDR error recovery routine,
IGFDEO, to determine whether to cancel or create an error recovery environment.
IGFDEO invokes the EST AE routine through an EST AE macro instruction and
passes the address of DERPLIST as a parameter.
When an error occurs, IGFDEI, another DDR error routine, uses DERPLIST to
determine what queued resources and storage are to be freed, to locate the address
of the retry routine, and to determine what information to pass to the retry
routine.
Each module creates its own DERPLIST, and the address is known locally.

Section 5. Component Analysis

5-269

Figure 5~49 (part 1) is a map of the DERPLIST. The fields shown in the map
are listed in alphabetic order in Figure 5-49 (parts 2 and 3).
DERPLIST

DEC

HEX

0

0

DERFUNK

4

4

DERREC

8

8

DERSPEC

12

C

DERRETRY

16

10

DERDASPN

. :20

16

DERRSRC

24

18

DERRCODE

28

lC

DERRDATA

32

20

DERRDDR

36

24

DERRSAVE

40

28

DERGMSPN

44

2C

DERGMADR

48

30

DERRCRTY

52

34

DERDDPA

56

38

DEREDATA60

I

I
I

I

DERSWCHS

I

DERQUEUE

I

DERDALNG
DERLRC

I

DERPFX

DERGMLNG

3C

Figure 5-49 (Part 1 of 3). DDR Error Recovery Parameter List
Description

DEC

HEX

LEN

Field

17

11

3

DERDALNG

Length of the module workarea.

16

to

DERDASPN

Subpool of the module workarea.

52

34

DERDDPA

If the DDR device dependent exit is in control (X'08'
on in DERSWCHS), this field contains the address of
the parameter list passed to the DDR device dependent
exit. Otherwise, zero.

4

Figure 5-49 (part 2 of 3). DDR Error Recovery Parameter List

5-270

MVS Diagnostic Techniques

DEC

HEX

LEN

Field

Description

56

38

8

DEREDATA

0

0

Additional DDR device dependent exit data.
If the load of the DDR exit is in progress (X'02' on
in DERSWCHS), this field contains the name of the
module being loaded.
If the DDR exit returned an invalid return code
(X'04' on in DERSWCHS), the first word of this field
contains the invalid return ~ode passed back by the exit
and the second word contains the highest valid return
code for that call.
If the DDR exit is in control (X'08' on in
DERSWCHS), this field contains the load module
name of the DDR device dependent exit (if the exit is
in LPA or L1NKLlB).
Otherwise, this field is zero.
Function code.
X'OI'. Issue the initial ESTAE for the calling module.
X'02'. Issue ESTAE 0 for the calling module.
Address of the area obtained by a GETMAIN macro
instruction specified in DERGMLNG.
Length of area obtained by a GETMAIN macro
instruction in a DDR module.
Subpool number of area obtained by a GETMAIN
macro instruction in a DDR module.
Local return code.
Rub prefix.
Queue indicators. (If zero, determine the queue from
DDRCOM.)
DASD queue.
Tape/unit record queue .
Tape repositioning queue .
Reserved .
Module base (CODEREG).
Retry address when the DDR device dependent exit
supplied an invalid return code.
Workarea base (DATAREG).
Address of the DDRCOM (DERPTR).
Address of the 24-byte recording of the ID to be used
during IGFDEI processing.
Address of retry routine after IGFDEI processing.
Save area register.
Resources controlled by this module (compared with
DDROWN in DDRCOM).
DERTAPE - Tape allocation resource held.
DERUREC - Unit record allocation resource held .
DERDISK - Disk allocation resource held .
Reserved .
Address of special cleanup exit during IGFDEI
processing.
IGFDEI indicator switches.
DERCRASH - No SDWA exists, do not issue a
SETRP.
DERPERK - Do not retry; issue SETRP to continue
termination.
DERECALL - This DDR module is recallable on error
conditions.
DERESTAE - Initial EST AE issued was successful.
DDR device dependent exit in control.
DDR device dependent exit supplied an invalid return
code.
Load of DDR device dependent exit in progress .
Vary service routine in control.

44

32

4

DERFUNK
DERINIT
DERCANC
DERGMADR

41

29

3

DERGMLNG

40

28

21
22
2

15
16
2

DERGMSPN
1
2
1

DERLRC
DERPFX
DERQUEUE

24
48

18
30

4
4

1. ......
. 1......
.. 1.....
... x xxxx
DERRCODE
DERRCRTY

28
32
4

IC
20
4

4
4
4

DERRDATA
DERRDDR
DERREC

12
36
20

C
24
14

4
4
1

DERRETRY
DERRSAVE
DERRSRC
1. ......
. 1. .....

8

8

4

... 1 ....
... x xxxx
DERSPEC

DERSWCHS
1. ......
.1. .....
.. 1.....
... 1 ....
.... I ....
..... 1..

.... .. 1.
....... 1

Figure 5-49 (Part 3 of 3).

DDR Error Recovery Parameter List

Section 5. Component Analysis

5-271

DDR Return Codes
The return codes for DDR are:
Module

Location of
Code

Return
Code

IGFDDO

register 15

0

Object

4

IGFDDI

register 15

12
0
4

IGFDIl

register 15

12
0
4

IGFDLl

register 15

12
0
4

IGFDMO

register 15

IGFDMI

register 15

IGFDRO

register 15

IGFDTO

register 15

IGFDTl

register 15

IGFDT2

register 15

IGFDUO

register 15

12
0
4
12
0
4
12
0
4
12
0
12
0
4
12
0
4
8
12
0
4

IGFDVO

register 15

IGFDVI

register 15

12
0
4
0
4
12

MeaDing
Valid condition
Invalid condition
Catastrophic condition
Valid condition
Invalid condition
Catastrophic error, DDRINVI, DDRTERI set
Element removed, queue not empty
Element removed, queue empty
Catastrophic error, queue empty
Device found
Device not found
Catastrophic error
Message issued without error
Invalid input detected in DDRCOM
Catastrophic error
Successful
Unsuccessful
Catastrophic error
Recording initiated successfully
Invalid function requested
Catastrophic error
SWAP completed successfully
SWAP terminated
Valid
Invalid
Catastrophic error
Positioning completed successfully
I/O error
Wrong volume loop
Catastrophic error
Valid condition
Invalid condition
Catastrophic condition
SWAP completed
SWAP canceled or terminated
Valid
Invalid
Catastrophic error

Software Recording
No special DDR information is recorded in the variable fields of the software
ABEND record. However, the FRR ID field of the load module/CSECT/FRR
ID data contains the date of the compilation of the CSECT. This may be used in
verifying the level of the module against the available microfiche.
DDR Storage Dumps
Whenever an abnormal termination occurs, the DDR ESTAE module IGFDEI
uses the SDUMP macro to dump those portions of main storage necessary to
diagnose the problem. Included in the dump are the SQA, PSA, IPA, trace table,
CSA, and the local storage. The dump is titled "Dynamic Device R,ecovery
Dump."

5,;,272

MVS Diagnostic Techniques

MIH Diagnostic Aids
This topic contains the following information that can be used to diagnose
problems in the missing interruption handler (MIH).
•
•
•
•

A description of the MIH process
A description of the MIH work area
An explanation of MIH software recording
A description of an MIH storage dump

MIH Process
The MIH process is invoked through the ATTACH macro instruction during
master scheduler initialization and executes in the master scheduler address space
(ASID = 1). Two modules perform the MIH processing; IGFTMCHK, a load
module in the link pack area, and IGFTMCOO, a CSECT in the nucleus.
MIH Work Area
IGFTMCHK obtains the MIH work area from fixed SQA, subpool 245. Both
IGFTMCHK and IGFTMCOO use this work area which contains the TQE, SRB,
LRB, message ECB, WTO buffer, ESTAE parameter list, 16 and 18 word save
. areas, MIH first and second level exit parameter lists, the message queue pointer,
all general usage work areas, and the secondary look-up table. The first 16 bytes
of the work area contain an identifier (**MIH WORK AREA **). IGFTMCHK
initializes the remainder of the work area to zeros. Once obtained, the work area
is not freed. If the MIH process is terminated, the work area is retained for
problem determination.
A pointer to the MIH work area is contained in register 10 and at location X'IC'
in the IGFINTVL CSECT. Figure 5-50 shows a mapping of the work area.
Fields of special interest in the MIH work area are:
Offset
(Hex)

Length

Name

Description

co

4

MIHRCNT

C4
C4

3
I
1. ......
. 1. .....
.. 1. ....

MIHMCHKF
MIHFLAGI
MIHESTAA
MIHIPLRA
MIHIPLOK
MIHUCBSK
MIHINITC
MIHSDIEA
MIHRDEA

MIH FRR retry counters for IGFTMCHK and IGFTMC01
respectively.
IGFTMCHK flag bytes:
MIH IGFTMCHK flag byte I:
ESTAE active.
SVC 76, IPL record active .
SVC 76, IPL record written.
UCB scan active.
IGFTMCHK initialization complete .
SET DIE successful.
SVC 76, RDE active, UPD time/date stamp .
Reserved .
MIH IGFTMCHK flag byte 2:
LOGREC processing active .
SVC 11, TIME macro active.
RECORD LOGREC active .
Reserved .
ESTAE routine - no SDWA provided .
MIH IGFTMCHK flag byte 3:
Message processing active.
Message build active .
Message build routine active.
SVC 35, WTO message active .
Action message requires DOM flag.

... 1 ....
.... 1...

C5

..... 1..
.... .. 1.
... .. .1
I
1. ......
.1. .....
.. 1. ....

MIHFLAG2
MIHLGRCA
MIHTIMEA
MIHRECDA

... x xxx.
.... ... 1
C6

1

1.......
. 1. .....
.. 1. ....
... 1 ....

.... 1. ..

MIHNSDWA
MIHFLAG3
MIHMSGPA
MIHMSGBA
MIHMBLDA
MIHWTOA
MIHACTNP

Section 5. Component Analysis

5-273

..... 1..

MIHDMSET

.... ..xx
C7
C7

3
1

I .......
.1 ......
.. 1. ....
.. .1 ....

.... I ...
..... 1..
...... 1.

...... .1
C8

1

MIHMCOIF
MIHFLAGI
MIHFRRA
MIHEXTIA
MIHUCBSA
MIHUCBVA
MIHEXT2A
MIHTQEA
MIHEXITE
MIHOIRTY
MIHFLAGS

xxxx xxxx
C9

1

I .......

MIHPOSTF
MIHPOST

. 1111111

CA
CC
CD
CE
CF

5-274

MVS Diagnostic Techniques

2
I
I
I

I

MIHFRRSA
MIHCODE
MIHPSTCD
MIHUCBTI

DOM table search flag.
Reserved .
IGFTMCOI flag bytes:
MIH IGFTMCOI flag byte I:
FRR active.
MIH eXit 1 active.
UCB scan active.
Valid UCB processing.
MIH exit 2 active.
MIH TQE ENQ active.
MIH permanent error in exit.
MIH FRR retry active.
MIH IGFTMCOI flag byte 2:
Reserved.
MIH POST flag byte:
MIH posting active.
TS instruction is used to serialize posting .
MIH IGFTMCOI FRR flag save area
MIH condition translation code.
MIH POST code.
MIH exit index in error.
Reserved.

0

header

10

TOE

90

SRB
BC

CO

MIHRCNT

00

LRB

I

MIHFLAGS

i

I MIH~RRSA

,

13C

ECB
MIHCODE IMIHPSrCDI MIHUCBTlI

WTO

188

ESTAE

198

MIHTIMEP - PRI binary sec

1A8

MIHTACCM - Accumulated time

MIHTOD - TOO value

1 B8

MIHTMCT - Sec EBCDIC value

MIHWK1

1C8

MIHWK2

108

MIHWK3

1E8

MIHR14SV

1F8

MIHINTVP

208

MIHEXT1P

218

MIHEXT2P

228

TMC01SAV

MIHTIMES - SEC binary sec

MIHREMOR

I
I

MIHMSGPR

MIHR13SV

MIHR14SA

MIHR14SB

MIHR14SC

MIHUCBLA

MIHR14SD

MIHINDEX

MIHUASCB

18 Word Save Area for IGFTMCHK
270 TMCHKSAV
18 Word Save Area for IGFTMCHK

2B8

MIHFRRSV
IGFTMC01 FRR Save Area

2F8

MIHPSTSV
IGFTMC01 POST Interface Save Area

33C

MIHDMTBL

3F2

MIHULKTB

Figure 5-50.

MIH DOM Table
Secondary Look-up Table for 48 UCB Entries

MIH Work Area

Section 5. Component Analysis

5-275

Software Recording
The CSECT name, PTF number and date are moved into the variable field of the
software ABEND record. The PTF number and date can be used in verifying the
level of the module against the available microfiche. The FRR ID field contains
the load module/CSECT/FRR ID.
MIH Storage Dumps
Whenever an abnormal termination occurs, storage areas necessary to diagnose a
problem are dumped by the ESTAE recovery routine, IGFTMCHS, in module
IGFTMCHK, using the SDUMP macro instruction. Included in the dump are
the SQA, NUC, and trace table.

5-276

MVS Diagnostic Techniques

Service Processor Call SVC and MSSFCALL DIAGNOSE
Instruction
Note: This topic describes the MVS support for processor complexes with the
monitoring and system support facility (MSSF). See the topic "Service Processor
Call SVC and SERVICE CALL Instruction" for a description of the MVS support
for processor complexes with the Service Processor Architecture.
The Service Processor Call SVC (SVC 122), formerly called the MSSFCALL
SVC, is a type 2 extended SVC with a routing code of 6 in register 15. It is used
to communicate with the monitoring and system support facility (MSSF) in the
processor controller of the processor complex.
MVS system routines issue the Service Processor Call SV C to request various
hardware functions and to obtain hardware status information.
When the Service Processor Call SVC is issued, the Service Processor Call SVC
processing routine (lEAVMSF) processes the SVC request. lEAVMSF issues the
DIAGNOSE instruction (operation code X'83'). The MSSFCALL DIAGNOSE
instruction directly interfaces with the MSSF, which is a logical unit within the
processor controller.
IEAVMSF issues the SERVICE CALL instruction (rather than the MSSFCALL
DIAGNOSE instruction) on processor complexes with the Service Processor
Architecture.
For program logic information, refer to the System Logic Library, System
Initialization Logic, and Input/Output Configuration Program (IOCP) Logic.
The following topics describe:
•

Service Processor Call SVC (SVC 122) used with the MSSF

•

Service Processor Call SVC (SVC 122) processing and control blocks used
with the MSSF

•

MSSFCALL DIAGNOSE instruction

Service Processor Call SVC (SVC 122) Used With the MSSF
To issue the Service Processor Call SVC for the MSSF, the caller prepares an
MSSFCALL data block (also called a service processor data block) and an
MSSFCALL command word (also called a service processor command word) in
the caller's own private area. The caller sets register 15 to 6 (the routing code)

Section 5. Component Analysis

5-277

and sets register 1 to the address of a parameter list, which points to the data
block and the command word.
Register 1
MSSFCALL data block

Parameter list

MSSFCALL command word

The parameter list is a standard SVC parameter list. The MSSFCALL data block
contains command-dependent information and is used to send data to the MSSF
and to receive responses and data from the MSSF. The MSSFCALL command
word specifies the function requested.
The following topics describe:
•
•

MSSFCALL data block
SVC abend and return codes with the MSSF

MSSFCALL Data Block
The MSSFCALL data block (also called the service processor data block) is a
variable-length data area. The format of the data block is:
0-1

2

Length
8

3-5
Reserved

6-7
Response
field

Data field
(0 to 2,040 bytes)

y
Length - bytes 0 and 1
specifies the length of the data block in eight-byte increments. The
minimum length is eight (X'0008') and the maximum length is 2,048
(X'0800') bytes. The length varies depending on the command request.
Errors in the specification of the length are indicated by the MSSF in the
response field.
Caller flags - byte 2
specifies flags associated with the command request. Set the appropriate
flags if used with the command; otherwise, set to X'OO'. Errors in the
specification of caller flags are indicated by the MSSF in the response field.

5-278

MVS Diagnostic Techniques

Reserved - bytes 3 through 5
set to X'OOOOOO'.
Response field - bytes 6 and 7
receives the two-byte response from the MSSF. At the completion of the
request, the MSSF sets this two-byte field to indicate the status of the
request. The field must be set to X'OOOO' before issuing the Service
Processor Call SVC.
Data field ... byte 8 to end of data block
specifies command-dependent information, if any, related to the command.
Before issuing the SVC, the caller either puts the appropriate
command-dependent information into the data field or sets the field to
zeroes. The MSSF returns command-dependent data in the data field if
applicable for the command.
SVC Abend and Return Codes With the MSSF
Abend Code - The Service Processor Call SVC processing routine (lEAVMSF)
issues system abend X'67A' if the caller is not authorized to issue the SVC or if
an error occurs during processing of the SVC. Refer to System Codes for a
description of abend X'67A'.
Return Codes - IEAVMSF returns the following return codes in register 15 to the
caller of the SVC.
Code

MeaDing

00(00)

Successful completion - the MSSFCALL data block contains the MSSF response (in bytes 6
and 7) and any data (in the data field) requested on the command.

04(04)

The MSSF is busy - the caller can reissue the SVC.

08(08)

One of the MSSFCALL SVCprocessing control blocks (MSFCB, MSFAB, or MSFKB) is in
use - the caller can reissue the SVC.

12(OC)

The MSSF is not available on the processor complex or the control block chain is invalid.

16(10)

The MSSF did not respond during a 100second disabled spin.

SVC Processing and Control Blocks With the MSSF
The Service Processor Call SVC processing routine (lEAVMSF) provides the
interface between system routines and the monitoring and system support facility
(MSSF) in the processor controller. lEAVMSF processes requests made by
programs issuing the Service Processor Call SVC (including the users of the data
communications link) and routines that· branch-enter IEAVMSF.
When processing the Service Processor Call SVC request, IEAVMSF copies the
caller's MSSFCALL data block to the data block pointed to by the MSFCB,
MSFAB, or MSFKB control block. The MSSF puts its respOnses and data into
the data block (pointed to by the MSFCB, MSFAB, or MSFKB). lEAVMSF
then copies the MSSF response and data, if any, into the. caller's· MSSFCALL
data block.

-Section S. Component Analysis

5-279

Figure 5-51 shows an overview of lEAVMSF processing.
Service Processor
Call SVC CSVC 122)

~

I

SVC FLIH
ClEAVESVC)

~
lEAVMSF - Service Processor Call
SVC processing
routine

•

Validates the request.

-

-

IEAVEVAL
Validity check
routine

Invalid r equest
results i n
abend X' S7A'

Processor controller
The MSSF executes the request.

•

Issues the MSSFCALL
DIAGNOSE instruction.

-

• Generates an X' 2401 '
external interruption.

~
•

Waits for the completion
of the request to the MSSF.

IEAVEEXT, IEAVMFIH, and
IEAVMSFS process the
interruption.

~
Caller

Figure 5-51.

Overview of SVC Processing With the MSSF

SVC Control Blocks Used with the MSSF
lEAVMSF uses three control blocks to serialize Service Processor Call SVC
requests, the MSSFCALL control block (MSFCB), the MSSFCALL attention
block (MSFAB), and the MSSFCALL communications block (MSFKB). All are
created at NIP time by the RIM module lEAVNPE6 and are located in the SQA.
The MSFKB is used to serialize all read-restart-reason commands. The MSFCB
is used to serialize all other requests except the TP connect and TP read
commands. The MSFAB is used to serialize the TP connect and TP read
commands.

5-280

MVS Diagnostic Techniques

Figure 5-52 shows an overview of the SVC control blocks.
lEAVMFRM

CVT

MSSFCALL
resource
manager

CVTMFRM

MSFCB's
data block

CVTMSFCB
MSFCB
CVTSCPIN
MSFCADB

MSFAB

MSFCBCMD.
MSFCMSFA

MSFAADB

MSFCMSFK

MSFABCMD.

MSFAB's
data block

System
hardware
information
MSFKB's
data block
.MSFCBCMD, MSFABCMD, and MSFKBCMD
contain the command word being processed.

MSFKADB
MSFKBCMD.

Figure 5-52. SVC Control Block Structure With the MSSF

MSSFCALL DIAGNOSE Instruction
The MSSFCALL DIAGNOSE instruction is a variation of the DIAGNOSE
instruction (operation code X '83'). The MSSFCALL DIAGNOSE instruction
directly interfaces with the MSSF in the processor controller. It is used to request
hardware functions and to request hardware status.
The MSSFCALL DIAGNOSE instruction is issued by the Service Processor Call
SVC processing routine (lEAVMSF) to process Service Processor Call SVC (SVC
122) requests. It is also issued by other system components (such as IPL, NIP,
and SADMP) to obtain system and hardware information.
The format of the MSSFCALL DIAGNOSE instruction is:

I X'83'

Rl

R3

0-7

8-11

12-15

Bits 0-7

Rl
R3
Bits 16-31

specifies
specifies
specifies
specifies

the
the
the
the

I X'OO80'
16-31

DIAGNOSE instruction (X'83').
register containing the address of the MSSFCALL data block.
register containing the MSSFCALL command word.
MSSFCALL instruction (which must be set to X'0080').

lEAVNIPO sets bit 22 of control register 0 (the class 21 external interruption
mask bit) to 1 for each processor. This enables the system for service signal
interruptions.

Section 5. Component Analysis

5.;;.281

The MSSF indicates the completion of the MSSFCALL DIAGNOSE instruction
by generating an external interruption~ The interruption code is X'2401 '.
MSSFCALL DIAGNOSE Instruction Condition Codes
At the completion of the MSSFCALL DIAGNOSE instruction, one of the
following condition codes is set in the PSW:

5-282

Code

MeaDing

o

The MSSF processed the request without error.

2

The MSSF is busy. (Note that IEAVMSF converts this condition code to a return code of 4,
busy.)

MVS Diagnostic Techniques

Service Processor Call SVC .and SERVICE CALL Instruction
Note: This topic describes the MVS support for processor complexes with the
Service Processor Architecture. See the topic "Service Processor Call SV C and
MSSFCALL DIAGNOSE Instruction" for a description of the MVS support for
processor complexes with a monitoring and system support facility (MSSF).
The Service Processor Call SVC (SVC 122) is a type 2 extended SVC with a
routing code of 6 in register 15. The SVC is used with processor complexes that
have the Service-Processor Architecture.
MVS system routines issue the Service Processor Call SVC to request various
hardware functions and to obtain hardware status information.
When the Service Processor Call SVC is issued, the Service Processor Call SVC
processing routine lEAVMSF processes the SVC request. IEAVMSF issues the
SERVICE CALL instruction to directly interface with the Service Processor
Architecture within the processor complex.
IPL module IEAVNIPO sets bit CVTSVPRC on (in field CVTFLAGI at X'178'
in the CVT) to indicate to IEAVMSF (and other system modules) that the
processor complex has the Service Processor Architecture.
For program logic information, refer to the System Logic Library, System
Initialization Logic, and Input/Output Configuration Program (IOCP) Logic.
The following topics briefly describe the:
•

Service Processor Call SVC (SVC 122) used with the Service Processor
Architecture

•

SERVICE CALL instruction

Service Processor Call SVC (8VC 122) Used With the Service Processor Architecture
To issue the Service Processor Call SVC, the caller prepares a service call control
block (SCCB), also called a service processor data block, and a service processor
command word in the caller's own private area. The caller sets register 15 to 6
(the routing code) and sets register 1 to the address of a parameter list, which
points to the SCCB and the command word.
Register 1
Service call control block (SCCS)

Parameter list

Service processor command word

Section 5. Component Analysis

5-283

The parameter list is a standard SVC parameter list. The SCCB contains
command-dependent information and is used to send data to the service processor
and to receive responses and data from the service processor. The command
word specifies the command to be executed by the SERVICE CALL instruction.
Service Call Control Block (SCCD)
The SCCB (also called the service processor data block) is a variable-length data
area. The format of the block is:
0-1
Length
8

2
Callp.r
flags

I

3--5

I

6-7
Response

Reserved

I field

Data field
(Q to 4,088 bytes)

-"....-

L

Length - bytes 0 and I
specifies the length of the data block. The minimum length is eight
(X'0008') and the maximum length is 4,096 (X'1000') bytes. The length
varies depending on the command request.
Caller flags - byte 2
specifies command-dependent information.
Reserved - bytes 3 through 5
set to X'OOOOOO'.
Response field - bytes 6 and 7
receives the two-byte response from the service processor. The service
processor sets this two-byte field to indicate the status of the request. The
field must be set to X'OOOO' before issuing the Service Processor Call SVC.
Data field - byte 8 to end of data block
specifies command-dependent information, if any, related to the command.
SVC Abend and Return Codes With the Service Processor Architecture
Abend Code - The Service Processor Call SVC processing routine (IEAVMSF)
issues system abend code X'67 A' if the caller is not authorized to issue the SVC
or if an error occurs during processing of the SVC. Refer to System Codes for a
de'scription of code X'67 A'.

5-284

MVS Diagnostic Techniques

Return Codes - IEAVMSF returns the following codes in register 15 to the caller
of the SVC.
Code

Meaning

00(00)

Successful completion - the SCeB contains the service processor response (in bytes 6 and 7)
and any data (in the data field) requested on the command.

04(04)

The service processor is busy - the caller can reissue the SVc.

08(08)

One of the Service Processor Call SVC control blocks (MSFCB or MSFKB) is in use - the
caller can reissue the SVc.

12(0C)

The service processor is not available or the control block chain is invalid.

16(10)

The service processor did not respond during a 10-second disabled spin.

SVC Processing With the Service Processor Architecture
The Service Processor Call SVC processing routine (IEAVMSF) provides the
interface between system routines and the Service Processor Architecture.
lEAVMSF processes requests made by programs issuing the Service Processor
Call SVC and routines that branch-enter IEAVMSF.
lEAVMSF enqueues (using the ENQ macro) the system resource
SYSMSF,MSFCONTROLBLOCK.
When processing the SVC request, IEAVMSF copies the caller's service call
control block (SCCB) to the data block pointed to.by the MSFCB or MSFK B
control block. The service processor puts its responses and data into the data
block pointed to by MSFCB or MSFKB. lEAVMSF then copies the response
and data (if any) into the caller's SCCB.

Section 5. Component Analysis

5-285

Figure 5-53 shows an overview of lEAVMSF processing.
Service Processor
Call SVC (SVC 122)

~

I

SVC FLIH
CIEAVESVC)

~
IEAVMSF - Service Processor Call
SVC processing
routine

•

Validates the request.

--

-

IEAVEVAL
Validity check
routine

Invalid r equest
results i n
abend X' 67A '

Service processor
Executes the request.

•

Issues the SERVICE
CALL instruction.

-

• Generates an X I 2401
external interruption.

I

~
•

Waits for the completion
of the request to the service
processor.

~.

I EAVE EXT, lEAVMFIH, and
IEAVMSFS process the
interruption.

~
Caller

Figure 5-53.

Overview of SVC Processing With the Service Processor Architecture

SVC Control Blocks Used With the Service Processor Architecture
lEAVMSF uses the control blocks MSFCB and MSFKB to serialize requests.
MSFCB and MSFKB are created at NIP time by the RIM module lEAVNPE6
and are located in the SQA.

5-286

MVS Diagnostic Techniques

Figure 5-54 shows an overview of the Service Processor Call SVC control blocks.
I EAVMFRM

cvr

Service
processor
resource
manager

CVTMFRM
CVTMSFCB

MSFCB

MSFCB's
data block

cvrsCPIN
.MSFCAOB

MSFKB

MSFCBCMO*
MSFCMSFK

MSFKB's
data block

MSFKAOB
MSFKBCMO*

System
hardware
information
*MSFCBCMD and MSFKBCMD contain the
command word being processed.

Figure 5-54.

SVC Control Block Structure With the Service Processor Architecture

SERVICE CALL Instruction
The SERVICE CALL instruction (operation code X'B220') interfaces with the
Service Processor Architecture. It is used to request hardware functions and to
request hardware status.
The SERVICE CALL instruction is issued by the SVC processing routine
(lEAVMSF) when lEAVMSF is processing Service Processor Call SVC requests.
The SERVICE CALL instruction is also issued by other system components (such
as NIP, IPL, and SADMP) to obtain system and hardware information.
lEAVNIPO sets bit 22 of control register 0 (the class 21 external interruption
mask bit) to 1 for each processor. This enables the system for service signal
interruptions.
The service processor indicates the completion of the SERVICE CALL instruction
by generating an external interruption. The interruption code is X'240 1' .
SERVICE CALL IDstructlon Condition Codes

At the completion of the SERVICE CALL instruction, one of the following
condition codes is set in the PSW:
Code

Meaning

o

The service processor has initiated the request and a service-signal interruption will be presented
when execution completes.

2

The service processor is busy.

3

The service processor is not available.

Section 5. Component Analysis

5-287

Cross Memory Services
Cross memory services, a component of the MVS system control program,
consists of the program call/authorization ryC/AUTH) services and the PCLINK
STACK/UNSTACK/EXTRACT services. This chapter contains diagnostic
information for both the PC/AUTH and the PCLINK services.

PC/AUTH Services
The PC/AUTH services create and manage the data structures that support the
program call ryC) instruction and allow control of the cross memory
authorization structure. These services are used by supervisor state or PSW key
mask (PKM) 0-7 callers, usually subsystems, to set up the environment for
controlling cross memory access to programs and/or data.
There are three instances, other than when the PC/AUTH address space is
initialized, when PC/AUTH code is executed. The first is when an address space
is created, the second is when a task or an address space is terminated, and the
third is when one of the 11 PC/AUTH services is invoked.
All PC/AUTH code executes in the PC/AUTH address space (PASID=2) except
the NIP RIM (lEAVNPF5) and the PC/AUTH address space initialization
routine (lEAVXMIN).
When an address space is created, lEAVXMIN initializes its address space second
table entry (ASTE) and chains the new address space to the system linkage table
(SL T) and the system authorization table (SAT). The new address space is given
an authorization index (AX) of 0, which makes it unauthorized to issue the PT or
SSAR instruction to another address space. It has access only to those global PC
services that are available to all address spaces via the SLT.
When a task or address space terminates, the PC/AUTH resource manager
(lEAVXPAM) gets control. If a cross memory resource owning (CMRO) task or
address space is terminating, IEAVXPAM recovers PC/AUTH-related resources.
The 11 PC/AUTH services are invoked via macro calls by supervisor state or
PKM 0-7 callers. The following table lists the macro names with their descriptive
names. The table is arranged in the same order as the entries in the system
function table (SFT).

5-288

Macro

Descriptive Name

LXRES
LXFRE
ETCRE
ETDES
ETCON
ETDIS
AXRES
AXFRE
AXEXT
AXSET
ATSET

Linkage index (LX) reserve
Linkage index (LX) free
Entry table (ET) create
Entry table (ET) destroy
Entry table (ET) connect
Entry table (ET) disconnect
Authorization index (AX) reserve
Authorization index (AX) free
Authorization index (AX) extract
Authorization index (AX) set
Authorization table (AT) set

MVS Diagnostic Techniques

For a complete description of these macros, refer to OS/VS2 System Programming
Library: Supervisor. For a description of the logic of the PC/AUTH services,
refer to OS/VS2 System Logic Library and OS/VS2 System Initialization Logic.
For PC/AUTH services, this topic contains the following:
•
•
•
•
•

Module structure of the PC/Auth modules
Process flow of PC/AUTH processing
Control block structure of PC/AUTH control blocks
Recovery consideratioQ~ for PC/AUTH services
Debugging hints for the PC/AUTH services

Module Structure
All PC/AUTH service routines and their FRR are contained in the load module
lEAVXPCA, which is loaded into the PC/AUTH address space from
SYSI.LINKLIB by the PC/AUTH address space initialization module
IEAVXMAS. IEAVXMAS is loaded from SYSl.LINKLIB into the PC/AUTH
address space by the PC/AUTH NIP RIM, IEAVNPF5. IEAVXMAS is given
control during NIP via a LINK macro from IEEPRWI2.
The PC/AUTH service routines in load module lEAVXPCA are ordered in the
same sequence as the entries in the system function table (SFT) for their
corresponding services. The following table lists the modules in load module
lEAVXPCA. The load module has an alias associated with each entry point that
receives control via a PC instruction. The alias enables lEAVXMAS to issue a
LOAD macro for each of these entry points to obtain the entry point address,
which is stored in the entry table entry (ETE) associated with the service. The
FRR (lEAVXPCR) is not loaded and therefore does not require an alias. Also
shown in the table are the associated system function table (8FT) index value, the
service-in-control code (pCRASERV) value, and the entry table index (EX) value.
Note that when a PC/AUTH service routine abends, the service-in-control code is
the high-order byte of the halfword reason code.
Module
Name

Entry
Points

SFT
Index

PCRASERV

EX
Value

IEAVXLRE
IEAVXLFR
IEAVXECR
IEAVXEDE
IEAVXECO
IEAVXEDI
IEAVXRFE

1
2
3
4
5

01
02
03
04
05
06

0
1
2
3
4
5
6

IEAVXPAM

IEAVXLRE
IEAVXLFR
IEAVXECR
IEAVXEDE
IEAVXECO
IEAVXEDI
IEAVXARE
IEAVXAFR
IEAVXAEX
IEAVXAXS
IEAVXATS
IEAVXACK
IEAVXPAM

IEAVXPCR

IEAVXPCR

IEAVXSET

6
7
8
9
10
11

12

07
08
09
OA
OB

OC
OD

7
8
9
A

B

Service/Function
LXRES (LX reserve)
LXFRE (LX free)
ETCRE (ET create)
ETDES (ET destroy)
ETCON (ET connect)
ETDIS (ET disconnect)
AXRES (AX reserve)
AXFRE (AX free)
AXEXT (AX extract)
AXSET (AX set)
ATSET (AT set)
Authorization check
PC/AUTH resource
manager
PC/AUTH FRR

III,

I

~/

Section 5. Component Analysis

5-289

There are three modules in the nucleus that are related to the PC/AUTH services.
They are: ,
lEAVXSFM -

a nonexecutable module containing the system function table (lEAVXSFT). It
provides.PC numbers for system services and pre-assigns linkage indexes (LXs) as
system LXs. When a system LX is connected to an entry table, all address spaces are
then connected to that system entry table.

iEAVXNEP -

a nonexecutable module containing the nucleus entry point table (lEAVXNEn. It
contains pairs of names and virtual addresses used to locate nucleus routines that can
be invoked by a PC instruction.

lEAVXEPM -

a service module used by the entry table create service (lEAVXECR) to find the
location of requested nucleus routines. It is also used by the PC/AUTH address space
initialization module (lEAVXMAS) to find the location of the OD6 abend routine
(lEAVXABE, located in lEAVXEPM).

The PC/AUTH address space initialization routine (lEAVXMIN) is in the link
pack area:
lEAVXMIN -

initializes the address space second table entry (ASTE) of a new address space, and
chains the new address space to the system linkage table (SLT) and the system
authorization table (SAn. IEAVXMIN is contained in the load module
IEAVEMCR.

Process Flow

When one of the PCIA UTH services is invoked by a macro call from a system
routine, the macro-generated code saves the caller's registers in a standard save
area, sets up the necessary parameters, and then issues the PC instruction. When
the service completes its function, it returns to the caller by issuing the PT
instruction. The macro-generated code then restores the caller's registers (except
those containing output values).
Each PC/AUTHservice routine performs a common sequence of operations.
Upon entry, each routine Saves the PC instruction information by using the
PCLINK STACK service. The routine then serializes its operation with other
services by obtaining the PC/AUTH address space's local lock. It then sets up
two levels of FRR for recovery, and obtains (via a GETMAIN) its dynamic work
area from the private area of the PC/AUTH address space.
At this point, each service routine performs its own service function.
Upon successful completion, the service routine frees (via a FREEMAIN) its
dyriamic work area, deletes its FRR coverage, and releases PC/AUTH address
space's local lock. The service then restores the information necessary to issue the
PT instructi'on to the caller by invoking the PCLINK UNSTACK,THRU service,
and then issues the PT instruction.

5-290

MVS Diagnostic Techniques

Control Block Structure

Most control blocks and programs related to the PCjAUTH services are located
in the LSQA, or pageable private area of the PCjAUTH address space.
LSQA
Because they must reside in fixed real storage, the control blocks that are accessed
by the cross memory instructions reside in the LSQA (subpool 255) of the
PCjAUTH address space~ These control blocks include:
LT -

Linkage tables (LTs) consisting of linkage table entries (LTEs), mapped by IHALTE.

SLT -

SysteQl linkage table;

AT -

Authorization tables (ATs) with entries mapped by IHAATD.

SAT -

System authorization table.

ET -

Entry tables (ETs) consisting of entry table entries (ETEs), mapped by IHAETE.

LPA -

PC/AUTH's latent parameter areas (LPAs) associated with PCJAUTH's ETEs. (Used only to
find the PCLlNK stack pool header.)

Pageable Private Area
The control blocks that are needed only by the PCjAUTH service routines reside
in the pageable private area (subpoo1229) of the PCjAUTH address space. These
control blocks include:
XMD-

Cross memory directory, mapped by IHAXMD.

LXAT-

Linkage index allocation table, mapped by IHALXAT.

AXAT-

Authorization index allocation table, mapped by IHAAXAT.

ETIB/ETIX - Entry table information block (ETIB) and ETIB extension (ETIX), mapped by
IHAETIB.

The formats of these control blocks are described later in this chapter.
Subpool 229 is also used for the dynamic data area storage for each of the
PCjAUTH service routines and their FRR, and for all temporary storage needed
by the services (such as the force disconnect queue blocks (FDQBs) used by the
LXFRE service for the FORCE option).
SQA
The doubleword latent parameter area (LPA) associated with each entry table
entry (ETE) is located in the SQA (subpool 245) for all entry tables (ETs) except
PCjAUTH's LPAs, which are located in the LSQA (subpool 255) of the
PCjAUTH address space.
Figure·5-55 shows an overview of the control block structure related to the
PCjAUTH services. More detailed control block diagrams are shown in OS j VS2
System Logic Library (in the topic "PCjAUTH Services"), and in OSjVS2 System
Programming Library,' Debugging Handbook.

Section 5. Component Analysis

5-291

PSA
I

I

PSASVT
I

-

I

SVT (Supervisor vector table)
SVTXMD

-

SVTXMSOP
SVTXM~UP

- - - - - - - --- - - - - - - - l~

-

LXAT

XMD

~-

XMDLXAT

t ...

XMDETIBF
XMDETIBL

ETIB

I---

ETiBNEXT -

@[

XMDAXAT ~

~-

+-.

I

ETIB
ETIBBACK

:1-'
- !

.. ETIX

ETIXEXT

~I

ETIBFEXT

L_ ETIX
~I

- - - - I, ---G)
A

ASCB

LT/SLT

ASCBLTOV
ASCBATOV
ASCBASTE

ASTE
ASTEICMA
ASTEATO
ASTEAX
ASTELTD

I,.

LPA

I~

0- PC/AUTH pageable private storage (subpool 229)
@@-

SOA (subpooI245)
PC/AUTH LSOA (subpool 255)

0- The ETIB contains addresses and lengths of its associated ET and LPA.

Figure 5-55.

5-292

MVS Diagnostic Techniques

PC/AUTH Control Block Structure

I

Control Block Formats

The format of the PC/AUTH control blocks (XMD, LXAT, AXAT, and
ETIB/ETIX) are described in this topic. Also, descriptions of key fields and
indicators in selected system control blocks (ASCB, ASTE, and SVT) are
provided.
XMD Control Block

The cross memory directory (XMD) anchors the other PCjAUTH control blocks.
Also, lEAVXMIN uses values from the XMD to initialize the AT and LT
pointers for a new address space.
Offset

Field

Contents

X'OO'
X'04'
X'OS'
X'tO'
X't4'
X'I5'
X'18'
X'IC'
X'IE'

XMDXMD
XMDLXAT
XMDETIBF
XMDETIBL
XMDAXAT
XMDFLGS
XMDRSV9
XMDRSVIO
XMDATLND
XMDSATLN

X'20'
X'24'
X'28'
X'2C'

XMDSATOR
XMDSATOV
XMDSLTD
XMDSLT

'XMD' acronym.
Address of the LXAT.
Address of the first ETID on the queue.
Address of the last ETIB on the queue.
Address of the AXAT.
Reserved.
Reserved.
Reserved.
Length, in bytes, of the SAT.
Bits 0-11 contain the number of words, minus one, in the SAT. Bits 12::-15
are zero. Used to initialize an ASTE.
Real address of the SAT in a format to initialize an ASTE.
Virtual address of the SAT.
Real address of the SLT (with the valid bit .on) in an ASTE format.
Virtual address of the SLT.

X'OC'

AXAT Control Block

The authorization index allocation table (AXAT) contains authorization index
(AX) ownership information.
Offset

Field

Contents

X'OO'
X'04'
X'08'
X'OC'
X'lO'

AXATNAME
AXATCT
AXATAVAL
AXATRSVD
AXATENT
AXATENTY

'AXAT' acronym.
Count of entries in the AXAT.
Number of entries currently available (unreserved).
Reserved.
First two-byte AXAT entry.
(Alternate name for the AXAT entry.)

A zero entry indicates that an AX is unreserved. If an entry is nonzero, it
contains the ASID that has reserved (owns) the corresponding AX. The first
entry in the table is the AX=O entry, the second is the AX= I entry, and so on.
The first two AXs are pre-assigned and owned by the PC/AUTH ASID.
Therefore, the first two entries always contain the PCjAUTH ASID, which is 2.
The following shows an AXAT as it might appear in a dump.
'AXAT'
CIE1CIE3

CT
0080

AVAL
003C

AX=O
0002

AX= 1
0002

AX=2
0009

AX=3
0013

AX=4
0000

\

'I

jj

Section 5. Component Analysis

5-293

LXAT Control Block

The linkage index allocation table (LXAT) contains linkage index (LX) ownership
information.
Offset

Field

Contents

X'OO'
X'OO'
X'04'
X'06'
X'08'

LXATHDR
LXATLXAT
LXATHILX
LXATMSLX
LXATINDX

LXAT header.
'LXAT' acronym.
Highest LX contained in the LXAT.
Maximum system LX in the LXAT.
Linkage index status, array -

Each entry in the array contains:
X'OO'
X'02'

LXATASID
LXATBIND

X'04'

LXATETCT

X'06'
.1 ......

LXATFLGS
LXATRIP
LXATOWND

.. I .....
.. .I ....

LXATSYS
LXATDORM

.... III I

LXATRSVI
LXATRSV2

I .......

X'OT

The ASID that owns this index. (Valid only if LXATOWND is on.)
The bind count - count of address spaces using this LX. For a system LX
that was ever connected, the field is X'FFFF'.
The entry table connect count - count of ETs connected to this LX. For a
system LX that is connected, the field is X'FFFF'.
Flag byte:
An LXRES macro is in process for this LX.
This LX is reserved - owned by the address space whose ASID is in
LXATASID.
This is a system LX .
This system LX is dormant. A dormant LX is a system LX whose owning
address space has terminated. A restartable subsystem that restarts in a
new address space can reconnect to this LX.
Reserved.
Reserved.

The LXAT is divided into two sections. All the LXs up to the LX number in the
LXATMSLX field are permanent system LXs. This number can be altered by
zapping the SVTMSLX field prior to IPL or during IPL but before PC/AUTH
initialization; it cannot be altered after IPL. The remainder of the LXs are
non-system LXs. For an LX of either type to be available for assignment by the
LXRES macro, the LXATOWND bit must be off and the LXATBIND and
LBXATETCT fields must both be zero. The following shows an LXAT as it
might appear in a dump:

LX=O:

'LXAT'
D3E7
ASID
0002

CIE3
BIND
FFFF

HILX
0020
ETCT
FFFF

MSLX
0010
FLGS
6000

LX=I:

ASID
0003

BIND
FFFF

ETCT
FFFF

FLGS
6000

LX=2:

ASID
0004

BIND
FFFF

ETCT
FFFF

FLGS
6000

ASID
0000
ASID
0000

BIND
0000
BIND
0000

ETCT
0000
ETCT
0000

FLGS
2000
FLGS
0000

LX=lO:
LX= 11:

5-294

MVS Diagnostic Techniques

Program call/authorization
(PCjAUTH)
Global resource serialization
(GRS)
Allocation address space
(ALLOCAS)

Available system LX
Available non-system LX

ETIB and ETIX Control Blocks

The entry table information blocks (ETIBs) contain entry table ownership and
connection information. They are arranged in a double-threaded queueA For
non-system connections, connection information is kept in ETIB extension blocks
(ETIXs), which are queued off the ETIB. ETIXs are arranged in a
single-threaded queue.
The format of the ETIB is:
Offset

Field

Contents

X'OO'
X'04'
X'OS'
X'OC'
X'to'

ETIBETIB
ETIBASCB
ETIBNEXT
ETIBBACK
ETIBETR

X'14'
X'IS'
X'Ie'
X'20'
X'24'
X'28'
X'29'

ETIBETV
ETIBLPAO
ETIBLPLN
ETIBRSVI
ETIBRSV2
ETIBRSV3
ETIBFLGS

'ETIB' acronym.
Address of the ASCB that owns the entry table (En.
Forward link fdr the ETIB queue.
Backward link for the ETIB queue.
Real address of the associated ET. Bits 26-31 contain an indicator of the
ET length (the number of ETEs/4 - 1).
Virtual address of the associated ET.
Address of the latent parameter area (LPA) for the ET.
Length of the latent parameter area (LPA).
Reserved.
Reserved.
Reserved.
Flag byte:
ETIBSYS This entry table is a system ET. (It is connected to a system
LX and is available to all address spaces.)
ETIBSS
This ET has space switch entries. (That is, an address space
switch occurs when the program described by the ETE is
invoked via the PC instruction.
ETIBCIL Connection information has been lost.
Reserved.
Count of connections to this entry table (ET). (For a system ET, this
value is X'FFFF'.
Address of first ETIX. This field is zero if there are no connections. It is
not used for system ETIBs (ETIBSYS = 1).

1. ......
.1. .....

.. 1. ....
.. .1 1111

X'2A'

ETIBCNCT

X'2C'

ETIBFEXT

The format of the ETIX is:
Offset

Field

X'OO'
X'04'
X'OS'
X'OA'
X'OC'

ETIXETIX
'ETIX' acronym.
ETIXRESV
Reserved.
ETIXSLOT
Count of connection slots in the ETIX (X' A').
ETIXFREE
Free slot count.
ETIXEXT
Pointer to next ETIX.
This field is followed by an array of 10 connection slots that show which address spaces are
connected to the ET and which LX the ET is connected to.
ETIXASIO
ASIO of the address space connected to this ET.
ETIXLX
Linkage index (LX) at which this ET is connected in the linkage table of
the above ASIO. (This value is the 12-bit LX value, right justified - not
the LX value as it is returned by the LXRES service.)

X'OO'
X'02'

Contents

The following shows an ETIX as it might appear in a dump:
'ETIX'
C5E3C9E7

reserved
00000000

SLOT/FREE
000AOO07

next ETIX
00000000

SLOTt:
ASIO/LX
00140005

SLOT2:
ASIO/LX
000EOO05

SLOT3:
ASIO/LX
00000000
(free)

SLOT4:
ASIO/LX
002COO05

SLOT 5:
ASIO/LX
00000000
(free)

... SLOT 10:
.. , ASIO/LX
... 00000000
(free)

Note: Used slots are not necessarily contiguous. Slot 3 is free, which indicates
that an address space was once connected and has been disconnected.

Section 5. Component Analysis

5-295

Key Fields and Indicators in System Control Blocks

The following fields and indicators in the ASCB, ASTE, and SVT (which are not
in the PCjAUTH address space) contain information related to the PC/AUTH
services.
ASCBETC -

This field indicates the number of entry tables (ETs) currently owned by the address
space. This count should always be equal to or greater than the number actually
owned, which is indicated in the ETIB queue. The PCjAUTH resource manager
(IEAVXPAM) keys on this value to determine if any ETs owned by an address space
must be cleaned up.

ASCBETCN -

The field indicates the number of connections to entry tables (ETs), owned by this
address space that contain space switch entries. This count should always be equal to
or greater than the number of connections that actually exist. A nonzero value in this
field indicates, that the authorization index (AX) of the address space cannot be
changed.

ASCBLXR -'

This field indicates the number of linkage indexes (LXs) reserved by this address
space. This count should always be equal to or greater than the number of LXs
reserved as indicated in the LXAT. The PCjAUTH resource manager (IEAVXPAM)
keys on this value to determine if any LXs must be freed for an address space.

ASCBAXR -

This field indicates the number of authorization indexes (AXs) reserved by this
address space. This count should always be equal to or greater than the number of
AXs as indicated in the AXAT. The PCjAUTH resource manager (IEAVXPAM)
keys on this value to determine if any AXs must be freed for an address space.

ASCBXMET -

This bit indicates that either space switch entry tables are owned by the address space,
or incomplete termination processing of PCjAUTH resources for the address space
has prevented reuse of the ASID.

ASCBXMEC - This bit indicates that one or more entry tables containing space switch entries were
created by this address space.
ASTEICMA -

This bit (high-order bit in field ASTEATO) indicates that the address space associated
with this ASTE is not available for cross memory access.

ASTELTV -

This bit (high-order bit in field ASTELTD) indicates that the linkage table entry
(LTE) is valid.

SVTXMSOP -

This bit indicates that the PCjAUTH services are operational.

SVTXMSUP -

This bit indicates that the PCjAUTH services have been initialized.

Recovery Considerations

PCjAUTH recovery is designed to recover from nonrecursive errors that do not
cause permanent damage to critical PCjAUTH data structures. All of the
PCj A UTH service routines and the resource manager are covered by a common
FRR routine, lEA VXPCR. The FRR contains a validation routine that attempts
to detect damage to PCjAUTH's pageable control blocks. If the FRR determines
that damage has occurred, it disables further execution of PCjAUTH services by
turning off the SVTXMSOP (operational) bit in the SVT. This prevents
PCjAUTH from continuing execution with known defective data. The FRR does
not contain logic to repair or reinitialize PCjAUTH if its control blocks are
damaged, with the exception of the ETIB/ETIX structure. The ETIB/ETIX
queues can be repaired by the queue verification routines, isolating the problem to
a subset of users while maintaining system integrity. PCjAUTH mainline service
routines always check that PC/AUTH is operational (SVTXMSOP= 1). They
assume, if PCjAUTH is operational, that PC/AUTH's control blocks are valid if
their acronyms are valid.

5-296

MVS Diagnostic Techniques

The FRR performs those recovery functions that are common to all the service
routines. This includes recording data in SYSl.LOGREC, taking an SVC dump
of PCjAUTH data at the time of the error, and validating the PCjAUTH control
blocks. If a service requests a retry, a retry of the function is performed. If retry
is not performed, a cleanup exit (in the service routine module) might be given
control to clean up resources specific to the service. The FRR then cleans up the
service routine's dynamic storage and PC LINK stack entry, and percolates to the
caller with an X'053' abend.
For a detailed description of the interfaces between the service routines and the
FRR, refer to the program listing for module lEAVXPCR. Figure 5-56 shows
the relationship of the key PCjAUTH recovery data structures. The Program
Call recovery area (PCRA) is mapped by the IHAPCRA mapping macro. The
fixed portion of the service routine recovery area (SRRA) isa mapped by the
IHASRRA mapping macro. The formats of the SRRA, PCRA, and PCRA flag
field is provided in the following topics.
PC/AUTH
service
routine

Service routine's
dynamic work area

r

GETMAIN
dynamic
work area

-I

FRR stack

SETFRR
,; (IEAVXPCR)
:

Second
level FRR

J

-

I---

_ Main PCRA

,~

~

~~
PCRASRRA ,--

:
:
:

-l
...

SETFRR
(lEAVXPCR)
:
:

First
level FRR

1

,.

5-56.

First level
PCRA
:::~

~~
PCRAMAIN

:

Figure

~~

SRRADATA

:
:
:
:

I

-~ ~SRRA
~

--

PCI AUTH Recovery Areas

SRRA Control Block
The format of the service routine recovery area (SRRA) is:

~I

f

Offset

Field

Contents

X'OO'
X'04'
X'08'
X'OA'
X'OC'
X'IO'
X'14'
X'18'
X'IC'
X'20'
X'24'
X'28'
X'2C'

SRRANAME
SRRADATA
SRRADLEN
SRRASLEN
SRRABASE
SRRABAS2
SRRARREG
SRRARTY@
SRRASUML
SRRAESAR
SRRAHOME
SRRAMLIA

'SRRA' acronym.
Address of the service routine's dynamic work area.
Length of the work area.
Length of the SRRA.
Service routine base register.
Second base register.
Address of the retry registers (0-15).
Address of retry routine.
Optional SUMLSTA list.
Secondary ASID.
Address of home ASCB.
Address of module level information.
Key variables:
These variables are unique for each service routine. Refer to the program
listings of the service routines for a description of these variables.

SeCtion 5. Component Analysis

5-297

Main PCRA Control Block
The format of the main Program Call recovery area (peRA) is:
Offset

Field

Contents

X'OO'
X'OJ'
X'02'

PCRASERV
PCRAREAS

X'04'
X'OC'
X'IO'
X'14'

PCRASTIK
PCRAFOOT
PCRARRDA
PCRASRRA

Service-in-control code.
Abend reason code.
PCRA flags:
Refer to the following topic "PCRA Flags" for a description of these bits.
For the main PCRA, PCRA2ND = I.
PCLINK token value.
FRR footprint data. (See Note 1.)
Address of the FRR dynamic work area. (See Note 2.)
AddreSs of the SRRA.

Notes:
1.

The PCRAFOOT field contains a value that indicates which section of the FRR
(lEA VXPCR) is processing. These footprints are useful in debugging when the
ERR encounters an error. The functional meaning of these footprints is:
Value in
PCRAFOOT

FRR Label

Function

X'OO'

IEAVXPCR

X'ot'
X'02'
X'03'
X'04'
X'OS'
X'06'
X'07'

POINT I
POINT2
POINT3
POINT4
POINTS
POINT6
POINT7

Preliminary processing, SYSI.LOGREC preparation, and
recursion checking.
Issue the SDUMP macro.
Validate PCjAUTH's control blocks.
Retry, if requested.
Call cleanup exit, if requested.
Free the service routine's dynamic work area.
Cleanup the FRR's dynamic work area.
Issue PC LINK UNSTACK and percolate the error.

2.

The value in PCRARRDA does not point to the RRDA structure defined in
lEA VXPCR, it points to the beginning of the FRR's dynamic work area.

First Level PCRA Control Block

5-298

Offset

Field

Contents

X'OO'
X'OI'
X'02'

PCRASERV
PCRAREAS
PCRA

X'04'
X'OC'
X'IO'
X'14'

PCRASTTK
PCRAFOOT
PCRARRDA
PCRAMAIN

Zero.
Zero.
PCRA flags:
Refer to the following topic "PCRA Flags" for a description of these bits.
For the first level PCRA, PCRAIST= 1.
Zero.
Zero.
Zero.
Address of the main PCRA.

MVS Diagnostic Techniques

PCRA Flags
The contents of the PCRA flag bytes at offsets X'02' and X'03' are:
Offset

X'02'
1.......
. 1. .....
.. 1. ....

Field

.. .1 ....

PCRARSBI
PCRACML
PCRACMS
PCRAKCML

.... 1. ..
..... 1..

PCRACLUP
PC RARCUR

..... .1.

PCRAFRRE
PCRARMGR

....... 1

X'03'
1. ......

PCRA1ST

.1. .....

PCRA2ND

.. 1. ....

PCRANTH

... 1 ....

PCRAPERC

.... 1. ..

PCRAREC2

..... 1..

PCRAFRRG
PCRADUMP
PCRARSB2

.... .. 1.

.... ... 1

Contents

Flag byte:
Reserved .
The PC/AUTH address space local lock is held.
The cross memory services lock is held .
The caller of the service now running already held the PC/AUTH
address space's local lock, and therefore it should not be released if
recovery percolates to RTM. (This occurs when the ETDIS service is
called by either the LXFRE macro with the FORCE option, or by the
ETDES amcro with the PURGE option.)
Cleanup exit invocation is requested.
Retry recursion indicator. If this bit is on when the FRR is entered
after a retry, then the retry is recursive and a retry request is not
honored. The bit is set on by the FRR when it retries to a service.
The service must clear the bit (set it to 0) after setting a new retry
address if the service wants further retry capability.
lEAVXPCR has been entered as an FRR.
IEAVXPCR has been entered as a CML (cross memory lock)
resource manager.
Flag byte:
'This PCRA is associated with the first level FRR. If this bit is on, the
sixth word of the PCRA (PCRAMAIN) contains the address of the
main PCRA.
This is the main PCRA, associated with the second level FRR. If this
bit is on, the sixth word of the PCRA (PCRASRRA) contains the
address of the SRRA.
This PCRA is associated with a nested (or Nth level) FRR, which is
set by the second (or another Nth) level FRR to protect itself. If this
bit is on, the sixth word of the PCRA (PCRAMAIN) contains the
address of the main PCRA.
Percolate to the caller. This bit is set on by the FRR to indicate to
any higher level FRR that recovery is complete and it should
percolate to RTM.
Recursion in the FRR. This bit is set on to indicate that the FRR has
detected a recursive error in its processing.
An FRR GETMAIN is in progress.
An SDUMP macro has been issued during this recovery process .
Reserved .

Debugging Hints
1.

The RR,DA structure defined in lEAVXPCR contains many flags that are
useful in debugging problems in the FRR, including flags that footprint the
progress through the control block validation process. If the validation
routine takes a recursive program check during its processing, the PCjAUTH
services are made inoperable. Because an SDUMP macro is issued only once
during the recovery process, the values in the RRDA cannot be obtained
from a dump when errors occur in the FRR. Each level of the FRR that
executes, however, records the RRDEBUG portion of the RRDA in the
SYSl.LOGREC variable recording area. For a mapping of the RRDA, refer
to the program listing for module lEAVXPCR.

2.

For SVC dumps, the dump title indicates which service had the problem. It
also provides the reason code and diagnostic value (described in System
Codes) for X'053' abends, or the system completion code and register 14
contents for other failures .. The SUMDUMP portion of the dump provides a
synchronous dump of the PCjAUTH data at the time ofth~ failure and
Section

5. Component Analysis

5-299

before any retry or cleanup action has been taken by the FRR. The first
SUMLSTA record contains the SUMLSTA list of storage ranges to be
synchronously dumped. The second SUMLSTA record is the lEAVXPCA
load module containing the service routines, resource manager, and FRR as
they appear at the time of the failure. These two records are followed by
SUMLSTA records that contain the PC/AUTH control blocks as they existed
at the time of the failure.

5-300

3.

The main PCRA contains the pointer to the SRRA in the executing service's
working storage; it also contains many flags of value in determining what is
going on, especially if the error occurs during recovery, retry, or cleanup
processing. The main PCRA at the time the suspended summary dump was
taken can be found by looking in the SUMDUMP portion of the dump. It is
the work area portion of the first FRR on the formatted FRR stack from the
interrupt handler save area (IHSA). The same PCRA can also be found in
the variable recording area of the SDWA record in the SUMDUMP section
of the dump but it is more difficult to read because it might not start on a
word boundary. Be sure to use the PCRA found in the SUMDUMP output
and not one found in asynchronous portions of the dump because the latter
does not necessarily relate to the error.

4.

The SYSl.LOGREC records written during recovery processing provide a
large amount of data relevant to the problem. The variable recording area
(VRA) in the SDWA is fully used. The data in the VRA is in the
key-length-data format where the key fields are defined by the IHAVRA
macro. The data includes the main PCRA at the time of entry to the FRR,
possible diagnostic messages from the FRR's validation routine, possible
diagnostics from the queue verification routines, and as much of the service
routine's SRRA as possible. Each service routine declares variables that are
of value in debugging within the SRRA structure, with the most useful near
the beginning of the SRRA, thus enhancing the diagnostic value of the
SYS1.LOGREC record. The SYSl.LOGREC entry contains the registers at
the time of the failure except that for X'053' abends with a X'xx97'
(unexpected error) reason code, the original value of register 15 is in the VRA
(VRAKEY=VRAORI5) and the original system completion code is also in
the VRA (VRAKEY=VRAOA).

5.

In stand-alone dumps, if a PCjAUTH service routine was running when the
system failed, two PCRAs should be found in the PSA. Look for a six-word
FRR parameter area with a pointer in the sixth word pointing to another
FRR parameter area. The second (main) PCRA has a PCLINK stack token
value in the second word. The PC LINK token value appears as two small
halfword values, the first is the number of levels of Program Calls to the
currently executing service (usually 0001), and the second is the PC/AUTH
ASID. The sixth word is a pointer to the SRRA for the executing service
routine in the PCIA UTH address space. The first word of the SRRA
contains the SRRA acronym. The fourth word contains the first or only base
register value of the service routine that was executing. This value is close to
the beginning of the code for the service that was executing.

MVS Diagnostic Techniques

The following shows how FRR parameter areas might appear in.a dump.
FRR ENTRIES
PARMAREA
PARMAREA
PARMAREA
PARMAREA

6.

05004242
00000080
80000000
60000000

00010002
00000000
50027AIE
50E42032

00000000
00000000
007D2230
50E42032

01000000
00000000
00000000
OOA4F2B8

007D21E8
00000000
00000000
OOE44368

007D24EC
OOOOOD08
OO02883C
ooA4F4FO

If the problem is an X'052' abend that should not be occurring, the reason
code indicates what part of tne data structure to look at if the caller's input is
not in error. To look at the PC/AUTH data structures, use the DUMP
command or a SLIP trap with ACTION=SVCD to dump the PC/AUTH
address space. For example, if a caller tries to disconnect an ET that the
caller had connected and receives an X'052' abend with an X'0613' reason
code (indicating the specified ET is not connected), then the debugger should
look at the ETIB queue. It is possible in this example that the ETIX queue
had been truncated due to an error. If this had occurred, the ETIBCIL
(connection information lost) bit would be set on in the ETIB associated with
the ET. If no ETIB can be found that is associated with the ET, then the
ETIB might have been removed from the queue due to an error. If either of
these queue repair operations has occurred, there should be an X'OS3' abend
dump and a SYSl.LOGREC record written with queue verification
diagnostics in its VRA indicating why the element was removed. Note that
an ETIB associated with a connection or disconnection operation can be
readily found in the PC/AUTH address space. This is because the token
value received from the ETCRE service and passed to the ETC ON, ETDIS,
or ETDES service is the address of the ETIB. For this ETDIS service X'OS2'
abend descrihl.-d in this example, the token value related to the error is
supplied in register 2.

SLIP Traps

If a program check is occurring in a PC/AUTH service routine or in the FRR
that cannot be solved with the information provided in a dump or the
SYSl.LOGREC records, set a SLIP trap similar to the following to stop the
system at the point of error.
SLIP SET,ID=ERR2,ASID=2,ERRTYP=ALL,A=WAIT,END

This trap matches on all errors that occur in the PC/AUTH address space. Only
the PC/AUTH service routines, resource manager, and FRR execute in the
PC/AUTH address space. To determine the PC/AUTH ASID, issue a 'D A,ALL'
operator command.
If the error is an erroneous X'OS2' abend, a SLIP trap with COMP = OS2 and a
comparison of the reason code in register IS can be used to detect a. specific
X'OS2' abend. Further selectivity can be achieved in some cases by checking for a
specific diagnostic register value. For example, the following trap checks for an
AXRES request with an invalid request count of 0, and provides an SVC dump of
both the current (calling) address space and the PC/AUTH address space
(ASID=2).

)

SLIP SET, ID=COS2, COMP=OS2"ACTION=SVCD ,ASIDLST= (0,2) ,
DATA=(lSR,EQ,00000703,4R,EQ,OOOOOOOO),ML=1,END

Section 5. Component Analysis

5-301

PCLINK Services
The PC LINK service routines provide services for users of the Program Call (PC)
and Program Transfer (PT) instructions by saving key linkage information in
queues of PC LINK stack elements (STKEs). There is a separate queue for each
oRB or SRB. A program that receives control via a PC instruction should issue
the PC LINK STACK macro prior to updating registers 2, 3,4, 13, and 14 (and 0,
1, and 15 if they are parameter registers). A PCLINK stack token value is
returned in register 14. The called program can then perform its processing,
which might result in other PC instructions being issued.
When the called program is about to return to its caller, it should load registers 0,
1, and 15 with any data to be passed back to the caller. It should then issue the
PC LINK UNSTACK,THRU macro and provide the token value received on the
PCLINK STACK macro. This restores registers 3, 13, and 14, and, optionally,
the original PSW protect key. The called program can then issue the PT
instruction to return to the caller.
For a description of the PCLINK macro and services, refer to OSjVS2 System
Programming Library: Supervisor. For a description of the logic of the PCLINK
services, refer to OSjVS2 System Logic Library.
STKE Control Block
Figure 5-57 shows the control block structure of the PC LINK stack elements
(STKEs) when a program has passed control to another program (via a PC
instruction), and when a program that has received control (via a PC instruction)
abends.
Important fields in the STKE are:

5-302

Offset

Length

Name

Contents

X'C'

4

STKEPREV

X'I4'
X'I8'
X'IC'
X'20'
X'24'
X'34'

4
4
4
4
4
4

STKESA
STKERET
STKEPRI5
STKEPRMO
STKEPRMI
STKEEPA

Contains either the address of the prior STKE, or the address
of the next free STKE.
Address of the caller's register save area.
Address of the instruction following the caller's PC instruction.
Contents of parameter register 15.
Contents of parameter register O.
Contents of parameter register 1.
Address (near the beginning) of the program receiving control
(via the PC instruction).

MVS Diagnostic Techniques

Address
space X

Program A
issues a PC
to program B
in address
space Y.

Program A

PC

Address
space Y

Program B
issues a PC
to program C
in the same
address space.

STKEEPA

Program B's
register
save area
Program C's
STKE

Abend

Program C
abends. Its
FRR issues
SDUMP.

PSA

Figure

5-57.

PCLINK Control Block Structure

Section 5. Component Analysis

5-303

December 27, 1985

Module Structure

The PCLINK services are contained in the nucleus module lEAVXSTK, which
has the following entry points:
Entry Point

Function

IEAVXSTS
lEAVXSTN
lEA VXUNS
lEAVXUNN
lEAVXEXT

PCLINK STACK,SAVE = YES
PCLINK STACK,SAVE = NO
PC LINK UNSTACK,SAVE = YES
PCLINK UNSTACK,SAVE = NO
PC LINK EXTRACT

The recovery routines in lEAVXSTK are:
Entry Point

Function

FRRFRSTK FRR for PCLINK STACK service
FRRUNSTK FRR for PCLINK UNSTACK service
FRRUNSK2 FRR for the FRRUNSTK FRR

Debugging Hints

I.

All of the FRRs tum off the PC LINK super bit and issue the SETRP macro
to record the error to SYSI.LOGREC. FRRUNSTK also issues the SDUMP
macro and, if requested by the caller, attempts a retry.

2.

By looking at the STKEs in a formatted dump, you can track the transfers of
control between modules that issue the PC instruction. You can do this in
the same way you would look at save areas to track transfers of control
between modules that use standard linkage conventions.

3.

A key indicator and field in the PSA useful for debugging are:
PSASTKE -

Pointer to the current PCLINK stack element (STKE).

PSASTKSP - PCLINK STACK/UNSTACK super bit. This bit is set on to allow I/O and
external interruptions to be disabled when the PCLINK service routine sets an
FRR or issues the GETMAIN or GETSRB macro during expansion of the local
or global STKE pools.

4.

5-304

If an X'OD5' abend occurs (which indicates that a PT instruction failed) and
the value in register 3, 4 or 14 is in error, check the following possible causes
before assuming that the PCLINK UNSTACK macro failed. First check that
none of the contents in the registers are destroyed between the issuance of the
PC LINK UNSTACK macro and the PT instruction. Second, check that
none of the contents in the registers are destroyed prior to the issuance of the
PC LINK STACK macro at the beginning of the program. Note that the
PC LINK service does not check the contents of the registers it is saving.

MVS Diagnostic Techniques

Global Resource Serialization
The global resource serialization component provides ENQ/DEQ/RESERVE
services, operator commands, and GQSCAN macro support.
The ENQ/DEQ/RESERVE services control the use of serially reusable resources.
The ENQ macro requests the use of a resource. The RESERVE macro requests
the use of a resource and generates the hardware RESERVE instruction if the
resource is on a shared DASD. The"DEQ macro releases the resource.
The DISPLAY GRS and VARY GRS operator commands are provided. The
DISPLAY GRS command obtains information about the systems in a global
resource serialization complex and the CTC links for the system on which the
command was issued. The VARY GRS command resumes global resource
serialization activities following a ring disruption, resumes or suspends global
resource serialization processing in a system, or purges a system from the global
.
resource serialization complex.
The GQSCAN macro obtains the status of resources and their uses from control
blocks in the global resource serialization address space.
For information on how to use the services provided by global resource
serialization, refer to OS/VS2 System Programming Library: Supervisor. For
information about the global resource serialization commands, refer to Operator's
Library: System Commands. For logic information about this component, refer
to OS/VS2 MVS Global Resource Serialization Logic.
This section contains the following topics for global resource serialization:
•

Functional Overview - includes a brief description of the various
subcomponent functions.

•

Control Blocks - contains control block overviews related to selected
subcomponents.

•

Module Flow Diagrams - these diagrams show the flow of control between
global resource serialization modules for selected functions.

•

Diagnostic Aids - contains debugging hints to help you isolate problems in
global resource serialization.

Section 5. Component Analysis

5-305

Functional Overview
The global resource serialization component consists of several subcomponents.
All global resource serialization module names begin with ISG and the fourth
character identifies the subcomponent that the module supports. The following
table summarizes the module naming conventions.
Module names: ISGsmmmm
ISG = Global resource serialization
s=

Subcomponent

B
C
D
G/L

Ring processing
Command processing
Dump support
Resource request processing
G - Mainline ENQ/DEQ/RESERVE processing
L - Fast path ENQ/DEQ/processing
CTC processing
WTO/WTOR message processing
Initialization
Queue scanning services
Storage management

J
M
N
Q
S

mmmm = Module identifier
(Note: An exception is ISGJPARM, an initialization module.)

Ring Processing
The ring processing subcomponent has the following functions:
•

Pass to all systems in the main ring the information required to serialize
global resource requests across all the systems.

•

Add or delete systems from the main ring as specified in the initialization
parameters or requested by the operator.

•

Provide information about the system and CTCs in the complex.

Other subcomponents invoked by ring processing are:
•
•
•
•

CTC processing
Storage management
WTO /WTOR message processing
Resource request processing

Command Processing
The command processing subcomponent supports the VARY GRS and the
DISPLAY GRS operator commands. The global resource serialization interface
module executes in the master scheduler's address space and receives control from
the command service processor. The command interface module posts the
command router in the global resoUrce serialization address space. The command
router module attaches the DISPLAY, PURGE, QUIESCE, or RESTART
command request processor.

5-306

MVS Diagnostic Techniques

Other subcomponents invoked by command processing are:
•
•
•
•

Queue scanning services
Ring processing
·WTOjWTOR message processing
~torage management

Dump Support
The dump support subcomponent provides the support to dump the global
resource serialization control blocks. The dump support modules obtain and
format information for SNAP dump, SVC dump, print dump (PRDMP), and
interactive problem control system (IPCS). Queue scanning services is invoked by
dump support.
Resource Request Processing (Mainline and Fast Path)
The resource request processing subcomponent performs ENQ/DEQ/RESERVE
request processing. It is also invoked during task and address space terminations
to clean up outstanding requests. Fast path processing handles local ENQ and
DEQ requests which do not require special processing. Mainline processing
handles all other requests.
Other subcomponents invoked by resource request processing are:
•
•

Ring processing
Storage management

CTC Processing
The CTC processing subcomponent builds control blocks for the CTCs that
connect the system in a global resource serialization complex (based on
information specified in the GRSCNFxx member of SYSl.PARMLIB). It
initiates I/O on the CTCs and handles their interrupts. When an interrupt is
received, it invokes the ring processing subcomponent.
WTOJWTOR Message Processing
The message processing subcomponent issues global resource serialization
messages (ISGnnns) to the operator and to the system log. It issues both
informational (WTO/MLWTO) and reply (WTOR) messages to the operator and
informational (WTL) messages to the system log.
Initialization
The initialization subcomponent has two primary functions:
•

Creating and initializing the global resource serialization address space.

•

Establishing the global resource serialization complex defined in the
GRSCNFxx and IEASYSxx members of SYS1.PARMLIB.

All other subcomponents are invoked by initialization except dump support.

Section 5. Component Analysis

5-307

Initialization is not discussed further in this publication. See OS/VS2 System
Initialization Logic for information on this subcomponent.
Queue Scanning Services
The queue scanning services subcomponent processes the requests made via the
GQSCAN macro.
Other subcomponents invoked by queue scanning are:
•
•

Storage management
Ring processing

Storage Management
The storage management subcomponent maintains the resource queue area (RQA)
of the global resource serialization address space. An interface module provides
access to the storage manager for routines that do no execute in the global
resource serialization address space. Also, the storage manager hashes resource
names and SYSIDjASID information to expedite searches into the local queue
hash table (LQHT), global queue hash table (GQHT), and system/ASID hash
table (SAHT).

Control Blocks
Global resource serialization uses the following control blocks. For the format of
these data areas, refer to OSjVS2 System Programming Library: Debugging
Handbook and OS/VS2 Data Areas (microfiche).
Data

5-308

Area

Description

CEPL

Command ESTAE parameter list - anchors the LIFO queue ofCRWAs and contains an
error recording area for requested functions.

CRB

Command request block - contains information required to process a DISPLAY GRS or
VARY GRS command.

CRWA

Command recovery work area - contains the error information used by the command
recovery routine to handle errors.

DEPL

SDUMP ESTAE parameter list - contains information used by the global resource
serialization dump support subcomponent to process an SDUMP request.

DPL

DEQ purge list - contains the information needed to complete processing for a DEQ
SYSID, DEQ ASID, or DEQ TCB purge request.

DSPL

Dump sort parameter list - contains information for the global resource serialization dump
sort routine.

GCB

Global resource serialization CTC-driver request block - is the parame~r list required by
the CTC-driver for all functions (except extracting area lengths).

GCC

Global resource serialization CTC-driver control card table - contains the information from
the global resource serialization SYSl.PARMLlB member for this system.

GCL

Global resource serialization CTC-driver link control block - contains information related
to each CTC in the system.

MVS Diagnostic Techniques

GCP

Global resource serialization CTC-driver buffer prefix - contains message length and
validity checking data.

GCQ

Global resource serialization CTC-driver queueing element - contains information used by
CTC processing when sending or receiving a message or an unusual-event notification.

GCT

Global resource serialization CTC-driver branch table - contains addresses of the CTC
processing DIE routines and exit routines.

GCV

Global resource serialization CTC-driver vector table - contains addresses of CTC-driver
entry points for CTC.:driver functions and information common to all CTCs used by CTC
processing.

GCX

Global resource serialization CTC-driver extract table - is the parameter list required by the
CTC-driver for the extraction of area lengths.

GVT

Global resource serialization vector table - contains common information (global queues,
pointers and entry point addresses) for all global resource serialization functions. It also
has sections containing information for the various subcomponents.

GVTX

Global resource serialization vector table extension - contains information specific to the
global resource serialization address space.

MRB

Message request block - contains information required to process message requests.

PEL

Parameter element - is the input parameter list to ENQ/DEQ/RESERVE processing.

PEXB

Pool extent block - maps a 4K page in the RQA.

PQCB

Placeholder queue control block - contains the information necessary to resume a global
resource serialization queue scanning request.

QCB

Queue control block - describes a resource to global resource serialization.

QEL

Queue element - describes the requester of a resource to global resource serialization.

QFPL

ENQ/DEQ/FRR parameter list - is the FRR parameter list used by ENQ/DEQ/RESERVE
processing.

QFPLl

Queue scanning services FRR parameter list - is the FRR parameter list used by queue
scanning services.

QHT

Queue has table - contains queue hash table entries. Each queue hash table entry is a
double-headed anchor of QCBs. There are two QHTs; one for global requests (GQHT),
and one for local requests (LQHT).

QWA

Queue work area - is a work area used by ENQ/DEQ/RESERVE processing modules.

QWB

Queue work block - describes a resource request. A global resource request is described by
a QWB in the private area of the global resource serialization address space. A local
resource request is described by the permanent QWB in the SQA.

QXB

Queue extension block - contains the data that describes an ENQ/DEQ/RESERVE request.

REPL

Ring processing EST AE parameter list - is the EST AE parameter list used by ring
processing.

RIB/RIBE Resource information block - contains the information that describes a resource and any
requesters for the resource. The variable portion of the RIB (containing RIB extents) is
located immediately after the RIB. Each RIB extent (RIBE) describes a requester of the
resource. RIBs and RIBEs are returned to the issuer of the GQSCAN macro.
RNLE

Resource name list entry - contains information about resources that are to be included or
excluded from global resource serialization processing and RESERVE resources that are to
be converted to global ENQs.

RPT

Resource pool table - contains entries for each cell type in the RQA There are two RPTs one for global resources (GRPT), and one for local resources (LRPT). Each RPT points to
the first and last PEXB for that pool.

Section 5. Component Analysis

5-309

RQA

Resource queue area - contains PEXBs that define QCBs, QELs, QXBs, QWBs, PQCBs,
MRBs, CRBs, and work areas.

RSA

Ring processing system authority message - is used to pass command data and
ENQ/DEQ/RESERVE requests between global resource serialization systems in the main
ring.

RSAIRCD Ring processing information record - is used to pass control information between systems
that are not both in the main ring.
RSC

Ring status change parameter list - is the parameter list used to call the interface module
ISGBCI.

RSL

Ring processing system link block - contains information about a CTC and is used by
global resource serialization ring processing functions.

RST

Ring processing status table - contains the status of global resource serialization systems
and CTCs.

RSV

Ring processing system vector table - contains information used by the global resource
serialization ring processing modules.

SAHT

System/ASID hash table - contains entries that point to a chain of QELs that define global
resource requesters from another system.

SMPL

Storage management parameter list entry - contains information for a request to global
resource serialization storage management.

Control Block Overviews
The figures in this topic show the control block structures of the global resource
serialization control blocks for the following:
•
•
•
•
•

•

•
•

5-310

Permanent TCBs
CTC processing
Ring processing
Command processing
ENQjDEQ processing
- Local resources
- Global resources
Queue scanning services
- Local resources
- Global resources
Storage management
WTOjWTOR Message processing

MVS Diagnostic Techniques

ASCB

ASXB

PRB
IEAVAROO
Region
control
task
PRB
IEAVTSDT

2

SVCdump
task
TCB

I TCBRBP
3

I
I

I

PRB
IEEPRWI2

I

Started
task control
TCB

I TCBRBP
4

I

I

I
I
I

TCB

I TCBRBP

4

I
I

I

I

--

4

ISGNASIM
Address
space
initialization

PRB
ISGCMDR
Command
router

...

-

3

PRB
ISGGRPOO
Global
resource
processor

I

TCB

I TCBRBP

-

--

PRS

PRS

I

...
II----~:

-

~

ISGBTC
Ring
processing
task mode
controller

Notes:
• The numbers show the hierarchy.
• When GRS=START or JOIN, all
TCB/PR Bs are permanent.
• When GRS=NONE: all TCB/PRBs
.are perman.ent except the TeB/PRB
for ISGGRPOO, which is temporary; and
the TCB/PRB for ISGBTC, which is
not present.

Figure 5-58. TCBs in the Global Resource Serialization Address Space

Section 5. Component Analysis

5-311

CVT

GClWGCQF
GClRGCQF
GCl

sense IOSB/SRB
read IOSB/SRB

GCl

write IOSB/SRB

\

\
\

GCl

(Read channel program)
(Write channel program)

\ Sense
IOSB/SRB
IOSUCB

Figure 5-59.

5-312

CTC Processing - Control Block Overview

MVS Diagnostic Techniques

CVT

If
CCVTGVT I
I

OWB
request
queue

I

i(!

GVT-

I

GVTGVTX

RSA

proc~s

OWB

!/

GVTREOO
GVTPRCOF

.queue
RSV

RSVIBFOR

GVTX

VI

RSA

RSVOBFOR

I

GVTXBRSV
RSVBCIBF

~

I

Main ring
input buffer

Main ring

output buffer

RSAIRCD

~ buffer

RSL (for CTCn)

RSL (for CTC1)

RSVRSLO

/

~

RSLNRSL

~~ GCB
GCBABUF

~~

$:~GCB
GCBABUF

~
RSAIRCD
buffer

RSVOWBIF
RSVOWBSF
RSVOWBHF

RSVENTY

V
-

RSAIRCD

J

buffer

OWB
internal
queue

I

~

r-_

,."

,

OWB
sent
queue
OWB
hold
queue

- -- ........

""" """
Figure 5-60.

~

....

r"-,

I'Ll

~~

RSVENTY (1 entry per system)
SYSNAME
SYSID
status flags

Ring Processing - Control Block Overview

Section 5. Component Analysis

5-313

Command

request
queue

Command
work

queue

Command
cleanup

queue

CRBCEPL
CRBRST

Figure 5-61.

CVT

Command Processing - Control Block Overview

aCB

aCB

QCBFOEL
aCBFaEL

aELOXB

ASCBLQEL

Figure 5-62.

5-314

ENQ/DEQ Processing - Local Resources - Control Block Overview

MVS Diagnostic Techniques

--

--.

aEL

• OCB

CVT

~ CVTGVT

!

OCBFOEL

GVT
GVTGVTX

,

J

GVTX

OCBFOEL
aCB

I

~QXB

OCBNOCB
OCBFOEL

GVTXGOHT

"OEL
OELNOEL

!

OELOXB

(

OCB

-

OELNOEL

... ·OEL
OELNOEL

OELOXB

V

J

aXB

Q:~LNQELQ U

OELOX~

~faEL

~

OELNOELO , /
GOHT

~

I

OELOXB

~OXB

I

--J
-

J

OELQXB.

'.-/
(lXB
ASCB

\..

SYSID/ASID
hash table

OEL
~~

ASCBGOEL
I

I

I

j

l,)

OELNOELO
OELNSYN
OELOXB

OXB

I
Figure 5-63.

ENQ/DEQ Processing - Global Resources - Control Block Overview

Section 5. Component Analysis

5-315

CVT

OCB

~

POCB

~

I

I

OCBNOCB

CVTGVT
J

OCBFOEL

GVT

~

POCBNOCB
POCBFOEL

J

GVTGVTX

I

/

ASCB
ASCBLOEL

GVTX

v--~ ...

Vi

OCB

...
~

OCBFOEL

OEL

r

OELOXB

I

OELNOELO

I

I

I

LOHT

tJ

....

/

~

OELOXB

-

OEL

---,oo;;j

OELNOELO
OELOXB

OXB
ASCB

)

OEL
OELNOEL

-

-

I
I

I

ASCBLOEL :
I

I

5-316

OEL

OELOXB

OXB

GVTXLOHT

Figure

~--

5-64.

Queue Scanning Services - Local Resources - Control Block Overview

MVS Diagnostic Techniques

\

OXB

I

CVT

OCB

.. aEL
OELNOEL

/t-------t~
OCBFOEL

~ CVTGVT

?

1-------1~OEL
OELOXB

POCB

GVT
J

POCBNOCB

OCB

-'

I'

GVTX

OCBNOCB

GVTXGOHT

OCBFOEL

D

D

I

I{

~

___-II ,

OELOXB

OXB

, OEL

t't-------1
OELOXB

OXB

",,~O_E_L_ _--,

J

~ ~ OELOXB
r ASCBGOEL
~""O_X_B_ _...
ASCB

GOHT

I

V
I

I

l' OCB

~OEL

ASCB
I

I-'

POCBFOEL

~ oxe

~

QELNOEL

r'~

(

1'1------4

GVTGVTX

4

~

~;.;;;.;::...-.--~

~ OELNOEL

ASCBGOELJ--'~~------~

I

-'

OELNOELO

SYSID/ASID
hash table

QELNOELO

1-----

OELNSYN
QELOXB

Figure

5-65.

-

OXB

Queue Scanning Services - Global Resources - Control Block Overview

Section 5. Component Analysis

5-317

GVT
RQA

rHi;e-;j - - - - - --1
I

I

GVTXLRPT

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _.....

~w~

______

Figure 5-66. Storage Management - Control Block Overview

5-318

MVS Diagnostic Techniques

.J

Synchronous Request
MRB

Register 1

I....__---'~

MRB@

~

MRBRMRB

MRB

~W_---------

Alnychronoul Request

MRB
MRBCEPL
MRBRMRB

Note: Control block structure when the
message processing routine (lSGMSGOO)
receives control.

Figure 5-67. WTO/WTOR Message Processing - Control Block Overview

Section 5. Component Analysis

5-319

Module Flow Diagrams
The figures in this topic show the flow of control between global resource
serialization modules for selected functions. Figure 5-68 shows an overview of
module flow between subcomponents, and includes a directory of the module flow
diagrams to help you use them.
In the diagrams, a solid double line indicates communication across the I/O
interface between systems. A broken double line indicates communication
between address spaces within one system.

5-320

MVS Diagnostic Techniques

System A

System 8

Operator

Operator

T

T

ISGCxxxx
Command
processing

ISGCxxxx

It --

~

ISGGxxxx
ISGLxxxx

ISGBxxxx

ISGJxxxx

Ring
processing

CTC
processing

ISGBxxxx

ISGJxxxx

-

-

CTC
processing

J

r

Command
processing

- Ring
~
processing

ISGGxxxx
ISGLxxxx

---.. ENO/DEO/

ENO/DEO/ f4RESERVE
processing

GQSCAN

~

RESERVE
processing

SVC dump

t

SVC dump

•

GQSCAN

+

ISGOxxxx

ISGDxxxx

ISGDxxxx

ISGQxxxx

Oueue
scanning
services

Dump
support

Dump
support

Queue
scanning
services

Figure Title (Module Flow for:)

CTC Processing
5-69 -- Handle Arrival of Immediate-CCW
5-70 -- Handle Arrival of RSA or RSAIRCD
5- 71 -- Send a RSA or RSAIRCD
Ring Processing
Send/Receive a RSA
Send a RSAIRCD or Immediote-CCW (Requested by ISGBCI)
Send a RSAIRCD (Requested by ISGBTC)
Handle Arrival of RSAIRCD (Not Requested by This System)
SNAPSHOT Function
SENDCMD (RSCRADDS) Function
SENDCMD (RSCRSNAD) Function

5- 72
5-73
5-74
5-75
5-76
5- 77
5-78

--------

5-79
5-80
5-81
5-82
5-83
5-84
5-85
5-86
5-87

Command Processing
-- Command Initialization and Cleanup
-- DISPLAY GRS
-- VARY GRS(x). PURGE
-- VARY GRS(x). QUIESCE to Another System
-- VARY GRS(x). QUIESCE by a System to Ouiesce Itself
-- VARY GRS(x). RESTART to Restart Another System
-- VARY 8RSCALU. RESTART to Restart All Systems
-- VARY GRS(x). RESTART by a System Not in the Main Ring
-- Join Processing at Initialization Time

ENO/DEO Mainline (Resource request processing)
5-88 -- Local Resource Request
5-89 -- Global Resource Request
5-90 -- Termination Resource Manager
5-91 -- Queue Scanning Services
5-92 -- Dump Support -- SVC Dump

~

Figure 5-'8. Module Flow Overview and Directory

Section 5. Component Analysis

5-321

Any Address Space
Attention Interrupt

"IIII

lOS - IECTCATN

•

Issues STARTIO channel
program for sense command
byte

II
II

t
ISGJDI CTC driver DIE
EP-DI 1000

•

Marks the GCl to show
immediate-CCW was
sensed

- •

Schedules an SRB to
execute ISGBSR

•

Returns to lOS

SRB
~ ISGBSR RSA send/receive

routine

•

Posts ECB GVTXBECB to
awaken ring processing task

•

Exits to dispatcher

~

(

Exit

POST

~ ISGBTC Ring processing
task mode controller Exception-handl ing task

"II
"
""
"II
"
II
"
"

•

Determines which GCl
(representing a CTC) received
the immediate-CCW

•

At EP-ISGBTCIR, sends the
RSAIRCD on the specified
CTC

•

Gives control, to CTC
processing, of the SRB used
to post GVTXBECB

•

Wait on ECB .GVTXBECB

(

•

Wait

ISGJFE
EP-ISGJGTUE
CTC driver
front end

f---+ See figure 5-74

---

~

~

ISGJFE
EP-ISGJGVSR
CTC driver
front end

II

Module Flow for CTC Processing - Handle Arrival of Immediate-CCW

Attention interrupt

Channel end

105 IECTCATN

10SSlIH

•

•

-+

Issues ST ARTIO channel
program for sense
command byte

+

Processes the read channel
program

J"

,

t
ISGJDI CTC driver DIE
EP-DI 1000

ISGJDI CTC driver DIE
EP·D12000

•
•

Analyzes resu Its of the sense
command byte

•

Analyzes results of the read
channel program

Returns to 105 and requests
initiation of a read channel
program

•
•

Schedules an SRB to execute
ISGJFE
Returns to 105

II

"

Global Resource Serialization
Address Space

1/

II~

ISGJF E CTC driver front end
EP-ISGJSRBX

"II

•

U

•

II

"

11
II
11

II

5-322

-,

)

Any Address Space

Figure 5-70.

-

-

"

II

)

Figure 5-69.

Global Resource Serialization Address Space

II

Loads regiiiters with the
address and length of
received RSA or RSAIRCD
Branches to ISGBSR to process
the received message

ISGBSR RSA send/receive
routine
EP·ISGBSRR processes a
received RSA
EP-ISGBSRRI processes
a received RSAIRCD
See figures 5· 72 and 5·75

Module Flow for CTC Processing - Handle Arrival of RSA or RSAIRCD

MVS Diagnostic Techniques

,

II

Global Resource Serialization
Addreu Space

(

l:nter

J

~

"II

From ring processing
Figure 5-73

"II

II

ISGBSR RSA send/receive
routine

II
II

EP-ISGBSRSR sends a RSA

Initializes a write channel
program and an 10SB

EP-ISGJSRBX

•

If a RSAIRCD was sent.
branches to ISGBSR to
handle the RSAIRCD
send-completion

(

Exit

~

t

...

•

Analyzes results of the write
channel program

•

If a RSA was sent, updates
GVTMRSCW to show RSA
send-completion occurred

•

If a RSAIRCD was sent,
schedules an SRB to
execute ISGJFE

•

Returns to lOS

II

--

II

SRB

1/

II
II

Proceses write channel
program

\I
J

II

ISGBSR RSA send/receive
routine'
EP-ISGBSRRI

•

lOS

ISGJDI CTC driver DIE
EP-DI3000

II

Issues STARTIO to initiate
the write channel program

~
•

II
II
II

ISGJFE eTC driver
front end
EP-ISGJSN BF

•

r+

II

j

r+

Channel end

"II

Ej)-ISGBSRRI sends a RSAIRCD

•
•

Any Addr. . Space

Handles RSAI RCD sendcompletion

II
II

II

II

II
Figure

5-71.

Module Flow for

erc Processing - Send a RSA or RSAIRCD

Section S. Component Analysis

5-323

( Enter)

f

From CTC processing
Figure 5-70

...

ISGBSR RSA send/receive routine
EP·ISGBSRR
•

Sets the RSA residence interval

•

Performs one of the following:

ISGBDR
Timer
manager

.-

--

1. Processes a command or message
If the received RSA contains a CRB or MRB from
another system - Obtains a CRB or MRB
- Initializes the CRB or MRB and places it on the
command request queue (GVTCMDRQ)
- Posts the command router's ECB GVTCECB

.....

ISGSALC
Storage
manger

..-

POST

....

ISGCMDR

~

Command
2. Processes a ring configuration command
router
If the received RSA shows that another system is
performing a ring configuration command (ADDSY,
SUBSYS, DELSYS, or SERRELS function) - Marks the RSV to indicate which function and
phase is being performed
POST
- Posts ECB GVTXBECB to awaken the ring
~----------~... ISGBTC
processing exception·handling task
Ring processing
3. Continues a ring processing function
task mode
If the received RSA shows that ring processing
controller
command should be continued via the RSA - Marks the RSV and RSA to indicate the ring
processing function has advanced to its next
phase
- If all phases of the function are complete:
marks the RSV to indicate completion and
the RSA to indicate the function is no longer
being performed
4. Initiates II ring processing function
If the received RSA shows that no other system is
performing a ring processing function, and the RSV
shows that this system is trying to perform a ring
processing function:
- Marks the RSV,to indicate a ring processing
function is in progress
- Updates the RSA to show that this system is
performing a ring processing function
•

Moves any QWBs on the sent queue (RSVQWBSF) to
the process queue (GVTPRCQF) or hold queue
(RSVQWBHF)

•

Posts the RB (GVTGRPRB) used by ISGGRPOO

•

Obtains QWBs and copies data from the RSA to the
QWBs and places the QWBs on the sent queue

•

Moves the QWBs that are on the request queue
(GVTREQQ) to the sent queue (RSVQWBSF),
and copies them into the RSA

•

Exits to the dispatcher

...

-

...

~

5-79

ISGGRPOO
Global resource
processor

POST

See figure

See figure

5-89

ISGGQWBO
EP·ISGGQWB1
Queue
service

i
Any Address Space

II

ISGBDR Timer manager

•

Residence interval
expires

IlsRB

II
II
II
II

II
Figure

5-324

5-72.

Global Resource Serialization Address Space

~

ISGBSR RSA send/receive
routine
EP·ISGBSRSR

•
•
•

Gives the RSA input buffer
to CTC processing

(

EXit)

Sends the RSA

~

.-

--

Exits to the dispatcher

i

Module Flow for Ring Processing - Send/Receive a RSA

MVS Diagnostic Techniques

ISGJFE
EP·ISGJGVBF
CTC driver
front end

...

ISGJFE
EP·ISGJSNBF
CTC driver
front end

See "figure

5-71

,

( Enter)

From ISGBCI

ISGBTC Ring processing task mode controller
EP-ISqBTCIR

•

Examines the RSL time stamp and flags (pas!)ed by ISGBCI,
subroutine NONMSEND) and performs one of the following:
1. If this system should wait for an RSAIRCD, pauses for a
short time to await the arrival of the RSAIRCD
2. If this system should send a RSAIRCD or an
immediate-CCW:
- Seizes control of the GCQ for this RSL
- Initializes the GCQ as an SRB
- Schedules the SRB to execute ISGBSR

•

-..

--

~

See figure 5-75
ISGJFE
EP-ISGJTKBF
CTC driver
front end

,

Returns to ISGBCI

ISGBCI Ring processing

•

~

Pauses until the request is complete
If a RSAIRCD was sent, awaits the arrival of a
response from the target system
- If an immediate-CCW was sent, awaits the sendcompletion from CTC processing
(Note that ISGBCI might send an immediate-CCW
on another CTC before receiving a response from
the remote system.)

-

•

Exits to caller

(

Exit

i

---

A

-

B

~

)

.j

ISGBSR RSA send/receive routine
EP-ISGBSRRI

•
•
•

Examines the RSV flags to determine if a RSAIRCD
or an immediate-CCW should be sent
Gives, to CTC processing, control of the GCQ and
RSAIRCD buffer for this RSL
Sends the RSAIRCD or immediate-CCW

•

Exits to the dispatcher

(

Exit

i

~

---

--

ISGJFE
EP-ISGJGVBF
CTC driver
front end

-....
~
_

ISGJFE
EP-ISGJSNBF
CTC driver
front end

See figure 5-71

)
From CTC processing

ISGBSR RSA send/receive routine
EP-ISGBSRRI
Receives the RSAIRCD response (requested by ISGBCI)
•

Marks the RSL to show that the RSAIRCD has arrived

•

If the RSV flags show that the RSVENTY table of this
system should be updated, copies the system status from
the received RSAIRCD to an entry in the RSVENTY table

•

Gives control of the GCO and RSAIRCD buffer for this
RSL back to CTC processing

•

Exits to the dispatcher

Figure

5-73.

ISGJFE
EP-ISGJGVBF
CTC driver
front end

Module Flow for Ring Processing - Send a RSAIRCD or Immediate-CCW (Requested by ISGHel)

Section 5. Component Analysis

5-325

( Enter)

+

From ISGBTC
Exception-handling task

ISGBTC Ring processing task mode controller
EP-ISBGTCI R
Examines the RSL time stamp and flags (passed by
ISGBTC, exception-handling task) and performs
one of the following:

•

..

1. If this system should wait for a RSAIRCD, pauses
for a short time to await the arrival of the RSAIRCO

2. If this system should send a RSAIRCD:

-

,
-

~

•

Seizes control of the GCQ for this RSL
Initializes the GCQ as an SRB
Schedules the SRB to execute ISGBSR

-

L

---

See figure 5-75
ISGJFE
EP-ISGJTKBF
CTC driver
front end

Returns to ISGBTC, exception-handling task

ISGBTC Ring processing task mode controller,
Exception-handling task

~

•

Processes another RSL, or waits on its ECB
(GVTXBECB)
(Note that the exception-handling task does not
wait for a send completion or arrival of a
RSAIRCD.)

(

Exit

~t

)

ISGBSR RSA send/receive routine
EP-ISGBSRRI

•
•
•

Copies the status of this system from the
RSVENTY table to the buffer for this RSL
Sends the RSAIRCD using the GCQ and buffer
for this RSL

--

--

ISGJFE
EP-ISGJSNBF
CTC driver
front end

Exits to the dispatcher

See figure 5-71

1- )
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --. -- (

Exit

CEnter )

From CTC processing

l
ISGBSR RSA send/receive routine
EP-ISGBSRRI

•
•

Receives the send completion
Gives control of the GCQ and buffer for this RSL
back to CTC processing

•

Exits to the dispatcher

(

Exit

i

Figure 5-74.

5-326

--

--

ISGJFE
EP-ISGJGVBF
eTC driver
front end

)

Module Flow for Ring Processing - Send a RSAIRCD (Requested by ISGBTC)

MVS Diagnostic Techniques

( Enter

From CTC processing

l
ISGBSR RSA send/receive routine
EP-ISGBSRRI
RSAIRCD is received from a remote system that is not
in response to a request from this system.

•

Marks the RSL to show that a RSAIRCD has arrived

•

If the RSV flags show that the RSVENTY table in
this system should be updated, copies the system
status from the received RSAIRCD to an entry in the
RSVENTY table

•

If the received RSAIRCD contains a command that has
not previously been received by this system:

--

Obtains a CRB
Copies data from the received RSAIRCD to the CRB
Places the CR B on the command request queue and
posts ECB GVTCECB

-

•

Copies the system status from the RSVENTY table to
the RSAIRCD that is to be sent

•

Sends the RSAIRCD using the GCQ and buffer for
this RSL

•

Exits to the dispatcher

(

Exit

i

Lr
...POST

--

ISGSALC
Storage
manager
ISGCMDR
Command
router

,.

See figure 5-79

ISGJFE
EP-ISGJSNBF
CTC driver
front end

See figure 5- 71

)

,

CEnter) From CTC processing
ISG BSR RSA send/receive routine
EP-ISGBSRRI
Receives the send completion

•
•
(

Figure

Gives control of the GCQ and buffer for this RSL
back to CTC processing
Exits to the dispatcher

i

Exit

---

--

ISGJFE
EP-ISGJGVBF
CTC driver
front end

)

5-75.

Module Flow for Ring Processing - Handle Arrival of RSAIRCD (Not Requested by This System)

Section 5. Component Analysis

5-327

(

Enter )

From command processing

+

ISGBCI Ring processing
Examines the RSC passed by the caller and starts the
SNAPSHOT function

•
•
•

Enqueues exclusively on the ISGBCI-ENO-resource
Marks the RSV to show that the RSVENTY table must be
updated with the status contained in any received RSAIRCD
For every RSL that is not used to send or receive the main
ring RSA, sends an immediate-CCW to obtain the status of
the remote system at the opposite end of the CTC represented
by that RSL

•

After all imrnediate-CCWs have been sent, pauses to allow
the remote systems to respond

•

If this system is not in the main ring and some remote system
is in the main ring, repeatedly sends a RSAIRCD to the
remote system. ISGBCI waits for the arrival of a response
before sending the next RSAIRCD. (Each RSAIRCD requests
a RSVENTY entry from the RSVENTY table of the remote
system.)

--- -- -- --------------......----

---

---

...'*

....

•
•
•
•
•
(

Exit

-

Copies system status from the RSVENTY entries to the RST
Copies eTC status from the RSLs to the RST
Dequeues the ISGBCI-ENO-resource
Returns to command processing

-+

Figure

5-328

)

5-76.

l\1odule Flow for Ring Processing - SNAPSHOT Function

MVS Diagnostic Techniques

Ring processing
task mode
controller
See figure 5 73

-- -- -- -- -- -- -- ---- ---

Marks the RSV to show that RSVENTY table updates are no
longer allowed

ISGBTC

ISGBTC
Ring processing
task mode
controller
See figure 5-73

From RESTART command
processing
ISGBCI Ring processing
A system, not in the main ring, is requesting a system in the
main ring to add it to the main ring
•

Examines the RSC passed by the caller and starts the SEN DCMD
(RSCRADDS) function

•

Enqueues exclusively on the ISGBCI·ENQ·resource

•

Chooses the RSL to the target system in the main ring

•

Initializes the RSAIRCD with the data from the input CRB
that requests this system to be added to the main ring

•

Sends the RSAIRCD to the target system and pauses
until the target system sends back the RSAIRCD

•

Repeats sending the RSAIRCD and pauses until the target
system responds that it is performing phase 1 A of the
ADDSYS function (or has cancelled the CRB)

•

Marks the RSV to show that the RSVENTY table must be
updated in this system

•

Sends a RSAIRCD to the target system to obtain the contents
of each entry in the target system's RSVENTY table and pauses
for the target system to respond to each RSAIRCD

•

Marks the RSV to show that the RSA can be received

•

Sends a RSAIRCD to the target system showing that this
system is in the main ring and is ready to process the RSA

•

Marks the RSV to show that RSVENTY table updates are
no longer allowed

•

Dequeues the ISGBCI·ENQ-resource

•

Returns to RESTART command processing

Figure

5-77.

ISGBTC
Ep·ISGBTCIR
Ring processing
task mode
controller
See figure 5-73
ISGBTC
Ep·ISG BTCI R
Ring processing
task mode
controller
See figure 5· 73

Module Flow for Ring Processing - SENDCMD (RSCRADDS) Function

Section 5. Component Analysis

5-329

From RESTART command processing

ISGBCI Ring processing
A system, in the main ring, will add a system not in the main
ring to the main ring
•

Examines the RSC passed by the caller and starts the
SENDCMD (RSCRSNAD) function

•

Enqueues exclusively on the ISGBCI-ENQ-resource

•

Chooses the RSL to the target system not in the main ring

•

Initializes the RSAIRCD with the data from the input
CRB that requests the target system to add itself to the
main ring

•

Sends the RSAIRCD to the target system and pauses until
the target system sends back the RSAIRCD

•

Repeats sending the RSAIRCD and pauses until the
target system responds that it is performing the
SENDCMD (RSCRADDS) function (or has cancelled the CRB)

•

Dequeues the ISGBCI-ENQ-resource

•

Returns to RESTART command processing

Figure

5-330

5-7ft

ISGBTC
EP-ISGBTCIR
Ring processing
task mode
controller
See figure 5-73 (for processing
done on this system) and
figure 5-75 (for processing
done on the target system)

Module Flow for Ring Processing - SENDCMD (RSCRSNAD) Function

MVS Diagnostic Techniques

Master Scheduler Address Space

"IIII

( Enter) From console services
,
(lEECBSOS)

r-----..:;...

ISGCMDI Command interface
•
•
•

Obtains a command request
block (CRB)

•

I nitializes the CR Band
places it on fhe command
request queue

•

Posts ECB GVTCECB

•

Waits for the command to
complete

--- POST

"'--------"4•

Deletes the recovery
environment

C Exit)

ISGCMDR Command router

II _-:-_.M.

Establishes a recovery
environment
Checks the console authority
and the command syntax

Global Resource Serialization Address Space.

ISGSMI
Storage
manager

.II
II
II
II

~ •

II
II

11

II

II

L....--

II
II
II
II

Moves the CR Bs from the
command request queue to
the command work queue
Initializes the CEPL, CRWA,
and RST areas for a CRB

•

Does a SNAPSHOT to fill
in the RST

•

Attaches a command
request processor

•

Places the CR B on the
cleanup queue

•

Repeats these steps for
each CR B on the command
work queue

See
figure 5-76

Lr

ISGBCI
Ring
processing

-

ATTACH'

*

f----------• Waits for another command
request to be placed on the
command request q~eue
EP-ISGETXR1

II

-

Return from
the command
.request processor

II

II
II

II
·Command request processors
ISGCDSP - DISPLAY GRS (figure 5-80)
ISGCPRG - VARY GRS(x), PURGE (figure 5-81)
ISGCQSC - VARY GRS(x), QUIESCE (figures5-82and 5-83)
ISGCRST - VARY GRS(x), RESTART (figures 5-84,5-85, and 5-86)
ISGMSGOO - Asynchronous message request
-

Figure

5-79.

Module Flow for Command Initialization and Cleanup

Section 5. Component Analysis

5-331

( Enter )

From figure 5-79

l
ISGCDSP Display request processor

•
•
•

Obtains storage for a control line
For a SYSTEM or ALL request:
- Obtains storage for a label line
- For each pair of system entries in the RST, obtains
storage for a data line
- Places the system information into the line

(

-

--

-.--

storage for a data line
Places the system information into' the line

Writes all lines of the message
Returns all storage for the lines
Returns to ISGCMDR

i

Exit

-

---

--

Module Flow for DISPLAY GRS

,

.-

--

ISGCPRG Purge request processor

•
•
•
•

•
•
•

Message
service
routine

----

( Enter) From figure 5-79

•

IEECB808
EP-MSGSERV

)

Figure 5-80.

•
•

-..

For a LINK or ALL request:

- Obtains storage for a label line
- For each pair of CTC entries in the RST, obtains
-

•
•
•

---

Determines the status of this system and others
in the complex

Issues message ISGOlll on this system
I nitiates a DE LSYS of the target system
Initiates a SYSID purge of the target system
Issues message ISG0181 for the resource requests
that were purged
Releases the QWBs and MRBs returned by ISGGQWBO
Issues message ISG0131 on this system
Broadcasts message ISG0131 to all active systems in
the ring

•

Returns to ISGCMDR

(

Exit

t

~

----.----..
0#

---

)

Message
routine

..-.

Module Flow for VARY GRS(x), PURGE

MVS Diagnostic Techniques

ISGBCI
Ring
processing
ISGGQWBO
EP-ISGGQWB5
Queue
service

--..
-#'

ISGMSGOO
Message
routine
ISGGQWBF
Queue
service

-

--,

---..

Figure 5-81.

5-332

ISGMSGOO

--,

#'

Issues GQSCAN to determine if the system to be
purged (target system) holds or is waiting for any
global resources
If the target system has outstanding global resource
requests, issues messages ISG0161 and ISG017D'
to obtain the operator's permission to continue the
purge

--,

ISGMSGOO
Message
routine
ISGBCI
Ring
processing

System A

(

System B

Enter ) From figure 5-79

+

ISGCQSC Quiesce request
processor

•
•
•

~

Sends a message request (SENDCMD
for message ISG011I) to the
target system

~

--

-

--------- ~
•

Performs a SUBSYS of the
target system

•

Issues message ISG0131 on
this system

•

Broadcasts message ISG0131
to all active systems in the
complex

•

Returns to ISGCMDR

(

Exit)

+

h.
~

~

ISGB~I

ISGBSR RSA send/receive

•
•

Message
routine

Determines the status of this
system and others in the complex
Issues message ISG0111

~

ISGMSGOO

~

~

Ring
processing
ISGBCI
Ring
processing
ISGMSGOO
Message
routine
ISGBCI
Ring
processing

Obtains a MRB

~
~

-

~ ISGSALC

Initializes the MRB with the
message request and places the
MRB on the command request
queue

Storage
manager

POST

ISGCMDR Command router

•

•
~

Issues message ISG0111

~ ISGMSGOO

Returns

Message
routine

ISGBTC Ring processing
task mode controller

•

Changes the status of this
system from active to
quiesced

•

Issues message ISG0131

•

Returns

~

ISGMSGOO
Message
routine

Figure 5-82. Module Flow for VARY GRS(x), QUIESCE to Another System

Section 5. Component Analysis

5-333

System B

System A
( Enter) From figure 5-79

+

~

ISGCQSC Quiesce request
processor
•

Determines the status of
this system and others
in the complex

•

J

Issues messages ISG0111
andISG01210nth~sy~em

•

Sends a quiesce request
(SENDCMD) to another
system in the main ring to
cause it to quiesce this
system
Issues message ISG0131

•

Returns to ISGCMDR

Message
......r.;.ou.;.t.;.in.;.,;e;""--I

•

Obtains a CRB

•

Initializes the CRB for the
quiesce request and places
the CR B on the command
request queue

r-....--i~~I~S~G~B~C~I~.JI---tt-'
,.

ISGMSGOO ~

See note

C Exit)

Message
routine

-

ISGBCI
Ring
processing
ISGMSGOO

Note: ISGBCI changes the status

of this system from active to quiesced.

Message
routine
ISGBCI
Ring
processing

Figure

5-334

5-83.

--

•

ISGSALC
Storage
manager

Processes the quiesce request
ATTACH

"

~

ISGCQSC Quiesce request processor

•

...

~

•

---. •

----.... •

--

Determines the status of this
system and others in the complex
Issues message ISG0111
Performs a SUBSYS of system A
Issues message ISG0131

•

Broadcasts message ISG0131
to all systems

•

Returns to

Module Flow for VARY GRS(x), QUIESCE by a System to Quiesce Itself

MVS Diagnostic Techniques

-

ISGCMDR Command router

Message
routine

...~..--...
~ ISGMSGOO

--

POST

Ring
processing

-----------•

ISGMSGOO

ISGBSR RSA send/receive

I~GCMDR

System B

System A

( Enter) From figure 5-79

+

ISGCRST Restart request
processor
•

..... ISG BSR RSA send/receive

Determines the status of this
system and others in the
complex

~

ISGMSGOO

•

Locates the RST entry for
system B

Message
routine

•

Issues message ISG0111

•

Does a SENDCMD (RSCRSNAD) ~ ISGBCI
~
to tell system B to restar~
Ring
itself
processing

•

Obtains a CRB

•

I nitializes the CR B for the
restart request and places the
CRB on the command request
queue

I

..

POST

1-.1:_--...
:
ISGSALC

---------------,
ISGCMDR Command router

'----~~~

r-

l-

•

I""

Does an ADDSYS of system B

•

Copies the compatibility level
and the RNLs into a buffer

•

Does a BUFSEND

~.

I--

Issues GQSCAN to obtain data
about all global resources and
requesters

•

Does a BUFSEND

•

Repeats these steps until all
data has been sent

ATTACH

. . . - . ISGBCI
Ring
processing

-- ....

t.:.

ISGCRST Restart request
p'rocessor
~

ISGBCI
Ring
processing

l - I-

~

~ ISGBCI

•
•
•

Does a BUFSEND of the
end-of-Hle

Does a BUFRECV for the
notification that system B
has completed

Releases serialization
(SERRELS)

Issues message ISG0131
on this system

•

Broadcasts message ISG0131
to all active systems in the
complex

•

Returns to ISGCMDR

e

.i._
Exit)

Figure

5-84.

ISGBCI

_

--- --~

r--

...

---

ISGBCI
Ring
processing

•
~

Cleans up and exits

Ie--

ISGCQMRG Queue merge

....~ •
•

~1-I--"~.J~R;;-;-:in::g:--1
processing

~

... ISGGQSRV

ISGGRPOO
Global
resource
processor

ISGMSGOO
Message
routine
I--

ISGBCI
Ring
processing
ISGBCI
Ring
processing

Does a BUFRECV
Compares the compatibility
level and RNLs to those
in this system

•

Does a BUFRECV

•

Issues GQSCAN for each
resource in the buffer

~

•

Generates the QWBs to get
this system's resource queues
to match the other systems
in the complex and puts the
QWBs on the process queue

+-

•

Posts ISGGRPOO to process
the aWBs

....

•

Repeats these steps until
end-of-file is received

Queue
service

ISGBCI
Ring
processing

~ ISGBCI
Ring
processing

Updates the resource queues

1---- -- -- -- - - -

ISGBCI

ISGBCI

--- ....-

r-.

Does a SENDCMD (RSCRADDS)
to signal system A that th is
system is ready

Ring
processing

l - i""

Ring
processing
~ ISGBCI
Ring
processing

~.

Ring
processing

1 - - - - - - - - - - - - -.•

•

Praeesses the restart
request

+

~---------

•

Storage
manager

~

t-- - - - -

-- -- --

•

Does a BUFSEND to notify
system A that queue updates
are complete

•
•

Releases serialization
(SERRELS)
Returns to iSGCRST

-

l"'"-

.

r--

Module Flow for VAJt¥ GRS(x), RESTART to Restart Another System

Section 5. Component Analysis

5-335

System A

CEnter)

System B

From figure 5-79

+

r+

ISGCRST Restart request
processor

•
•
•

For an operator command:
Does a STARTPOP to
perform restart processing
on this system

F-or an internal command:
Does a ST ARTPOP - withpermission to perform
automatic restart processing on this system

-

•
~ •

Issues message ISG0131
Locates the next RST entry
for a restartable system

•

•

Determines the status of this
system and others in the
complex

-

Issues message ISG0111

ISGBSR RSA send/receive

•

-- -..
~

ISGBCI

Obtains a CRB
Initializes the CRB for the
restart request and places the
CRB on the command request
queue

I

Ring
processing

POST

•

--- -...
~

~

•

Does an ADDSYS of system B
Copies the compatibility level
and the R N Ls into a buffer

•

Does a BUFSEND
Issues GOSCAN to obtain data
about all global resources and
requesters

~.

-

~

Message
routine

r- ISGBCI

~

Ring
processing

ISGMSGOO

.-

•
•

Does a BUFSEND
Repeats these steps until all
data has been sent

"------ ---- -- ----

•

•

Does a BUFSEND of the
end-of-file

~ ISGBCI

~

~ ISGBCI

•

Releases serialization
(SERRELS)

•
•

Issues message ISG0131 on
this system

~

L •
•
(
Figure

5-336

~

~

Resturns to ISGCMDR

1.
Exit)

Ring
processing
ISGBCI
Ring
processing

+

•

Does a SENDCMD (RSCRADDS)
to signal system A that this
system is ready

•

Updates the resource queues

•

Cleans up and exits

r-

ISGBCI

rJ- ISGBCI
~ Ring
processing

I--

~

ISGGOSRV

•
•

•

~•

:.r

•

Oueue
service

r- r-

-

ISGGRPOO
Global
resource
processor
ISGBCI

rc-- •
•

~

Ring
processing

/

Does a BUFRECV

Repeats these steps until
end-of-file is received

•

system A that queue updates
are complete

•

Releases serialization
(SERRELS)

•

Returns to ISGCRST

ISGBCI
. Ring
pro.cessing

Module Flow for VARY GRS(ALL), REST ART to Restart AU Systems

MVS Diagnostic Techniques

~

Issues GOSCAN for each
resource in the buffer
Generates the OWBs to get
this system's resources
queues to match the other
systems in the complex and
puts the OWBs on the process
queue
Posts ISGGRPOO to process
the OWBs

r------- -- -- --Does a BUFSEND to notify

Ring
processing
ISGBCI

Does a BUFRECV
Compares the compatibility
level and RNLs to those in
this system

Message
routine
~

~

~ ISGCOMRG Oueue merge

~ ISGMSGOO'

Repeats these steps for each
restartable system

5-85.

,...

Ring
processing

Ring
processing

Does a BUFRECV for the
notification that system B
has completed

Broadcasts message ISG0131
to all active systems in the
complex

-

Ring
processing

~ ISGBCI

Processes the restart reql..!est

~-------------

ISGBCI

ISGBCI
Ring
processing

Storage
manager

ISGCRST Restart request
processor

Ring
processing

~

ISGSALC

ATTACH

ISGMSGOO

ISGBCI
Ring
processing

-

....

ISGCMDR Command router

Ring
processing

~-----------

•
•

,.

ISGBCI

Message
routine
Does a SENDCMD
(RSCRSNAD) to tell
system B to restart itself

-

---

I---

System B

System A

( Enter) From figure 5-79

l

ISGCRST Restart request
processor

r+

ISGBSR RSA send/receive

•

•

Determines the status of this
system and others in the
complex

•

Issues messages ISG0111 and
ISG0121

•

r- iDoes a SENDCMD (RSCRADDS) ~ ISGBCI
to tell system A to build a new
~ """
Ring
main ring that includes system B
processing

•

1

Initializes the CRB for the
restart request and places
the CR B on the command
request queue

I

ISGMSGOO

POST

Message
routine

-...

•

Issues message ISG0131 on
this system

~

•

Does a SENDCMD to broadcast
message ISG031 to all active
systems in the complex

•

Returns tolSGCMDR (command
router)

1.

ISGMSGOO

•

- -- •

ISGBCI
Ring
processing

ISGMSGOO -.
Message
routine

i

-

C Exit
• Does a BUFRECV
........
1-------------Compares the compatibility

•

level and RNLs to those
in thts 'system

~. Does a BU FR ECV
~------------

•

•
•
..... •

Issues GaSCAN for each
resource in the buffer

~

~ ISGGaSRV
Queue
service

Posts ISGGRPOO to process
the aWBs

~ ISGGRP()O

•

Returns to ISGCRST

5-86.

ISGBCI
Ring
processing

..--

ISGBCI
Ring
processing
""'---

.

:t.

rISGBCI
Ring
processing

Does an ADDSYS of system B

-- --

•
•
•

Copies the compatibility level
and the RNLs into a buffer

.. ...
-- -

---

-...

~

Ring
processing

Ring
processing

Issues message ISG0111

•

~ ISGBCI
III

Determines that a restart for
system B is possible

----

---

ISGBCI
Ring
processing ~

ISGBCI
~

system A that queue updates
are complete
Releases serialization
(SERRELS)

ISGBCI
Ring
processing

-

Global
resource
processor

Repeats these steps until
end-of-file is received

•

Figure

ISGBCI
Ring
processing

Generates the aWBs to get
this system's resource queues
to match the other systems in
the complex and puts the
aWBs on the process queue

---- --------Does a BUFSEND to notify
•

.....

ISGBCI
Ring
processing

ATTACH

ISGCRST Restart request
processor

Message
routine

~ ISGCQMRG Queue merge

ISGSALC
Storage
manager

Processes the restart request

,.

~.

r-~.

-...

ISGCMDR Command router

-----------Links to ISGCQMRG

---- -----------

--

Obtains a CRB

~

•
•

Does a BUFSEND

~

Issues GaSCAN to obtain
data about all glbbal resources
and requesters
Does a BUFSEND
Repeats these steps until all
data has been sent

~-----------

•
•

Does a BUFSEND of the
end-of-file

•
•

Releases serialization
(SERRELS)

(

~

Does a BUFRECV for the
notification that system B
has completed

Cleans up and exits

i
Exit

)

ISGBCI
Ring
processing

Module Flow for VARY GRS(x), RESTART by a System Not in the Main Ring

Section 5. Component Analysis

5-337

System B

System A

(Enter)

l
ISGNGRSP Option processor
(initialization module)

•

Does a SNAPSHOT of the
complex

•

Determines the status of this
system and others in the
complex

Ring
processing

I

POST

-

. .~

ISGBCI

I-- l-

Ring
processing

~

1~

•

Does a SENDMCD to broadcast message ISG0041 to all
active systems in the complex

•

Returns to initialization
processing

~ ISGMSGOO
Message
routine
ISGBCI
Ring
processing

ISGMSGOO
Message
routine

.I_
(

-

Ring
processing

.....---..

~.

Does a BUFRECV

~ ISGBCI
Ring
processing

Compares the compatibility
level and RNLs to those in
this system
Does a BUFRECV

~ ISGBCI

•
l...-

•

Issues GQSCAN for each
resource in the buffer
Generates the QWBs to get
this system's resource queues
to match the other systems in
the complex and puts the QWBs
on the process queue

--

Ring
~
processing

1-- ~-. - - . - - - - - - -

•
•

~

ISGGQSRV
Queue
service

Posts ISGGRPOO to process the ~ ISGGRPOO
QWBs
Global
resource
Repeats these steps until
processor
end-of-file is received

i--- - - - - - - - - - - -

L.-.-

•

Does a BUFSEND to notify
system A that queue updates
are complete

t-~ ISGBCI
Ring
processing

•
•

Releases serialization
(SERRELS)

~

Figure

5-338

Returns to ISGNGRSP

5-87.

ISGBCI

I-...

Exit)

t., ISGCQMRG Queue merge

•
•

ISGBCI
Ring
processing
ISGBCI
Ring
processing

L

ISGBCI
Ring
processing

~

•

Determines that a restart
for system B is possible

•

Issues message ISG011 I

-- ...-

•

Does an ADDSYS of system B

--

•
•
•

Oopies the compatibility level
and the RNLs into a buffer

--

--

~

.-..

,.

-- -...
'"

Does a BUFSEND
Issues GQSCAN to obtain data
about all global resources and
requesters

•
•

ISGBCI
Ring
processing
ISGBCI
Ring
processing

ISGBCI
Ring
processing

~

r--

-•

-,.

~

..

Does a BUFSEND

~

Module Flow for Join Processing at Initialization Time

MVS Diagnostic Techniques

ATTACH

ISGCRST Restart request
processor

1---- - - - - - - - - - - -

Issues message ISGOO41
on th is system

..

I-

Links to ISGCQMRG

~.

ISGSALC
Storage
manager

Processes the restart request

1---- - - - - - - - - -- r-- •

.

~

ISGCMDR Command router

•

Ioc-

Does a SENDCMD (RSCRADDS) ~
to tell system A to build a
new main ring that includes
system B

--

Initializes the CRB for the
restart request and places
the CRB on the command
request queue

~ ISGMSGOO
Message
routine

to this system
Issues message ISGOO31

•
•

~ ISGBCI

Selects a system to send data
• about
all global resources

•
•

~ ISGBSR RSA send/receive
Obtains a CRB

-----------Does a BUFSEND of the

Repeats these steps until all
data has been sent
end-of-file

•

Does a BUFRECV for the
notification that system B
has completed

•
•

Release serialization
(SERRELS)

,

Cleans up and exits

~

(

Exit

User's Address Space

II
II

ENO/DEO/ SVC

•

PC

II

l

~

(

Exit

~

)

•

Returns

II

-- -- -- ----- -

•

i

(

Exit

-

ISGSALC
Storage
manager
ISGSDA!-

ISGGOWBI OWB initialization
EP-ISGGED01 (ENO/DEO)

•

•

II
II

II

Invokes ISGGREXO resource
exit routine at EPs:
- ISGGSIEX (Inclusion exit)
- ISGGSEEX (Exclusion exit)
- ISGGRCEX (RESERVE
conversion exit)

5-88.

-

II
II

II
II
II

ISGGOWBI OWB initialization
Initializes the SQA OWB

Figure

-

.

Storage
manager

Obtains storage

-

--

...

ISGSALC
Storage
manaQer

"

~

•

Initializes the resource request
blocks

•

Oueues or dequeues the resource
request blocks to or from the
local queues

•
•

Frees local storage

-

rL

Returns

II

II
~

-

Returns to ISGGNODO

ISGGNODO ENO/DEO/RESERVE
processing

II

)

Sets addressabil ity to the global
resource serialization address
space

~

~

~

II

Initializes the local OWA

Sets up to process the request
~-Returns to caller via exit prolog

II
II
II
II
I

Validity checks the request

- •

Hashing
routine

II

II

processing
EP-IGC048 (DEO)
EP-IGC056 (ENO)

•

!!

Queues or dequeues the resource
request blocks to or from the
local queues

ISGSHASH
EP-ISGSGLH

II
II

If request cannot be handled by
fast path processi ng
Returns to caller via exit prolog

•
•

•

__

II

L,a.. ISGGNODO ENO/DEQ/RESERVE

:~

II
II

•

•

Initializes the resource request
blocks

II

~--------

•

•

Invokes ISGGREXO resource
exit routine at EP:
- ISGGSI EX (I nclusion exit)
If request can be handled by fast
path processing

ISGLNODO ENO/DEQ fast path
routine
EP-ISGLDQOO (DEQ)
EP-ISGLNQOO (ENQ)

II

Validity checks the request

i

-

II

ISGLNODQ ENO/DEO fast path
routine
EP-IGC048FP (DEO)
EP-IGC056FP (ENO)

r--

...

II
II

SVC FLiH

•
•

JI

II

IEAVESVC

•
•

Global Resource Serialization Address Space

ISGSHASH
EP-ISGSGLH
Hashing
routine
ISGSDAL
Storage
manager

II

II
II

Module Flow for ENQ/DEQ Mainline - Local Resource Request

Section 5. Component Analysis

5-339

User's Address Space
ENQ/OEQSVC

+

,

IEAVESVC SVC FLiH

II
II
II

I

ISGLNOOQ ENQ/OEQ Fast path

•

;--

If

Branches to ISGGNOOO to
process global requests

IIII

ISGGNOOO ENO/OEQ/RESERVE
processing
EP-IGC048 (OEO)
EP·IGC056 (ENQ)

~

•
r---

II

II
II

Validity checks the request

•

Initializes the local OWA

•

Sets up to process .the request

•

Returns to caller via exit prolog

~-------------,-

i

-

C Exit )
~

ISGGOWBI OWB initialization
EP-ISGGE001 (ENO/OEO)

•

•

II

Invokes ISGGREXO resource
exit routine at EPs:
ISGGSI EX (I nclusion exit)
- ISGGSEEX (Exclusion exit)
--- ISGGRCEX (RESERVE
conversion exit)
Sets addressability to the global
resou rce serial ization address
space

-PC

Obtains storage
Returns to ISGGNOOO

-

---

ISGSALC
Storage
manager

+

.II
II

II
II
II
II
II

Initializes the SOA OWB

•

-.

ISGGNOOO ENO/OEO/RESERVE
processing

II

ISGGOWBI OWB initialization

•
•

Gloval Resource Serialization Address Space

II
II

PT

•

Copies the SOA OWB into the
global resource serialization
private area OWB

•

Puts the request on the request
queue

•

Waits for the request to be
processed

-- -~

- ....

1---- -- - - - - - - - - - -

'---

•

Returns

ISGGOWBC
OWB copy
routine

ISGGWAIT
Wait
routine

ct

II

II

__________ -.-ll
-

-

~- -

- - --AnyAddr';sssPa;;-----"- -

ISGBOR Timer manager
•

SRB

RSA residency interval expired

II
II
II

II

-

----- - - - - - - - -

routine
•

Moves the request queue to the
RSA and sent queue and sends
the RSA

See figure 5-72

II
-·-----------1r------------------ISGBSR RSA send/receive routine
-I/O interrupt
II - • Moves requests from the sent
See figure 5-72
queue to the process queue and
+
II
IEAVEIO I/O FLiH
posts ISGGRPOO
•

II
II

RSA message arrival

+

_.

II

ISGJDI CTC driver DI E

•

Schedules ISGBSR to process
the RSA

SRB

-

II
II
II

.'igure

5-340
(

5-89.

•

Returns to the dispatcher

,

POST

ISGGRPOO Global resource
processor
• Oueues or dequeues the
request to or from the
global resource queues

•

Posts the caller

Waits for the next request

Module Flow forENQ/DEQ Mainline - Global Resource Request

MVS Diagnostic Techniques

ISGGNOOO

f

ENO/OEQ
processor

-....

B

Terminating Address Space

II

II
\I

Enter) From RTM

-.

~

Initializes the OWA for ISGGTRMl

•

Invokes ISGGTRMl to purge
resources

~

II
Exit

.t

~ == ~i~ ~R~ = === == == == =
manager - stage 2

Lr

~------i

~

•

Obtains a dynamic area

•

Purges local reSOurces

•

Purges global resources

•

Frees the returned OWB

•

Places purge messages on the
command request queue and
notifies the command router

•

Frees Dynamic storage

•

Returns to ISGGTRMO

•

Dequeues local resources

•

Frees OCBs, OELs, and OXBs

1+
~

ISGSDAL
Storage
manager

II
\I
\I
II
II

necessary, i nvo ke STATUS
via SVC 79 (to IEAVSETS)

~ ISGGTRMl Termination resource

ENO/DEO/
RESERVE
processing

~----------~

)1\11

-.If-"reset
- -must-complete"
- - - is- - -

=

ISGGDEOP DEO purge
processing

II

If the global resource serialization
address space is not initialized or
there are no resources to purge,
returns to RTM

•

- . ISGGNODO
EP-ISGGDOOO

II

ISGGTRMO Termination resource
manager - stage 1
•

Global Resource Serialization Address Space

ISGGOWBO Oueue work block
service routine (EP-ISGGOWBS)
•
•

:::::!J

ISGSALC
Storage

~
Obtains a OWB for the task or
address space termination request

Places the OWB on the request
queue and waits for the request
to be processed

ISGSALC
Storage
manager

ISGGWAIT Wait routine

L-----....I

~

---

•

Sets up to wait

•

Branches to wait routine to
wait for the request to be
processed

ISGSDAL

Storage
POST ......m_an_a_g_e_r--.l
ISGCMDR
~ Command

IEAVWAIT
Wait
routine

router

--

...

= == == == == == == == == == == , l t-S-to-r-ag-e--I
Interrupt on CTC
II . . .m_a_n_a_g_er_...
ISGSDAL

Any

ISGJ! CTC driver DIE

Address
Space

•

Schedules ISGBSR to process
the RSA

II
11\

====+~=====~
ISGBSR RSA send/receive
•

~
~

Places the OWBs on the process
queue

ISGGRPOO Global resource
processor
•

Processes the task or address
space termination request

•

Purges resources

•

Notifies the requester that the
purge request is complete (if the
requester is from this system)

•

Figure 5-90.

Wait for more requests

ISGGDEOP DEO purge
processing

•
•

Dequeues a resource

f-t-

-

Frees OCBs, OELs, and OWBs .-

:if

IEAOPTOl

W-

IEAVWAIT

RB post
routine

ISGGNODO
ENO/DEO/
RESERVE
processing

...

ISGSDAL
Storage
manager

POST

Wait
routine

Module Flow for the Termination Resource Manager

Section 5. Component Analysis

5-341

User's Address Space

--...

User program

:
:
GOS·CAN
~

Global Resource Serialization Address

---

PC
PT

ISGOSCAN Oueue scanning service

•
•

5-91.

Starts (or resumes) the search of the LOHT and/or GOHT
for resources that have the attributes specified on GOSCAN

•
•
•
•

Places the information found on the search in the internal
buffer

Returns to the caller

II

II
II
II

;

II

Establishes a recovery environment
Obtains a page of resource
information
Writes a page of resource information
to the dump data set
Repeats these steps, for each page
of information, until all information
is dumped

I. l r

PC

--

~ IEAVTSEO
SVC dump
I/O routine

---------------Deletes the recovery environment
•

Figure

5-342

Returns to I EAVTSDU

5-92.

Module Flow for Dump Support - SVC Dump

MVS Diagnostic Techniques

Global Resource Serialization Address Space

II

Processes the G RSO request

•

ISGSDAL
Storage
manager

Module Flow for Queue Scanning Services

ISGDSDMP SVC dump exit

~

~

~

Releases the internal buffer and dynamic area

IEAVTSDU SVC dump exit
interface routine

~

Storage
manager

If the search is not complete and the user-provided area is
full, sets the token value if token was specified

I

•
•
•
•

ISGSALC

If the search is not complete and the user-provided area is
not full, repeats these steps

Enter) SVC dump request

•

...

If the search is complete or the internal buffer is full, copies
the contents of the buffer to the user-provided area

Any Address Space

(

.-

Copies the parameter list (from the GOSCAN macro) into
the dynamic area and syntax checks it. (A syntax error
results in an 09A abend)

•

•
•
Figure

Obtains an internal buffer and a dynamic area in the ROA

II

ISGDGCBO Dump control blocks

•

Obtains a page of resource information,
in the order listed, from the following
global resource serialization control
blocks:
- GVT
- ASCB
- GVTX,GOHT,LOHT,GRPT,LRPT
SAHT, RSV, and RSV entries
- Active ROA pages for OCBs, OELs,
OX Bs, and POCBs

•

Returns to caller

II
II
II

II

~

Diagnostic Aids
This topic contains diagnostic aids to help you solve problems with global
resource serialization. It contains the following sections:
•
•
•
•
•
•
•
•
•
•

Check on Enabled Wait During IPL
System Indicators
Probe Points
CTC Processing Debugging Hints
Ring Processing Debugging Hints
ENQ/DEQ/RESERVE Processing Debugging Hints
Storage Management Debugging Hints
Serialization
Recovery Routines
SYSI.LOGREC Recording

Check on Enabled Wait During IPL
If an enabled wait occurs during IPL processing, you can make the following
check to determine if the wait was due to missing entries in the SYSTEMS
exclusion RNL.

•

Check the request queue in the GVT (GVTREQQ) for QWBs.

•

Compare the resource name identified in the PEL portion of the QWB to the
entries in the SYSTEMS exclusion RNL and SYSTEM inclusion RNL.

•

If the RNLs indicate that the resource name identifies a global resource, the
requester of that resource must wait until master scheduler initialization
completes before the requester is granted control of the resource.

•

If the requester must complete processing prior to master scheduler
initialization completing, the resource name must be added to the SYSTEMS
exclusion RNL.

System Indicators
The following indicators, when set to one, have these meanings:
GVT indicators:
GVTGRSNA -

Global resource serialization is not active. (Only local requests can be processed.)

GVTNCMDR -

Global resource serialization commands cannot be processed.

GVTGQDMG -

Global resource queues have been damaged. This system will reject VARY
GRS,RESTART commands.

GVTNCOMM -

CTC-driver and ring processing functions are not operative..

GVTNREQS -

Requests cannot be put on the command request queue.

GeL indicators:
GCLINOP -

CTC processing will not allow use of this CTC because a software error occurred
and the control blocks of this CTC (GCL or RSL) might be damaged.

GCLIOERR -

CTC processing will not allow use of this CTC because an I/O error occurred on
this C{C.

GCLOFFLN -

CTC processing will not allow use of this CTC because the CTC has been varied
offiine.

Section 5. Component Analysis

5-343

Probe Points

The following probe points are useful to help you debug global resource
serialization problems or set SLIP traps.
I.

Probe point for obtaining the RSA message that this system received:
Module: ISGBSR
Label:
RECVPTl
Data:
- RSAPTR (register 6) points to the RSA.
- Register 4 contains the length of the RSA.
- Register 13 points to the RSV.
- RSVIBFOR (RSV + X'BC') points to the received RSA.

2.

Probe point for obtaining the RSA message that this system sent:
Module: ISGBSR
Label:
SENDPTI
Data:
- Register 13 points to the RSV.
- RSVOBFOR (RSV + X'90') points to the sent RSA.

3.

Probe point for obtaining the QWB that is to processed (the first QWB on the
process queue):
Module: ISGGRPOO
Label:
GRPNXTPQ
Data:
- Register 3 points to the GVT.
- GVTPRCQF (GVT + X'40') points to the QWB to be processed.

eTC Processing Debugging Hints

The following debugging hints help you isolate problems in the CTC processing
subcomponent.

5-344

I.

Field GCLWGCQF of the GCL is the write queue of the corresponding GCL
(representing a CTC) and points to a write GCQ when the write queue is not
empty. GCLWGCQF is zero when the write queue is empty.

2.

Field GCLCNTS is bumped by one before the STARTIO for a SENDBUF
or SENDBUF-IMMEDIATE. Field GCLCNTC is bumped by one when the
SENDBUF or SENDBUF-IMMEDIATE completes. Therefore, by
comparing these two count fields you can determine if a write operation is in
progress.

3.

Field GCLRGCQF is the read queue of the corresponding GCL and points
to a read GCQ when the read queue is not empty. GCLRGCQF points to a
dummy GCQ (located in the GCV) when the read queue is empty.

4.

The address in field GCLRGCQF is a word-multiple address when the GCL
does not have a read channel program in progress. .The address is bumped by
one when a read channel program is started. Therefore, by checking the low
order bit in GCLRGCQF you can determine if a read channel program is in
progress.

5.

Field GCLTRACE contains the last 15 CCW operation codes sensed from the
corresponding CTC. In a dump, the acronym TRCI appears a short distance
before this field. The occurrence of an EE or ED operation code in this area

MVS Diagnostic Techniques

indicates that the system taking the dump sensed a broken channel program
that was started by the system at the opposite end of the CTC.
Ring Processing Debugging Hints
The following debugging hints help you isolate problems in the ring processing
subcomponent.
1.

Field RSVIBFOR points to the RSA input buffer. Field RSVMRLRL
contains the length of the last RSA received.

2.

Field RSVOBFOR points to the RSA output buffer. Field GCBLNBUF of
the RSA output GCB contains the length of the last RSA sent or the length
of the RSA that soon will be sent. Field RSVGCBOP points to the RSA
output GCB.

3.

Field RSARCSEQ of the RSA is the RSA send count, which is a number that
is bumped by one each time the RSA is sent. By comparing RSARCSEQ in
the input buffer to RSARCSEQ in the output buffer, you can determine if the
system that took the dump was holding the RSA at the time of the dump.
Also, by comparing RSARCSEQ values in dumps taken by different systems,
you can determine which system last received the RSA before a failure.

4.

When a system is in the main ring, field RSVRSASC contains the RSA send
count of the last RSA sent by this system (if the system is not holding the
RSA) or the send count of the RSA that will soon be sent by this system (if
the system is holding the RSA). RSVRSASC is set to zero when a system
does main ring cleanup.

5.

Subroutine CLNUFAIL (in module ISGBCI) does the main ring cleanup.
When a system does main ring cleanup after a main ring disruption,
CLNUF AIL copies field RSVRSASC to an entry in the RSVENTY table,
and also marks entries in the RSVENTY table to show which systems were in
the main ring at the time of the disruption and which RSA was last received
before the disruption. Because main ring cleanup is serialized by the
ISGBCI-ENQ-resource, cleanup might not occur immediately after the main
ring disruption because another task might be holding the
ISGBCI-ENQ-resource at the time of the disruption.

ENQ/DEQ/RESERVE Processing Debugging Hints
The following debugging hints help you isolate problems in the
ENQ/DEQ/RESERVE processing subcomponent.
1.

The queue work areas (QWAs) used by ENQ/DEQ mainline processing
contain information that is useful in solving ENQ/DEQ/RESERVE problems.
There are two QWAs: one for local resource processing (the local QW A
pointed to by GVTLQWA), and the other for global resource processing (the
global QW A pointed to by GVTGQW A).
The QW A is divided into the following major areas:
QWABASIC -

This is the basic section of the QWA. It contains the information required
by the mainline routine to process the resource request. For example, it
indicates whether or not the request is authorized, whether global resources

Section 5. Component Analysis

5-345

are part of the request, and whether the request is an ENQ or DEQ. This
is also the only section of the QWA that can be mapped to the SVRB
extended save area or the RMPL work area.
QWARSA

~

This is the first request save area section of the QWA. It contains the
information required to process a global or local resource request. This
section is moved to the QWBHRSA field and later restored to the
QWARSA field by module ISGGRPOO. It exists in the QWABASIC
section of the QWA.

QWARSA2 -

This is the second request save area section of the QWA. It contains the
information needed to process a global or local resource request. This
section contains the requester's job name, SYSID, ASID, and ASCB
address. This data is moved to the QWBHRSA2 field and later restored to
the QWARSA2 field by module ISGGRPOO. It exists in the QWARDA
section of the QWA.

QWARDA -

This is the request data area section of the QWA. It contains the counts of
the types of resources being processed, and the addresses of internal control
blocks.

Work/Save areas -

This series of general work/save areas follows the QWARDA area in the
QWA and are used by the resource request processing routines. These
areas are used to save register contents.

QWATRMRM -

This work area section of the QWA is used by the termination resource
manager. It contains information used by ISGGTRMO and ISGGTRMI to
process a termination request.

When a local resource is being processed, the QWABASIC section of the
QWA is moved to the SVRB extended save area when the requester of the
resource must be suspended because the resource is not immediately available.
QWABASIC infonnation is then referenced in the SVRB extended save area
following the notification that the resource is available.
When a global resource is being processed, the QWABASIC section of the
QWA is always moved to the SVRB extended save area because the global
resource requester is always suspended.
After the requester is notified (via cross memory post) that the requested
resource is availabI'e, the data in the SVRB extended save area is copied back
to the QWABASIC section of the QWA. This infonnation in QWABASIC is
then used to complete the processing of the request.
The main point to consider about the QWA is that whenever an
ENQ/DEQ/RESERVE requester is suspended, the SVRB extended save area
contains useful infonnation that can be used in debugging. An important
piece of infonnation in the QWABASIC section of the SVRB extended save
area is the QWB address used to define a global resource request. By locating
this QWB (pointed to by QWAQWBA), you can find the data presented to
ENQ/DEQ/RESERVE processing in the original requ:est. If this field in the
QWA is zero, then a local resource is being processed.
2.

ENQ/DEQ/RESERVE processing uses two types of QWBs to process
resource requests: the SQA QWB (pointed to by GVTSQWB), and the global
resource serialization address space QWBs (pointed to by QXBQWB,
GVTREQQ, and GVTPRCQF).
When a local resource is being processed, the SQA QWB is used. When a
global resource is being processed, the SQA QWB is used only until the global

5-346

MVS Diagnostic Techniques

resource serialization private area QWBs are constructed. The following
shows
the process in which the resource data is passed between ISGGNQDQ and
ISGGRPOO.

3.

•

The requester's PEL is moved to the SQA QWB.

•

The local QW A is initialized.

•

Information in the QWA and SQA QWB is moved to the global resource
serialization private area QWBs.

•

The QW ABASIC section of the local QWA is moved to the SVRB
extended save area.

•

The global resource serialization private area QWBs are placed on the
request queue. (These QWBs are subsequently moved to the process
queue by ring processing routines.)

•

The ring processing function notifies ISGGRPOO that work (QWBs) is
now available on the process queue.

•

ISGGRPOO moves the QWBHRSA and QWBHRSA2 fields to the global
QWARSA and QW ARSA2 fields respectively.

•

ISGGRPOO processes the requests and notifies the requester
(ISGGNQDQ SVRB) when the resource request is satisfied.

•

ISGGNQDQ restores the local QW A from the QW ABASIC section of
the SVRB extended save area. It then locates the global resource
serialization private area QWBs defining this request from the restored
QWABASIC section. This address is then used to restore the QWARSA
from the QWBHRSA.

Prior to master scheduler initialization completing, any global resource
requests placed on the request queue that are required for IPL processing will
cause an enabled wait state. To prevent this from occurring, any global
resource requests required during IPL processing before master scheduler
initialization has completed should be placed in the SYSTEMS exclusion
RNL.

ENQ/DEQ/RESERVE Termination Resource Manager Debugging Hints
The following debugging hints help you isolate problems in the
ENQ/DEQ/RESERVE termination resource manager function:
l.

)

For normal and abnormal task termination, ISGGTRMO receives control
from RTM in either the. address space of the terminating task or the address
space of the master scheduler. In either case, ISGGTRMO issues a PC to
ISGGTRMI in the global resource serialization address space to process the
request. The input resource manager parameter list (RMPL, which is pointed
to by register 1 on entry) defines the type of termination request.

Section 5. Component Analysis

5-347

2.

ISGGTRMO uses the local QWA to store information related to its
processing. QWABASIC is initialized with common resource processing
information and QWATRMRM is initialized with information related to the
task or address space being purged. For the format of this data, refer to the
QWA in the Debugging Handbook.

3.

If only local resources are being purged, the ENQ/DEQ cross memory
services lock (CMSEQDQ) is held to provide serialization for the local QWA.

4.

If global resources need to be purged, then the data stored in the QWA must
be preserved during this process. ISGGTRMI saves this data in the dynamic
area before calling ISGGQWB5. Register 9 in ISGGTRMI points to the
dynamic area. The information in the dynamic area includes the QWARSA,
QWAASCB, QWATRMRM, QWAJOBNM, GVTXLSMP, and RUB
(register update block).

Storage Management Debugging Hints
The following debugging hints help you isolate problems in the storage
management subcomponent.
1.

Most global resource serialization control blocks reside in the global resource
serialization address space. Pools of control blocks are maintained in
resource pools as defined by two resource pool tables (RPTs), the local RPT
and the global RPT. RPTs, in turn, address pool extension blocks (PEXBs)
that define the control blocks (cells) for global resource serialization. (For an
overview of these control blocks, see Figure 5-66.)
Each PEXB is 4K bytes in length and contains multiple cells for control
blocks of the same type and size. Listed below are the global resource
serialization control blocks that are defined within a PEXB. (The RPT
indexes are described in the following hint.)
Control
Block

QCB
QCB
QCB
QEL
QXB
QWB
HWKA
TWKA
PQCB
MRB
CRB

RPT
Index

I
2
3
4
5
6
6
7
8

9
lO

Name

Attributes

queue control block - size I
queue control block - size 2
queue control block - size 3
queue element
queue extension block
queue work block
huge work area
tiny work area
placeholder QCB
message request block
command request block

local or global
local or global
local or global
local or global
local or global
global only
local only
local or global
local or global
local or global
global only

The RPT header contains either the acronym LRPT (local RPT) or GRPT
(global RPT). Also, in the PEXB headers, the PEXBs addressed by each
RPT contain the acronym PEXB as well as the acronym for one of the
control blocks listed above. This information is useful when you are scanning
the RQA in a dump listing to locate a particular control block, or when you
find an address of an unknown control block. From the information in the
PEXB, you can determine the type of control block (defined by the acronym)
and whether or not the control block is in use by global resource serialization.

5-348

MVS Diagnostic Techniques

The control block is in use if it is not chained to the available cell chain in the
PEXB header.
The available chain is double-headed (pEXFRST and PEXLAST) and
single-threaded (PEXNCELL). Note that the first four bytes of each cell are
used to chain available cells together.
2.

A storage manager parameter list (SMPL) is the input to the storage manager
allocation (ISGSALC) and deallocation (ISGSDAL) routines. The SMPL
describes the number and type of control blocks requested .. The type of
control block is defined by an RPT index value in the SMPL. The RPT
indexes (defined in the ISGRPT and ISGSMPL mapping macros) are used to
index into the RPT to locate the RPT entry (RPTE) for the control block in
question.

3.

The QCB is defined in three sizes: size I for those with an RNAME of 24
bytes or less, size 2 for those with an RNAME of 44 bytes or less, and size 3
for those with an RNAME of 255 bytes or less. Each QCB has a unique
index corresponding to the three sizes.

4.

The sequence in which the storage manager allocates control blocks is:

5.

)

•

When a request is received, ISGSALC attempts to satisfy the request
from the queue of active PEXBs that are chained from RPTEFPXB and
RPTELPXB. If, while scanning the active PEXB queue, ISGSALC finds
a PEXB with no available cells, the PEXB is rechained to the end of the
active PEXB queue.

•

If sufficient PEXBs are not available on the active queue, ISGSALC
searches the inactive PEXB queue that is chained from RPTEIAPQ. If
available, the inactive PEXB is moved to the front of the active PEXB
queue and the required cells are obtained from this PEXB.

•

If the inactive PEXB chain is empty and the request is still not satisfied,
an additional page is obtained from the RQA. A new PEXB is then
constructed and chained to the front of the active queue.

•

If the RQA has been completely assigned, then the storage manager issues
abend 09A with a reason code of 8104.

A bit map in the RQA defines each page of the RQA. When the storage
manager attempts to allocate a control block and no active or inactive PEXB
is found, the RQA bit map is searched for an available page. (The address of
the bit map is in GVTXBTMP and the length of the bit map is in
GVTXBTML.) The storage manager allocates control blocks from the high
end of the RQA for global resources and the low end for local resources.
Therefore, for global resources, the search proceeds from the high order bit in
the bit map to the low order bit. For local resources, the search proceeds
from the low order bit in the bit map to the high order bit. When a page is
allocated in the RQA, the corresponding bit in the bit map is set to 1. When
a page is deallocated from the RQA, such as a PEXB, the corresponding bit
in the bit map is set to O. By scannIng the bits in the bit map, you can
determine the number and locations of all allocated control blocks in the
RQA. (The address of the RQA is in GVTXRQA.)

Section 5. Component Analysis

5-349

6.

You can locate a PEXB header by zeroing the low order 12 bits of the cell (or
control block) address. The PEXB header contains the addresses of the first
and last available cells in this PEXB. The header also contains pointers to
the previous and next PEXBs for this control block. By scanning the queue
of available cells (pointed to by PEXFRST), you can determine if a particular
control block is allocated to a function or has been released.
When cells are returned to the storage manager, they are placed at the end of
the available chain. When cells are assigned by the storage manager, they are
assigned from the front of the queue. This ensures that a history of cell usage
is maintained within the PEXBs because the oldest are used first.
When all cells within a PEXB have been freed, the PEXB is moved to the
front of the chain of available PEXBs (that is, the inactive PEXBs pointed to
by RPTEIAPQ). Therefore, a history of PEXBs is not maintained.
Whenever the count of inactive PEXBs (maintained in GVTXIACT) equals
the count in RPTIACNT, all inactive PEXBs defined by this PRT are
released. The storage manager deallocation routine (ISGSDAL) schedules
ISGSPRLS to perform the page release function (via a branch entry to
IEAVPSIB).

7.

Control blocks in the RQA are not fixed. Instead, global resource
serialization relies on the storage isolation function of SRM to ensure that the
real frames associated with these virtual pages remain in storage until a
critical storage shortage is encountered. (Refer to the Initialization and
Tuning Guide for information about storage isolation.)

8.

With the exception of the QWB, all global control blocks are serialized with
the global resource serialization local lock. All local resources and the QWB
are serialized with the ENQ/DEQ cross memory services lock (CMSEQDQ).

Serialization
When GRS = NONE is specified, all required global resource serialization
resources are serialized with the CMSEQDQ lock.
When GRS=START or GRS=JOIN is specified, the following chart summarizes
the serialization of the resources used by global resource serialization.
CMSEQDQ

Local

CS

X
X
X
X

X
X
X

X
X
X
X
X

5-350

MVS Diagnostic Techniques

Resource
Local hash table
Global has table
SYSID/ASID hash table
Local ASCB QEL queue
Global ASCB QEL queue
Local storage management pools
Global storage management pools
Storage management QWB pools
Request queue
Process queue
Local QWA
Global QWA

Legend:
CMSEQDQ - ENQ/DEQ cross memory services lock
Local - Global resource serialization local lock
CS - Compare and Swap instruction
Recovery Routines
The recovery routines for the global resource serialization subfunctions are:
Recovery Routine

SubfunctiOD

ISGBERCV - ESTAE
ISGBFRCV - FRR

Ring processing

ISGCRCV - EST AE
ISGCRETO - FRR
ISGCRETI - FRR

Command processing

ISGDSDMP (EP-ISGDSDRV) - EST AE
ISGDSNAP (EP-ISGDSNRV) - ESTAE

Dump support

ISGGESTO - ESTAE
ISGGFRRO - FRR

Request (ENQ/DEQ/RESERVE)
processing

ISGGQSRV (EP-ISGGRTRy) - FRR

Global queue services

ISGJRCV - FRR

CTC processing

ISGCRCV - ESTAE

WTO/WTOR message processing

ISGCRCV - EST AE

Initialization

ISGQSCNR - FRR

Queue scanning services

ISGGFRRO - FRR
ISGSMI (EP-ISGSMIFR) - FRR

Storage management

SYSl.LOGREC Recording
All global resource serialization recovery routines (except ISGGESTO) record the
following information in the SDW A:
SDWAMODN - Load module name
SDWACSCT
- CSECT name
- Date of compilation
- Product/PTF number
SDWACID
- Component identifier (SCSDS)
- Subcomponent identifier
SDWAREXN - Recovery routine name

Additional information is recorded in the variable recording area (SDWAVRA) in
the key-length-data format as described in the following topics.
Recorded by ISGBERCV
ISGBERCV records the following in the SDW AVRA:
•

The REPL and its address. (The REPL contains execution footprints. Also,
if the failing module was working with a particular RSL, the REPL contains
the address of that RSL.)

Section 5. Component Analysis

5-351

•

The RSC being processed at the time of failure and its address. (Recorded
only if ISGBCI was the failing module.)

•

Six words copied from the DCB of the CTC that encountered the timeout
condition. (Recorded only if ISGBCI is the failing module and the abend
reason code is 620C.)

Recorded by ISGBFRCV

ISGBFRCV records the following in the SDWAVRA:
•

The RVR and its address. (The RVR contains execution footprints. Also, if
the failing module was working with a particular RSL, the RVR contains the
address of that RSL.)

•

The ISGBSR entry point that encountered the failure.

•

The addresses of the RSLs used to receive and send the RSA.

•

Field RSVCRSAT of the RSV, which indicates whether a ring processing
function was being performed at the time of the failure. Also, field
RSVCPHNO, which indicates the phase of the function being performed.

•

The addresses of the RSA input buffer and output buffer, plus six words from
the beginning of each buffer.

If the failure occurred for entry point ISGBSRRI, the following is also recorded:
•
•
•

The address of the RSL.
The device address of the CTC represented by that RSL.
The RSL flags: RSLLKSF, RSLLKIF, and RSLBFCTC.

Recorded by ISGCRCV

ISGCRCV records the following in the SDW AVRA:
•

The contents of the CRWALEIB field (LOGREC error information) when
ISGCRCV begins recovery processing.

•

The parameter list passed to ISGBCI if the error exit routine determined that
the failure occurred during a call to ISGBCI. (ISGCRCV invokes exit
routines in failing modules as a part of its recovery processing.)

•

The contents of the CRWALEIB field when ISGCRCV completes processing.

For each CRWA on the chain, ISGCRCV repeats the recording noted above.
Therefore, multiple CRWALEIB fields might be recorded.
Recorded by ISGCRETO

ISGCRETO (at entry point ISGCRORV) records the following in the SDWAVRA:
•

5-352

The FRR parameter list. (Refer to the P ARMAREA structure in module
ISGCRETO.)

MVS Diagnostic Techniques

Recorded by ISGCRETI

ISGCRETI (at entry point ISGCRIRV) records the following in the SDWAVRA:
•

The FRR parameter list. (Refer to the PARMAREA structure in module
ISGCRETl.)

Recorded by ISGDSDMP

ISGDSDMP (at entry point ISGDSDRV) records the following in the
SDWAVRA:
•

The contents of the DEPL (ESTAE parameter list for SDUMP).

Recorded by ISGDSNAP

ISGDSNAP (at entry point ISGDSNRV) records the following in the
SOWAVRA:
•

The ESTAE parameter list. (Refer to the PARMAREA structure in module
ISGDSNAP.)

Recorded by ISGGESTO

ISGGESTO does not request recording to SYSl.LOGREC. Nothing is copied
into SOW AVRA.
Recorded by ISGGFRRO

ISGGFRRO records the following in the SDW AVRA:
•

The contents of the QFPL (ENQ/DEQ FRR parameter list).

•

The contents of the output data area (ODA) if the queue verifier routine
detects queue damage. (Refer to module lEAVEQVO for the mapping of the
ODA.)

•

Internal processing flags. (Refer to the FLAGS structure in module
ISGGFRRO.)

•

Resource damage flags. (Refer to the DAMAGE structure in 'module
ISGGFRRO.)

Recorded by ISGGQSRV

ISGGQSRV (at entry point ISGGRECV) records the following in the
SDWAVRA:
•

The error information block (EIB), which is local to ISGGQSRV.

Section 5. Component Analysis

5-353

Recorded by ISGJRCV
ISGJRCV records the following in the SOWA VRA:
•

The CTC unit address.

•

The address of the IOSB.

•

The IOSB fields: IOSFLA, IOSFLB, IOSFLC, IOSCOO, IOSCSW, IOSSNS,
and IOSUSE.

•

The address of the GCQ.

•

The first five words of the GCQ.

•

The contents of GCL.

Recorded by ISGQSCNR
ISGQSCNR records the following in the SOWAVRA:
•

The contents of QFPLI (queue scanning services FRR parameter list).

•

The input parameter list (built by the GQSCAN macro) to ISGQSCAN, if it
is available.

•

The original system completion code and reason code describing the error.

•

The control block cell type and address, if the control block was found not
valid.

•

Internal recovery status flags. (Refer to the RCVYSTFG structure in module
ISGQSCNR.)

Note: ISGQSCNR does not record the 09A abend code issued by ISGQSCAN.

Recorded by ISGSMI
ISGSMI (at entry point ISGSMIFR) records the following in the SOWAVRA:

5-354

•

The FRR parameter list. (Refer to the P ARMAREA structure in module
ISGSMI.)

•

The original system completion code and reason code (in SOWAGR15)
describing the error.

MVS Diagnostic Techniques

Appendix A. Process Flows
This appendix describes the flow of various MVS processes. These processes are
described in the following chapters:
•
•
•
•
•

RSM Processing for Page Faults
Swapping
EXCP/IOS
GETMAIN/FREEMAIN
VT AM Process

•

TSO

)
Appendix A. Process Flows

A-1

RSM Processing for Page Faults
This chapter describes the important aspects of the RSM component's page-fault
processing. Figure A-I outlines the major functions in this processing.
Note: When page fault assist (PFA) microcode is installed and active, initial page
faults are usually resolved by PFA without presenting an interruption to the
software. (Also note that PFA does not make entries in the trace table.)

During page fault processing, several important tests are made. The following
describes what these tests are, where they are made, and what they mean during
the course of the RSM page fault process.

lEA VPIX Tests
lEAVPIX performs the following:
•

Checks the PGTE to ensure that PGTPVM is still on after the SALLOC lock
has been obtained. This is done because in an MP environment the other
processor might have validated the PGTE (turned PGTPVM off) between the
time this processor page-faulted and the time the SALLOC lock was obtained.

•

Checks the PGTE to ensure that PGTPAM is on. If it is not, this is a logical
protection violation.

•

For a first reference, a PFTE is allocated directly, if one is available on the
available frame queue; the page is cleared to zeros and the PGTE is validated.
A first reference is one where the PGTE contains X'OO 19' or X'0009' and
there is no auxiliary storage assigned or there is no deferred PCB for the
page.

•

If reclaim from the available frame queue is possible, IEAVPIX allocates the
PFTE and validates the PGTE.

•

If IEAVPIX cannot allocate a PFTE, it initializes a PCB and calls
IEAVGFA.

IEAVGFA Tests
IEAVGFAperforms the following:

A -2

•

Checks the XPTE to determine if any other requests for this page are
outstanding. If XPTDEFER is on, other paging requests (PCBs) for this
page have been deferred. (The PCB is on the GFA defer: queue anchored in
the PVT.) Normally, the fact that a paging request is currently outstanding is
indicated by PFTPCBSI, but in the defer case there is no frame and therefore
no PFTE is yet associated with the request. Collect any deferred requests for
this page (using a match on VBNO and also on the ASID if the page is in the
private area) and relate them to the current request.

•

Analyzes the current request and any related requests for the requirements of
the frame that is needed for the requests.

MVS Diagnostic T echniq ues

•

Checks to see if the XRBN from the PGTE does not represent a first
reference case. If it is not a first reference, it can be determined if page I/O is
in progress for the page, of if the frame has been .used for another purpose
since last backing the VBN. If no I/O is in progress, the frame is acceptable
to the current request and its related requests, and the frame still contains the
requested VBN; then the frame is reclaimed and is available immediately.

•

If PFTPCBSI is on, checks to see if a PCB can be found on an I/O queue.
The VBNO value is used to search for the correct PCB on the I/O queue to he
searched. If no PCB is found, lEA VGFA issues a COD abend to record the
error. If a PCB is found, a PCB relate function is performed if the I/O frame
is acceptable to the current request and its related requests.

•

If an old frame with or without I/O in progress cannot be found that is
acceptable to the current request and its related requests, a frame is selected
from the front of the AFQ. The PFTE is fil1ed in and it is queued on either
the common or the local frame queue. The XPTE (XPTXAV) is now
checked to see if the paging data sets contain a copy of this virtual page. I.f
XPTXAV is on, a page in operation is started; if it is off, the frame is cleared
to zeroes.

•

If the AFQ is empty, the request is deferred by placing the current PCB and
any related PCBs on the PCB defer queue (PVTGF ADF) of the PVT. The
XPTDEFER flag is set in the XPTE.

•

If a page-in is needed, the XRBN of the allocated frame is placed in the PCB
in the AlA (which is always physically adjacent to the PCB) and the AlA is
passed to ASM. Processing then exits as shown by steps 9, 10 and 11 in
Figure A-I.

lEA VPIOP Tests
lEAVPIOP receives control from ASM and lEA VPIOP is passed the AlA when
I/O has completed. lEA VPIOP checks for an I/O error and marks the PCB I/O
complete. If necessary, IEAVPIOP indicates an I/O error in the PCB.
lEAVPIOP checks PCBFREAL to determine if the reason for the page-in still
exists. If PCBFREAL = 1, the page-in has been NOPed for some reason (such as
FREEMAIN) and the frame is sent to the AFQ. If PCBFREAL = 0, the PGTE is
validated. IEAVPIOP will then RESET/RESUME the suspended page fauiter
and the PCB is returned to the free queue. If RESUME is unsuccessful, then
lEA VPIOP will leave the PCB on the I/O queue and SCHEDULE lEAVIOCP.

Appendix A. Process Flows

A-3

®

PIC 11
IEAVEPC
Determines type of
program interrupt
IEAVFP
Locates PGT E
and XPTE

IEAVEDSO
Saves status and
selects next unit
of work to run

@
IEAVPIX
Formats page
fault PCB

IEAVPCB
Allocates a
PCB from the
PCB free
queue

0

0

IEAVGFA

IEAVPFTE
Moves PFTE
from AFO to
LFO or CFO

IEAVSUSP
(physically located in
IEAVEPC) Suspends
page faulting TCB/SAB
and allocates an SSA B
for an SAB mode page
fault

IEAVPCB
Queues PCB on
I/O queue

Note: Circled numbers indicate the sequence of processing.

Figure A-I (Part I of 2).

A -4

MVS Diagnostic Techniques

Page Fault Process Flow

ILAIODAV
Passes AlA (ASM's
request element)
to ASM.

ILRPAGCM
ASM I/O complete
processor

Executes under an
I ECVPST (POST
STATUS) SRB

IEAVPIOP
•
•

Validates PGTE
Resets/Resumes
page faulter
Frees the PCB
Schedules IEAVIOCP
if could'not do resume

•
•

IEAVETCL

IEAVRSET

IEAVPCB

Resume sets
dispatchable
suspended
unlocked TCBs

(physically located
in I EAV EPC) Sets
dispatchable
suspended SSRBs
or locked TCBs

Returns PCB to
PCB free queue

IEAVIOCP
•
•

•

Runs in page
faulting address
space in SRB mode
Resets page
faulter for any PCB
bel ongi ng to
address space with
PCBRESET=1
Frees the PCB

Note: Circled numbers indicate the sequence of processing.

Figure

A-I (Part 2 of 2).

Page Fault Process Flow

Appendix A. Process Flows

A -5

lEA VIOCP Tests
lEAVIOCP runs in SRB mode and searches the local and common PCB queues
looking for I/O complete PCBs. Once found, lEAVIOCP calls lEAVRSET for
any I/O complete PCBs with PCBRESET = 1. The reset function (lEAVRSET in
lEAVEPC) is responsible for making the suspended work (TCB/SSRB)
redispa tcha ble.
lEAVIOCP searches the local and common PCB queues looking for I/O complete
PCBs. Once found, lEAVIOCP calls lEAVRSET for any I/O complete PCBs
with PCB RESET = 1. The reset function (lEAVRSET in lEAVEPC) is
responsible for making the suspended work (TCB/SSRB) redispatchable.
lEAVIOCP validates the PGTE for any I/O-complete PCB with a nOll-zero
PCBVBN, with PCBFREAL = 0, and without an I/O error (PCBIOERR = 0).
When this is done, lEAVIOCP returns the PCB to the free queue.
Because lEAVIOCP is queue-driven, it might not be able to get the local lock
when it requests it. In such a case, it can be held in suspension by a page faulter
whose PCB is on the queue lEAVIOCP is working on. Therefore, up to two
SRBs can be scheduled for lEAVIOCP at one time. If lEAVIOCP does not hold
the local lock and discovers an I/O-complete PCB that needs to be reset and for
which reset requires the local lock (PCBLLHLD = 0, PCBSRBMD = 0,
PCBPEX = I, an unlocked TCB page fault), it can call lEAVOPBR to reschedule
itself (exit to dispatcher). IEAVIOCP continues its scan of the PCB queues, doing
any work possible before it exits to the dispatcher.

A -6

MVS Diagnostic Techniques

Swapping
This chapter describes the major considerations and decisions of the swapping
processes (swap-in and swap-out).

Swap-In Process
The numbers in the following descriptions correlate to the circled numbers in
Figure A-2.
1 - 2

SRM schedules IEAVSWlN and passes it the address of the ASCB in SRBPARM.
lEAVSWlN obtains working-set size (SPCTWSSZ) + 1 PCBs. It then scans the SPCT
LSQA entries and fills in a PCB for each entry. Next IEAVSWlN scans the stage one
pageable page entries. Finally, IEAVSWIN scans the fix entries. For private area fix entries,
it builds a stage one PCB. For common area fixes, it adds the SPCT fix count to the PFTE
fix count. For common area fixes not in storage, it builds a PCB. Next, lEAVSWIN scans
the SPCT segment entries and builds a PCB for each bit map entry. It then returns unused
PCBs to the PCB free queue and calls IEAVGFA. If enough frames are not available for the
stage one pages, IEAVGFA returns a code of eight to IEAVSWIN and sets PCBRETRY.
IEAVSWIN notifies SRM via a SYSEVENT SWINFL to try the swap-in later.

3 - 4

IEAVGF A allocates frames for both stage one and stage two PCBs and then calls ASM to
start swap-in I/O.

5

After swap-in I/O completes, the lEAVSWIN root exit IEAVSIRT is called by IEAVPIOP
with stage one PCBs chained from the root PCB. lEAVSWIN does the following:
•
•
•
•

Updates PFTFXCT if any fix counts are greater than 255
Sets ASTESTD
Fills in SGTEs in non-translate mode
Fills in PGTEs in non-translate mode

6

IEAVSIRT calls lEAVPCB to free the root and all stage one PCBs.

7

IEAVSIRT calls ASCBCHAP to put the ASCB back on the ASCB queue.

8

IEAVSIRT calls status to start both quiesceable and non-quiesceable SRBs.

9

IEAVSIRT obtains an SRB from the RSM cell pool and schedules IEAVSWPP into the
swapped-in address space so it can post the region control task. SWINPOST posts RCT's
ASCBQECB to restore the address space and to start the I/O for stage two pages. Note that
stage two frames are allocated at the same time as stage one frames.

10

IEAVGFA allocates frames for stage two PCBs and then calls ASM to start paging I/O.

Appendix A. Process Flows

A -7

IRARMCSI
SRM schedules
swap-in
PCBs on exit
from SWIN
mainline

IEAVPCB
SWIN gets
SPCTWSSZ+1
PCBs

(';;'\

~_ _\V_2;:;;-._ _~

IEAVSWIN
(MAINLINE)
Executes in SRB
mode in master's
address space.
Builds PCBs and
gets frames
allocated

Stage 1

o
IEAVGFA
Allocates
Stage 1
frames

ILRSWAP
Starts
Swap-in
paging I/O

Stage 1 I/O Completes
ILRPAGCM

IEAVPIOP
Decrements
SWIN root
count; Calls
root exit
when CQunt=O

®

IEAVSWIN
Entry IEAVSIRT
(root exit)
Rebuilds segment
and page tables

Schedules SRB to
swapped-in
address space

IEAVSWIN
Entry I EA VSWPP
Post RCT to
restore address
space, build PCBs,
and get frames
allocated

PCBs on entry to
SWIN root exit

IEAVPCB
Frees root
and Stage 1
PCBs

IEAVEACO
(ASCBCHAP)
Places ASCB
on dispatching
Queue

IGG079
(entry IGC07903)
Status start SRBs

IEAVGfA
Allocates
Stage 2
frames

Private Area Stage 1 PCBs chained out of
PCBRWRK 1 and PCBRWRK2

ILRIODRV
Starts paging
I/O

Figure

A-2.

Swap-In Process Flow

A-8

MVS Diagnostic Techniques

Swap-Out Process
IEAVAR02

SRM (IRARMCSO) posts the region control task (RCT) to swap out the address
space. RCT is responsible for:
•

lOS purge processing: I/O requests that have been requested or started are
purged or quiesced, respectively.

•

Halting all tasks in the address space with the exception of its own task.

•

Preventing system SRBs from executing.

IEAVSOUT

The numbers in the following descriptions correlate to the circled numbers in
Figure A-3.
1

IEAVSOUT receives control from RCT and calls STATUS (IEAVSSNQ) to stop
non-quiesceable SRBs.

2

lEAVSOUT gets enough PCBs to page out every private area page in the address space plus one
to be used as a swap out root.

3

IEAVSOUT clears the swap control table (SPCT) LSQA stage one pageable page, and fix entries
(SPCTSWPE), and all bits in the bit maps in the segment entries (SPCTSEGE). Prior to this,
the SPCT reflects the status of the address space at the last swap-out. SPCTSEGEs provide a
mechanism to check how many and which segments are obtained via GETMAIN in an address
space because there is a SPCTSEGE for each private area segment that is obtained by
GETMAIN.

4

IEAVSOUT builds a six-byte LSQA entry for each frame on the LSQA frame queue.

5

IEAVSOUT builds an eight-byte fix entry for each page (private or common) that has an FOE
on any TCB in this address space. The fix count is added into the fix entry SPCTSWPE. Note
that fixes done without a TCB address supplied do not have FOEs.

6

IEAVSOUT initializes a root PCB to zero. It initializes the remaining PCBs, which might be
used to swap-out a page as follows:
Partially initialized Swap-Out PCB
PCB
X'OO'
X'08'
X'tO'
X'14'

X'20'
X'24'
X'2C'

FFOOOOOO
,,00000000
06aaaaaa
00000000
80000000
80000000
00000000
00000000
aaaaaaaa
00000000
00000000
18COOOOO
00000000
00000000
00000000
00000000

-

Not currently queued flags

-

Root and output flags, and
address of root PCB
Free r~al frame flag
Swap-out flag

-

Address of ASCB

-

Start of AlA
Swap-out and write flags

Appendix A. Process Flows

A-9

IEAVAR02
Region Control Task

~

IEAVSOUT

0)

0
0
0
0
G)

0
0
0
@
@
@

Stops non-quiesceable SRBs
Gets ASCBFMCT+l PCBs
(1 extra for root)
Initializes SPCT
Builds LSOA entries in SPCT
SRB for
IEAVPIOI

Builds fix entries in SPCT
from FOEs
Initializes PCBs including
root
Purges paging I/O
Completes Stage 1 PCBs
(LSQA and Fixed)
Completes working set PCBs
(changed private area)
Frees unused PCBs
Schedule I EAVPI 01 to master
scheduler's address space
Returns to RCT

After the SRB is dispatched in
space:

PCBs are on local queue
(RSM L 100) when
received by PIO I

@

IEAVEACO
(ASCBCHAP)
Removes ASCB
from dispatching
queue

IEAVINV
Issues PTLB
ILRSWAP
Starts paging
I/O

Figure

A-3.

Swap-out Process Flow

A -10

MVS Diagnostic Techniques

7

lEAVSOUT purges paging for this address space on the common PCB I/O queue, local PCB
I/O queue, and the OFA deferred queue. The processing is to post users waiting on fixes, reset
page faulters, and to NO·OP the PCB. (Fix entries are made for PCBs found for private area
zero TCD fixes.) The NO-OP process makes the PCB look like a cancelled page load PCB; that
is, no notification (RESET/POSTING) is to be done and the frame is to be freed. PCBs on the
OFA defer queue are removed. The only exceptions here are for zero TCB fixes for which no
entries could be made in the SPCT (OETMAIN for SQA failed). These PCBs remain
unchanged and the fixed frame remains fixed throughout the swap.

8

IEAVSOUT fills XRBNs and VBNs into PCBs for each LSQA stage one pageable page or fix
entry now in the SPCT. Even unchanged fixed or LSQA pages are paged out. If a one·stage
swap is to be done, unchanged recently referenced pageable pages are also paged out.

9

IEAVSOUT next initializes a PCB for each changed page on the local frame queue for which a
stage one pageable page PCB was not built. It then sets a bit in the bit map (SPCTBITM) for
all pages that are to be paged in as part of stage two swap-in. The steal is based on a
comparison of a criterion number passed by SRM in OUXBSTC to PFTUIC.

10

IEAVSOUT returns any unused PCBs to the free queue. This marks where un the free queue
the swap-out began.

11

IEAVSOUT schedules an SRB for IEAVPIOI, releases the SALLOC lock, and returns to ReT
(lEAVAR02), which waits for ASCBQECB to be posted by swap-in (IEAVSWIN). Because
release of the SALLOC lock enables the processor, an address space is often swapped·out before
RCT has gotten a chance to wait. When analyzing a stand-alone dump, you will see the
following if the above case is true:
•
•
•
•

The RCT is dispatcLible.
There is no wait count in RBWCF.
There are no frames allocated to storage (ASCBFMCT = 0).
The address space is not on the ASCB dispatch ability queue.

Do not consider this situation a problem.

lEAVPIOl
IEAVPIOI receives control in the master scheduler's address space. It calls
ASCBCHAP to remove the ASCB from the dispatching queue, calls ASM with
the string of AlAs passed to it from lEAVSOUT via the SRBPARM field, and
calls lEAVINV to PTLB and exits.

Appendix A. Process Flows

A-II

EXCP/IOS
Figure A-4 is an overview of the I/O process through MVS using EXCP as the
driver. The following outline correlates to this process.
1.

Problem program issues GET/PUT (implied wait).

2.

Problem program branches to access method.

3.

Access method issues SVC 0 (EXCP) to EXCP front end.
or
Access method issues SVC 114 (EXCPVR) to EXCP front end.

4.

EXCP front end:
a.
b.
c.
d.
e.

Valida tes request.
Builds RQE.
Queues related requests.
If a VIO data set, goes to window intercept processor.
Builds SRB/IOSB.
f. If a virtual user, gets TCCW and BEB.
g. Branches to PAGE FIX appendage (if specified and not a V = R region).
h. Branch returns.
1.
If EXCPVR request, fixes pages from PAGE FIX appendage.
j. Fixes DEB for V = R user if not already fixed.
k. If a DASD device, branches to END of EXTENT appendage (if seek
address is out of specified extent).
1. Branch returns.
m. Branches to START I/O appendage if specified.
n. Branch returns.
o. If virtual user: translates CCWs, fixes pages for buffers, and builds IDAL.
!' !~~'-!~~ START I/O ~~~;:'~ (~;~~~b. ~~ti'j" tv lOS flV11l I;;;11U).
5.

lOS front end.
a.
b.
c.
d.
e.

A-12

M VS Diagnostic Techniques

Builds 10Q.
Selects physical path (channel scheduling).
If path available, adds prefix CCWs and issues SIO; otherwise, queues
10Q on LCH.
Restarts all queued l/Os to available channels.
Branch returns to EXCP front end and branch returns from EXCP front
end to problem program WAIT.

'-='
~

;*

Enabled, Supervisor, Key 0, Under TCB, Local Lock

Enabled, Problem Program, User Key, Under TCB

It>

--------BR

i>

GET/PUT

~

Access Method
EXCP

EXCP Front End

SVC 0 (EXCP)

-

Enabied, Supervisor. Key 0, Under TCB, Local Lock

-----------

~

~

~

'""

~

i

PAGE FIX
AppendagE

BRANCH

1

BRANCH

I

Path
Available
?
Yes

BRANCH

Branches IDASD Device and Seek
Address is Out of Extent}

BRANCH

~

Oueues 100 on LCH
Return To Caller

-----,

I

Branches (If SIO Appendage Specified)

I

I

BRANCH

C~I~pendag;):=

No

Prefixes CCWs
Issues SIO (Instruction)
Restarts All Oueued I/Os
to Available Channels
Returns

Fixes DEB For V=R if Not Fixed Yet.

"

IDS Front End
Builds 100
Selects Physical Path
(CHANNEL SCHEDULING}

Branches (If PAGE FIX Appendage
Specified and Not V=R Region)

EOE
Appendage

~

Disabled, Supervisor, Key 0, Under TCB

~

Validates Request
Builds ROE
Oueues Related Requests
If VIO Data Set, Goes to WINDOW
INTERCEPT PROCESSOR
Builds SRBIIOSB
If Virtual User, Gets TCCW and BEB

SVC 114 (EXCPVR)

o
00

lOS

EXCP Processor

User

"'l

BRANCH

Channel Program
Execution

If Virtual User: Translates CCWs,
Fixes Pages For Buffers, Builds IDAL

Enabled, Problem Program, User Key, Under TCB

-- -- --

WAIT
ECB=ECBX

--

-- ----

Issues ST ART 10 (Macro}

BRANCH

Returns

--------------------- f-----Supervisor,
-- --Disabled,
-- ----- - Key 0
Disabled,
Supervis~e~

II I/O Interrupt

I

I

BRANCH

---------

I

Supervisor, Disabled, Key ~

f-- - -

Disabled Interrupt Exit (DIE)

(

IDS Back End

BRANCH

l

BRANCH

Maps 10SB/IOB
BRANCH

Maps 108/1058

BRANCH

Oueues Type 3 Related Requests

-

y"
TRAS

-

- - - - -- -- -- - - - - -r---Supervisor,
-- ---- ---- ---- --- f - - - -Supervisor,
Enabled, Key 0, Under SRB
Enabled, User Key, Local Lock, Under SRB
- - - - - - - - - - -- -- ---- - -- -- -- - Appendages

?>
PCI fV=Vj

""o'"'

CE

~

Cf}
Cf}

BRANCH

Maps 10SB/IOB

ABE

~

~

I

Cf}

>
......
I

W

.

Maps 108/IOSB
Termination:
Maps 10SB/IOB
Start Related Requests
Free Control Blocks
Posts ECB = ECBX
Exits to Dispatcher

NO

Schedules POST STATUS
(Global SRB)
Channel Restart
Returns to FLiH

-- -- -- -- -- -- -- -- -- - - Supervisor, Enabled, Key 0, Under SRB

-----.-----

,

IDS POST STATUS

E XCP Back End

BRANCH

DIE?

l

TRAS

:>

~
8;;<'

<>)

FLiH

If PCI and V=R or EXCPVR
PCI
Appendage

l---- -- -- - -

BRANCH

If Exit Processing (PCI, CE, ABE)

BRANCH

BRANCH

No

Error

Yes
7

Branches to ERP or
Schedules ERP
Exits to Dispatcher

From
Dispatcher

6.

lOS back end (entry from I/O FLIH) entered as a result of I/O interrupt.
a.

If DIE is specified:

1) TRAS (translates address space - to get addressability to control
blocks in originating address space).
2) Branch enters DIE.
3) If PCI and Y = R or EXCPYR, maps 10SB to lOB and branch enters
PCI appendage.
4) PCI processing.
5) Branch returns ot DIE.
6) Maps lOB to 10SB.
7) Queues type-3-related requests.
8) Branch return to lOS front end.
9) TRAS (returns to addressability at time of interrupt).

7.

b.

Schedules POST STATUS fflglobal" (means POST STATUS will be
entered via dispatcher).

c.

Branches to channel restart to start queued 10QEs on LCHs.

d.

Returns to FLIH.

e.

If system was in SRB mode, loads PSW for SRB or returns to dispatcher.

lOS POST STATUS (scheduled from lOS back end).
a.

If PCI, CE or ABE appendages specified:
1) Branch enters EXCP back end.
2) Maps 10SB to lOB.
3) Branch enters appropriate appendage.
5) Branch returns to EXCP back end.
6) Maps lOB to 10SB.
7) Branch returns to lOS POST STATUS.

b.

If error, schedules ERP. (See 8.)

c.

Branches to EXCP back end for termination processing.
1)
2)
3)
4)
5)

8.

ERP interface.
a.
b.
c.

A -14

Maps 10SB to lOB.
Starts related requests.
Unfixes buffer pages.
Posts ECB (the one after the GET/PUT).
Exits to the dispatcher.

MVS Diagnostic Techniques

If IBM ERP, get ERP work area.
If DASD (lECYDERP), branch to ERP.
If non-DASD, schedule ERP loader (lECYERPL) under SIRB. Use
stage II exit effector to queue SRB to ASXBFSRB. Set stage II exit
effector switch in ASCB.

GETMAIN/FREEMAIN
This chapter describes the processing for virtual storage requests in terms of
GETMAIN processing and FREEMAIN processing. The flow through the
GETMAIN jFREEMAIN process is complicated and the VSM control block
structure should be understood prior to following this process. This process flow
is not intended to explain how GETMAINjFREEMAIN works but to provide an
understanding of the important considerations of virtual storage management,
how the important control blocks are manipulated, and the common subroutines
ofVSM.

GETMAIN Processing
The following describes the processing required to satisfy a given -GETMAIN.
1.

A problem program issues an SVC 10 GETMAIN for subpool 0 for 256
bytes.

2.

GETMAIN (entry at IGCOI0) saves the TCB addresses in LDA, sets
FRR (module IEAVGFRR), sets up the length
and subpool ID for common processing routines, saves the caller's mode in
LDARQSTA, and goes to the common GETMAIN routine, GMCOMMI.
GETMAINjFRE~MAIN's

3.

GMCOMMI goes to routine UG4SPO to find the SPQE for the requested
subpool 0, PGTSPQE2 is called to search the TCBMSS chain. If no SPQE is
found, PGTSPQE2 saves the address of the previous SPQE on the chain in
SPQE SAVE.
UG4PSO then calls routine GETSPQEC to get a 16-byte element to build and
chain-in an SPQE for the requested subpool. The 16-byte blocks for internal
control blocks are obtained via GETMAINC (a simple GETCELL function).
After obtaining the SPQE, module lEAVGM04 is branched to and processing
continues at label lEAVGM4G.

4.

At label ROUND, the request is rounded up to a doubleword boundary.

5.

GMCOMM calls GFRECORE to search the FQEs pointed to by each DQE
for the appropriate subpool. A first-fit algorithm is used to find a free
element large enough to satisfy the request. Exception: LSQAjSQA req uests
for 4096 bytes or less are not satisfied across page boundaries because the
request can be for page or segment tables that must reside in contiguous real
storage.

6.

If storage is found in an FQE, GFRECORE calls GFQEUPDT to maintain
and update the FQE chain. (Control is passed to step 9.)

7.

If storage is not found in an FQE, GFRECORE determines the number of
4K-blocks that are required and calls G4KSRCH to satisfy the request.

8.

G4KSRCH performs the following functions:
a.

Calls FBQSRCH to search the appropriate FBQE chain to find 4K bytes
of free space. (For problem program subpools, TCBPQE points to PQE
Appendix A. Process Flows . A -15

which points to FBQE.) Once found, FBQSRCH removes the space from
the FBQE and, if the FBQE is empty, frees it via an internal
FREEMAIN (FMAINB in module lEAVGMOO) or an .internal freecell
(FMAINC in module lEAVGMOO).

9.

h.

Acquires a DQE and chains it onto the DQE chain anchored in the
SPQE.

c.

Calls RSM (IEAVFPI) to locate the page table entry (PGTE) and the
external page table entry (XPTE) .of the new 4K-block. Then at label
SETUPPTE it initializes both the GETMAIN-assigned flag (PGTPAM)
in the PGTE and the XPTPROT (protection key) in the XPTE ( + 0).
Note: This is the only place XPTPROT is set.

d.

Updates the SMF region usage fields of the TCT (task control table).

e.

Creates an FQE and chains it from the DQE that was just built.

f.

Returns to GMCOMM I.

GMCOMMI places the address of the allocated storage in register 1 and sets
the return code. Then GMCOMMI performs housekeeping of any areas
chained from FMAREAS in the LDA, deletes the FRR, and passes control to
the EXIT prologue.

FREEMAIN Processing
The following is a logic flow of the FREEMAIN process when a problem
program issues an SVC 10 requesting 256 bytes from subpool O.
1.

Upon entry at IGCOIO', FREEMAIN:
a.
b.
c.
d.
e.

A -16

Saves the TCB address in LDA.
Establishes the FRR (lEAVGFRR).
Saves the callers mode in LDARQSTA.
Sets up the length and subpool ID for common processing.
Passes control to FMCOMMI.

2.

FMCOMMI passes control to FMCOM because the request is not to free an
entire subpool. FMCOM calls PGTSPQE2 to locate the SPQE. When the
appropriate SPQE is found, control passes to module lEAVGM04 (at label
IEAVGM4F) where processing continues. The associated DQEs are searched
to locate the one DQE that describes the area to be freed.

3.

The routine at label QELOCATE ensures that the area is not already
described in an FQE (if it is, the requestor is abnormally terminated).
Subroutine CREATFQE obtains a 16;'byte element for an FQE, then builds
the FQE and adds it to the proper FQE chain. Note: If possible, FQEs are
combined if the new free space is adjacent to free space described by an
existing FQE.

4.

If less than 4K bytes are freed, FREEMAIN has completed its task and
control is passed to the EXIT prologue.

MVS Diagnostic Techniques

s.
a.

If all space described by a DQE has become free, FREEMAIN frees the
FQE and DQE and notifies RSM (IEAVRELV) that a page(s) can be
released.

b. If a virtual page is freed, FREEMAIN frees the FQE (and adjusts the
DQE if the free pages exist at either end of the described area) and
notifies RSM (IEAVRELV) to release the page(s).
c.

If the free page exists in the middle of the area described by the DQE,
FREEMAIN obtains a new DQE and the two DQEs will now describe
the area (essentially the area has been split into two parts). FREEMAIN
updates the associated FQEs and notifies RSM (lEAVRELV) to releas\:
the page(s).

Note: RSM invalidates the PGTE(s) for the associated pages being freed
and calls ASM to release the auxiliary storage copy of the page. If a
page table has become completely free, lEAVGM04 is passed the PGT
address, which is queued Jrom a field in the LDA (FMAREAS) to be
freed at exit time. FMAREAS is really a list of items no longer required
to describe virtual storage.

6.

After restructuring the DQEs, MRELEASE returns virtual space to the
appropriate FBQEs. If possible, MRELEASE places 4K blocks of storage in
an existing FBQE; if not, it builds a new FBQE and includes it in the existing
FBQE chain.

7.

FREEMAIN returns to FMCOMMIA, which performs FMAREAS
bookkeeping, deletes the FRR, and returns to the caller.
Note: FMAREAS anchors a one-way chain of areas to be freed. The area
itself contains the address of the next area at offset +0 and the subpool's ID
and length at offset +4. These areas are not freed immediately, because
freeing them might cause register save area overlays on the double recursion
into FREEMAIN processing.

Appendix A. Process Flows

A-17

VTAM Process
The following sho~s the logic flow through the VTAM component into lOS and
out to the 3705 when an application issues a SEND request. This description
includes the major module flow and the control blocks required in order to
process the request. Note that this is a general processing flow; additional
modules not shown can be entered depending on options and device type.
Figure A-5 illustrates the system modes at various stages of the VTAM
processing.
1.

The application program issues the VTAM SEND macro, passing an RPL
(request parameter list), which points to the data that is to be sent.

2.

The SEND macro branches to a VTAM interface routine (1STAICIR).

3.

ISTAICIR determines that this is a non-authorized request and issues the
VTAM SVC. This is a type 1 SVC (SVC 124).

4.

The type 1 SVC routine (ISTAPC22) obtains an MQL (MPST queueing
element), places the address of the user RPL in it, and issues the TPQUE
macro to queue the MQL to the TPIO PAB for the application's address
space.

5.

The TPQUE macro (normally) issues the TPSCHED macro in order to
schedule the TPIO PAB.

6.

The TPSCHED macro invokes ISTAPC32, which queues the TPIO PAB to
the memory process scheduling table (MPST), and schedules an SRB to
execute ISTAPC55.

7.

ISTAPC32 returns to ISTAPC22.

8.

1STAPC22 issues a Type 1 exit back to 1STAICIR.

9.

1STAICIR determines if the request was synchronous or asynchronous. If it
was synchronous, is issues the WAIT macro. If it was asynchronous, it
returns control to the application program.

10. When the SRB is dispatched, ISTAPC55 dequeues the TPIO PAB from the
MPST, obtains a component recovery area (CRA) from the large pageable
(LP) pool and passes control to ISTAPC57.
11. ISTAPC57 formats the request parameter header (RPH) (within the CRA),
dequeues the MQL from the TPIO PAB, and passes control to ISTAPC23.
12. ISTAPC23 release the MQL, obtains a Copy RPL (CRPL) from the CRPL
pool and copies the user RPL into it.
13. ISTAPC23 then issues the TPQUE macro to queue the CRPL to the control
layer outbound PAB in the appropriate FMCB and schedules control layer
processing.

A -18

MVS Diagnostic Techniques

14. ISTAPC23 then issues the VTAM·TPEXIT macro, which passes control to
ISTAPC31.
15. ISTAPC31 recognizes that there is more work to do· (control layer processing)
and passes control to 1STAPCS7.
Application's Address Space
Task Mode

I

Application's Address Space
SRB Mode

Any Address Space
Disabled Mode

I/O interrupt

\
VS2 Dispatcher
Via SRB

~
Control Layer
Processing

TP lOS
Processing

Exits to VS2 Dispatcher

I

I
I
J

Figure

A-S.

VTAM SEND Process Flow

16. ISTAPCS7 reformats the RPH (within the same CRA) for processing by the
control layer.
17. ISTAPCS7 then passes control to the control layer (lSTDCCOO).
18. ISTDCCOO recognizes that this is a SEND request, obtains a logical channel
program block (LCPB) from th~ CRPL pool, and invokes ISTRCC22.
19. ISTRCC22 sets up the logical channel command words (LCCWs) in the
LCPB from the options in the CRPLand issues the TPQUE macro to queue
the LCPB to the TPIOS outbound PAB in the FMCB and schedule TPIOS
processing.

Appendix A. Process Flows

A -19

20. ISTRCC22 then passes control to ISTCDDOO, which issues the TPEXIT
macro.
21. The TPEXIT macro passes control to ISTAPC31, which recognizes that there
is more work to do (TPIOS processing) and passes control to 1STAPCS7.
22. 1STAPCS7 reformats the RPH (within the same eRA) for TPIOS processing
and passes control to ISTZAFIB.
23. Within TPIOS, ISTZDF AO allocates the fixed I/O buffer; ISTZDFCO' and
ISTZDFDO move the user data to the I/O buffer.
24. Once the data is moved from the user's buffer, TPIOS invokes a routine
(ISTRCFYO) which calls 1STAICPT. 1STAICPT copies the CRPL back to
the user's RPL, frees the CRPL, and POSTs the ECB complete.
2S. ISTRCFYO then frees the LCPB and returns control to TPIOS.
26. TPIOS then invokes ISTZEMBB, which obtains the UCB lock for the 370S
and checks the ICNCB (intermediate controller node control block) to see if
there is an active channel program currently executing for the 370S.
27. If the 370S is busy, ISTZEMBB queues the I/O buffer to the ICNCB write
queue, releases the UCB lock, and returns to TPIOS. (Go to step 29.)
28. If the 370S is not busy, ISTZEMBB calls ISTZEMAB, which issues the
STARTIO macro to lOS and then returns to ISTZEMBB, which returns to
TPIOS. The IOSB, which is the interface to lOS, physically resides within the
ICNCB.
29. After ISTZEMBB returns to TPIOS, TPIOS issues the TPEXIT macro, which
invokes 1STAPC31.
30. ISTAPC31 recognizes that there is nothing more to do and calls ISTAPCS8.
31. ISTAPCS8 frees the CRA an exits to the VS2 dispatcher.
32. Sometime later, an I/O interrupt occurs as a result of the write channel
program completing.
33. lOS passes ·control to the VTAM DIE (disable interrupt exit) (ISTZFM3B).
34. ISTZFM3B frees the I/O buffer and returns to lOS, indicating that POST
ST ATUS should not be scheduled.
3S. lOS exits to the dispatcher.

A -20

MVS Diagnostic Techniques

TSO
Following are- some of the more important processes-invoLved with the
.TSO/TIOC/TCAMinterfaceportion ofMVS. The processes are:
•
•
•
•
•
•
•
•

Time Sharing Initialization
LOGONProcessing
TSO Line Drop Processing
TMP· and Command Processor Interface
TSO Command Processor Recovery
TSO Terminal I/O Overview
TSO/TIOC Terminal I/O Diagnostic Techniques
TSO Attention Processing

Time Sharing Initialization
The system operator issues the MODIFY command (F TeAM, TS=START) to
initialize the time sharing system. Terminal I/O control (TIOe) logic is
documented in OS/VS TeAM Level 10 Logic.
The major functions that occur during time sharing initialization are:
1.

The SYSl.PARMLIB member IKJPRMxx is read to determine the TIOe
buffer size and number, the maximum number of time sharing users allowed
to !:>e logged on at one time, and thresholds for the maximum number of
Tloe buffers a single user can use at one time.

2.

The main control block for the time sharing system (TIOe reference table TIOCRPT) is initialized. This control block points to the free queue of TIOe
buffers and has status flags indicating whether the system is in an LWAIT
(out of TIOe buffers). The TIOCRPTalso points to a pool of terminal
status blocks.

3. The pool of terminal status blocks (TSBs) is built. The number of TSBs is
determined by the maximum user parameter in IKJPRMxx. A TSB is
assigned to a user during logon processing. The TSB connects the ASCB of
the user to the terminal-name table entry of the terminal. From the
terminal-name table entry, TCAM can locate t~e terminal table entry for the
user and hence the address of the destination QCB. The TSB contains input
and output queues for TIOCbuffers that are used by the time sharing user.
The TSB also contains status indicators that record whether the user is in an
input wait (TGET issued and no TIOC buffer on TSB input queue) or an
output wait (maximum number of TIOC buffers used for output).
4. The TIOC buffer pool is built. The number and size of the buffers is
determined from IKJPRMxx. If no parmlib member was specified on the
MODIFY TCAM command, SYSl.PARMLIB is searched for the default
parmlib member name - IKJPRMOO. If this member is not found, standard
default values are used.
5. The 'TSO HAS BEEN INITIALIZED' message is issued (via WTO).

Appendix A. Process Flows

A-21

Terminal User Issues LOGON

, - - - -- -- -- -- -r;;;S-;;';;-'
I

Address Space

I

I

I
I
I
I
I
II

I

TIOC

ATTACH

SVC34
'LOGON'

IEDAY3
TIOC
LOGON
SYNC

POST

IEDAYL

and
IEDAYLL

I

I

TeAM Address Space

I

-~

I

I

I
I

I
I
LOGON

Processor

XCTL
STC
ATTACH
TMP

New User Address Space

Note: Details of this process are shown in
part 2 of this figure.

Figure A-6 (Part 1 of 2).

MVS Diagnostic Techniques

I
I
I
I

L---.---r----1--

A-22

I

Ove"iew of Logon Processing

LOGON Scheduling
IKJEFLA
STC

XCTL

..

Installation
Exit

Logon
Initialization

I

IUNK

IKJEFLB

IKJEFLE

IKJEFLC

Logon
Scheduler
Router

ATTACH

Calls Job
Scheduling
Subroutine

POST

Logon
Monitor

LINK

Schedules
Session

CALL

Logon
Verification

IKJEFLH
Logon
Information
Routine

IXCTL
IKJEFLJ

IEESB605
Job
Scheduling
Subroutine
(STC)

LINK

Pre-TMP
Exit

ATTACH

TMP
Issues
"READY"
Message

Figure A-6 (part 2 of 2). Overview of Logon Processing

Appendix A. Process Flows

A-23

LOGON Processing
The major functions of LOGON processing are:
1.

TCAM handles line I/O and routes the buffer to the TSO message handler.
The message handler routes the buffer to various functional routines. One of
these is logon.

2.

The logon routine receives control from the TSO message handler as a result
of the expansion of the LOGON macro. Logon routes the buffer to
TSINPUT so that logon scheduling may retrieve it via a TGET SVC. TIOC
logon then issues an SVC 34 to notify the master scheduler that logon
processing should be started. TIOC then issues QTIP 10 to initialize control
blocks. Note: QTIP is the TIOC code invoked when SVC 101 is issued. It
performs functions related to communication between the TCAM and TSO
user address spaces. The specific function it is to perform is indicated by an
entry code (for example, QTIP 10). A table of entry codes, their callers, the
functions performed, and the modules that provide the function is contained
in OS/VS TeAM Level 10 Logic.
QTIP issues an XMPOST to inform the master scheduler that TIOC
initialization is complete and that memory create may begin. TIOC then
returns to the message handler for final buffer disposition. If logon fails or is
terminated, TIOC i~ notified so that the appropriate error message can be
issued.

3.

TSINPVT invokes QTIP to move the contents of the TeAM buffer to the
TIOC buffers. This data can then be accessed using TGET services.

4.

The master scheduler recognizes that a logon has been requested and attaches
TIOC synchronization. This routine waits until QTIP signals with a post that
memory create can begin. Once an address space has been initialized for the
logon request, the region control task is the first task to be dispatched.

5.

Region control establishes an ESTAE routine, attaches the dump task,
attaches started task control, and waits for one of the following:
•
•
•

A-24

An attention request signaled by TIOC via XMPOST
A swap request signaled by SRM
A termination request

6.

Started task control recognizes that logon is requested and passes control to
logon initialization (lKJEFLA).

7.

Logon initialization opens the VADS and broadcast data sets, initializes
control blocks, and calls logon scheduling (IKJEFLB).

8.

The logon load module contains four service modules. One, IKJEFLPO,
contains the default values for the number of seconds requested between
'LOGON PROCEEDING' messages and the number of logon attempts
allowed before automatic logoff. Both values are sysgen options on the TSO
macro. The logon scheduler attaches the logon monitor (lKJEFLC). The
scheduler and monitor now begin parallel processing. WAITs and POSTs are
used when synchronization is required.

MVS Diagnostic Techniques

9.

The logon monitor (IKJEFLC) builds the environment control table (ECT),
sets the tIrst element of the input stack to indicate terminal input, and links to
logon verification.

10~

Logon v~rification (IKJEFLE) calls the user's pre-prompt exit if it was coded.
Logon verification makes the following, checks:
•
•
•

Determines (via ENQ) iftheuserid is in use.
Checks the user's password, account number, and procedure name.
Checks the performance group requested in the LOGON command.

Logon verification proJ,llpts the user for missing parameters if required
parameters' do'not have defaults in the UADS. After all required parameters
have been obtained, verification builds the JOB and EXEC statement images
for the session. The EXEC statement contains the name of a logon procedure
specified in the UADS or the LOGON command.
11. Logon verification posts the logon scheduler when the parameters are
complete and the jobcan,be scheduled. The scheduler's job now is to cause
the broadcast messages to be listed at the terminal at the same time that the
user's job is being scheduled. 10 do this, it posts the monitor task and then
XCTLs to the initiator, passing it the JCL that has been created.
12. The logon monitor regains control when signaled by the logon scheduler,
attaches the LISTBC command processor to write broadcast messages to the
terminal, and then waits for a post from a special initiator logon routine.
This post signals that final processing can be completed.
13. The initiator uses the TSO internal reader to send the logon job to JES2.
JES2 reads the user's procedure from the procedure library specified by the
&TSU job class parameter and changes the JCL to internal text. This is
placed on the spool data set. Once this processing has completed, the
initiator requests the user's job by ID and completes initiation and allocation.
Initiation finally gives control to a special TSO routine (pre-TMP exit,
IKJEFLJ). This routine posts the logon monitor and issues a WAIT. The
logon monitor then terminates. This causes the initiator task to regain
control. The logon monitor is then detached. Once the monitor is detached,
the initiator attaches the TMP and waits.
14. The TMP (specified as IKJEFTOI in the LOGON PROC on the EXEC
statement) performs initialization and then issues a PUTGET to write the
'READY' message and request a command from the user. This PUTGET
results in a TPUT to send READY and a TGET to request terminal input.
The user is now in an input wait. This signals SRM to perform a swap-out
until input is available.
Figure A-7 shows TCAM's organization after a TSO logon. The following are
detailed descriptions of the logon process including information on control block
manipulation. The numbers in parentheses correlate to the numbers in the
preceding summary of the logon process.

Appendix A. Process Flows

A-25

Common Storage
ASCB

CVT

TS buffers
(with data)

TCAM's Address Space
TSINPUTaCB

MCP

H

""

/

TCAM buffers
MH

7

1
-TSO
- User ASID

Figure A-7. TeAM Organization After a TSO Logon

A -26

MVS Diagnostic Techniques

TSINPUT aCB

I

TIOC Logo"

Proc~ss;"g

(2):

•

Checks the maximum user count in TIOCRPT.

•

Issues SVC 34 'LOGON'.

•

Places the returned ASID in the QCB for this line.

•

Calls QTIP (entry 10) to find and initialize the TSB.
Puts TSB address in the ASCB for the user's address space.
Puts the ASCB address in the TSB.
·Updates the user count.
Puts the·UeB address in the TSB.
XMPOSTs 'TIOC SYNC'.

•

Sets the QCB to indicate TSO.

•

Pass the logon message buffer to TSINPUT QCB (which is now available to
system logon processing via GETLINE).

Logo" Inititdizatio" (IKIEFLA) (7): Logon initialization uses the address of the
ASCB as input arid does the following:
•

Ensures SYS1.UADS and SYS1.BRODCAST data sets are allocated.

•

Gets the LWA (logon work area) from the LSQA. (See Figure A-8.)

•
•

Puts the LWA address in the ASXB.
Gets the JSEL Gob scheduling entrance list) from the LSQA.

•

Puts the CSCB and ASCB addresses in the JSEL.

•

Gets the JSXL Gob scheduling exit list) from the LSQA.

•

Puts the LWA address in the JSXL. JSXL contains pointers to the
PRE-TMP, POST-TMP, and PRE-FREEPART exits.

•
•
•

Puts the JSXL address in the JSEL.
Gets the UPT (user profile table) from subpool230.
Issues BLDL for the installation exit routine (Release 2 only).

•

Gets the PSCB (protected step control block) from subpool 230.

•
•
•

Puts the PSCB address in the LWA.
Puts the UPT address in the PSCB.
Get-s the re-Iogon buffer from subpool230.

•

Puts the re-Iogon address in the PSCB.

•

Calls the logon scheduler router.

Logo" Scheduler Router (IKIEFLB) (8):
•
•
•
•

Frees subpool O.
Attaches the logon monitor.
Posts the monitor with the 'schedule' code.
Waits for the 'what to do' post from the monitor.

Appendix A. Process Flows

A-27

ASXB

X'14'

~ LWA
Logon work area
II

LWA"

PSCB

X'20' • ECT
24

LOGON ECB

~ RLGB

28

PROMPT ECB

30

2C

SCHED ECB

34 • UPT

5C ~ LOGON ECB
60 , PROMPT ECB

o
4

.-...-------1
•

*The logon work area (lKJEFLWA) is a 148-byte area that is created by IKJEFLA
and is pointed to by ASXB and JSXL. It contains control block pointers, entrance
lists, and parameter lists that are required for logon/logoff.

Figure

A-28

MVS Diagnostic Techniques

A-S.

Logon Work Area

(AJgtM'Mollitor (IKIEFLC)· (9):
•
•
•
•
•
•
•

•
•
•
•
•
•
•
•

Switches the storage key to '8'.
Gets theSTAXwork area fromsubpooll.
Gets the BCT (environment control table) from subpooll.
Puts the BeT addtess in the LWA.
Invokes the STACK macro (input is to come from the terminal).
Gets thenewCSCB (command scheduler control block) from the SQA.
Sets theCSCB toindicate to the master scheduler that the job is:
swapp able
terminal job
.cancellable
TSO
Gets the local and CMS locks.
Puts the CSCB address in the ASCB.
Frees the local and CMS locks.
Issues the MGCR macro to remove the old CSCB from the chain.
Puts the new CSCB pointer in the JSCB and JSEL.
Issues the MGCR macro to add the new CSCB to the chain.
Issue the STAX m.acro to set up attention handling.
Links to logon verification.

Logon Verification (IKJEFLE) (10):
•

Calls the installation exit (if necessary).

•

Issues GETLINE or uses the installation supplied'buffer containing the logon
parameters.

•

Calls the command scan service routine to ensure that input is the LOGON
or LOGOFF command (assumes LOGON).

•

Calls PARSE for logon parameter parsing.

•

Indicates no password required for the UADS.

•

Issues ENQ on the UADS (prevents the ACCT CP from changing UADS).

•

Opens the UADS.

•

Issues FIND for the use rid member (userid is taken from the logon
parameter).

•

Places the userid in the PSCB (protected step control block).

•

Posts the logon scheduler.

•

Waits for the post from the logon scheduler.

Logon Scheduler (IKJEFLB):
•
•
•

Enqueues (via ENQ) on SYSIKJUA.USERID.
Posts logon verification.
Waits for logon verification.
Appendix A. Process Flows

A -29

Logon Verification (IKIEFLE):

A -30

•

Dequeues (via DEQ) from DADS.

•

Puts the userid in the CSCB.

•

Puts the userid in the ASCB.

•

Enqueues (via ENQ) on DADS.

•

Finds userid member.

•

Dequeues (via DEQ) on DADS.

•

Reads UADS.

•

Issues check.

•

Places the parameter in the proper control block.

•

Places the password in the TSB.

•

Places the procname in the CSCB.

•

Places the region size in the PSCB.

•

Informs SRM of the performance group.

•

Builds the JCL:
/ /USERID JOB 'account#' ,REGION = region size
/ /procname EXEC procname, PERFORM = performance group

•

Issues the 'LOGON IN PROGRESS' message to the terminal.

•

Closes the DADS.

•

Clears 'NO PASSWORD' in the JSCB.

•

Dequeues (via DEQ) from UADS.

•

Posts the logon scheduler to schedule the session. (11)

•

Waits for the logon scheduler.

•

Sends the broadcast messages (via the information routine). (12)

•

Issues the 'LOGON IN PROGRESS' messages until posted by the initiator.

•

Frees subpool 78.

MVS Diagnostic Techniques

Logon Scheduler (IKJEFLB) (11):
•
•
•

Sets up the interface to JSS.
Posts the logon monitor.
XCTLs to JSS (initiator).

Job Scheduling Subroutine (IEESB605) (13):
•

Calls the PRE-TMP exit.

PRE-TMP Exit (IKJEFLJ):
•

Posts the monitor task to terminate.

•

Moves the PSCB from (unaccountable) subpool230 storage to (accountable)
subpool 252 storage. The PSCB address is placed in the active JSCB.

•

Moves the UPT and the re-Iogon buffer to 0 (allows updating by CPs).

•

Returns to the initiator.

Initiator:
•

Attaches TMP (PARM = 'xxx ... ' is passed).

TMP (14):
•
•

Issues "READY" message.
Requests terminal input.

Appendix A. Process Flows

A -31

LOGON Scheduling Diagnostic Aids
The following two figures contain information that can be.used for diagnosing
problems that occur during logon scheduling.
Field Name
8nclCOIiteIRs
LWAINXI
LWALA
LWALB
LWALC
LWALE
LWALEA
LWALI
LWALH
LWALL
LWALGM
LWALJ
.LWALK
LWALG
LWALGB
LWALS
LWALTBC
LWAMCK
LWAPCK
LWAPHASE
LWAPHASE
LWAPSW
LWATNBT

Figure A-9.

A-32

MVS Diagnostic Techniques

Name of

=1

=1
=1
=1
=1
=1
=1
=1
=1
=1
=1
=1
=1
=1
=1
=1
=0
=1

Ex~Moduie
IKJEFLD
IKJEFLA
IKJEFLB
IKJEFLC
IKJEFLE
IKJEFLEA
iIoEFLI
IKJEFLH
IKJEFLL
IKJEFLGM
IKJEFLJ
IKJEFLK
IKJEFLG
IKJEFLGB
IKJEFLS
IKJEFLH
IKJEFLGB
IKJEFLGB
Any LOGON module
except IKJEFLH
IKJEFLH
IKJEFLGB
IKJEFLG

Common Name of Module
Exit (written by installation)
LOGON Initialization
LOGON Scheduling
LOGON Monitor
LOGON/LOGOFF Verification
Parse/Scan Interface
Installation Interface
LOGON Synchronizer
LOGOFF Processing
LOGON Message Handler
Pre = attach Exit
Post-attach Exit
Attention Exit
LOGON Monitor Recovery
LOGON Scheduling Recovery and Retry
Mail and Notices Processing
ABEND was a machine check
ABEND was a program check
LOGON/LOGOFF Verification
In~tallation

LOGON Synchronizer
Console Restart key depressed
Attention Routine

LOGON Work Area Bits That Indicate the Currently Executing Module

Module

Module

Issuing

Being
Posted
IKJEFLC

POST
IKJEFLB

IKJEFLC

IKJEFLB

IKJEFLB

KJEFLE

Location
of
ECB
field
LWASECB
inLWA

field
LWAPECB
inLWA

field
LWAPECB
inLWA

Condition of
Post
Code

16

Module Is$uing

POST
Ready to invoke job
scheduling subroutine
(lEESB60S).

Action Taken by
Module Being
Posted
Invoke LOGON
information routine
(IKJEFLH).

24

Terminating for
LOGOFF or for
unusual termination
of LOGON monitor
(IKJEFLC).

Perform clean-up
operations and
terminate.

12

Termination or
attention requested.

Issue D EQ on user
iden tifica tion.

16

Verified and processed
the LOGON
parameters.

Schedule a terminal
session.

24

Processing a LOGOFF
command.

Terminate.

8

Authorized the user
identification.

Issue ENQ on user
identification.

12

Error processing.

Issue DEQ on user
identification.

IKJEFLJ

IKJEFLH

field
LWASECB
inLWA

20

Detects that the
initiator is ready to
attach the TMP.

Finish LISTBC
processing; return
to caller.

IKJEFLH

IKJEFLJ

field
LWAPECB
inLWA

20

Finished LISTBC
processing.

Terminate so the
initiator can attach
the TMP.

Figure

A-tO.

LOGON Scheduling Post Codes

Appendix A. Process Flows

A -33

TSO Line Drop Processing
The following description corresponds to the overview of line drop processing
shown in Figure A-II.

IEDAYH (Part of TCAM MCP):
•

Gets control from the TCAM dispatcher when either of the following occurs:
-

A hang up on a monitoring channel program or a message generation.
Each input or output message ends.

•

Tests for and handles several kinds of errors. If it discovers the line has
dropped, it begins terminating the user. Each of the following is considered a
line drop:
Entry because of a hang up on a monitoring channel program or a
message generation
A 3705 control unit error - indicated in the SCB. (station control block)
A permanent terminal error - indicated in the SCB
A countable error and an appropriate number of retries have been done indicated in the SCB

•

If a line drops, issues a QTIP 4 (SVC 101, entry co.de 4).

QTIP 4 (IEDAYHH):
•

TSBHUNG= I.

•

Issues QTIP 28 to free the TCAM buffers.

•

If the reconnect time limit is 0 (in TIOCRPT), then branch enters SIC
(system-initiated-cancel IKJEFLF) with code 622; upon return, returns to
caller.

•

For a non-O RECONLIM:
Sets TSBMINL equal to the reconnect time hmn.
If TIOCTECB (in TIOCRPT) is posted, then increases the value in
TSBMINL by one. Otherwise, posts TIOCTECB (which IEDAY802,
running as a subtask of TCAM, is waiting for).

•

A -34

Returns.

MVS Diagnostic Techniques

LINE DROP IN TSO ENVIRONMENT
TeAM Address Space
TCAMMCP
SVC 101
IEDAYH

POST
QTIP4

..

I--

....

IEDAY802
Subtasks
of TCAM

CALL

-

SIC
IKJEFLF

I
r---------.J

USER Address Space

I

SCHEDULE
SRB
I

POST

r---

SIC (SRB)
IKJL4TOO

I

t

SVC
INITIATOR*

-

-

CALL
SVC 34

I

RETURN

~

TMP

CALLRTM

-

I

I
I

___
_ _ _ _ ----.J
ABEND

Command
Processor

*Upon return, continues with
normal logoff.

Figure

A-II.

Overview of TSO Line Drop Process

Appendix A. Process Flows

A-35

IEDAY802 (sub task of TCAM): Keeps track of users whose lines have dropped
and, if the time limit expires before they come back, terminates the address space.
IEDAY802 does the following:

•

Waits for TIOCTECB.

•

Sets the one-minut ~ timer.

•

Invokes QTIP 27 (lEDAY88) SVC 101, entry 27 which scans the TSBs for
TSBHUNG = 1 and TSBMINL"O.
-

If so, QTIP 27 decreases TSBMINL by 1.

-

If TSBMINL is now 0, QTIP 27 branch enters SIC
(system-initiated-cancel) with code 622.

-

QTIP 27 returns a code of 0 if any users have time left or a code of 4 if
all users have been cancelled.

•

If the return code is 0, IEDAY802 goes to the one-minute timer.

•

If the return code is 4, lED AY802 waits for TIOCTECB.

SIC (system-initiated cancel):

IKJEFLF schedules an SRB in the address space to be terminated, passes a
completion code (622 for line drop), and returns to the caller.
IKJL4TOO runs under the SRB scheduled by IKJEFLF and gets control the next
time the address space is dispatched. IKJL4TOO does the following:
•
•
•

•

•
•

If TMP is in control, skips to POST.
Issues STATUS STOP for TCB = (lWAIT JOWAIT dispatchability bits).
Issues QTIP 24, which sets TSBCANC = 1 and removes OWAIT for other
address spaces TPUTing to this user.
POST cancels the ECB in the CSCB (IKJL4TOO branch enters POST with
completion code 622). The initiator (lEFSD263) waits for the ECB while
TMP is in control.
If TMP is not in control, issues STATUS START for the logon scheduler and
monitor tasks.
Exits.

Initiator (IEFSD263):

•
•

Waits for the CANCEL ECB and ATTACH ECB of the TMP task.
When the CANCEL ECB is posted, issues SVC 34 to abnormally terminate
the user.

SVC 34:

•

A -36

Issues CALLRTM, which- sets the resume PSW of the TMP task to point to
an SVC D instruction and forces the TMP task to be dispatchable.

MVS Diagnostic Techniques

S;yC -D (RTM2):

•

Oversees the termination of the TMp,task and all daughter tasks.

•

When the TMP task terminates, its attach ECB is posted, giving the initiator
control again.

Initiator:
Processing continues the same as for normal logoff except:
•

IKJEFLK, the POST-TMP exit module, issues QTIP 24.

•

IKJEFLC issues the "session cancelled" message before the logon scheduler
XCTLs to the STC termination.

•

If the line drops, IEDAY8, the TIOC resource manager, does not force the
remaining messages out.

TMP and Command Processor Interface
The following is a description of the TMP and command processor flow.
1. The TMP is attached by the initiator as a result of a logon command from a
terminal user or the execution of a batch job. Logon initialization establishes
the STAE environment to handle abends and the STAX exit to handle
attention interrupts.
2.

The TMP mainline routine receives control and determines which buffer to
obtain. This can be either:
a. The logon buffer (from PART = on the EXEC statement of the logon
procedure)
b. The command buffer, as a result of a PUTGET
c.

The buffer obtained by the attention prolog

d. The buffer obtained by the STAI exit
3.

If the current input is the command buffer, the TMP must check for five

special cases as follows:
a.

PUTGET is responsible for checking for a '?' in the first buffer position
in response to a mode message. When one is detected PUTGET
immediately issues the next available second-level message. This TMP
should never receive a '1' in a buffer, but if the user enters a '~' (blank ?).
PUTGET passes the buffer through to the TMP.

b. A null line.
c.

TEST command without operands.

d. TIME command.
Appendix A. Process Flows

A-37

e.

If scan determines that the data in the buffer is not one of these special

cases and that the data begins with an alphabetic character and is less
than eight bytes, the TMP issues an ATTACH for the command name.
Prior to ATTACH processing a search is conducted (through MLPA,
LPA, joblib, LNKLSTxx, respectively) to assure a successful ATTACH.
If the ATTACH is not successful, the TMP assumes a CLIST and
attaches the EXEC CP to search the user's command procedure library.
If the TMP does not locate either a command or a command procedure
whose name is the same as that fQund in the input buffer, a
'COMMAND NOT FOUND' Inessage is issued to the terminal.
4. If the command processor was attached, the TMP waits for an ECB list
containing the following ECBs:
a.

STAI ECB: The TMP's STAI exit routine posts this when a command
processor abnormally terminates and does not recover with its own STAE
routine.

b. Attention exit ECB: The TMP's attention exit routine posts this when it
gains control. It gains control when the user enters an attention
interrupt and the TMP exit is the current level exit. For more details, see
the discussion of "TSO attention processing" later in this chapter.
c.

STOP/MODIFY ECB: This ECB is posted if a stop userid is requested by
the system operator.

d. Command processor ECB: This is the ECB specified in the attach of the
command processor. It is posted when the processor terminates.
5.

If the command processor ECB is posted, the TMP repeats step 2 to

determine what action to take.
6. If the attention exit or STAI ECB is posted, the TMP does one of the
following:
a.

If a '1>1' was entered in response to the mode message, the TMP sends
second level messages to the terminal.

b. If a null line was entered, TMP returns control to the command
processor. If an attention interrupt occurred, the TMP continues normal
processing. If an abend occurred, the TMP takes a dump.
c.

If TEST was entered without operands, the TMP links to TEST and

places the interrupted command processor under test control. When
TEST processing is ended, the TMP detaches the current command and
prompts the user with a 'READY' to enter a new command.
d. If the TIME command was entered, the TMP displays the current time
and prompts the user for a new command. In this case, the user can
exercise any of the preceding options or enter a new command.
e.

A-38

MVS Diagnostic Techniques

If the user enters a new command or exercises one of the preceding
options, the TMP detaches the current command and issues a PUTGEt
requesting new input.

The following common control blocks are used for communication among the
TMP, connnand processors, and service routines (PUTGET, PARSE, etc.):

lKITMPWA (TMP Work AretJ)
Created by:
Length:

IKJEFT01
1076 bytes

I WORt~R I
TMPWA

o
TPL MAPPING

3C

Pointed to by:

TMPWAPTR,WORKAPTR

14C

,.CPPL

Function: Provides communication among
TMP modules. Contains register save
areas, parameter lists for TEST and TMP,
ABEND exit routines, and mappings of
macros commonly used by TMP modules.

158

168

,

ECT

• PSCB

170
• UPT

lKICPPL (Commtlnd Processor Parameter List)
Created by:

IKJEFT01

2E4
2E8
2EC
2FO

Length:

16 Bytes

Pointed to by:

Register 1

Function: Provides parameters for the
command processor.

2F4

~

UPT

, PSCB

~

ECT

334
(ECT)
338

33C

lXIECT (Environment Control Table)

340

Created by:

348

IKJEFTOI

(CPPL), CBUF

~ IOWA

I. SMSG
PRIMARY
COMMAND
SUBCOMMAND

350

Length:

40 bytes

Pointed to by:

TPL,CPPL

Function: Provides communication among
the TMP, CP, and service routines.
Contains current command/subcommand
names, pointers to work areas and
second-level message chains, and return
codes.

Appendix A. Process. Flows

A -39

lKJPSCB (Protected Step Control Block)
Created by:

IKJEFLA

Length:

72 bytes

Pointed to by:

LWA, CPPL

0

User to

8

30

Function: Contains information from
UADS, control bits, and accounting
data for the user ID. (This accounting
data is controlled by the installation
via the ACCOUNT command.)

PSCB

34

t

RLGa

,

UPT

lKJRLGB (Re-Logon Buffer)
RLGB

Created by:

IKJEFLA

Length:

264 bytes

Pointed to by:

PSCB

X'100'1-.------------I
_ ECT

Function: Contains the LOGON/LOGOFF
command entered at the terminal at
the end of the session.
UPT

lKJUPT (User Profile Table)
Created by:

IKJEFLA

Length:

24 bytes

Pointed to by:

PSCB,CPPL

Function: Contains information
stored in VADS that is used by
LOGON/LOGOFF, the TMP,
and the command processors.
(This information is all
controlled by the installation
via the PROFILE command.)

A -40

MVS Diagnostic Techniques

C
User
Environmental
Switches

Line
Line
Delete' Delete
Char
Char

10
~

18

DSNAME
Prefix

I

TSO Command Processor Recovery
The following describes the TSO command processors. Figure A-12 summarizes
their recovery activity.

ACCOUNT
The STAE exit routine for ACCOUNT flushes the input stack and posts the
ACCOUNT ECB before returning to continue abend processing. ACCOUNT
attaches the HELP command processor, specifying for a STAI exit routine the
same name as the STAE exit routine.
EDIT

The ESTAE exit routine for EDIT flushes the input stack, stops automatic line
prompting, and frees any acquired storage still remaining. The EDIT work area,
mapped by IKJEBECA, can be located in a dump to obtain certain data on the
EDIT session. The pointer to the communication area is passed between routines
in register O. By convention, most routines keep the pointer in register 9 during
execution. A description of IKJEBECA can be found in the data areas
microfiche (Data Areas).

LOGON
The ESTAE exit routine for LOGON dequeues from the userid, closes the UADS
data set, and detaches IKJEFLC. The LOGON work area, mapped by
IKJEFLWA, can be located in the dump (field ASXBLWA in the ASXB) to
obtain certain information on the session. A description of IKJEFLWA can be
found in the data areas microfiche.
LOGON also has an EST AI exit routine, which dequeues from the userid, closes
the UADS data set, cancels the attention exit, and frees subpools 1 and 78.

OPERATOR
The STAE exit routine for OPERATOR stops all active monitor function if the
abend is caused by a DETACH with STAB. OPERATOR also has a STAI exit
routine that is the same name as the ST AE exit routine.
The SVC 100 parameter list, mapped by IKJEFFIB and passed to the
OPERATOR command processor, can be located in the dump and certain data
about the session can be obtained. A description of IKJEFFIB can be found in
the data areas microfiche.

OUTPUT
Before returning to continue abendprocessing, the ESTAE exit routine for
OUTPUT closes any data sets that are being processed. The OUTPUT work
area, mapped by IKJOCMTB, can be located in a dump (while OUTPUT is in
control) and certain data about the session can be obtained.
OUTPUT attaches the HELP command processor specifying a STAI exit routine.
The STAI exit routine simply returns to continue abend processing.

Appendix A. Process Flows

A -41

SUBMIT
The SUBMIT command processor iUns under the STAI environment established
by SVC 100. This STAI routine closes the INTRDR data set before it returns to
continue abend processing. The SVC 100 parameter list, mapped by IKJEFFIB
and passed to the SUBMIT command processor, can be located in the dump and
certain data on the session can be obtained. A description of IKJEFFIB can be
found in the data areas microfiche.
Command
Processor

STAE
ESTAE

ACCOUNT

STAE

STAll
ESTAI

RETRY

SDUMP

LOGREC

STAI
EDIT

ESTAE

X

LOGON

ESTAE

X
ESTAI

OPERATOR

STAE
STAI

OUTPUT

ESTAE

Messages
IKJ56554I
IKJ565541
See Note 1
110564521
IKJ564511
IKJ564521
IKJ564061

X
X

IKJ550041
IKJ55004I

X
X
See Note 2

See Note 3

IKJ56318I

STAI
SUBMIT

STAI

IKJ56294I

Notes:

If

1.

Abend codes B37, D37, and E37 point to IKJ52427I, IKJ52428I; the others point to IKJ52422I.
the data set is modified, abend codes point to IKJ52555I.

2.

SDUMP is issuedfor all abends exceptfor DETACH with STAE, codes 437,913, and 422.

3.

LOGREC is written to except for DETACH with STAE.

4.

An effective trapping and problem solving techniquefor TSO command processors is to stop the error
processing in the appropriate error recovery routine.

Figure A-12.

Summary of Command Processor Recovery Activity

TSO Terminal 1/0 Overview
Terminal I/O flow is divided into two parts, input flow and output flow. This
overview highlights each at the SVC level.
TS/TCAM uses the services of three SVCs to communicate between the user's
address space and the TCAM address space:

A-42

1.

TGET/TPUT (SVC93): The TMP and command processors issue this SVC
to move data form the user's buffer to an interface buffer in CSA (TIOC
buffer).

2.

QTIP (SVC 101): This SVC is a set of multipurpose routines that perform
functions for both the user address space and the TCAM address space. For
example, QTIP is used by TCAM to move data from a TCAM buffer to an
interface (TIOC) buffer and is also used by TGET jTPUT to move data from
a user's buffer to a TIOC buffer.

3.

STCC (SVC 94): This SVC is a set of routines used to update TCAM
control blocks from the user! s address space. For example, the user can use

MVS Diagnostic Techniques

the terminal command to change a terminal characteristic. This is
communicated to TCAM via SVC 94.
TS/TCAM data flow also requires a logical connection between a terminal, a line,
and an address space. This is accomplished as follows:
.• The terminal macro in the user's MCP establishes the connection between a
terminal name and a destination (destination QCB).
•

At TCAM initialization, OPEN establishes the connection between the
destination and a physical terminal (a line cQntrol block is connected to the
terminal name table via an index into the table).

•

Logon processing establishes the connection between the destination QCB and
the user's address space (the destination QCB contains the ASID of the user
and the user's terminal status block (TSB) contains an index to the TCAM
terminal name table). Also, a user's TSB and ASCBpoint to each other.
The station's control block contains the address of the TSINPUT QCB.

Terminal I/O flow also .requires the use of two special TCAM subtasks:
TSINPUT and TSOUTPUT. TSOUTPUT acts as the router for all messages
coming from time sharing users. TSOUTPUT is responsible for editing output
messages as it moves the data from the time sharing interface buffers (TIOC
buffers) in CSA to the TCAM buffers in the TCAM address space. Once
TSOUTPUT has moved data to the TCAM buffer~, the buffer is routed to the
output side of the message handler and then written to the terminal.
TSOUTPUT also runs as a subroutine of TCAM. TSOUTPUT is the first
subroutine in control of the disk I/O QCB in a TCAM system that supports time
sharing.
Terminal Output Flow

Assume thata user has logged on, the TMP has been initialized, and a PUTGET
has been issued by the TMP to put out a 'READY' message and request input
from the terminal user. The following now occurs:
1. The TMP invokes the services of the PUTQET service routine, which issues a
TPUT and then a TGET (both SVC 93s). TPUT performs the following
basic functions:
a.

Obtains a TIOC buffer from the pool of free buffers. If a buffer is not
available or the user has passed the· output buffer limit (OWAITHI
parameter in IKJPRMOO), the user is placed in an output wait (the
appropriate flag is set in the TSB).

b. If a buffer is available, th~ 'READY' message is moved from the user's
buffer to the TIOC buffer.
c.

The user's terminal status block is placed on TCAM's asynchronous
ready queue. (A special element at TSB + X'40' is used.)

d. An XMPOST is done to alert TCAM.
e.

Control is returned to PUTGET.

Appendix A. Process F16ws

A-43

2.

When the TCAM address space is dispatched, and the MCP TCB regains
control, TCAM searches its asynchronous ready queue and discovers the
user's TSB. However, because this is a TS/TCAM system, TSOUTPUT
receives control instead of the disk I/O routine. TSOUTPUT performs the
following functions:
a.

Builds TCAM buffers from basic TCAM buffer units.

b.

Uses QTIP services to move the TIOC buffer from the TSB header queue
(queue of complete output messages) to the TSB output trailer queue
(queue of TIOC buffers being moved).

c.

Uses special TIOC edit routines (not QTIP) to move and edit data from
the TIOC buffer to the TCAM buffer.

d.

Once the data has been moved into the TCAM buffers, the TCAM
buffers are routed to the output side of the message handler and are then
written to the terminal. After the message is successfully written, the
TIOC buffers are freed via a subsequent call to TSOUTPUT.

Terminal Input Flow
The following process can run in parallel with step 2 in the preceding section,
"Terminal Output Flow." It starts when control is returned to PUT GET as
described at the end of step 1 in that section.
1.

A -44

PUTGET issues a TGET to obtain input. TGET (SVC 93) performs the
following functions:
a.

Checks to determine if there is an input buffer on the user's terminal
status input queue. TCAM normally allows users of remote terminals to
enter input while the current input is being processed. Therefore, it is
possible that input could be 'stacked' and an input buffer found on the
TSB input queue. However, TCAM does not allow local devices to
'stack' input. In this case, assume a local device and no buffer on the
TSB input queue.

b.

Therefore, the TGET notifies SRM that an input WAIT has been entered
and sets the appropriate flag in the TSB (lWAIT condition).

c.

SRM eventually performs a swap-out on the user.

2.

The user now enters a new command at the display station and hits
'ENTER'. TCAM handles the interrupt, associates it via the LCB to a
terminal name table index, terminal table entry, and destination QCB.

3.

The TCAM buffer is routed to the input side of the appropriate message
handler (determined from the DCB for the line). The message handler
normally translates the data from line code to EBCDIC. The message
handler must locate the destination QCB of the terminal that issued the
message and also check that the terminal is logged on to time sharing. If it is
logged on, the message handler routes the buffer to TSINPUT as the common
input destination for all time sharing messages.

MVS Diagnostic Techniques

4.

TSINPUT performs the following functions:
a.

From the ASID value in the terminal's destination QCB, TSINPUT
determines which address space should receive a particular message.

b. TSINPUT obtains a TIOC buffer from the free buffer pool. If no TIOC
buffers are available, the TCAM buffer is chained from a special queue in
the TSINPUT QCB until TIOC buffers are made available. In this case,
the time sharing system is placed in an LWAIT (out of TIOC buffers).
c.

If a TIOC buffer is available, TSINPUT uses the services of QTIP to
move data from the TCAM buffer to the TIOC buffer. Most line control
characters and all 3270 buffer control characters are edited out of the
message during this move.

d.

SRM is notified that the user is no longer in an input wait and may be
swapped in.

e.

The TCAM buffer is routed to the buffer disposition routine for final
processing.

5.

Once the TCAM buffer has been freed and final cleanup has been performed
on the line, TCAM searches for additional work on the work-to-do queues.
If there is none, TCAM enters a wait.

6.

Once SRM has swapped-in the user, TGET regains control. Using QTIP,
TGET moves the data from the TIOC buffer to the user's buffer.

TSO/TIOC Terminal 1/0 Diagnostic Techniques
For terminal hangs or interlocks involving TSO terminal I/O, a good place to
start is at the TSB and TIOCRPT. The TSBs are physically contiguous and
adjacent to the TIOCRPT (all in CSA), as shown below:

TCX (TCAM CVT extension)

+24

TIOCRPT (reference pointer table)

TSB

TIOCRPT is described in the Debugging Handbook. TSB is described in Data
Areas (microfiche). TIOC is described in OS/VS TeAM Level 10 Logic.
TSBOWIP and TSBWOWIP are used to serialize TPUTs to a user. TSBOWIP is
set at the start of a TPUT SVC, while that SVC holds the local and CMS locks.

Appendix A. Process Flows

A -45

If another TPUT is issued before OWIP is reset, then WOWIP is set and the
issuer of the second TPUT is put in OWAlT.
The task that has "seized the TSB" (that is, set OWIP) can be detennj.ned by
checking TSBCTCB. (TSBTJIP and TSBTJOW serve approximately the same
function for cross-memory TPUTs.)

TSO Attention Processing
The following section summarizes the process of TSO attentions. The numbers in
parentheses correlate to the numbers in Figure A-I3.

TCAM Channel End Appendage (1)
•

Ensures TCAM is active.

•

Finds the element associated with this terminal.

•

Places the element on the asynchronous queue.

•

TCAM dispatcher merges the asynchronous queue to the ready queue and
give control to the message handler.

•

TeAM recognizes the following forms· of terminal attention interrupts:
I/O attention interrupt for a 2741, which is checked in the line end
appendage.
Two separate interrupts for the 3270; (1) a keyboard-invoked I/O
attention interrupt, followed by (2) an I/O complete interrupt for the read
issued by TCAM in response to the first interrupt.
A user character string for a simulated attention, which is checked by the
SIMATTN routine.

Simulated Attention (2):
The message control program (MCP) reads input from the terminal the same as it
does for normal operation. It then passes the message to the message handler.

Message Handler (MH) (3):
•

Checks for the following conditions and calls TIOC if any exist:
Terminal input (character string)
PAl function key
Terminal output lines

TIOC Attention Handler (4):
•
•
•

e
A -46

Ensures TSO is active.
Gets the user's TSB.
Checks if the attention was caused by a deleted line.
Invokes QTIP (TIOC/TSO interface).

MVS Diagnostic Techniques

Hardware Attention

Simulated Attention

(3)

(1)

-

TeAM Channel
End Appendage

Message
Handler

(2)

--

Message
Control
Program (MCP)

r

(4)

TIOC
Attention
Handler

/

/
/

/

/

r-.L--(
Time

I

Sharing

(5)

QTlP
Attention
Handler

/

t- - (6)-

RCT

L~~~J

-

/

r- L -,
User Issues
IL ___
STAX
I
-1

(7)

RCT
Attention
Scheduler

(9)

RCT
Attention
Exit
~

If

(8)

Figure

Selected
UserSTAX
Exit

A-13. TSO Attention Flow

QTIP Attention Handler (5):
•

Checks if the user has issued any STAX macros.

•

Ensures the number of unprocessed attentions does not exceed the number of
active STAXs (causes '!I'=TOO MANY ATTENTIONS or
'I' = ATTENTION ACCEPTED to be printed at the terminal).

•

Posts the RCT to schedule the user's attention exit.

•

Purges input and output message queues to/from user except ASID type
messages.

RCT (Region Task Control) (6):
•

Waits for:
Termination
QUIESCE/RESTORE
Attention

Appendix A. Process Flows

A-47

RCT Attention Scheduler (7):

•

Cancels previously-scheduled attentions that have not been executed.

•

Determines the current attention level requested.

•

Disables any affected tasks.

•

If OBUF and/or IBUF was specified on the STAX macro, issues TPUT
and/or TGET.

User STAX Exit (8):

•

User defined.

RCT Attention Exit (9):

•
•
•

Enables any affected tasks.
Checks for another attention pending.
RCT enters wait.

TSO APAR Documentation

TSO APAR documentation should include:
•

Terminal input and output.

•

SYSUDUMP or stand-alone dump, as appropriate.

•

Information about how the system differs from PID release in the TSO area:
PTF list.
Information about non-IBM commands that appear in terminal output.
Description of any TMP modifications.
Description of applicable installation exits (LOGON, SUBMIT, etc.).

•

A -48

Listing of the logon procedure, with a list of membernames in STEPLIBs, if
any.

MVS Diagnostic Techniques

Appendix B. Stand-Alone Dump Analysis
This appendix contains a procedure that has been used successfully in stand-alone
dump analysis. It is part of the course material in Field Engineering classes that
teachMVS problem determination. This procedure does not attempt to cover all
situations but it can be used as a guide through major status areas until you
become thoroughly familiar with the system.

Overview
Stand-alone dumps are generally taken by the operator when:
•
•
•

The system has stopped in a solid wait state with a wait state code.
There appears to be a system loop.
The system is not running or is running slowly.

Usually the 'Title From Dump' reflects what the operator thought happened.
Before becoming too involved in the problem itself, it is a good practice to get
some feel for the status of the system at the time the dump was taken. Some
valuable system status indicators can be obtained from the formatted section of
the dump. Indicators can be obtained from the formatted portion of the dump
under "System Summary" (produced by the SUMMARY control statement) and
CSD, PSA, LCCA, and PCCA (produced by the CPUDATA control statement).
Although it is seldom that anyone indicator definitely points out the problem,
when -all indicators are noted and analyzed. a pattern might emerge that points
the problem solver to the proper area for further investigation.
The enabled wait generally occurs as a result of the lack of some critical system
resource. If the PRINT statement of PRDMP is used, PRDMP identifies the
current task. If the current task is the wait task, the message "Current Task =
Wait Task" might appear.
If it appears you have an enabled wait condition, read the chapter on "Waits" in
Section 4 of this book before proceeding with your analysis.

The system can appear or actually prove to be bottlenecked because the operator
cannot communicate with MVS. This is the sign of a problem almost anywhere
in MVS, but an error in the communication task or its associated processing
might be the direct cause. The communication task is identified by a X'FD' in
the TCBTID field (TCB + X'EE'). By inspecting the RB structUre associated with
this task, you can determine the current status. It is not unusual to find one RB
with a resume PSW address in the LPA and an RB wait count of one. If more

Appendix B. Stand-Alone Dump Analysis

B-1

than one RB is chained from the TCB and you could not enter commands,
analyze the RB structure as this is not a normal condition.
Remember that communications task processing is very dependent on the rest of
the operating system. Probably some external service or process has caused the
communications task to back-up, and this possibility should be investigated.
For the system to continue execution, the major components must be operational.
If any critical system components such as master scheduler, ASM, JES2, and
TCAM for TSO, terminate abnormally and fail to recover, the system cannot
continue normal operation. Usually this can be determined from the records in
SYSl.LOGREC. However, check the TCB summary in the formatted section for
completion codes.
The presence of a TCB completion code does not positively identify the associated
task as being inoperative. It is possible that the completion code is residual and
the task has recovered. The presence of a completion code makes the task
suspect, however, and should be investigated.
Unless the operator STORE STATUS command was issued before taking the
dtimp or the "Title from Dump" reflects a WSC (wait state code), it can be
difficult to determine if a WSC exists and what it is if it does.
If however, the WSC PSW is dispatched by NIP during IPL, it is generally
located in one of two places:
•

In the MCH new PSW if a program check occurred prior to RTM
initialization.

•

In the nucleus vector table (NVT + X'EO') in the case of a system-detected
error during the NIP process.

The other WSCs (they are few in number) issued by the system are dispatched by
the master scheduler communications task and ASM. The current address space
should identify who loaded the WSC PSW; WSC PSWs are issued when the
system determines that it cannot continue. They are usually preceded by other
error indicators that should be investigated along with theWSC.
Note: A valid WSC looks like: X'OOOAOOOO OOnnnxxx'
where:

nnn is the reason code
xxx is the wait state code.

A disabled wait normally has a wait state code associated with it. If so, "he
messages and codes should contain a problem description.
If there is no wait state code, the trace table should indicate the last sequence of
events leading to the wait state condition. Probably a bad PSW (wait bit on) has
been loaded.
If no valid WSC exists and if the PSW reflects the wait bit, is disabled, and the
STORE STATUS registers are not equal to zero, suspect: a user or Field
Engineering trap or a SLIP trap (with a wait state code of X'OlB~), a bad branch,
or system damage. Examine the trace table and attempt to define the events that
led lip to the wait condition. Was the last entry an SRB dispatch or an SVC I/O

B-2

MVS Diagnostic Techniques

interrupt? U sing the PSW address, determine the entry point of the routine if
possible.
The PSA is a system area whose status indicators are dynamically changing. The
status indicators reflect the condition of the system the instant the dump was
taken. Taken out of context, they can be misleading.
Therefore, find out if the operator entered a STORE STATUS command and
keep in mind that the status could have been stored any time and not necessarily
just before the dump~
Note: If you IPL the stand-alone dump program from the system control (SC)
frame on the 3033, it is not necessary to perform the STORE STATUS operation.
Status is automatically stored when stand-alone dump is invoked from the SC
frame.
Note: The best evidence that the operator issued STORE STATUS is the content
of 'Current Registers and PSW at Time of Dump.' This is because the stored
status is put in the PSA + X'IOO' and the registers are put at PSA + X'160- IFF',
and SADMPprogram reads this area as the current PSW and registers and writes
them to the dump data set. On a UP, the formatted current data will be the same
as in the PSA. On an MP system, however, the SADMP program issues SIGP to
another processor to store status. The STORE STATUS command always stores
in the unprefixed PSA at location zero. This means that the unprefixed PSA will
contain the registers and PSW from another processor. If the SADMP program
did not save the STORE STATUS data before issuing the SIGPinstruction to the
other processor, the data from the operator's STORE STATUS command would
be overlaid and the contents lost.

Also note that on an MP system there are three PSAs and the AMDPRDMP
program formats all of them for you. The unprefixed PSA is used only during
NIP (and SADMP). Always be sure you are looking at the right PSA when you
are analyzing the PSA contents.
If the PSW + X'OI' = xE or x2, the PSW is a wait PSW. If PSW + X'OO' =
X'04', the system was disabled. If PSW + X'OO' = X'07', the system was enabled.
Determine whether the PSW contains a WSC or an address. Then determine
what key the PSW reflects. PSW + X'OI' = X'xC' or X'xE' where the x = key,
as follows:

o = supervisor
I =
5 =
6 =
7 =
8 =
9-F

scheduler/JES2/JES3
lOS, data management, actual block processor, O/C/EOV
TCAM/VTAM
IMS
virtual problem program
= V = R problem program

In a SADMP on a UP, locations X'OO' through X'18' are always overlaid by the
IPL CCWs and PSW from the IPL of SADMP itself. These locations never
contain valid data.

Appendix B. Stand-Alone Dump Analysis

B-3

Loops can be either disabled or enabled. The best way of determining which has
occurred is by examining the PSW, the loop recording option table, and the trace
table.
Recorded addresses that fall within the SRM code are usually not indicative of a
loop because this code is entered periodically as a result of a timer interrupt. This
signifies, however, that the system does enable for interrupts and you can treat the
error as an enabled loop.
Note: If the only addresses the operator furnished or the loop recording option
recorded are in the timer or SRM .code, check that it is not really an enabled wait
condition.

The typical disabled loop is quite short, whereas the enabled loop covers a wide
range of addresses. Be careful that the recorded addresses that may reflect a short
loop are not a 'loop within a loop.' Scan the trace table and try to determine if a
pattern of activity exists. Look for SIOs to the same device, SVCs from the same
address, program checks occurring frequently for other than page faults, or any
repetitive activity. If no pattern exists, try to correlate the last trace entry with
what you already know about the loop (for example, I/O interrupts, a loop in an
lOS or SRB dispatch, and a loop in the nucleus in some routine which is entered
via an SRB).
The enabled loop usually reflects a wide range of addresses and can even span
address spaces between a user and the system address spaces. An examination of
the trace table usually shows some pattern of activity that is recognizable as a
loop.
Be especially suspicious of a SVC OD or SVC OA for the same size area, SVC 33,
SVC 4C, and SIOs to the same device with the same IOSB address in register 1.
Trace table entries with SVC OD and/or SVC 33 in a stand~alone dump usually
mean that some task is abending and the system is attempting to recover and
purge the task from the system.
If any address within the loop points to the lock manager (module IEAVELK),
the problem is probably caused by someone requesting an unavailable spin lock
On a UP, this is an invalid condition and always signifies an overlaid lockword.
On an MP system, this signifies that another processor is holding the lock and
failing to release it. There is a strong possibility that this indicates an overlaid
lockword also. If not, the problem is on another processor. In either case,
register 11 can point to the lockword requested and register 14 is the address of
the requestor. Check the value in the lockword. Valid values are a full word of
zeros or three bytes of zeros and the CPUID in the fourth byte. Any other bit
configuration causes the system to spin in a disabled loop and signifies an overlaid
lockword. Register 12 always contains the bit mask to check the locks-held-table
in the PSA.
If the lockword is overlaid, you must identify who overlaid it. It is possible that
the lockword was overlaid in conjunction with some other problem.

This proc~dure is designed to aid the problem solver and to supplement the
diagnostic procedures he has developed over the years. Its main purpose is to call
attention to the new serviceability features within MVS and provide an index into

B-4

MVS Diagnostic Techniques

the correct component analysis procedures, in Section 5 of this manual. Once
again, the· component analysis procedures are there as hints and helps rather than
to provide a structured approach to all problems.
start

)

"">-.:..:.N=0--i~ Note 11

"7-Y_e_s--i~ Note 21
Current FRR stack
+ X' 28' " X' 00 '

",>-_N_0--l~ Note 18
Yes
LCCA+X'210' - 80

Yes
Any Bit On At
PSA+X'2F8'

>-Y_e_s---'l~ Note 14
PSA+X'2F8'
- 0000xxx1

Note 13

Note 15

Yes

>------'1... Note 20

Note 25

Figure B-1. Stand-alone Dump Analysis Flowchart

Appendix B. Stand-Alone Dump Analysis

B-5

Analysis Procedure
The following explanations correlate to the "Notes" in Figure B-1.
Note 0 - Dummy Task?

The dummy wait has been dispatched on the processor if the following fields
contain the values shown:
STORE STATUS PSW = 070EOOOO 00000000
STORE STATUS GPRs = 0
PSATNEW = PSATOLD = 0
PSAANEW points to ASID 0
PSAAOLD points to ASID I
PSASUPI = 04 (dispatcher)
PSAMODE = 08 (wait)
Note 1 - System Enabled/or IIO?

Is bit 6 on in the current PSW?
Is control register 2 correctly loaded?
The current status of the system is in the PSA if a STORE STATUS command
was entered before the dump was taken.
Note 2 - Dispatchahle Work to be Done?

I.

One of the first places to check for system dispatchability is the common
system data area (CSD). For example, CSD + X'C' = X'40' indicates that
most of the system is non-dispatchable. This bit can be set by SDUMP. Is
any address space abending and in the process of taking an SDUMP? Check
the TCB summary for completion codes.

2.

Dispatchable work within an address space is indicated by:
ASCB + X'80' = X'FFFFFFFF' or X'4FFFFFFF'
ASCB + X'80' = X'OOOOOOOO' (indicates the LOCAL lock is available)
ASCB + X'DO' = SRB on the address space service management queue
(ASCBLSMQ)
ASCB + X'D4' = SRB on the address space service priority list (ASCBLSPL)
ASCB + X'D8' " 0 indicates ready TCBs not requiring the LOCAL lock.
ASCB + X'DC' " 0 indicates ready TCBs requiring the LOCAL lock.

B-6

3.

The JES2/JES3 address space can contain work that should be passed to a
waiting initiator or interface that has an address space for SYSIN or
SYSOUT data.

4.

Dispatchable work at the system level is indicated by SRBs queued to the
global service manager queue (GSMQ) and the global service priority list
(GSPL).

MVS Diagnostic Techniques

For (1), you must determine who set the bit on, who should have reset it and why
the bit was set. It might be necessary to trap on the setting of this bit.
For (2), a X'7FFFFFFF' indicates that the holder of the local lock is suspended
(for example, a page fault or CMS lock request). A CPUID value (such as
X'OOOOOO40') indicates that the unit of work holding the local lock is currently
running on that processor. Any nonzero value indicates that the lock is held and
that" TCBs requiring the LOCAL lock cannot be dispatched.
For (3), check the JES control blocks more closely.
For (4), determine why the dispatcher is not functioning. See the "Dispatcher"
chapter in Section 5 of this manual.
Note 3 - Enqueue Lockout'!

As in other systems, an exclusive enqueue prevents other tasks from using the
same resource. However, in MVS, locks are now used frequently instead of an
enqueue.
1.

Use the QCB format function (QCBTRACE, Q, or GRSTRACE option of
print dump) to print the QCBs and check for exclusive enqueues.

2.

CVT.+ X'lBO' points to the GVT.
GVT + X' 10' points to the GVTX.
GVTX + X'A4' points to the global queue hash table.
GVTX + X'AS' points to the local queue hash table.
GVTX + X'AC' points to the SYSID/ASID hash table.
ASCB + X' 110' points to the global QEL queue.
ASCB + X'114' points to the local QEL queue.
Note: The GVTX, the hash tables, and the QEL queues reside in the GRS
address space.

3.

Any QEL reflecting exclusive control prevents any other task from using that
resource. Any QEL reflecting shared status prevents any task requesting
exclusive control from using that resource.

4.

The Debugging Handbook defines some of the major and minor ENQ names.

Note 4 - Incomplete lID?

Label IECVSHDR in IEANUCOI points to a pool of cells used by lOS to build
the IOQ (I/O queue element). The IOQs are found in two places:
1.

An 10Q chained to the UCB-4 indicates an I/O operation is in progress or
has completed on that device. The flag bytes at UCB + 6 determine the
current state of the device. The device is available when the flag byte is zero.
No request for this device should be chained to the LCH during an enabled
wait.

2.

The 10Qs are chained to the logical channel queues (LCH) if the I/O
operation has been requested but not started.

Appendix B. Stand-Alone Dump Analysis

B-7

The LCH is pointed to by the CVT + X'8C'. The entry for each logical
channel is 20 bytes long. At X'OO' into each entry is a pointer to the first
IOQ queued for that logical channel. The presence of IOQs on any logical
channel is immediately suspect when examining an enabled wait state dump_
An empty queue (no requests) is indicated by a word of FFFFFFFF in the
LCH at X'OO'.
Note 5 -Is Any Task in a Page Wait?
Check the TCB RBs for a wait count not equal to zero.
RB+X'IC' = wait count
RB-8 " 40 (FLAG I)
TCBFLGS4 " '04'. This indicates a page-fault wait or a synchronous page fix
wait.
Note 6 - Explicit Wait in System Code?
Does the address in the PSW fall within the nucleus or LPA code? Compare the
address with a NUCMAP or LPA map.
Check the load list and CDEs for system modules that have been loaded into the
private area.
Note 7 - Real Storage Okay?
If a task remains in a page wait, it could indicate a shortage of page frames or a
real storage failure.
The control blocks that contain status about the use of real storage are:
1.

Page vector table (PVT)
PVT + X'04' = available frame count
PVT + X'24' = free PCB count
PVT+ X'754' = deferred for lack of free page frames

2.

Page frame table (PFT)
Shows use of each frame of real storage available for paging.

Note 8 -Is Auxiliary Storage Okay?
If tasks are in a page wait and real storage is not a problem, the trouble could be
within the auxiliary storage manager (ASM).
ASM status indicators are:

B-8

I.

ASMVT + X'28' = the number of paging I/O requests received

2.

ASMVT + X'2C'

3.

ASMVT + X'30' = the number of swap I/O requests received

MVS Diagnostic Techniques

= the number of paging I/O requests completed

4.

ASMVT + X'34' = the number of swap I/O requests completed

5. ASMVT+X'58' = the SRB address used to redrive work through ASM
6.

SRB + X' 1C' = the address of an 8-byte parameter list that contains the
addresses- of the first and last I/O requests to be redriven through ASM

7. 10RB + X'03' = indicates whether the I/O requests on the 10RB have been
passed to lOS.
If the number of I/O requests completed is equal to the number of I/O requests
received, ASM has no outstanding work. If I/O requests have been started but
not completed, determine what has happened to the I/O. If ASM's redrive SRB
parameter list is nonzero, the SRB has been scheduled. Determine what the
dispatcher has done with the SRB.

Note 9 -Is lOS Okay'!
If all 10RBs ~re idle (IORB + X'03', bit 0 is zero), then lOS has completely
processed all the I/O that ASM has started.

Note 10 -Interrupted TeB'!

The condition that caused the TCB holding the local lock or local lock and at
least one cross memory services lock to be suspended has been resolved. The save
area to be restored upon dispatching is the IHSA.
A TCB holding the local lock, or local lock and at least one cross memory
services lock has been interrupted by a higher priority task. The save area used
for redispatching is the IHSA. See the chapter "Dispatcher" in Section 5 or the
chapter "System Execution Modes and Status Saving" in Section 2 of this manual.
Note 11 - Not R TM'!

Without the detection of a failure by MVS, which would have caused entry into
RTM, check the following. If the trace table in the stand-alone dump reflects the
same task in most of its entries, this could be normal operation or the task could
be in a loop. Check the following for status information:
LCCA
PSA
PCCA
Trace table
TCB
RB/SVRB
If no failure information is found (the system appears to be running normally),
the problem might be that another task or address space should be running and is
unable to. Check the following for status information:

1.

Check each address space that is expected to be running to find out why it is
not running. The information about each address space and task within that
address space can be found in: ASCB, ASXB, TCB, and RB/SVRB.

Appendix B. Stand-Alone Dump Analysis

B-9

2.

Or, check the total system to find out why other work is not being run.
Check the status of the system resources:
ENQ lockout of data sets
I/O failures
RSM or ASM failure
Waits in system code for other system resources (such as buffers)

If you are checking other than the current task, the TCBs could be dispatchable,
but not yet dispatched. If the task is non-dispatchable (non-dispatchability bits
on in the TCB), this can indicate an error situation. Or the task could be simply
waiting (indicated by a wait count in the current RB). Check the dispatchability
flags in the following control blocks for status of this task or select another
address space or task and continue at Point A.
Status information can be found in: ASCB, ASXB, TCB, and RB/SVRB.

Note 12 - RTM2, Yes.
The most important place to find information about abend codes is Message
Library: System Codes.
The RTM2 work area address is stored by RTM2 in TCB + X~EO'. Every system
dump (SYSABEND/SYSMDUMP/SYSUDUMP) should have at least one TCB
with an RTM2WA address at TCB+X'EO'. The error indicators contained in the
RTM2WA are described in the Debugging Handbook.
If an ESTAE routine is in control when an error occurs, RTM builds an SDWA
(described in the Debugging Handbook) and places its address at the
RTM2WA+X'D4'.
Additional information about the failure may be found in the LOGREC buffer.
RTM2WA+X'38' points to RTCT; RTCT+X'20' points to the LOGREC buffer.
If recursion occurs during RTM processing, other RTM2WAs may exist. If other
work areas were obtained, the last one is pointed to by the TCB + X'EO'. The last
RTM2WA points to the previous work area (RTM2WA + X' 168, 16C, 170').
The RTM2WA is obtained from LSQA. It is therefore unique to each address
space. If you are looking at a stand-alone dump, be sure that the area you are
looking at belongs to the failing address space.
If the abending task is one of several abending tasks it is important to decide
which task to look at first. There could be several failures or one failure causing
all the others. Any failure in the system address spaces (JES2, master scheduler)
are important be~ause they might have caused the user address spaces to
.terminate.
For the system to continue execution, the major components must be operational.
If any of the critical system components (master scheduler, ASM, JES2, TCAM
for TSO, etc.) abend and fail to recover, the system cannot continue normal
operation. Usually this can be determined from the records in LOGREC.
However, check the TCB summary in the format section for completion codes.

B-IO

MVS Diagnostic Techniques

The presence of a TCBcompletion'code :does: not positively identify the associated
task asbeinginoperational. It ispossibie that the completion code is residual and
the task has 'recovered~ The _presence of a completion code makes the task _suspect
however" and should be investigated.
Simplify your choice of address ,spaces by using:
•
•
•

SYSl.LOGREC external and intenial entries
Console sheets
Trace table or GTF (check for SVC D or program check entries)

Once you have selected an address space' and TCB, continue at Point A. (Check
Section 5 for the component analysis of the involved component.)
In addition to the RTM2WA, status indicators related to the problem cab. be
found in:
•
•
•
•

Trace table
ESTAE control block (SCB)
RBjSVRB
TCB

Note 13 - Local Lock Only?

The current ASCB + X'SO' contains the CPU ID. The current TCB + X'FO' also
contains the CPU ID. The loop is within this task. Status is saved (if a STORE
STATUS was done) in:
•
•
•
•
•
•

PSA
LCCA
Current stack
Local SDWA (ASXB + X'6C') - if the task abended while holding the lock
Trace table
In-storage LOGREC buffer

Is. this task looping in the lock manager's code? Check the PSA + X'22S' and
LCCA + X'20C'. If the task is looping and this is an MP system, another
processor could be causing the loop by not freeing a spin lock that it is currently
holding. The failure to free or obtain a lock-can be caused by the lockword being
overlaid on either an MP or UP.
If all processors of an MP are looping in lock manager code, then the failure
could be in that code. If only one processor is in lock manager code, then the
failure is likely to be in the processor currently holding the lock.

Where is the task looping? Why doesn't it free the locks? Is RTM involved with
this task? If it is, continue at Point A.
See the chapters on "Locking" and "Effects of Multi-Processing on Problem
Analysis" in Section 2 of this manual.

Appendix B. Stand-Alone Dump Analysis

B-ll

Note 14 - Local Lock Plus Another Lock.

The current ASCB + X'80' contains the CPU ID. The current TCB + X'FU'
contains the CPU ID. The loop could be a spin loop waiting for the other
processor to release a global lock. In this case, determine why the lock has not
been released.
Status indicators can be found in the following areas (if a STORE STATUS was
done):
•

PSA

•

LCCA

•

Current stack

•

Local SDWA (ASXB + X'6C') - if the task abended while holding the local
lock and at least one cross memory services lock

•

Trace table

•

In-storage LOG REC buffer

See Note 13 for additional information. Also see the chapters "Locking" and
"Effects of Multiprocessing on Problem Analysis" in Section 2 of this manual.
Note 15 - Global Lock Held.

A global lock loop in an MP system could be normal. The spin loop continues
until the global lock is released by the other processor. Determine why the other
processor has not released the lock.
Error status indicators can be found in the following areas if a STORE STATUS
was done:
•
•
•
•

PSA (current PSW)
LCCA
Current stack
Global SDWA (if there was an abended failure while the global lock was
held)

The global SDWA for the super stacks is located at the respective super
stack + X'410'. For the normal stack, the global SDWA immediately follows the
RESTART super stack SDWA+X'3FO'.
Now continue at Point A in the procedure. See Note 13 for additional
information. Also see the chapters "Locking" and "Effects of Multiprocessing on
Problem Analysis" in Section 2 of this manual.

B-12

MVS Diagnostic Techniques

Note 16 - lOS lVotOkfJ.v.

Check the requests sent to lOS. from auxiliary storage manager (ASM). Control
blocks containing information are:
1.

PART (paging activity reference table) - One entry per page data set. Each
PART entry· contains a pointer to an IORB (I/O request block) at X'lC' and
a pointer to a· UCB at X'2C'.

2.

10RB contains the following I/O related data:
10RB + X' l' = number of IORBs for this page data set
IORB + X'3' = indicates whether 10RB is in use
10RB+ X'4' = pointer to next 10RB for this page data set
IORB+X'8' = pointer to the first PCCW
10RB + X'C' = pointer to the 10SB
IORB + X'2C' = pointer to the last CCW in the channel program.

Refer to the Component Analysis section for additional lOS status indicators.
Note 17 - SlIspended SRB or TeB With Lock Held.

An SRB can be suspended because of a page fault, a synchronous page fix, a
request for a cross memory services lock when it is being held by another address
space, or SMF suspension. The save area for the suspended SRB is the SSRB. If
interrupted by a page fault, the SSRB is pointed to by the corresponding
PCB+X'lC'.
For a general cross memory services lock request, the SSRB is on the requested
CMS lock suspend queue, which can be located in the system lock area. (See the
topic on locking to locate the system lock area.)
For an ENQ/DEQ cross memory services lock request, the SSRB is on the
CMSEQDQ lock suspend queue (CMSEDSQH).
A locked TCB can be suspended for the same reasons as an SRB. The save area
is the IHSA of the locally locked address space (described in the Debugging
Handbook). The IHSA is valid during a page fault if the corresponding
PCB + X'08' flag is on. The IHSA is vafid for a cross memory services (CMS)
lock suspension if the ASCB is on the CMS lock suspend queue (SQH) for that
cross memory service lock requested (either the general CMS, the CMSEQDQ, or
the CMSSMF).
Note 18 - Not RTM2.

The presence of a TCB completion code does not positively identify the associated
task as being inoperational. It is possible that the completion code is residual and
the task has recovered. The presence of a completion code makes the task suspect
however, and it should be investigated.
The save areas have been released. The status of the error has been written to
SYSl.LOGREC. Continue at Point A with other TCBs in the dump. Another
abending task is likely. If this is a stand-alone dump, it very likely has the needed

Appendix B. Stand-Alone Dump Analysis

B-13

LOGREC entry in the in-storage buffer. CVT+'23C' points to RTCT;
RTCT+ X'20' points to the LOGREC buffer.
Note 19 - Real Storage Not Okay.

If page waits seem to be caused by the lack of real frames, check their usage. The
PFT contains information about each frame currently being used. Important
items to check are:
Which ASID holds the most real storage?
What are the frames being used for?
Is it valid that they be held or is there a problem with the freeing of the frames?
Status information might be found in the PVT, PFT, and RSMHD and ASCB
(X'98') for the ASID that is holding all the frames.
See the "RSM" chapter in Section 5 of this manual" for more information about
RSM.
Note 20 - lOS Okay.

Either something was missed along the way or the failure might be in one of the
following areas:
•

The lOS interrupt handler has failed to schedule the SRB/IOSB t

SDWAREXN, SDWAMDAT, SDWAMVRS, SDWACID, and
SDWARRL.
VSAM CHECKPOINT (lDAOxxxx) or VSAM RESTART (IDAOxxxx) with one
of the following:
MACHINE CHECK
PROGRAM CHECK LOCATION=xxxxxx
RESTART KEY DEPRESSED
PAGING ERROR
ABEND Sxxx, Uxxxx, REGISTER 15=xxxxxxxx
Component: VSAM - Checkpoint/Restart (5752-SCIDE)
Issuing Module: IDACKRAI - EST AE
PLM: OS/VS2 Virtual Storage Access Method (VSAM) Logic

Explanation: An error has occurred during VSAM checkpoint or restart
processing. The ESTAE routine issues the SDUMP macro. The title on the
dump depends on the type of error and whether checkpoint or restart was in
control at the time of error. The areas dumped are SQA, LPA, and user's
region.

Appendix C. SVC DUMP Title Directory

e-81

.I..L'U...

~l'IkO-JV:7J ~LJt;~t;mOer £.1, l~ls))

to :SYL~-1l33-2

Operator- and Caller-Defined SVC Dump Titles
This topic provides diagnostic information for the modules that initiate SVC
dumps via the SDUMP macro but where the dump title is defined by the system
operator or the caller of SVC dump.
variable title - supplied by the system operator
Component: Master Scheduler Commands (5752-SCIB8)
Issuing Module: IEECB866 - Console Dump
PLM: OSjVS2 System Logic Library
Explanation: The system operator has issued the DUMP command and

specified the title of the SVC dump on the command.
Problem Determination: None.

variable title - supplied by the system operator
Component: JES2 (5752-SCIBH)
Issuing Module: HASPTERM or HASPRAS
PLM: JES2 Logic.
Explanation: The system operator has entered an SVC dump title in
response to the $HASP098 message. This title overrides the default dump
title. The areas dumped are PSA, NUC, RGN, TRT, SQA, CSA, LPA, and
SWA.
Problem Determination: For information on the error, refer to messages

$HASP098 and $HASP095 in JES2 Messages.
variable title - supplied by the caller
Component: Task Manager (5752-SCICL)
Issuing Module: lEAVECHO - CHAP Service Routine
PLM: OS j VS2 System Logic Library
Explanation: An error has been detected in the TCB dispatching queue for

the current address space by the TCB queue verification routine. The FRR
(IGC044RI) issues the SDUMP macro. The areas dumped are LSQA,
SQA, and TRT.
Problem Determination: A software record is written to SYSl.LOGREC.
The SDWAVRA contains the associated TCB-queue-verification output.

C-82

MVS Diagnostic Techniques

SVC Dumps Without Titles
This topic proyides diagnostic information for the modules that initiate SVC
dumps but where no titles are supplied on the SDUMP macro.
no title
Component: Catalog Controller 3 - CVOL Processor (5752-SCIDH)
Issuing Module: IGGOCLCB - ESTAE
PLM: OS/VS2 CVOL Processor Logic
Explanation: An abend has occurred during the processing of a GENERIC
LOCATE request for a CVOL. All storage resources are freed and the
CVOL processor SDUMP routine issues the SDUMP macro. The area
dumped is LP A.
no title
Component: lOS (5752-SCIC3)
Issuing Module: IGCOOO 1F
PLM: OS/VS2 I/O Supervisor Logic
Explanation: An error has occurred during IGCOOOIF (nonresident purge)
processing. The areas dumped are PSA, SQA, NUC, and TRT.
Problem Determination: A software record is written to SYS1.LOGREC.
The SDUMP buffer contains a copy of the purge work area and optionally:
- A copy of a UCB (if the IOSUCB lock is held)
- A copy of a LCH (if the IOSLCH lock is held)
- Copies of IOQEs on the LCH for which the lock is held.
The most likely cause of the error is an invalid IOSB address.
no title
Component: JES3 (5752-SCIBA)
Issuing Module: IATIIII (IATYIIW work area)
PLM: OS/VS2 MVS JES3 Logic
Explanation: An abend has occurred during interpreter/initiator (IATIIII)
processing. The EST AE routine established by lATIIII is given control to
examine the functioJ;l control table (PCT) active at the time of termination
to determine which function or DSP failed. The areas dumped are PSA,
RGN, LPA, TRT, and CSA.

Appendix C; SVC DUMP Title Directory

C-83

Problem Determination: A software record is written to SYS1.LOGREC.
Register 9 points to a work area containing formatted messages.
no title
Component: RTM (5752-SCICM)
Issuing Module: lEAVTRTE
PLM: OSjVS2 System Logic Library
Explanation: The SDUMP macro is issued by the RTM2 exit processor
(IEAVTRTE) as a result of an error during abnormal termination of a
subtask of the jobstep task. The jobstep task is terminated with a DOD
completion code. The current task is set non-dispatchable in order to wait
for the jobstep task to detach it. If another failure occurs, the address space
is terminated. The areas dumped are SQA, LSQA, LPA, TRT, CSA, and
SWA.
Problem Determination: The RTM2WAs addressed by the current TCB
contain the most pertinent information.
no title
Component: VTAM or ACFjVTAM (5752-SCI23)
Issuing Module: ISTZRMOI - FRR
PLM: VT AM - refer to the microfiche; for ACF jVTAM refer to
A CFj VTAM Logic
Explanation: An abend has o~curred duringVTAM processing while the
global UCB spin lock was held. The areas dumped are ALLPSA, CSA,
LSQA, SQA, TRT, LPA, NUC, and SWA.
Problem Determination: A software record is written to SYS1.LOGREC.
The SQA includes the UCB and the ICNCB or LDNCB control block.

C-84

MVS Diagnostic Techniques

TNL SN28-5095 (December 27, 1985) to SY28-1133-2

Module to SVC Dump Title Cross-Reference
This topic lists, in alphameric order, the MVS modules that issue the SDUMP
macro and provides the titles of the SVC dumps specified by the modules on the
SDUMP macro.
Issuing
Module

Dump
Title

AHLGTFI
AHLMCER
AHLREADR
AHLSBUF
AHLSETEV
AHLTMON
AHLWTASK
AHLWTO

AHL007I GTF TERMINATING ON ERROR CONDITION
ERROR IN MODULE AHLMCER
DUMP OF AHLREADR
DUMP OF GTF MODULE AHLSBLOK
ERROR IN AHLSETEV
GTF TERMINATING ON ERROR CONDITION
DUMP OF GTF MODULE AHLWTASK
DUMP BYJ(OF) MODULE xxxxxxxx

CSVVFCRE
CSVVFCRE
CSVVFGET

COMPON = PROGRAM-MANAGER ... CSVVFCES .. .
COMPON = PROGRAM-MANAGER ... CSVVFCFR .. .
VIRTUAL FETCH JPQ FAILURE
VIRTUAL FETCH LOCAL CONTROL BLOCK ...
VIRTUAL FETCH RETRY INHIBITED
VIRTUAL FETCH JPQ FAILURE
VIRTUAL FETCH LOCAL CONTROL BLOCK...
VIRTUAL FETCH RETRY INHIBITED

CSVVFIND

ERBMFDEA
ERBMFEEQ
ERBMFSDE

RMFDEA
COMPON=RMF-ENQ EVENT HANDLER ...
RMFSDE

HASPCKPT
HASPFSSM
HASPTERM
or
HASPRAS

DUMP OF JES2 DATA. ..
JES2 FSI ERROR ...
ABEND code AT hhhhhhhh (nnnnnn) + X'nnnn' ceHASPDUMP SUBSYS = ssss ...
title - supplied by the system operator

IATABNO
IATDMFR

IATSSRE
IATSSXM

IAT3702 dspname (ddd) ABENDEDJFAILED ...
ERROR IN IATSIDMO FOR SYSOUT DATA SET
IAT1801 ERROR IN IADMDKT - IATYISR POSSIBLY LOST
none
IAT4830 IATIISB MASTERTASK ABEND
IAT4831 IATIISB SUBTASK ABEND
JES3 LOCATE SUBTASK ABEND
IATSIJS JSESEXIT
JES3 SNA FRR IATSNDF
IATSNLS - ESTAE EXIT
IATSSCM READ-END FAILURE
SSICS ABEND 6FB
SSICS ESTAE-IATSSCM
COMPON = JES3 SUBSYS COMMUNIC. ..
COMPON = JES3 SUBSYS COMMUNIC ...

ICBRECRD
ICBVPROO

ICBRECRD RECORDING FAILED
ICB4251 ABEND IN PROCESS- MSVC TASK (nnnnnnnn)

IATIIII
IATIISB
IATLVLC
IATSIJS
IATSNDF
IATSNLS
IATSSCM

Appendix C. SVC DUMP Title Directory

C-85

December 27, 1985

ICHRSTOO
ICHSEC02

ICHRSTOO - RACF SVCS, ABEND CODE = xxx, ...
RACF INITIALIZATION FAILURE

ICTMCSOI
ICTMKGOO
ICTMKGOI
ICTMKMOI
ICTMKM04
ICTMSM07
ICTMSM08
ICTMSM09

ICTMCSOI, CRYPTOGRAPHY INITIALIZATION
ICTMKGOO, KEY GENERATOR PROGRAM
ICTMKGOI HANDLE SYSIN MODULE
ICTMKMOI, START CRYPTOGRAPHY COMMAND
ICTMKM04 - KEY MANAGER
ICTMSM07 - ICTMSM07 - CIPHER DUMP
ICTMSM07 - ICTMSM08 TRNSKEY DUMP
ICTMSM07 - ICTMSM09 EMK DUMP

IDACKRAI

VSAM CHECKPOINT (IDAOxxxx) ...
VSAM RESTART (IDAOxxxx) ...
ISAM INTRFC, OPEN/CLOSE, IDAOI92I/IDA0200S ...
IDAOI9SB:IDAI2IF7 - ABEND FROM BUILD IDACPA
FIOD:IDAOI9S2 - ABEND FROM FIOD FRR
IEC251I, VSAM GSR FORCE DLVRP DUMP DATA
ABP:IDAI21A2 - ABEND FROM ABP FRR
ABP:IDAI2IA3 - ABEND FROM NORMAL END FRR
ABP:IDAI2IA4 - ABEND FROM ABNORMAL END FRR

IDAICIAI
IDAOl9SB
IDAOl9S2
IDA0200T
IDAl2lA2
IDAl2lA3
IDAl2lA4

IEASMFSP
IEAVADOI

IEAVTRTE
IEAVTRT2
IEAVTSLP
IEAVTSLR
IEAVXPCR
IEAVXSTK

SMF ERRMOD=IEASMFSP, RECVRMOD=IEASMFSP
ERROR DURING SNAP
ERROR IN QMNGRIO PROCESSING
FAILURE DURING SNAP RECOVERY
RCT DUMPING LSQA
PGM CHECK IN IEAVGCAS
IEAVEACOIEAVEACOIEAVEAC3
variable title - supplied by caller
IEAVEMCR - MEMORY CREATE ABNORMAL TERMINATION
IEAVEMDL - MEMORY DELETE ABNORMAL TERMINATION
IEAVEMRQ UNEXPECTED ABEND
IEAVEMRQ - UNEXPECTED ABEND WITH DISPATCHER LOCK
COMPON = SUPV CNTL,COMPID = SCI C5
ERROR IN GETMAIN/FREEMAIN
PGM CHECK IN IEAVPRTO
COMPON = COMMTASK .. .ISSUER = IEAVMFRR ...
COMPON = COMMTASK .. .ISSUER = lEAVN700 .. .
COMPON = COMMTASK. ..ISSUER = IEAVN701 .. .
ERROR IN REAL STORAGE MANAGER
ERROR IN REAL STORAGE MANAGER FRR
TIMER FRR DUMP
COMPON = COMMTASK .. .ISSUER = lEAVSTAA ...
IEAVSY50 IGCOOI IGC002 XMPOST FAIL - NO ERRET
ABDUMP ERROR
ENQUEUE FAILURE IN ABDUMP
ABEND IN IEAVTGLB
ABEND IN IEAVTJBN
ABEND IN lEA VTLCL
RECORD PERMANENT ERROR
RECORD TEMPORARY ERROR
no title
IEAVTRT2 - UNRECOVERABLE ABEND FAILURE
SLIP ID = xxxx
ERROR IN IEAVTSLP
ABEND = aaa,REASON = xxyy,GPRrr = ZZZZZZ:Z:Z, •••
ABEND = aaa,COMPON = PCjAUTH-PCLlNK UNSTACK. ..

IECIHIO
IECIOSCN
IECVBRSV

lOS - IECIHIO ERROR
lOS - IECIOSCN ERROR
COMPON = IOS .. .ISSUER = I ECVBRSV

IEAVAROO
IEAVCARR
IEAVEACO
IEAVECHO
IEAVEMCR
IEAVEMDL
IEAVEMRQ
IEAVETCL
IEAVGFRR
IEAVGPRR
IEAVMFRR
IEAVN700
IEAVN701
IEAVRCV
IEAVRTIl
IEAVSTAA
IEAVSY50
IEAVTABD
IEAVTGLB
IEAVTJBN
IEAVTLCL
IEAVTRET

C-86

MVS Diagnostic Techniques

IECVDAVY
I ECVDPTH
IECVERPL
IECVESIO
IECVFCHN
IECVFDEV
IECVGENA
IECVHREC
IECVIOPM
IECVIOSI
IECVIRST
IECVPST
IECVRDIO
IECVRRSV
IECVSMGR

DAVVERROR
COMPON= JOS,COMPID:;:: SCIC3,ISSUER=IECVDPTH
lOS - lECVERPL: ERROR
IECVESIOER,ROR
COMPON=,IOS .. .ISSUER =IECVFCHN,FCHNFRR
COMPON :;::'IOS ... ISSUER;:: IECVFDEV,FDEVFRR...
COMPON= IQS .. .ISSUER = IECVG,ENA
COMPON =IOS •. .ISSUER = IECVHREC
IECVIOPMPROGRAMERROR
COMPON=IOS,COMPID=SCIC3~ISSUER=IECVIOSI

IECVIRSTERROR
lOS - POST STATUS ERROR
IECVRDIO ERROR
COMPON = 10S .. .ISSUER = IECVRRSV
lOS· IECVSMGR ERROR
lOS - SMGR SQA EXHAUSTED

IEECB800
IEECB860
IEECB862
IEECB866
IEECB906
IEECB914
IEEMB803
IEEMB804
IEEMB806
IEEMB812
IEEMB816
IEEMB825
IEEMB827
IEEMB830
IEEMB834
IEEMB835
IEEMB836
IEEMB839
IEEMB860
IEEMB881
IEEMB883
JEEMB887
IEEMPDM
IEEMPS03
IEEMPVST
IEESB665
IEESB670
IEEVIPL
IEEVLDWT
IEEVPTH
IEEVWAIT
IEE24110
IEE5103D

IEECB800 .. TRACK COMMAND
IEECB861- FAILURE iN COMMAND xxxx
COMPON = M S CMNDS,COMPID =SCIB8, ...
variable title - supplied by the system operator
IEECB906 SLIP ESTAE DUMP
,
IEECB914 SLIP TSO COMM RTN ESTAE DUMP
SYSTEM LOG DUMP
SYSTEM LOG SVC DUMP
SYSTEM LOG DUMP
STORAGE DUMP TAKEN AT ENTRY TO IEEMB812 ESTAE
COMPID = SCIB8,xxx ABEND IN MASTER TR .. .
SMF ABEND, ERRMOD =IEEMB829/IEFU29, .. .
SMF INITIALIZATION, RECVRMOD=U1EMB827
SMF ABEND, ERRMOD=XXXXXxxx, RECVRMOD= IEEMB830
SMF ABEND ED, ERRMOD= IEEMB834, RECVMOD = IEEMB834
SET SMF COMMAND - IEEMB835
ABEND IN SMF INTERVAL PROCESSING - ROUTINE ...
SMF TIMER - IEEMB839
IEEMB860
COMPON=M S CMNDS,COMPID=SCIB8,.. .
COMPON=M S CMNDS,COMPID=SCIB8, .. .
COMPON = MS CMNDS,COMPID = SCIB8,ISSUER = IEEMB887 ...
IEEMPDM - DUMP OF MAIN WORKAREA
IEEMPS03 - DUMP OF MAIN WORKAREA
IEEMPVST - DUMP OF MAIN WORKAREA
STARTED TASK CONTROL
STARTED TASK CONTROL
IEEVIPL - ERROR IN MASTER SCHEDULER INIT
IEEVLDWT ERROR
IEEVPTH - MAIN WORKAREA DUMP
COMPON = MSTR-WAIT.. .ISSUER = IEEVWAlT...
D U"ALLOC ABEND
IEE5103D - FAILURE IN SVC34/COMMAND xxxx

IEFAB4ED
IEFAB4E6

LOAD MOD-IEFW21SD EXIT RTN-xx.xxxxxx
ABEND =aaa,COMPON =ALLOC,COMPID = SCIB4,
ERRMOD= ...
COMMON AUTHORIZATION ROUTINE ...
ENF ABEND ERRORMOD = IEFENFFX
LOAD MOD-IEFW21SD EXIT RTN-xxxxxxxx
ENF ABEND ERRORMOP = IEFENFFX
ENF ABEND ERRORMOD =IEFENFNM
EVENT NOTIFICATION FACILITY ERROR
IEFIB620
SWACREATE
RESOURCE MANAGER
ERROR IN BROADCAST FUNCTION,ABEND= aaa, ...
ERROR IN SUBSYSTEM SE~VICE RTN, COMPON=INIT-SSI

IEFCMAUT
IEFENFFX
IEFAB4ED
IEFENFFX
IEFENFNM
IEFENFWT
IEFIB620
IEFIB645
IEFISEXR
IEFJRASP
IEFJSBLD

Appendix C. SVC DUMP Title Directory

C-87

IEFJSIN2
IEFNB9CR

IEFSJCNL
IEFXB609

ERROR IN SUBSYSTEM INITIALIZATION, COMPON=INIT-SSI ...
ABEND = aaa,COMPON = CONVERTER...
RESTART INTERRUPT IN CONVERTER**IEFNB9CR**
ABEND = aaa,COMPON = INTERPRETER::.
RESTART INTERRUPT IN INTERPRETER**IEFNB9IR**
SCHEDULER JCL FACILITY...
ERROR DURING RESTART PROCESSING - IEFXB609

IFGORROA
IFGORROE
IFGORROF
IFGOTCOA

IEC999I IFGORROA,error-modulejobname, .. .
IEC999I IFGORROA,error-modulejobname, .. .
IEC999I IFGORROA,IFGORROF jobname,stepname...
IEC999IIFGOTCOA/4A/5A,subroutinejobname...

IGCTOO 18
I GCT002D
IGCT002E
IGCT002l
IGCT005C
IGCT005G
IGCT006H
I GCTOO69
IGCTOIOE
IGCTl05C
IGCTl08l
IGCOOOIF
IGC0002F
IGC12l

I GCTOO l8,jobname,stepname
IGCT002Djobname,stepname
IGCT002Ejobname,stepname
IGCT0021,jobname,stepname
IGCT005CJobname,stepname
IGCT005Gjobname,stepname
IGCT006Hjobname,stepname,procstepname,744
IGCT0069 jobname,stepname,
IGCTOIOEjobname,stepname
IGCTl05Cjobname,stepname
IGCTI 081 jobname,stepname
no title
IGC0002F CATLG CTLR 3
ABP:IGC121 - ABEND FROM SIOD FRR

IGFDEI
IGFTMCHK

DYNAMIC DEVICE RECOVERY ERROR DUMP
IGFTMCHK MIH PROGRAM ERROR

IGGOCLA9
IGGOCLCA
IGGOCLCB
IGGOCLCD

JOB=jobname hh:mm:ss yy.ddd DUMP BY IGGOCLA9 ...
SDUMP - IGGOCLCA CVOL CATALOG MANAGEMENT
no title
SDUMP - IGGOCLCD - CVOL CATALOG MANAGEMENT

IKJCT460
IKJEFLGB
IKJEFLGM
IKJEFLS
IKJEFT05

TSO OUTPUT CP ESTAE
TSOLOGON ESTAI
IKJEFLGM REQUEST
TSOLOGON ESTAE
TSO SDUMP FROM IKJEFT05 .,.

IKTCAS52
IKTLTERM

TCASDUMP
IKTLTERM - I/O ERROR

IOSYRSUM

COMPON = IOS .. .ISSUER = IOSVRSUM ...

IRARMERR
IRARMSRV

SRM RECOVERY ENTERED,COMPON=SRM
SRM - IRARMSRV 55F ABEND DURING XMPOST

ISGBERCV
ISGBFRCV
ISGCRCV
ISGCRETO

COMPON = GRS-RING-PROC .. .ISSUER = ISGBERCV
COMPON = GRS-RING-PROC .. .ISSUER = ISGBFRCV
REQUESTOR = xxx,ISSUER = ISGCRV ...
COMPON =GRS-COMMANDS .. .ISSUER =ISGCRETO ...

IEFNB9IR

C-88

MVS Diagnostic Techniques

ISGCRETI
ISGDSNAP
ISGGFRRO
ISGJENFO
ISGJRCV
ISGQSCNR
ISGSMI

COMPON = GRS-COMMANDS .. .ISSUER = ISGCRETl ...
COMPON = GRS .. .ISSUER = ISGDSNRV
COMPON = GRS .. .ISSUER = ISGGFRRO
COMPON = GRS-CTC-DRIVER .. .ISSUER = ISGJENFO
COMPON =GRS-CTC-DRIVER ... ISSUER =ISGJRCV
COMPON =GRS-QUEUE SCANNING .. .ISSUER = ISGQSCNR
COMPON = GRS,COMPID = SCSDS,ISSUER =ISGSMIFR

ISTAPCES
ISTAPCFR
ISTAPCMT
ISTAPC61
ISTAPC62
ISTAPC66
ISTATMOO
ISTINCST
ISTORMMG
ISTRAMA2

ISTAPCES - ACF /VTAM PSS ESTAE ROUTINE
ISTAPCFR - ACF/VTAM PSS FUNCTIONAL RECOVERY
ISTAPCMT - ACFfVTAM ABEND IN MEMORY TERMINATION
ISTAPC61 - VTAM IRB ABEND
ISTAPC62 - VTAM SRB ABEND
ISTAPC66 - VTAM ABEND
ISTATMOO - VTAMTERMINATION SUBTASK ESTAE
ISTINCST - VTAM STAE EXIT
ISTORMMG - ACF/VTAM FRR DUMP
ISTRAMA2 DUMP FOR TRAMA6
ISTRAMA2 DUMP FOR TRAMST
ISTRAMA3 - VTAM TASK TERM FAILS
ISTRAMA4 - VTAM MEMORY TERMINATION ESTAE
no title

ISTRAMA3
ISTRAMA4
ISTZRMOI

Appendix C. SVC DUMP Title Directory

C-89

(
C-90

MVS Diagnostic Techniques

Appendix D. Abbreviations
ABP
ACA
ACB
ACE
ACFfVTAM
ACP
ACR
ACT
ADA
ADB
AFQ
AlA
ALCWA
ALPAQ
AMB
AMBL
AMCBS
AMDSB
AP
APF
APG
ASCB
ASID
ASM
ASMHD
ASMVT
ASPCT
ASST
ASTE
ASVT
ASXB
AT
ATA
AVT
AX
AXAT

- Actual block processor
- ASM control area
- Access method control block
- ASM control element
- Advanced Communications Function for VTAM (Program Product)
_. Automatic command processing
- Alternate CPU recovery
- Account control table
- Automatic data area
- Allocation descriptor block
- Available frame queue
- ASM I/O request area
- Allocation work area
- Active link pack area queue
- Access method block
- AMB list
- Access method control block structure
- Access method data statistics block
- Attached processor
- Authorized program facility
- Automatic priority group
- Address space control block
- Address space identification
- Auxiliary storage manager
- Auxiliary storage management header
- ASM vector table
- Auxiliary storage page correspondence table
- Address space sector table
- Address space second table entry
- Address space vector table
- Address space extension block
- Authorization table
- ASM tracking area
- TCAM address vector table
- Authorization index
- Authorization index allocation table

BASEA
BPCB
BUFC

- Master scheduler resident data area
- Buffer pool control block
- Buffer control area

CA
CAW
CAXWA
CCA
CCH
CCW
CDE
CEPL
CFQ
CHAP
CI
CIDF
CKB
CMB

- Control area or cllannel adapter
- Channel address word
., Catalog ACB extended work area
- Catalog communications area
- Channel check handler
- Channel command word
- Contents directory entry
- Command ESTAE parameter list
- Common frame queue
- Change priority
- Control interval
- .Control interval definition field
- Checkpoint buffer
-·Console message butTer

Appendix D. Abbreviations

D-1

CML
CMS
CMSWA
CPA
CPAB
CPB
CPPL
CPU
CPUID
CQE
CRA
CRB
CRWA
CSA
CSCB
CSD
CTGPL
CVT
CXSA

- Cross memory lock
- Cross memory services or catalog management services
- CMS work area
- Channel program area
- Cell pool anchor block
- Channel program block
- Command processor parameter list
- Central processing unit
- CPU identification
- Console queue element
- Component recovery area
- Command request block
- Command recovery work area
- Common service area
- Command scheduling control block
- Common system data area
- Catalog parameter list
- Communications vector table
- Communications extended save area

DADSM
DAIT
DALT
DAM
DAT
DAVV
DCB
DCM
DCT
DDR
DDRCOM
DE
DEB
DECB
DEPL
DIDOCS
DIE
DIR
DMDT
DMVT
DPL
DQE
DRQ
DSAB
DSCB
DSPCT
DSPL
DVT

Direct access device space management
- Display allocation index table
- Display allocation lookup table
. - Direct access method
- Dynamic address translation
- Direct access volume verification
- Data control block
- Display control module
- Device control table
- Dynamic device reconfiguration
- Dynamic device reconfiguration communication table
- Directory entry
- Data extent block
- Data event control block
- SDUMP ESTAE parameter list
- Device independent display operators console support
- Disabled interruption exit
- Deferred incident record
- Domain descriptor table
- Domain vector table
- DEQ purge list
- Descriptor queue element
- Data ready queue
- Data set association block
- Data set control block
- Data set page correspondence table
- Dump sort parameter list
- Destination vector table or display allocation vector table

ECB
ECC
ECT
EDB
EDL
EDT
EED
ElL
EIP
EMS
ENF
ENFPM
EOA
EOE
EOV
EP
EPATH
EPS
ERP

D-2

MVS Diagnostic Techniques

- Event control block
- Error checking and correction
- Environment control table
- Extent descriptor table
- Eligible device list
- Eligible device table
- Extended error descriptor
- Event indication list
- EXCP intercept processor
- Emergency signal
- Event notification facility
- ENF event parameter list
- End of address
- End of extent
- End of volume
- Emulator program
- Error path· (recovery audit trail area)
- External page storage
- Error recovery procedures

EWA
EX

.. ,Error te<:OveryprocedureS;mterrate block
·Ex~edSTAE
- ,Extend~STAI
- Entry table
.. Entry table entry
- Entry table information blOCk
- ETIB elEtension.
.; EVent table
- Common SRP work area
-Entry table' index

FBQE
FOB
FETWK.'
FIFO
FLlH
FMCB
FOE
FOT
FQE
FRR
FRRS
FSA
FSACB
FSAXB
FSB
FVT
FSI
FSS
FSSCB
FSSWORK
FSSXB

-Freeblock. queue element
- Feedback data block
-Fetch work area
- First in fIrst out
- First leve1.interrupt handler
- VTAM f~ction management control block
- Fixed ownership element
- Fixed ownership table
- Free queue element
- Functional recovery routine
- FRR stack
- Functional subsystem application
- FSA control block
- FSACB extension
- Feedback status block
- Field vector table
- Functional subsystem interface
- Functional subsystem
- Functional subsystem control block
- ESS PCE work area
- FSSCB extension

GCB
GCC
GCL
GCP
GCT
GCV
GCX
GDA
GPR
GQHT
GRS
GSMQ
GSPL
GSR
GTF
GVT
GVTX

- Global resource serialization CTC-driver request block
- Global resource serialization CTC-driver control card table
- Global resource serialization CTC-driver link control block
- Global resource serialization, CTC-driver buffer prefIx
- Global resource serialization CTC-driver queueing element
- Global resource serialization. crC-driver branch table
- Global resource serialization CTC-driver vector table
- Global resource serialization CTC-drlver extract table
- Global data area
- General purpose register .
- Global queue hash table
- Global resource serialization
- Global serVice manager queue
- Global system priority list
- Global shared resource
- Generalized trace facility
- Global resource serialization vector table
- GVT extension

HFCT
HIR

- HASP FSS communications control block
- Hardware instruction retry

IC
ICNCB
IHSA
ILC/CC
lOB
10E
10MB
10QE
10RB
lOS
10SB
lOT
IOWA
IPC

- InstruCtion counter
- Intermediate controller node control block
- Interrupt handler Save area
- Instruction length condition code
- Input output block
- I/O request element
- I/O management block
- I/O queue element
- 1/0 request block
- 1/0 supervisor
- 1/0 supervisor block
- 1/0 table
- 1/0 work area
- Inter-processor communication

EIU'IB
ESTAE

ESTAI
'ET

ETE

rnB
ETIX

EVNt

GCQ

Appendix D. Abbreviations

D-3

D-4

IPCS
IPL
IPS
IQE
IRB
IRT
ISAM

- Interactive problem control system
- Initial program load
- Installation performance specifications
- Interrupt queue element
- Interrupt request block
- lOS recovery table
- Indexed sequential access method

JCL
JCT
JOT
JOVT
JES
JES2 NJE
JESCT
JFCB
JFCBX
JIB
JIX
JOE
JOT
JPQ
JQE
JSCB
JSEL
JSXL

- Job control language
- Job control table
- JCL definition table
- JCL definition vector table
- Job Entry Subsystem
- JES2 Network Job Entry (program Product)
- JES control table
- Job file control block
- Job file control block extension
- JOE information block
- Job queue index
- Job output element
- Job output table
- Job pack queue
- Job queue element
- Job step control block
- Job scheduling entry list
- Job scheduling exit list

KSOS

- Key sequence data set

LCB
LCCA
LCCAVT
LCH
LCPB J
LCT
LOA
LFQ
LG
LGF
LGCB
LGE
LGN
LGVT
LGVTE
LIFO
LIT
LLE
LLQ
LPA
LPOE
LPID
LPME
LQHT
LRB
LSIO
LSMQ
LSPL
LSQA
LT
LTE
LUB
LWA
LWK
LX
LXAT

- TP line control block
- Logical configuration communication area
- LCCA vector table
- Logical channel queue
- Logical channel program block
- Linkage control table
- Local data area
- Local frame queue
- Logical group
- Line group block
- Logical group control block
- Logical group entry
- Logical group number
- Logical group vector table
- Logical group vector table entry
- Last in first out
- Lock interface table
- Load list element
- Load list queue
- Link pack area or latent parameter area
- Link pack directory entry
- Logical page identifier
- Logical to physical mapping entry (or) logical page mapping entry
- Local queue hash table
- Logrec buffer
- Logical slot 10
- Local service manager queue
- Local service priority list
- Local system queue area
- Linkage table
- Linkage table entry
- NCP logical unit block
- Logon work area
- Local work area
- Linkage index
- Linkage index allocation table

MCH
MCIC

- Machine check handler
- Machine check interrupt code

MVS Diagnostic Techniques

MCP
MCS
MFA
MH
MIH
MLPA
MP
MPF
MPFr
MPST
MRD
MSFAB
MSFCD
MSFKD
MSS
MSSC
MSSF
MSVC
MVS
MWA

- Message control program
- Multiple console .support
- Malfunction alert
.. Message handler
-Missing inte1'l"ijpt handler
- Modified 4ink pack area
- Multiprocessor
- Message processing facility
- MPF table
;. Memory process scheduling table
- Message request block
- MSSFCALL SVC attention block
- MSSFCALL SVC control block
- MSSFCALL
communication block
- Mass storage subsystem
- Mass storage system communicator
- Monitoring and system support facility
- Mass storage volume control
-Multiple Virtual Storage
- Module work area

NCD
NCP
NIP

- VTAM node control block
- Network Control Program
- Nucleus initialization program

OCR
OCT
OPWA
ORE
OUCB
OUSB
OUXB

- Output control record
- Output control table
- Open work area
- Operator reply element
- SRM-user control block
- SRM-user swappable block
- SRM-user extension block

PAB
PART
PARTE
PAT
PCjAUTH
PCB
PCCA
PCCAVT
PCCB
PCCW
PCE
PCRA
POOB
POS
PEL
PEP
PER
PEXD
PFT
PFTE
POT
POTE
PICA
PIE
PIT
PIU
PLH
PLPA
PLPAD
PQCB
PQE
PRB
PSA
PSCB
PSS
PST

- Process anchor block
- Paging activity reference table
- PART entry
- Page allocation table
- Program call/authorization
- Page control block
- Physical configuration communication area
- PCCA vector table
- Private catalog control block
- Paging channel command work area
- Processor control element
- Program call recovery area
- Peripheral data definition block
- Partitioned data set
- Parameter element
- Partitioned emulator program
- Program event recording
- Pool extent block
- Page frame table
- Page frame table entry
- Page table
- Page table entry
• Program interrupt control area
- Program interrupt element
- Partition information table
- Physical information unit
- Place holder
- Pageable link pack area
- PLPA directory
- Placeholder queue control block
- Partition queue element
- Program request block
- Prefixed save area
- Protected step control block
- Process scheduling service
- Process scheduling table

svt

Appendix D. Abbreviations

D-5

D-6

PSW
PTLB
PVT
PVTAFC
PWF
PWKA

- Program status word
- Purge translation loo~aside buffer
- Paging vector table
- PVT available frame count
- Power Warning Feature Support
- Paging work area

QAB
QCB
QEL
QFPL
QFPLl
QHT
QWA
QWB
QXB

- Queue anchor block
- Queue control block
- Queue element
- ENQ/DEQ FRR parameter list
- Queue scanning services FRR parameter list
- Queue hash table
- Queue work area
- Queue work block
- Queue extension block

RACF
RB
RBA
RBN
RCA
RCB
RCT
RDCM
RDF
RDT
RDTE
REPL
RIB
RIBE
RIM
RJE
RMCT
RMF
RMS
RNLE
RPH
RPL
RPT
RQA
RQE
RRPA
RSA
RSAIRCD
RSC
RSL
RSM
RSMHD
RST
RSV
RTAM
RTCA
RTCT
RTM

- Resource Access Control Facility (Program Product)
- Request block
- Relative byte address
- Real block number
- RSM recovery communication area
- Resource control block
- Region control task
- Resident display control module
- Record definition field
- Resource definition table
- Resource definition table entry
- Ring processing ESTAE parameter list
- Resource information block
- Resource information block extent
- Resource initialization module
- Remote job entry
- Resource manager control table
- Resource Measurement Facility (Program Product)
- Recovery management support
- Resource name list entry
- Request parameter header
- Request parameter list
- Request pool table
- Resource queue area
- Request queue element
- Recovery routine parameter area
- Ring processing system authority message
- Ring processing information record
- Ring status change parameter list
- Ring processing system link block
- Real storage manager
- RSM header
- Ring processing status table
- Ring processing system vector table
- Remote terminal access method
- Recovery termination control area
- Recovery termination control table
- Recovery termination manager

S/A
SAHT
SAM
SART
SAST
SAT
SCCD"
SCCW
SCT
SDWA
SFT
SGT

- Stand-alone (dump program)
- System/ASID hash table
- Sequential access method
- Swap activity reference table
- Subsystem allocation sequence table
- Swap allocation table or system authorization table
- Service call control block
- Swap channel control work area
- Step control table
- System diagnostic work area
- System function table or swap function table
- Segment table

MVS Diagnostic Techniques

)

SGTE
SHAS
SIC
SIGP
SIO
SlOT
SJF
SLIH
SLIP
SLT
SMF
SMPL
SMS
SNA
SPCT
SPQE
SQA
SRB
SRM
SRR
SRRA
SSCP
SSCVT
SSI
SSIB
SSOB
SSQ
SSRB
SSVT
STAE
STAI
STC
STCB
STKE
STOR
SVC
SVRB
SVT
SWA
SWB

- Segment table entry
- Subsystem hash table
- System initiated cancel
- Signal processor instruction
- Start input/output
- Step I/O table
- Scheduler JCL facility
- Second level interrupt handler
- Serviceability level indication processing
- System linkage table
- System management facility
- Storage management parameter list entry
- Storage management services
- System Network Architecture
- Swap control table
- Subpool queue element
- System queue area
- Service request block
- System resources manager
- Serially reusable resource
- Service routine recovery area
- System services control point
- Subsystem communications vector table
- Subsystem interface
- Subsystem identification block
- Subsystem options block
- SVRB suspend queue
- Suspended service request block
- Subsystem vector table
- Specify task abnormal exit
- Subtask abend intercept
- Start task control
- Subtask control block
- Stack element
- Segment table origin register
- Supervisor call
- Supervisor request block
- Supervisor vector table
- Scheduler work area
- Scheduler work block

TCAM
TCB
TCH
TDCM
TEA
TH
TIOC
TIOT
TLB
TMC
TME
TMP
TOD
TSB
TSO
TIE

- Telecommunications Access Method
- Task control block
- Test channel
- Pageable display control module
- Translation exception address
- Transmission header
- Terminal I/O coordinator
- Task input/output table
- Translation lookaside buffer
- Task mode controller
- Task mode element
- Terminal monitor program
- Time of day
- Terminal status block
- Time Sharing Option
- Trace table entry

UADS
UCB
UCM
UCME
UIC
UPT

- User attribute data sets
- Unit control block
- Unit control module
- Unit control module entry
- Unreferenced interval count
- User profile table

VBN
VBP
VDSCB
VFCB

- Virtual block number
- Virtual block processor
- Virtual data set control block
- Virtual fetch control block

Appendix D. Abbreviations

D-7

VFHE
VFPM
VFVT
VFWK
VIO
VSAM
VSM
VTAM
VTOC
VUT

- Virtual fetch hash entry
- Virtual fetch parameter list
- Virtual fetch vector table
- Virtual fetch work area
- Virtual I/O
- Virtual storage access method
- Virtual storage management
- Virtual Telecommunications Access Method
- Volume table of contents
- Volume unload table

WAST
WMST
WQE·
WSC
WTQE

- Workload activity specification table
- Workload manager specification table
- Write queue element
- Wait state code
- Wait queue element

XL

- Extent list
- Cross memory directory
- External page table entry
- Extended real block number
- Extended status block

XMD
XPTE
XRBN
XSB

D-8

MVS Diagnostic Techniques

Index
A
abbreviations
list of D-l
abend codes
COD in ASM 5-134
EXCP 5-32
Service Processor Call SVC 5-279, 5-284
started task control 2-93
SWA manager 2-94
symptoms of lOS problems 5-28
OBO in allocation 5-194
OC4 in allocation 5-195
08x series in ASM 5-132
306 abend in program manager 5-71
806 abend in program manager 5-66
abend dump debugging 2-86
abend resource manager 5-66
abnormal end appendages
with ERPs 5-49
abnormal task termination (RTM) 5-225
ACB (access method control block)
how to locate 5-160
major fields in 5-161
ACCOUNT command processor A-41
ACF/TCAM
See TCAM
ACF/VTAM
See VTAM
ACR
See alternate CPU recovery
ACTION keyword
SLIP 2-112
action message retention facility
debugging aids 5-251
additional data gathering techniques 2-95
address space
analysis 2-6
ASM's 5-117
dispatchable work in B-6
dispatcher's 5-8
initialization 5-84
OUCB queues 5-147
states recognized by SRM 5-142
termination 5-229
tests made by dispatcher 5-13
wait 5-9
addresses
commonly bad 2-80

AlA
RSM test on A-3
allocation
of virtual storage 5-87
allocation/unallocation
abends
OBO 5-194

0C4 5-195
address space (ALLOCAS) 5-180
address space termination 5-194
allocation
common 5-174
description 5-172
fixed device 5-175
generic 5-175
recovery 5-175
serialization 5-192
TP 5-175
batch initialization 5-173
common allocation 5-174
common unallocation 5-175
component analysis 5-172
control block processing 5-177
debugging aids 5-176
debugging hints 5-192
device selection 5-193
dynamic initialization 5-173
ESTAE processing 5-180
functional description 5-172
JFCB housekeeping 5-174
module naming conventions 5-176
reason codes 5-197
registers and save ares 5-177
unallocation
common· 5-175
description 5-173
unit status recording 5-180
volume mount and verify 5-176, 5-195
alternate CPU recovery (ACR)
problem analysis 2-75
AMCBS
major fields in 5-159
AMDPRDMP
control statements 2-97
example of use of data 4-10
GRSTRACE option
use for loop analysis 4-17
use for wait analysis 4-10
how to copy tapes 2-99
QCBTRACE option
use for loop analysis 4-17
use for wait analysis 4-10
APF authorization 5-70
appendage footprint table
with PWF 5-265
appendages
abnormal end
with ERPs 5-49
ASCB (address space control block)
analysis 2-6
indicators 2-14
ASM (auxiliary storage man~ger)
address space structure 5-117

Index

X-I

cell pools 5-117
component analysis 5-112
component functional flow 5-113
control blocks 5-116, 5-135
converting a slot number to full seek address
COD abend 5-134
error analysis suggestions 5-127
finding the LSID for a given page 5-121
footprints and traces 5-118
FRR/ESTAE work areas 5-132
general debugging approach 5-119
incorrect pages 5-120
interfaces with other components 5-118
operating characteristics 5-117
page/swap data set errors 5-127
paging interlocks 5-119
recovery
as a debugging tool 5-133
considerations 5-131
footprints 5-133
structure 5-132
traces 5-132
register conventions 5-118
requesting I/O 5-114
requesting swap I/O 5-115
saving an LG 5-113
SDWA variable recording area 5-134
serialization 5-129
SRB structure 5-117
storage considerations 5-117
system mode 5-117
task structure 5-117
unuseable paging data sets 5-125
validity checking 5-128
08x abend codes 5-132
ASMDATA statement (ofPRDMP) 2-99
ATA (ASM tracking area) 5-135
ATTACH (program manager function) 5-61
attention processing (TSO) A-46
audit trail area (EPATH) 5-136
auxiliary storage manager
See ASM

B

backout (for DEFINE/DELETE)
batch initialization 5-173
BLDL table analysis 4-27
BSHEADER data area 5-139
BUFCONBK data area 5-139
buffer
external call 2-59
LOGREC 2-38
translation lookaside 2-43

5-168

C
caller-defined SVC dump titles

x -2

C-82

MVS Diagnostic Techniques

5-124

cancel process (RTM) 5-227
catalog communications area
See CCA
catalog management
backout 5-168
CMS function gate 5-167
component analysis 5-158
debugging aids 5-170
diagnostic output 5-167
establishing/releasing a recovery
environment 5-165
how to find registers 5-158
maintaining a pushdown list end mark 5-166
major control blocks 5-159
major registers 5-159
module structure 5-164
recovery routine functions 5-167
tracking GETMAIN/FREEMAIN activity 5-166
VSAM catalog recovery logic 5-165
catalog parameter list (CTGPL)
major fields 5-162
CAXWA
major fields 5-161
major flags 5-162
CCA (catalog communication area)
major fields 5-163
major flags 5-164
CCH (channel check handler)
diagnostic aids 5-266
message IGF0021 5-266
PCCA fields 5-267
CDE (contents directory entry)
allocation 5-70
analysis 4-27
initialization by IDENTIFY 5-65
order of on ALPAQ 5-68
pool control 5-72
cell pool anchor block
See CPAB
cell pool management
VSM 5-92
channel check handler
See CCH
channel program
with ERPs 5-50
channel scheduler
invoked for lOS 5-25
channel set ID 5-32
channel set switching 5-32
checkpoint/restart
with SLIP command 2-128
CHNGDUMP command
to change SDUMP contents 2-95, 3-5
to override SVC dump parameters 2-99
class locks
with ASM 5-130
CML (cross memory lock)
classification 2-26
definition 2-22
location 2-26

CMS function gate ?-167
CMS lock 2-22
CMS lockword
contents 2-25
suspend queues 2-28
CMSEQDQ lock 2-22
CMSSMF lock 2-22
COMM task
See communications task
command processing (global resource serialization)
control block overview 5-314
introduction 5-306
module flow 5-331
command processor
and TMP interface A-37
parameter list A-39
common allocation 5-174
common service area
See CSA
common unallocation 5-175
communications task
component analysis 5-244
control blocks 5-246
current status 4-13
debugging hints 5-248
functional description 5-244
sequence of processing 5-245
compare and swap
serialization with ASM 5-131
completion codes in IOSB for ASM errors 5-126
component analysis 5-1
considerations
MVS 2-1
console
not responding to attention 5-248
console switching 5-251
contents directory entries
See CDE
contents supervision
See virtual fetch
CONTROL Q command debugging aids 5-253
converting virtual to real addresses 5-108
CPAB 5-92
CPUDAT A statement (of PRDMP) 2-98
CQE control block 5-246
cross memory lock
See CML
cross memory services
component analysis 5-288
lock description 2-22, 2-28
lock suspend queues 2-28
cross memory services lock 2-28
CSA (common service area)
analysis of use of 4-28
CTC processing
control block overview 5-312
debugging hints 5-344
introduction 5-307
module flow 5-322. 5-323
CTGPL (catalog parameter list)

major fields 5-162
current recovery stack
See FRR stacks
CVOL processor 5-165
CVTMAP statement (of PRDMP)
CXSA control block 5-246
COD abend in ASM 5-134

2-98

D

DASD ERPs 5-53
data gathering techniques 2-95
data sets
page/swap errors 5-127
DDR (dynamic device reconfiguration)
DDRCOM table 5-268
DERPLIST parameter list 5-269
diagnostic aids 5-268
return codes 5-272
software recording 5-272
storage dump 5-272
task description 5-268
DDRCOM table 5-268
debugging hints (chapter) 2-75
DEFINE/DELETE backout 5-169
DELETE (function of program manager)
delete listen request (EN F)
description 5-212
example 5-219
DERPLIST parameter list 5-269
DIAGNOSE instruction
description 5-277, 5-281
trace entry 2-64
diagnostic materials approach 3-1
diagnostic techniques
component analysis 5-1
diagnostic approach 3-1
important considerations 2-1
introduction I-I
process flows A-I
stand-alone dump analysis B-1
SVC dump title directory C-l
sympton analysis approach 4-1
DIDOCS
in-operation indicator 5-252
locking 5-252
trace table 5-252
disabled loop
See loops
disabled mode 2-12
disabled wait
See waits
DISP lock
description 2-22
dispatchability tests
address space 5-13
SRB 5-13
task 5-13
dispatchable units of work

5-64

Index

X-3

in an address space B-6
prio,rity and location 5-4
dispatcher
abend codes 5-16
component analysis 5-2
determining the last dispatch 5-14
dispatchability tests 5-13
error conditions 5-16
important entry points 5-2
processing overview 5-10
recovery considerations 5-15
DISPLAY DUMP command 2-95
DISPLAY GRS command
introduction 5-305, 5-306
module flow 5-332
DSNLIST data area 5-140
dummy task B-6
dump analysis
abend dumps 2-86
areas 4-24
?vIP 2-45
problem program 2-86
stand-alone 2-2, 3-2, B-1
summary dump 2-89
tracing procedure 2-66
DUMP command 2-95
dump footprint table
with PWF 5-265
dumps
how to copy tapes 2-99
how to print 2-97
SVC dump titles C-l
tailoring with SLIP 2-117
dynamic device reconfiguration
See DDR

E

EDIT command processor A-41
EDIT statement (of PRDMP) 2-98
EDT
See eligible device table
EED
important fields 2-41
ElL control block 5-246
eligible device table (EDT)
description 5-193
verification routine 5-194
Emergency Signal instruction
See EMS
EMS (function of SIGP)
definition 2-49
process flow 2-56
enabled loop
See loops
enabled loop exception 4-17
enabled wait
See waits
ENF (event notification facility)

X-4

MVS Diagnostic Techniques

component analysis 5-212
control blocks 5.-215
event codes 5-212
examples of logic flow 5-217
exit routines 5-214
initialization 5-216
processing 5-217
recovery routines 5-220
requests for services 5-212
return codes 5-217
ENFCT control block 5-215
ENFDS control block 5-215
ENFLS control block 5-215
ENFPM parameter list 5-212
ENFVT control block 5-215
ENQ/DEQ
analysis for enabled waits 4-10
analysis for performance degradation 4-23
common ENQ resource names 4-12
enqueue lockout B-7
global save area 4-24
ENQ/DEQ/RESERVE services
control block overview 5-314, 5-315
debugging hints 5-345
introduction 5-305, 5-307
module flow 5-339, 5-340
EP mode traces 4-22
EPATH (error path) 5-136
ERPs (error recovery procedures)
abnormal end appendages 2-77, 5-49
description 5-48
EWA (ERP work area) 5-30
traps 5-54
.
with ACR 2-76
error id 5-232
error interpreter table 5-50
error recovery procedures
See ERPs
event notification facility
See ENF
event parameter list (ENFPM) 5-212
EW A (ERP work area) 5-30
EXCP abend codes 5-32
EXCP debugging area (XDBA) 5-33
EXCP major control block relationships 5-27
EXCP/IOS process flow A-12
execution modes
See system mode
exit resource manager 5-64
exit routines (ENF) 5-214
explicit waits 2-7
extended error descriptor (EED) 2-41, 5-222
external call (XC function of SIGP)
description 2-49
process flow 2-55
external symptoms 1-2

F

FETCH
program manager work area (FETWK) 5-72
FORCE command 5-228
FORMAT statement (of PRDMP) 2-98
formatted RtM control blocks 2-42
formatting (LOGREC buffer) 2~3'8
FREEMAIN
See GETMAIN/FREEMAIN
FRR (functional recovery routine)
ASM's 5-132
FRR stacks
important field contents 2-40, B-15
GETMAINS's 5-90
RSM's 5-104
FRR/ESTAE
ASM work areas 5-133
PSS (functional subsystem)
functional recovery routine
See FRR
functional subsystem
See PSS
functional subsystem application
See FSA
functional subsystem interface
See FSI

probe points 5-344
recovery routines 5-351
serialization 5-350
system indicators 5-343
SYSl.LOGREC recording 5-351
global SRBs
control block relationships 5-6
dispatching 5-5
mode indicators set by dispatcher 5-14
queue structure 5-6
status indicators B-17
global system analysis (chapter) 2-2
GQSCAN macro
See also queue scanning services
introduction 5-305
GRSTRACE (AMDPRDMP option)
use for loop analysis 4-17
use for wait analysis 4-10
GRSTRACE statement (of PRDMP) 2-98
GSMQ/LSMQ 2-5
GSPLs/LSPLs 2-5
GTF (generalized trace facility)
bypassing lost events 2-68
I/O and SIO trace (EP) 4-21
RNIO trace 4-21
trace examples 2-64
with SLIP command 2-115

G
GDA (global data area) for VSM 5-89
GETMAIN processing A-I5
FREEMAIN processing A-16
GETMAIN/FREEMAIN
GETMAIN FRR 5-90
indication in trace table 2-71
process flow A-15
SVC 120 5-94
virtual storage allocation 5-87
GETPART/FREEPART 5-86
global data area for VSM 5-89
global indicators of current system state 2-2
global locks
definition 2-21
error status B-12
requests for unavailable 2-26
spin locks
content of lockword 2-25
definition 2-23
suspend locks
content of lockword 2-25
definition 2-23
global resource serialization
component analysis 5-305
control blocks 5-308, 5-348
control blocks overviews 5-310
diagnostic aids 5-343
functional overview 5-306
module flow diagrams 5-320
module flow overview 5-321
module naming conventions 5-306

H

hardcopy log
master trace 2-71
hardware-detected errors
analysis 3-8
hierarchy of locks 2-23

I

I/O
capability in MP 2-59
enabled B-6
incomplete B-7
NCP trace
See NCP
problems in enabled waits 4-8
requesting (ASM) 5-114
requesting swap 5-115
trace entries 2-69
VTAM I/O trace
. See VTAM
I/O manager
debugging 5-157
modules 5-157
I/O request
information in PLH 5-152
IDENTIFY (function of program manager)
lEA VGF A tests by RSM A-2
lEAVIOCP tests by RSM A-6

5-65

Index

X-5

lEA VPIOP tests by RSM A-3
.lEA VPIX tests by RSM A-2
IEAVSWIN A-7
ILC/CC important field contents 2-3
in-operation indicator
DIDOCS 5-252
incorrect output (chapter)
analyzing system functions 4-30
initial analysis 4-29
isolating the component 4-29
installation performance specifications (IPS) 5-141
inter-processor communication 2-49
interactive problem control system (IPCS) 1-4
intercept condition
ERPs 5-51
in terruptions
status saving 2-15
intersect
description 2-31
service routine 4-16
lOB
See 10MB
10MB 5-157
lOS (I/O supervisor)
ABEND codes 5-28
back-end processing 5-25, A-14
component analysis 5-25
diagnostic aids 5-32
ERP processing 5-48
EXCP/IOS process flow A-12
front-end processing 5-25, A-12
general hints 5-30
loops 5-28
major control block relationships 5-27
message table 5-46
output of recovery procedures 5-34
POST STATUS A-14
problem analysis . 5-25
processing overview 5-26
return codes 5-47
save areas 5-30
SDW A variable recording area 5-34
storage manager queues 4-27
VTAM interaction A-18
wait state codes 5-47
wait states 5-29
10SjEXCP process flow A-13
10SB fields 5-43
10SCAT lock 2-22, 2-26
IOSCOD field 5-44
IOSDRVID field 5-43
10SLCH lock 2-22, 2-26
10SPROC field 5-44
IOSUCB lock 2-22, 2-26
IOSYNCH lock 2-22,2-26
IPC
See inter-processor communication
IPCS 1-4

. X-6

MVS Diagnostic Techniques

1
1ES2 (job entry subsystem)
note to readers 5-201
operator commands for status information 4-24
1ES3
See note in Preface
1FCB housekeeping 5-174
join processing
module flow 5-338

K

K Q command debugging aids
key-length-data format
SDWAVRA 2-35

5-253

L

LCCA indicators 2-13
LCH queues
analysis for enabled waits 4-9
LDA
important flags 5-87
LG
saving 5-113
line drop (TSO processing) A-34
LINK (function of program manager)
description 5-60
module search sequence 5-68
listen request (ENF)
description 5-212
example 5-217
exit routine 5-214
LMODmap
how to print 2-103
LOAD (function of program manager)
description 5-64
module search sequence 5-68
local lock
definition 2-21
lockword contents 2-25
lockword location 2-26
requests for unavailable 2-27
suspend (definition) 2-23
with ASM 5-130
local SRBs
dispatching 5-5, 5-7
dispatching priority in address space 5-8
mode indicators set by dispatcher 5-15
status indicators B-16
locating status information in a storage dump
lock interface table (lEAVESLA) 2-26
locked mode
definition 2-13
status saving during execution 2-11
locking (chapter) 2-21
locks (see also lockwords)

2-15

)

categories 2-21
classification 2-26
determining which held on a processor 2;.24
hierarchy 2-23
location of 2-26
PSAHLSI bits 2-24
requests for unavailable 2-26
table of definitions 2-22
types 2-22
with ASM 5-117, 5-129
lockwords
contents of 2-25
how to find 2-26
LOGDATA verb 2-38
logging
ERPs 5-51
logical groups
assigning 5-112
releasing 5-113
logon
command processor A-41
diagnostic aids A-32
initialization A-27
monitor A-29
post codes A-33
process overview A-24
scheduler A-29, A-31
scheduler router A-27
TMP exit A-31
verification A-29, A-30
work area A-28, A-32
LOGREC
analysis 2-34
considerations 2-36
for debugging SVC dump 5-234
formatting 2-38
how to print 2-104
listing LOGREC data set 2-34
recording control buffer 2-38
loop recording option 4-16
loops
analysis 4-15
disabled
definition 4-15
system mode 4-18
enabled
definition 4-15
exception 4-17
in lock manager code B-16, B-18
symptoms of lOS problems 5-28
low storage overlays 2-78
LPAMAP statement (of PRDMP) 2-98
LPSW
common uses of 4-2
LSID
finding for a page 5-121
LSMQ 2-5
LSPL 2-5

M

machine check handler
See MCH
machine checks
debugging 2-81
interruption code (M CIC) 2-81
reference matrix 2-84
master trace
debugging aias 5-254
description 2-71
trace table 2-72
trace table entry 2-73
MCH (machine check handler)
diagnostic aids 5-256
PWA 5-257
return codes 5-256
MCIC (machine check interruption code) 2-81
message flow
through the system 4-20
message. processing facility (MPF)
description 2-74
table (MPFT) 2-74
lllessages
ERPs 5-51
IGF0021 5-266
lOS message table 5-46
lost 5-249
master trace 2-71
missing on one console 5-250
processing facility 2-74
routed to wrong console 5-250
truncated 5-250
MIH (missing interruption handler)
diagnostic aids 5-273
process 5-273
software recording 5-276
storage dumps 5-276
work area 5-273
miscellaneous debugging hints (chapter) 2-75
missing interruption handler
See MIH
module search sequence
for LINK,ATTACH, XCTL, LOAD 5-68
of private libranes 5-69
module subpools 5-71
monitoring and system support facility
See MSSF
MP (mUltiprocessing)
activity in trace table 2-70
associated data areas 2-45
debugging hints 2-58
direct services 2-50
dump analysi$, 2-45
dump analysis hints 2-48
effects on problem analysis 2-43
features of MP environment 2-43
parallelism 2-46
PSA analysis B-3
remote immediate services 2-52

Index

X-7

remote pendable services 2-51
SIGP instruction 2-49
system stop routine 2-133
MPF (message processing facility) 2-74
MPFT (MPF table) 2-74
MSGBUFFER data area 5-140
MSSF (monitoring and system support facility)
with MSSFCALL DIAGNOSE instruction 5-277,
5-281
with Service Processor Call SVC 5-277
MSSFCALL data block
description 5-278
MSSFCALL DIAGNOSE instruction
condition codes 5-282
description 5-277, 5-281
trace entry 2-64
MSSFCALL SVC
See Service Processor Call SVC
multi processing
See MP
MVS trace
See trace table

N

NCP (network cont.rol program)
traces 4-22
no-work wait (see also waits) 4-7
normal task termination 5-224

o
O/C/EOV (open/c1ose/end-of-volume)
abends 2-80
DEB chaining 5-156
debugging aids 5-155
ENQs issued by 5-156
messages 5-155
online problem analysis 1-4
open/close/end-of-volume
See O/C/EOV
OPERATOR command processor A-41
operator commands
for status information 4-23
to identify performance degradation 4-23
operator-defined SVC dump titles C-82·
ORE control block 5-246
OUCB (SRM user control block)
analysis 5~147
important fields 5-142
OUTPUT command processor A-41
output of lOS recovery procedures 5-34
overlays
storage
cause of wait state PSWs 4-3
how to locate the trace table 2-62
in low storage 2-78
pattern recognition 2-77

X-8

MVS Diagnostic Techniques

P

page control block
See PCB
page fault
process flow A-2, A-4
reclaim 5-102
trace examples 2-64
waits 4-9
page frame table entries
See PFTE
page stealing 5-101
page waits B-8
page/swap data set errors 5-127
paging
finding the LSID 5-121
incorrect pages 5-120
interlocks 5-119
process 5-101
unuseable data sets 5-125
paging requests
analysis 4-27
parallelism 2-46
PART/PAT bit
locating 5-123
pattern recognition 2-77
PC/AUTH services
control blocks 5-291
debugging hints 5-299
description 5-288
module structure 5-289
process flow 5-290
recovery cO'nsiderations 5-296
recovery data areas 5-297
SLIP traps 5-301
PCB (page control block)
important fields in 5-99
trace facility 5-111
use in debugging A-9
PCCA fields for CCH 5-267
PCCB major fields and flags 5-159
PCLINK services
debugging hints 5-304
description 5-302
module structure 5-304
STKE control block 5-302
PER activation/deactivation
debugging aids 5-240
process flow 5-230
recovery 5-240
PER monitoring 2-105
PER traps 2-127
performance degradation
chapter on 4-23
dump analysis area 4-24
operator commands to identify 4-23
PFTE (page frame table entries)
analysis 4-27

(

y~

important field~ 5-101
PGTE
RSM test on A-2
physically disabled mode 2-12
PLH (place holder) 5-152
post codes
LOGON A-33
Power Warning Feature Support
See PWF
PRB initialization 5-61
PRDMP
See AMDPRDMP
PRE-TMP exit A-31
PRINT statement (of PRDMP) 2-98
printer ERP 5-53
private libraries
module search sequence 5-69
problem analysis techniques 1~ 1
problem program dump debugging 2-86
process flows
chapter A-I
EXCP/IOS A-12
GETMAIN/FREEMAIN A-IS
page faults (RSM processing) A-2
TSO A-21
VTAM A-18
processor work area (PWA) 5-257
program call/authorization
See PC/AUTH services
program checks
interrupts 5-16
program manager
APF authorization 5-70
ATTACH 5-61
CDE
allocation 5-70
CDE pool control 5-72
component analysis 5-55
control blocks 5-55~ 5-57
DELETE 5-64
exit resource manager 5-64
FETCH/program manager work area 5-72
functional description 5-55
functional flow 5-60
IDENTIFY 5-65
LINK 5-60
LOAD 5-64
module description 5-56
module search sequence
for LINK~ ATT ACH~ XCTL~ LOAD 5-68
of private libraries 5-69
module subpools 5-71
organization 5-55
overview 5-57
queue validation 5-58
queues
description 5-55, 5-57
RB extended save area 5-72
SYNCH 5-65
system initialization 5-58

XCTL 5-61
306 abend 5-71
806 abend 5-66
PSA (prefixed save area)
contents' of important fields 2-4
indicators 2-13
used to determine current system state
using as a patch area 2-104
PSW (program status word)
analysis 2-3
wait state B-2
pushdown list end mark
maintaining 5-166
PW A work area 5-257
PWF (Power Warning Feature)
appendage footprint table 5-265
communications area 5-258
data areas 5-257
diagnostic aids 5-257
dump footprint table 5-265
LOGREC recording 5-266
return codes 5-257

2-2~

2-13

Q

QCBTRACE (AMDPRDMP option)
use for loop analysis 4-17
use for wait analysis 4-10
QCBTRACE statement (of PRDMP) 2-98
QTIP
processing A-24
queue scanning services
control block overview 5-3l6~ 5-317
introduction 5-305, 5-308
module flow 5-342
R

RB

(request,blo~k)

analysis 2-8
extended save area (RBEXSAVE) 5-72
manipulation by XCTL 5-63
new RB initialization for XCTL 5-62
RCB (recording control buffer) 2-38
RDCM (resident display control module) 5-246
real addresses
converting 5-108
real frame shortage
indicators 4-28
real storage manager
See RSM
reason codes
allocation 5-197
RSM5-105
started task control 2-93
SWA manager 2-94
reclaim (function of RSM) 5-102
record management

Index

X-9

debugging aids 5-153
processing 5-151
recovery audit trail (ASM) 5-136
recovery management support
See RMS
recovery procedures
output of lOS modules 5-34
recovery stack 2-13
recovery work areas
use of 2-33
register conventions
ASM 5-118
relate (function of RSM) 5-103
replies
lost 5-249
requesting
I/O (ASM) 5-114
swap I/O (ASM) 5-115
reset services
See stop/reset services
resource request processing
See global resource serialization
RESUME service
See SUSPEND/RESUME/TCTL services
retry process (RTM) 5-226
retry /restart
with ERPs 5-50
return codes
Service Processor Call SVC 5-279, 5-284
ring processing
control block overview 5-313
debugging hints 5-345
introduction 5-306
module flow 5-3~4, 5-325, 5-326, 5-327, 5-328,
5-329, 5-330
RMCT (SRM control table)
system indicators 5-143
RMS (recovery management support)
component analysis
diagnostic aids
CCH 5-256, 5-266
DDR 5-256, 5-268
MCH 5-256
MIH 5-256, 5-273
PWF 5-256, 5-257
RPL error fields 5-151
RSM (real storage manager)
abend reason codes 5-105
component analysis 5-97
debugging tips 5-107
major control blocks 5-97
page fault processing A-2
page stealing process 5-101
reclaim 5-102
recovery 5-104
relate 5-103
RTM (recovery termination manager)
cancel 5-227
component analysis 5-221
error id 5-232

X-I0

MVS Diagnostic Techniques

extended error" descriptor (EED) 5-222
FORCE command 5-228
functional description 5-221
hardware error processing 5-222
major RTM modules 5-221
PER processing 5-230
process flow 5-222
retry 5-226
RTMI 5-221
RTM2 5-221
SLIP command debugging aids 5-238
stack vector table 2-13
SVC dump debugging aids 5-233
system diagnostic work area (SDWA) 5-222
termination
abnormal task 5-225
address space 5-229
normal task 5-224
RTM2WA
definition 2-41

S

SALLOC lock
description 2-22, 2-26
with ASM 5-129
SCCB (service call control block) 5-284
SCHEDULE macro 2-11
scheduler work area
See SW A manager
SDUMP macro C-l
SDUMPs (see also SVC dumps)
analysis 3-4
how to change contents of 3-5
parameter list 3-5
titles C-l
SDWA (system diagnostic work area)
data recorded by dispatcher 5-15
use by SYSl.LOGREC 2-34
use in FRR stack 2-41
use in /RTM2 2-42
with SVC dump 5-234, 5-235
SDWAVRA (SDWA variable recording area)
entries $-90
error indjicato~s 5-91
key-length-data format 2-35
use by ASM 5-134
use by catalog management 5-167
sense command
with ERPs 5-52
serialization
ASM 5-129
service call control block (SCCB) 5-284
SERVICE CALL instruction
condition codes 5-287
description 5-283, 5-287
trace entry 2-64
Service Processor Architecture 5-283
Service Processor· Call SVC

abend codes 5~279,5-284
control blocks 5-280, 5-286
data block 5:278
description 5-277, 5-283
introduction 5-277, 5-283
processing 5-279, 5-285
return codes 5-279, 5..;284
trace entry 2-64
with ACR 2-76
with MSSFCALL DIAGNOSE instruction
with SERVICE CALL instruction 5-283
signal request (ENF)
description 5-212
example 5-218
exit routine 5-214
SIGP (signal processor) instruction
description 2-49
return codes 2-50
XC function 2-49
SLIP command
ACTION keyword 2-112
control blocks 5-242
controlling traps 2-125
debugging aids 5-238
description 2-105
designing an effective trap 2-125
dump tailoring 2-117
event qualifiers 2-105
examples 2-118
examples with TSO 2-124
PER monitoring 2-105
placement of PER traps 2-127
,processor recovery 5-239
summary 2-129
trap design 2-125
using 2-105
with checkpoint/restart 2-128
SLIP processor
PER activation/deactivation 5-240
recovery 5-239
slot number
converting to full seek address 5-124
SMF suspension 2-19
software-detected errors
analysis 3-7
SPCT (swap control table)
important fields in 5-100
special exits
dispatching 5-4
spin locks
definition 2-22
SRB (see also local and global SRBs)
dispatching queues 2-5, 5-5
local 5-7
mode 2-11
mode interruptions 2-15
suspension 2-8, 2-17, 2-27
tests made by dispatcher 5-13
SRB/SSRB pool manager
description 5-17

5-277

entry points 5-17
error conditions 5-: 19
recovery considerations 5-18
SRM (system resources manager)
address space states 5-142
component analysis 5-141
control blocks 5-145
entry point summaries 5-149
error recovery 5-148
indicators 5-143
objectives 5-141
SDWA data 5-149
system (RMCT) indicators 5-143
user (OUCB) indicators 5-147
SSB (SMF suspend block) 2-19
SSI (subsystem interface)
component analysis 5-202
debugging hints 5-211
function codes 5-211
initialization processing 5-202
logic flow examples 5-208
major control blocks 5-203
requesting services 5-206
return codes 5-208
subsystem
allocation sequence table 5-202
communications vector table (SSCVT) 5-202
vector table (SSVT) 5-202
stand-alone dump
analysis 2-2
analysis procedure B-6
chapter on 3-2
description B-1
determining system mode from 2-13
flowchart B-5
how to print 2-97
special notes 2-2
started task control
See STC
status information
locating in storage dump 2-15
STC (started task control)
abend codes 2-93
reason codes 2-93
step initiation/termination 5-86
STKE control block 5-302
stop/reset services
description 5-19
entry points 5-19
error conditions 5-21
recovery considerations 5-20
storage management (global resource serialization)
control block overview 5-318
debugging hints 5-348
introduction' 5-308
SUBMIT command processor A-42
subpools for modules 5-71
subsystem interface
See SSI orFSI
SUM DUMP output 2-89

Index

X-II

SUMDUMP statement (of PRDMP) 2·98
summary dump 2·89
SUMMARY statement (of PRDMP) 2·98
super bits
See PSASUPER
supervisor control 5·2
superzaps
system stop routine 2·133
to expand trace table 2·133
suspend locks
definition 2·22
SUSPEND/RESUME/TCTL services
description 5·22
entry points 5·22
error conditions 5·24
recovery considerations 5·23
suspended
locally locked tasks 2·17
SRB status 2·8
SRB/task with lock ,held B·13
tasks or address space caused by unsatisfied ENQ
request 4·10
suspension
SMF 2·19
SVC D entries in trace table 2· 70
SVC dump title directory C·l
SVC dumps
analysis 3·4
caller·defined titles C·82
debugging of
control blocks, use of 5·237
SLIP traps, use in 5·234
SYSl.LOGREC, use in 5-234
entry points
error conditions 5~234
how to override parameters 2-99
module cross reference C-85
operator-defined titles C-82
resource cleanup 5-238
SDUMP macro BRANCH = parameter
system-defined titles C-2
titles C-l
without titles C-83
SVC 122 5-277, 5-283
SWA (scheduler work area) manager
reason codes 2-94
swap transition flags 5-142
swap-in process A-7
swap-out process A-9, A-1O
swapping
process flow A-7
SWIN (lEVSWIN) A-7
sympton analysis approach 4-1
SYNCH (function of program manager) 5-65
SYSABENDs
analysis approach 3-7
SYSMDUMPs
analysis approach 3-7
system degradation
See performance degradation

X -12

MVS Diagnostic Techniques

system diagnostic work area
See SDWA
system execution modes and status saving 2-10
system hung
See waits
system modes
determining from stand-alone dump 2-13
locked mode 2-13
physically disabled mode 2-12
SRB mode 2..11
task mode 2-10
system opt,ions for SVC dump 2-99
system resources manager
See SRM
system stop routine 2-133
system-defined SVC dump titles C-2
SYSUDUMPs
analysis approach 3-7
SYSZECI6-PURGE 4-12
SYSZVARY-x 4-12
SYSI.COMWRITE data set
how to print 2-103
SYS1.DUMP
how to clear without printing 2-102
how to print 2-101
SYS1.LOGREC
See LOGREC
SYS1.STGINDEX
how to recreate 2-103
SYSI.UADS
how to rebuild 2-100

T

tape ERP 5-53
task
analysis 2-7
locally locked interrupted 2-13
locally locked suspended 2-17, 2-25, 2-27, 4-9
mode indicators set by dispatcher 5-15
mode interruptions 2-15
RB structure 2-8
tests made by dispatcher 5-13
task mode
description 2-10
TCAM
organization after a TSO logon A-26
TIOC logon processing A-27
traces 4-22
TSO terminal I/O diagnostic techniques A-45
TCB (task control block)
analysis 2-7
dispatching priority in address space 5-8
summary report 2-5
suspended with lock held B-6
with global resource serialization 5-311
TCTL services
See SUSPENDjRESUME/TCTL services
TDCM (pageable display control module) 5-246

v

teleprocessing
See TP
timer value in trace table 2-69
TMPIcommand processor
interface A-37
work area A-39
TP (teleprocessing)
typical problems 4-20
TP traces (see also trace table)
types of 4-21
trace entry
Service Processor Call SVC 2-64
trace table
cautionary notes 2-69
how to expand 2-133
how to locate 2-61
master trace 2-72
traps
SLIP command 2-105
types of entries 2-63
with DIDOCS 5-252
traces (see also trace table)
analysis of 2-61
events not traced 2-70
examples 2-64
interpreting 2-66
master trace 2-71
PCB facility 5-111
summary of 4-21
summary of TP traces 4-21
unit exception on 3705 2-70
TSO (time sharing option)
APAR documentation A-48
attention processing A-46
command processor recovery A-41
line drop processing A-34, A-35
overview of logon processing A-22
process flow A-21
terminal I/O flow A-42
time sharing initialization A-21
TSO/TIOC terminal I/O diagnostic
techniques A-45

VARY GRS command
introduction 5-305, 5-306
PURGE module flow 5-332
QUIESCE module flow 5-333, 5-334
RESTART module flow 5-335, 5-336, 5-337
virtual addresses
converting 5-108
virtual fetch
control blocks 5-78
debugging hints 5-80
description 5-74
functional flow 5-75
module organization 5-74
recovery processing 5-79
virtual storage access method
See VSAM
virtual storage manager
See VSM
virtual telecommunications access method
See VTAM
volume mount and verify 5-176, 5-195
VSAM (virtual storage access method)
component analysis 5-151
debugging aids 5-153
error codes 5-154, 5-155
I/O manager debugging 5-157
O/C/EOV debugging aids 5-155
O/C/EOV messages 5-155
record management
buffer control block (BUFC) 5-152
request parameter list (RPL) 5-151
VSM (virtual storage manager)
address space initialization 5-84
allocation 5-87
basic functions 5-82
cell pool management 5-92
control block usage 5-85
debugging hints 5-92
GETMAIN/FREEMAIN process flow A-I5
global data areas (GDA) 5-89
step initialization/termination 5-86
view of MVS storage 5-83
VT AM (virtual telecommunications access method)
note to readers 5-150
process flow A-18
traces 4-22

U

UCB
analysis for enabled waits 4-9
UCM (unit control module) 5-246
UCME (UCM entry) 5-246
unallocation
description 5-173
unit allocation status recording
control blocks 5-181
debugging hints 5-183
description 5-180
recovery considerations 5-183
unit check
with ERPs 5-52
use of recovery work areas for problem analysis

w
wait address space 5-9
waits
chapter on 4-2
disabled
analysis approach 4-3
;haracteristics of 4-2
2-33

Index

X-I3

locked console exception 4-3
with communications task 5-249
enabled
analysis approach 4--5
analysis via trace table 2-69
characteristics of 4-4
with communications task 5-248
with global resource serialization 5-343
enabled loop exception 4-17
explicit 2-7, B-8
in user code B-18
indications of paging interlocks 5-119
no-work wait 4-7
OUCB analysis 5-147
page fault waits 4-9
page waits B-8
wait state PSW B-2
window spin 2-52
work queues
TCBs
address space analysis 2-5
WQE control block 5-246

description 5-61
module search sequence 5-68
RB manipulation 5;.63
XDBA (EXCP debugging area) 5-33
XPTE
RSM test on A-2

z
zaps
See superzaps

o
080 abend in allocation 5-194
OC4 abend in allocation 5-195
08x abends in ASM 5-132

3

306 abend in program manager 5-71

x
XC (SIGP external call)
definition 2-49
process flow 2-55
XCTL (function of program manager)

X -14

MVS Diagnostic Techniques

8

806 abend in program manager

5-66

--... --

--.-.

--

~

l~r.n: /Technical Newsletter

This Newsletter No.
Date
Base Publication No.
File No.
Prerequisite Newsletters/
Supplements

SN28-5095
December 27, 1985
SY28-1133-2
S370-37
None

MVS Diagnostic Techniques
©Copyright IBM Corp. 1981, 1985
MVS/System Product - JES3, Program No. 5665-291
MVS/System Product - JES2, Program No. 5740-XC6
This Technical Newsletter contains replacement pages for MVS Diagnostic Techniques in support of
MVS/System Product Version I Release 3.6.
Before inserting any of the attached pages into MVS Diagnostic Techniques, read carefully the
instructions on this cover. They indicate when and how you should insert pages.
Pages to
be Removed

Attached Pages
to be Inserted *

Cover - Edition Notice
vii - viii
xxv - xxvi
5-303 - 5-304
C-3 - C-4
C-33 - C-34
C-81 - C-82
C-85 - C-86

Cover - Edition Notice
vii - viii
xxv - xxvi
5-303 - 5-304
C-3 - C-4
C-33 - C-34
C-81 - C-82
C-85 - C-86

*If you are inserting pages from different Newsletters/Supplements and identical page numbers are
involved, always use the page with the latest date (shown in the slug at the top of the page). The page
with the latest date contains the most complete information.
A change to the text or to an illustration is indicated by a vertical line to the left of the change.
Summary of Amendments
This Technical Newsletter contains updates in support of Version 1 Release 3.6 of MVS/System Product
and several technical corrections.

Note: Please file this cover letter at the back of the publication to provide a record of changes.

IBM Corporation, Information Development, Dept. 058, Building 921-2,
P.O. Box 390, Poughkeepsie, New York 12602

©Copyright IBM Corp. 1985
©Copyright IBM Corp. 1985

Printed in U.S.A.

MVSDiagnostic Techniques

READER'S
COMMENT
FORM

SY28-1133-2

This mariual is part of a library that serves as a reference source for systems analysts, progralD.l1}ers,
and operators of IBM systems. You may use this form to communicate your comments about this
publication, its organization, or subject matter, with the understanding that IBM may use or distribute
whafeverinformation you supply in any way it believes appropriate without incurring any obligation to
you.
Note: Copies of IBM publications are not stocked at the location to which this form is addressed. Please
direct any requests for copies of publications, or for assistance in using your IBM system, to your IBM
representati,e or to the IBM branch office serring your locality.
Possible topics for comment are:
Clarity

Accuracy

Completeness

Organization

Coding

Retrieval

Legibility

If you wish a reply, give your name, company, mailing address, and date:
;~
!';;

i.:C
.....

h5
"
"III
:; ....
~

: 0

58.

~.s

~]

- E
~ E
"':::I

010'

3~

I::

::i
0'

;,.£:

I::
0

§~

;(

::10
iI:"

n.~
E~

"0

~

II(/)

L-

Q"

:I
(.)

-I::

E!(/)

o.~

0

11:::1

111111

:::I(/)

8~

1::"
c(/)
0:::1

~~
o.c

ceo

iiii:

N
0
z

What is your occupation?
How do you use this publication?
Number of latest Newsletter associated with this publication:
Thank you for your cooperation. No postage stamp necessary if mailed in the U.S.A. (Elsewhere, an
IBM office or representative will be happy to forward your comments or you may mail directly to the
address in the Edition Notice on the back of the title page.)

MVS Diagnostic Techniques
SY28-1133-2

5370-37

Reader's Comment Form
'I

o
....

i

Fold and tape

Please Do Not Staple

Fold and tape

!

----------------~--------------------------------------------------------------------------------------------------------------------1

NO POSTAGE
NECESSARY
IF MAILED
IN THE
UNITED STATES

III" I
BUSINESS REPLY MAIL
FIRST CLASS

PERMIT NO. 40

ARMONK, N.Y.

POSTAGE WILL BE PAID BY ADDRESSEE

International Business Machines Corporation
Department 058, Building 921 -2
PO Box 390
Poughkeepsie, New York 12602
Fold and tape

Please Do Not Staple

Fold and tape

----....
-------..-------------.....,.. -.

Printed in U.S.A.

.-

-..

- - - -..,.-®

SY28-1133-02

MVS Diagnostic Techniques
SY28-1133-2

S370-37

------- --- -------

Printed in U.S.A.

-~--

-.

=~=~=®
Source Exif Data: 
File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.3
Linearized                      : No
XMP Toolkit                     : Adobe XMP Core 4.2.1-c043 52.372728, 2009/01/18-15:56:37
Create Date                     : 2014:07:02 09:21:37-08:00
Modify Date                     : 2014:07:02 08:54:38-07:00
Metadata Date                   : 2014:07:02 08:54:38-07:00
Producer                        : Adobe Acrobat 9.55 Paper Capture Plug-in
Format                          : application/pdf
Document ID                     : uuid:02705ff5-1a2e-e341-bb01-41530e46194a
Instance ID                     : uuid:0b015ad0-9c55-8f49-82f4-4f5af32aea94
Page Layout                     : SinglePage
Page Mode                       : UseNone
Page Count                      : 746
EXIF Metadata provided by EXIF.tools

Navigation menu