SY28 0764 0_OS_VS2_System_Logic_Library_Vol_4_Rel_3.7_Jul76 0 OS VS2 System Logic Library Vol 4 Rel 3.7 Jul76
User Manual: SY28-0764-0_OS_VS2_System_Logic_Library_Vol_4_Rel_3.7_Jul76
Open the PDF directly: View PDF 
.
Page Count: 534
| Download | |
| Open PDF In Browser | View PDF |
5Y28-0764.;O
File No. 5370-36
Systems
OS!VS2
System Logic Library
Volume 4
VS2.03.805
VS2.03.807
Pages numbered as duplicates in this publication must be retained because
each of these documents information specific to individual Selectable Units.
This minor revision incorporates the following Selectable Units:
Supervisor Performance # 1
Supervisor Performance #2
VS2.03.805
VS2.03.807
The selectable unit to which the information applies, is noted in the upper corner of the page.
First Edition (July, 1976)
This is a reprint of SY28-0716-0 incorporating changes released in the following
Selectable Unit Newsletters:
SN28-2687
SN28-2693
(dated May 28, 1976)
(dated May 28,1976)
This edition applies to Release 3.7 of OS/VS2 and to all subsequent releases of OS/VS2 until
otherwi.';e indicated in new editions or Technical Newsletters. Changes are continually made to .
the information herein; before using this publication in connection with the operation of IBM
systems, consult the latest IBM System/370 Bibliography, GC20-o00l, for the editions that are
applicable and current.
Requests for copies of IBM publications should be made to your IBM representative or to the
IBM branch office serving your locality.
A form for readers' comments is provided at the back of this publication. If the form has been
removed, comments may be addressed to IBM Corporation, J.>ublications Development,
Department 058, Building 706-2, PO Box 390, Poughkeepsie, N.Y. 12602. Comments become
the property of IBM.
©Copyright International Business Machines Corporat.ion 1976
Preface
System Logic Library comprises seven volumes.
Following is the content and order number for each
volume.
OS /VS2 System Logic Library,
Volume 1 contents: SY28-0713
MVS logic introduction
Abbreviation list
Index for all volumes
Volume 2 contents: SY28-0714
Method of Operation diagrams for
Communications Task
Command Processing
Region Control Task (RCT)
Started Task Control (STC)
LOGON Scheduling
Volume 3 contents: SY28.;.0715
Method of Operation diagrams for
System Resources Manager (SRM)
System Activity Measurement Activity (MF /1 )
JOB Scheduling
-Subsystem Interface
-Master Subsystem
-Initiator /Terminator
-SWA Create Interface
-Converter /Interpreter
-SWA Manager
-Allocation/Unallocation
-System Management Facilities (SMF)
-System Log
-Checkpoint/Restart
Volume 4 contents: SY28-0716
Method of Operation diagrams for
Timer Supervision
Supervisor Control
Task Management
Program Management
Recovery /Termination Management (R/TM)
Volume 5 contents: SY28-0717
Method of Operation diagrams for
Real Storage Management (RSM)
Virtual Storage Management (VSM)
Auxiliary Storage Management (ASM)
Volume 6 contents: SY28-0718
Program Organization
Volume 7 contents: SY28-0719
Directory
Data Areas
Diagnostic Aids
Please note that if you use only one order
number, you will only receive that volume. To
receive all seven volumes, you must either use all
seven form numbers or, simply the following
number: SBOF-8210. If you use SBOF-8210, you
will receive all seven volumes.
The publication is intended for persons who are
debugging or modifying the system. For general
information about the use of the MVS system, refer
to the publication Introduction to OS / VS Release
2, GC28-0661.
How This Publication is Organized
This publication contains six chapters. Following! is
a synopsis of the information in each section:
• Introduction and Master Index - an
overview of each of the functions this
publication documents, an abbreviation list of
all acronyms used in the publication, and a
complete index for all seven volumes.
• Method of Operation - a functional
approach to each of the subcomponents, using
both diagrams and text. Each subcomponent
begins with an introduction; all the diagrams
and text applying to that subcomponent
follow.
• Program Organization - a description of
module-to-module flow for each
subcomponent; a description of each module's
function, including entry and exit. The
module-to-module flow is ordered by
subcomponent. The module descriptions are
in alphabetic order without regard to
subcomponent.
• Directory - a cross-reference from names in
the various subcomponents to their place in
the source code and in the publication.
• Data Areas - a description of the major
data areas used by the subcomponents (only
those, however, that are not described in
OS / VS Data Areas, SYB8-0606, which is
on microfiche); a data area usage table,
showing whether a module reads or updates a
data area; a control block overview diagram
for each subcomponent, showing the various
pointer schemes for the control blocks
applicable to each subcomponent; a table
detailing data area acronyms, mapping- macro
instructions, common names, and symbol
usage table.
Preface 3
• Diagnostic Aids - the messages issued,
including the modules that issue, detect? and
contain the message; register usage; return
codes; wait state codes; and miscellaneous
aids.
4
OS/VSl System: Logic Libnry:Volumc 4 (VSl Release 3..7)
Corequisite Reading
The following publications are corequisites:
• OS/VS2 JES2 Logic, SY2S-0622
• OS/VS Data Areas, SYBS-0606 (This
document is on microfiche.)
• OS/VS2 Syslem Initialization Logic,
SY2S-0623
Contents
Section 2: Method of Operation . . . . . . . .
Timer Supervision
............ .
Method-of-Operation Diagrams . . . . . .
18-1. TIME Service Routine (lEAVRTOl)
18-2. STIMER Service Routine (IEAVRTOO)
18-3. TTIMER Service Routine (lEAVRTOO)
18-3A. SETDIE Routine (lEAVRT02) (VS2.03.807)
18-4. TQE Enqueue Routine (lEAVRTIO)
18-5. TQE Dequeue Routine (lEAVRTIO) . . . .
18-6. TQE Purge Routine (lEAVRTIl) . . . . .
18-7. Timer Second Level Interrupt Handler (IEAVRTIO)
18-8. Set Clock Comparator Routine (lEAVRTIO)
18-9. TQE Processing Routine (lEAVRTIO) . . . . .
18-10. Timer Functional Recovery Routine (lEA VR TI 1)
18-11. Set Specific Clock (SSC) Routine (lEAVRTOD)
18-12. TOD Clock Operator Communication Routine (IEAVRTOD)
18-13. TOD Clock Synchronization Routine (lEAVRTOD)
18-14. TOD Clock Status Test Routine (lEAVRTOD)
18-15. Synchronous Timer Recovery Routine (lEAVRTI1)
18-16. Asynchronous Timer Recovery Routine (lEAVRTOD)
Supervisor Control
Service Manager . . . . . . . . . .
Dispatching Work . . . . . . . . .
Handling Interruptions . . . . . . .
Interprocessor Communications (lPC)
Scheduling Exit Rout.ines . .
Serializing System Resources
Supervisor Control Recovery
Validity Checking . . . . .
Method-of-Operation Diagrams
19-1. Dispatcher (lEAVED SO)
19-2. GloBal SRB Dispatcher (lEAVED SO)
19-3. Local SRB Dispatcher (lEAVED SO)
19-4. Local Supervisor Dispatcher .(lEAVEDSO)
19-5. Task Dispatcher (lEAVED SO) . . . . .
19-6. Wait Task Dispatcher (lEAVED SO)
19-7. Memory Switch (lEAVEMSO) . - . . . .
19-8. SVC Interruption Handler (lEA VESVC)
19-9. I/O Interruption Handler (IEAVEIO)
19-10. External First Level Interruption Handler (IEAVEEXT)
19-11. Program Check Interruption Handler (PC IH) (lEA VEPC)
19-12. Restart Interruption Handler (lEAVERES)
........ .
19-13. Signal Service Routines (lpe) (lEA VERI, lEA VERP, IEAVEDR)
19-14. External Call Second Level Interruption Handler (lEAVEXS) . .
19-15. Emergency Signal Second Level Interruption Handler (lEA VEES)
19-16. Stage 1 Exit Effector (lEA VEFOO)
19-17. Stage 2 Exit Effector (lEA VEEE2)
19-18. Stage 3 Exit Effector (lEA VEEEO)
19-19. SCHEDULE Processing (lEAVES CO)
19-20. PURGEDQ Processing (lEA VEPDO)
19-21. SETLOCK Processing (lEA VELK)
19-22. Validity Check Processing (lEA VEV AL)
19-23. ASCBCHAP Processing (lEA VEACO)
19-24. Trace Processing (lEA VTRCE) . . . .
19-25. Queue Verification (lEAVEQVO) . . .
19-26. Super FRR (lEA VESPR)
......
. .
19-27. Address Space/Lock Verification Processing (IEAVELCR)
19-28. Suspend Routine (lEA VETCL) (VS2.03.807)
19-29. Transfer Control-Transfer Logical (TCTL)
(lEA VETCL) (VS2.03.807)
...... .
19-30. Resume Routine (lEA VETCL) (VS2.03.807)
Task Management
...... .
Creating and Deleting Subtasks
Controlling Task Execution . .
Direct Control of Tasks
Indirect Control of Tasks
Providing Informational Services
4-1
4-3
4-6
4-6
4-8
4-10
· 4-11
· 4-12
· 4-14
· 4-16
· 4-18
· 4-20
· 4-22
· 4-24
· 4-26
· 4-30
· 4-32
· 4-34
· 4-36
· 4-38
· 4-41
· 4-42
· 4-43
.4-44
.4-44
· 4-46
· 4-58
· 4-58
· 4-59
· 4-54
· 4-54
.4-72
· 4-74
· 4-76
· 4-78
· 4-82
· 4-84
· 4-86
, 4-94
· 4-98
4-104
4-116
4-120
4-126
4-128
4-130
4-132
4-134
4-138
4-144
4-148
4-162
4-164
4-168
4-170
4-172
4-176
4-191.0
4-191.2
4-191.6
4-193
4-193
4-196
4-196
4-196
4-196
Contents 5
Method-of-Operation Diagrams . . . . . .
20-1. ATTACH Processing (lEAVEATO)
20-2. DETACH Processing (lEA VEEDO)
20-3. CHAP Routine (lEAVECHO) . .
20-4. WAIT Processing (lEAVSY50)
20-5. POST Processing (lEAVSY50)
20-6. EVENTS Processing (lEA VEVTO) .
20-7. ENQ/Reserve Processing (lEAVENQ 1)
20-8. DEQ Processing (lEAVENQ1)
20-9. ENQ/DEQ/Reserve Recovery (lEAVENQ1)
20-10. SPIE Processing (lEAVTBOO)
20-11. EXTRACT Processing (lEAVTBOO)
20-12. EXIT Processing (lEA VEOR)
20-13. EXIT Prolog Processing (lEAVEEXP)
20-14. STATUS Processing (lEA VSETS)
20-15. MODESET Processing (lEAVMODE)
20-16. TESTAUTH Processing (lEAVTEST)
Program Management . . . . . . . . .
Searching For and Scheduling Modules
JP A Storage Areas . . . .
LP A Storage Areas . . . . .
Auxiliary Storage Libraries
Synchronizing Exit Routines
Fetching Modules into Storage
Method-of-Operation Diagrams
21-1. LINK Routine (lEAVLKOO)
21-2. Routing to Searching Routines (lEAVLK01)
21-3. Searching the LPA Directory (lEAVLKOO) .
21-4. BLDL/Program Fetch Interface (lEAVLKOl)
21-5. SYNCH Routine (lEAVLKOO) . .
21-6. LOAD Routine (lEAVLKOO)
21-7. DELETE Routine (lEAVLKOO) . . . . . .
21-8. IDENTIFY Routine (lEAVIDOO) . . . . .
21-9. XCTL Routine (lEAVLKOO) . . . . . . .
21-10. Overlay Supervisor (lEWSUOVR, IEWSWOVR)
21-11. Program Fetch (lEWFETCH)
Recovery/Termination Management (R/TM)
RTM 1 Functions . . . . .
.
SLIH Mode Processing
Service Mode Processing
Hardware Error Mode .
RTM2 Functions . . . . .
Normal Termination
Abnormal Termination
Address Space Termination . . . . . . . . . . . .
Recovery/Termination Management Support Functions
STA Services . . . . . . . . .
Alternate CPU Recovery (ACR)
SETFRR . . . . . . . . . . .
Initializing FRR Stacks
Dumping . . . . . . . . . . .
Formatted Dump-SNAP Dump
Unformatted Dump-SVC Dump
CHNGDUMP Operator Command
Recording Services . . . . . . .
Method-of-Operation Diagrams
22-1. RTM 1 Overview (lEA VTRTM)
22-2. RTMI Initialization (lEAVTRTl)
22-3. Process Hardware Error (lEAVTRT2)
22-4. Processing SLIH Requests (lEA VTRTM)
22-5. Routing to FRRs (lEAVTRTS)
22-6. RTM 1 Recursion Processing (lEA VTRTR)
22-7. Reschedule RTMI (lEAVTRTM)
22-8. System-Directed Task Termination (lEAVTRTM)
22-9. Reschedule Locally Locked Task or SRB (lEAVTRTM)
22-10. RTMI Clean-up Processing (lEAVTRTM)
22-11. RTMI Exit Processing (lEAVTRTl)
22-12. RTM2 Overview (lEAVTRT2) . . .
22-13. RTM2 Initialization (lEA VTRT2)
22-14. Recursion Processor 1 (lEAVTRT2)
22-15. Recursion Processor 2 (lEAVTRTE)
6
OS/VS2 System Logic Library Volume 4 (VS2.03.807)
4-198
4-198
4-206
4-214
4-220
4-222
4-234
4-242
4-246
4-248
4-250
4-254
4-256
4-258
4-260
4-268
4-270
4-273
4-273
4-273
4-275
4-275
4-275
4-275
4-278
4-278
4-284
4-286
4-288
4-290
4-292
4-294
4-296
4-300
4-306
4-308
4-319
4-319
4-319
4-319
4-320
4-320
4-320
4-320
4-nl
4-321
4-322
4-322
4-322
4-322
4-322
4-322
4-323
4-323
4-323
4-342
4-342
4-344
4-348
4-352
4-354
4-362
4-366
4-370
4-372
4-374
4-376
4-378
4-382
4-384
4-386
22-16.
22-17.
22-18.
22-19.
22-20.
22-21.
22-22.
22-23.
22-24.
22-25.
22-26.
22-27.
22-28.
22-29.
22-30.
22-31.
22-32.
22-33.
22-34.
Inde1(
Recover Task Processing (lEAVT AS 1)
ABDUMP Processing (lEAVTABD)
.
Synchronize Failing Tasks (lEAVTRTC)
.
Task Purge Processing (lEAVTSKT)
Task Purge Resource Managers (lEAVTSKT)
Addres~ Space Purge Processing (lEA VTMMT)
.
Address Space Purge Resource Managers (lEAVTMMT)
RTM2 Exit Processing (lEAVTRTE) . . . . . . . . .
Address Space Termination Processing (lEAVTMTC)
.
STAE/EST AE Processing (lEA VST AO) . . . . .. . . .
Alternate CPU Recovery (ACR) Overview (lEAVT ACR)
FRR Stack Initialization (lEAVTSIN)
SETFRR (SETFRR) . . . . . . . .
SVC 51 Overview (lEAVADOO)
SNAP Dump Processing (lEAVAD 1)
SVC Dump Processing (lEA VADOO) .
Schedule Dump Processing (lEAVTSDX)
CHNGDUMP (lEEMB815)
Recor4ing Processing (lEAVTRER)
4-388
4-392
4-396
4-398
4-402
4-408
4-410
4-420
4-426
4-430
4-436
4-440
4-442
4-444
4-446
4-452
4-458
4-462
4-466
.
1-1
Contents 7
Figures
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
8
2-32
2..;33
2'-34
2-35
2-36
2-37
2'-38
2.;.39
2-40
2-41
2-42
2-46
2-47
2-48
2-49
2-50
2-51
2-52
2-53
2-54
2-55
Timer Supervision Visual Contents . . . •.
SRB Scheduling Pointer Structure . . . . .
Asynchronous Exit Effector Data Structure .
Supervisor Control Recovery Data Structure
Supervisor Control Visual Contents
....
The TCB Ready Queue . . . . . . . . . .
The TCB Family Queue '.' . . • . . . . .
Task Management Visual Contents ... . . . .
STATUS-Action Codes and Fields They Change
Control Blocks for Modules in the JPA
Program Management Visual Contents .
Page I/O Error Processing . . . . . .
Hardware Error Processing . . . . . .
The Process of Normal Task Termination
Abnormal End-of-Task
Retry . . . . . . . . . . . . . . . .
Cancel
............... .
The Process of Terminating an Address Space
ABEND/SNAP Dump Processing . . . . .
SVC Dump Overview . . . . . . • . . . . .
Recovery/Termination Management Visual Contents
OS/VS2 System Logic Library Volume 4 (VS2.03.807)
• 4-4
· 4-42
· 4-47
· 4-50
· 4-51
4-194
4-195
4-197
4-265
4-274
4-277
4-324
4-326
4-328
4-330
4-331
4-332
4-333
4-335
4-336
4-339
Section 2: Method of Operation
This section uses diagrams and text to describe the
functions performed by the scheduler, supervisor,
MF /1, SRM, and ASM functions of the OS/VS2
operating system. Tl1e diagrams emphasize
functions performed rather than the program logic
and organization. Logic and organization is
described in "Section 3: Program Organization."
The method-of-operation diagrams are arranged
by subcomponent as follows:
• Communications Task.
• Command Processing (includes
Reconfiguration Commands).
• Region Control Task (RCT).
• Started Task Control (STC) (includes
ST ART/LOGON/MOUNT).
• LOGON Scheduling
• System Resources Manager
• System Activity Measurement Facility
(MF/l)
• Job Scheduling:
- Subsystem Interface.
- Master Subsystem.
- Initiator/Terminator.
- SW A Create Interface.
- Converter /Interpreter.
- SW A Manager.
- Allocation/Unallocation.
- System Management Facilities (SMF).
- System Log.
- Checkpoint/Restart.
• Timer Supervision.
• Supervisor Control.
• Task Manageme,nt.
• Program Management.
•
•
•
•
Recovery/Termination Management (R/TM).
Real Storage Management (RSM).
Virtual Storage Management (VSM).
Auxiliary Storage Management (ASM).
The diagrams for each subcomponent are
preceded by an introduction that summarizes the
subcomponent's function. Following each
introduction is a visual table of contents that
displays the organization and hierarchy of the
diagrams for that subcomponent.
The diagrams cross-reference each other using
diagram numbers and module names. As an aid in
locating the diagrams that are cross-referenced, an
alphabetic list of all diagram names and their
corresponding page numbers follows this
introduction.
Method-of -operation diagrams are arranged in
an input-processing.,.output format: the left side of
the diagram contains data that serves as input to
the processing steps in the center of the diagram,
and the right side contains the data that is output
from the processing steps. Each processing step is
numbered; the number corresponds to an amplified
explanation of the step in the "Extended
Description" area. The object module name and
labels in the extended description point to the code
that performs the function.
Note: The relative size and the order of fields
within input and output data areas do not always
represent the actual size and format of the data
area.
)
Section 2: Method of Operation
am;:
4.1
iT;
A';:
",dd
AQX
. . Primary pro.... lng - Indicates major functionaillow .
• • •_~ Secondary processing ~ indicates fUhctional flow within Ii diagram.
'--_--.>
Data movement, modifldltion, Ot' use.
- - .... Data reference - indicates the testing Ot' reading of a data area to
determine the course of SUbsequent processing.
- -........~ Pointer - indicates that a data area contains the address of another
data area.
(
~
--D
Indirect pointer - indicates Intermediate pointers haVe been omitted.
Connector - indicates that a diagram Is continued on the next page.
Figure 2·1. Key to Symbols Used in Method-of·Operation Diagrams
4·2
OS/VS2System Logic Library Volume 4 (VS2 Release 3.7)
VS2.03.807
Timer Supervision
The timer supervision routines support the
System/370 time-of-day clock, clock comparator,
and CPU timer. The routines use these components
to obtain the time of day and the date, schedule
activity after a specified interval, and schedule
activity after a specified time of day. Other timer
routines set the time-of-day clock and synchronize
the TOO clocks in a multiprocessing system.
For TIME macro instructions, the TIME routine
returns the date and time of day to the requester.
For STIMER macro instructions, the STIMER
routine sets a requested time interval that expires
after the specified time has elapsed or at the
specified time of day. When the requested time
interval expires, a timer or clock comparator
interruption occurs and the Timer Second Level
Interruption Handler processes it. If the requester
specifies the task timing option, the time interval is
decreased only when the requester's task is active.
If the requester specifies wait timing, his task is
placed in a wait state until the time interval
expires. If the requester specifies real timing, the
time interval is decreased continuously.
For TTIMER requests, the TTl MER routine
returns the amount of time remaining in an interval
previously set by a STIMER macro instruction. The
routine can also cancel the remaining time interval
if so requested.
Timer supervision also provides a SETDIE
routine that allows system programs (programs
executing in supervisor state and with a protect key
of 0) to specify a real time interval, after which a
disabled interrupt exit (DIE) is to be given control.
With SETDIE, the system program supplies timer
supervision with a pre-built TQE. When the timer
SLIH processes such a TQE (called a DIE TQE), it
gives control directly to the specified exit routine
(DIE).
Timer supervision maintains two queues of TQES
(timer queue elements): one for task timing
._.
requests, pointed to from the TCB of the reqeusting
task and containing only one TQE at a time; and,
one for real and wait timing requests, pointed to
from the TPC (timer work area) and containing all
real wait type TQES in the system. TQES (other
than a DIE TQE) are constructed by the STIMER
routine, and each element represents a request for
a timed interval. Each new TQE is placed on the
appropriate queue in the order in which the
requested interval expires. When an interval
expires, a timer interruption occurs. The Timer
Second Level Interruption Handler removes the top
TQE from the appropriate queue and determines
what action to take.
Other timer routines pro~ide for the initialization
of the TOO clock at IPL (see OS/VS2 System
Initialization Logic, SY28-0623) and when a CPU
is being varied online, and the resetting or
resynchronizing of a TOO clock that has suffered a
machine check.
In either case, the Set Specific Clock routine
searches for a TOO clock in the system to which
the new or error TOO clock in the system to which
the new or error TOO clock can be synchronized. If
one is found, the synchronization is done and the
results are validated. If no other valid TOO clock is
found, a routine is entered that ensures that the
TOO clock will be set with the correct value.
A set of service routines provide common
services to the timer supervision functions. TQE
Enqueue and TQE Dequeue provide for the
movement of TQES to or from the timing queues.
TQE Purge purges all timer TQES and SRBs during
task termination. An FRR and two hardware
recovery routines are also included.
Section 2: Method of Operation 4-3
~
~
Timing
Services
Overview(no diagram)
o
{I)
~.N
{I)
I
.t"'"
~.
t"'"
~
~
~
~
(D
18,1
18-2
TIME
Service
Routine
(lEAVRT01)
STiMER
Service
Routine
(IEAVRTOO)
L18-3
L18-6 1
I 18-10
18-7
I
Timer
TTIMER
Service
Routine
(IEAVRTOO)
TOE Purge
Routine
(lEAVRTI1)
~
I
Timer
Functional
Recovery
Routine
(I EAVRTI 11
Second Level
Interrupt
Handler Routine
(lEAVRTlO)
<:
{I)
~
<:>
~N
c..J
00
o
c..J
00
~
18-8
TOE Enqueue
Routine
(lEAVRTIO)
Set Clock
Comparator
Routine
(lEAVRTlO)
TOE Dequeue
Routine
(lEAVRTIO)
18-9
118-15
Synchronous
Timer
Recovery
Routine
(lEAVRTI1)
TOE
Processing
Routine
(IEAVRTIO)
!18-3A
1
S'
18-11
Set Specific
Clock
Routine
(JEAVRTOO)
18-16
"'-
Asynchronous
Timer Recovery
Routine
(lEAVRTOD)
SETDIE
(IEAVRT02)
!
------
TOO Clock
Operator
Communication
Routine
(JEAVRTOD)
Figure 2-32. Timer Supervision Visual Contents (Part 1 of 2)
18-13
l1!-14
TOO Clock
Synchronjzation
Routine
(JEAVRTOD)
TOO Clock
Status Test
Routine
(lEAVRTOD)
Section 2: Method of Operation
4-5
I
4:0-
0.-
oen
~
N
j,
Diagram 18-1. TIME Service Routine (IEAVRTOl) (part 1 of 2)
From SVC First
Level Interrupt
/
Handler (IEAVESVC) p
Input
/
en
'<
..... :
~
....
r"'"
·f~
,)
l. ()
C
~.[
vet S-Jt
S_J2.-C__ -
I!
rocess
1:~S;Th~~te3i!{5:i~tccf'0:*!-:~~:~.tc~'<~o~:c2!:;;"~:':Vo'~,,;:i~ 'ci,c~2l::(:;;~'1zs0zb;c;~' r$~~"
1
:3
- f
c)
:c>i;~
Check for timer initialization.
CVT
~
(5.
Register 1
r"'"
!
2
Get local date.
~
3
Get local time from a valid
TOO clock.
4
Convert the local time to the units
requested.
~
(I)
4:0--
'
toN
"
00
0
.::!
Caller
Diagram 184. TQE Enqueue Routine (lEAVRTIO) (part 2 of 2)
Extended Description
Module
Label
IEAVRTIO
IEAOTEOO
The TOE Enqueue routine (I EA VRTIO) enqueues the subject TOE (Timer Oueue Element) on the proper timing
queue: the real time queue for real or wait type TOEs; or
the task queue for a task type TOE.
1
TOE Enqueue determines from the TOETYPE field
what type of TOE is being processed.
Field Setting
00
01
11
TQE Type
Task
Wait
Real
<
2
(;f.l
TOE Enqueue enqueues a task type TOE from a TCB
by setting the TCBTME field and setting the TOE
fields to indicate the TCB with which the TOE is associated,
and to indicate that the TOE is on a timer queue. Then it
sets the CPU timer and, for recovery purposes, saves the
time-of-day when the CPU timer was set.
N
o
tN
00
o
........
3
TOE Enqueue sets a TCB flag to indicate a real or
wait type TOE. This flag is not set, however, for a
01 E TOE. Then it searches the real time queue and places
the subject TOE in the proper place. It indicates that the
TOE is on the real timer queue.
•
4
TOE Enqueue verifies that the top TOE in the real
timing queue is being timed and if not, sets the clock
comparator.
5
c;I)
(D
~
o·
=
N
~
(D
8'
~
o
..,
o
'"0
S
g.
=
~
tN
TOE Enqueue returns control to the caller.
IEAVRTIO
SETCC
~
Diagram 18-5. TQE Dequeue Routine (IEAVRTIO) (part 1 of 2)
~
From a timing
service routine
or other caller
&5
~
'.
~
til
~
<
Register 1
I
(D
EI
t"'"
~
n·
J ~I
TOE
TOEFLGS
~
1- ---~
TCB
I-
1
'"
Determine type of TOE.
V-
t"'"
...0:
~
-
TOE
~
<:
0
c
2
~
EI
(D
Task Type
Remove the TOE from the
appropriate queue.
~
CVT
'
"
3
""
. 1
For a task type TOE, set the
CPU timer .
14
I.'
.. ~ PCCA
"
PCCA
",'.>
~
4
If a user TOE was being timed,
clear the PCCA indicators for
all CPUs timing it.
'"
PCCATOEP
V----~
5
I
For a rea I type TOE, ensure
that the top TOE in the real
timer queue is being timed.
Register 2
I
Return Address
I
.~"
"y
) 6
Return.
Diagram 18-5. TQE Dequeue Routine (IEAVRTIO) (part 2 of 2)
Extended Description
Module
Label
IEAVRTIO
IEAVOTDOO
lEA VRTIO
SETCC
The TOE Dequeue routine (I EA VRTIO) dequeues the subject TOE from the real time queue for a real or wait type
TOE, or from the task queue for a task type TOE.
1
TOE Dequeue checks the TOETYPE field in the TOE
to determine its type.
Field Setting
00
01
11
TQE Type
Task
Wait
Real
2
TOE Dequeue resets the pointers to the TOE, and
marks the TOE to indicate that the TOE is off a timing
queue.
3
TOE Dequeue sets the CPU Timer to a high value to
insure against timer interruptions.
4
TOE Dequeue clears fields in the PCCA (Physical
Configuration Communication Area) entries to indicate
that the TOE is no longer being timed.
•
til
(\)
C')
g.
::s
~
so:
(\)
~
Q.
o....
o
"0
~
o·::s
f'-
<.11
5
TOE Dequeue verifies that the top TOE in the real
timing queue is being timed.
6
TOE Dequeue returns control to the caller.
of"
Diagram 18-6. TQE Purge Routine (IEAVRTIl) (part 1 of 2)
01
From End-of-Task
(lEAVTSKT)
0
en
"~Ettk~IDi5~;;*hl\i*t!t;£i¥)i.1:fi~*~hhtI;}§;'~t{t±i¥i~4rt;:?;tt~t.£b~;d;E~±;:?4:::%E)·~:~D
'<
~
(!)
:3
Register 1
,1
I 2
TOE
t"'"
~
(=).
-,
t"'"
CT
I
I
~
B
c
:3
(!)
~
'<
C".Il
t-J
o
(,H
00
o
....
'-'
0
L
For a user TOE, schedule an SRB if
not a 01 E TOE. In this case, branch
enter specified exit routine.
For the channel reconfiguration hardware
(CRH) TOE, pass control to the CRH SRB
scheduling routine if the interval is expired,
and then return. Otherwise, go to step 9 to
enqueue the TOE.
4
For a System Resource Manager TOE, notify
the SRM if the time interval expired and
return. Otherwise, go to step 9.
I
I
I
I
Dequeue TOE and determine type.
3
I
ASVT
5
For an MF/I TOE, notify MF/I if the time
interval has expired and return. Otherwise,
go to step 9.
6
For a job step timing TOE, check for
violations of job step CPU time and
wait limits.
7
For any violation, scheduie an SRB to
pass control to SMF. Update the
Job Step Timing 1"OE 4 Go to step 9.
8
For a midnight TOE, clear the hardware
error counts for timer components not
permanently damaged, update the date
in the CVT, and update the midnight
value in the TPC.
9
Enqueue the TOE on the proper queue.
:6 ASCB
I-ASCBJSTL
ASCBSWTL
I
--
-"
~
~-
1_J
I
I
10
1(!~;;i0$ii
Return.
Caller
SRB
~
N
o
(,H
00
o
....
Diagram 18-9. TQE Processing Routine (IEAVRTIO)
Extended Description
(part 2
of 2)
Module
Label
I EAVRTIO
IEAVRTIO
2
IEAVRTIO
If the user TOE is a 01 E TOE, the user's exit (01 E)
routine is branch entered directly from PROCTOE.
3
If the interval is complete, PROCTOE gets the address of
IECVCRHS and branches to it (using BALR).
4
If the time interval is complete, PROCTOE notifies
the System Resources Manager with a SYSEVENT
macro instruction that the interval is complete.
5
PROCTOE notifies MF/I, using the MFROUTER
macro instruction, when the interval being timed by
the MF/I TOE has completed.
I.f.l
("l)
!l
o·
=
IV
s::
sa.
[
o....
o
'0
("l)
'"1
~
S·
=
N
"""
w
Label
IEATLEXT
IEAVRTIO
IEATLEXT
AECTLRTN
PROCTOE checks all address spaces for violations
of a job step's time limit or a waiting job step's wait
time limit by checking the ASCBJSTL and ASCBSWTL
fields.
PROCTOE dequeues the TOE from the real timer
queue and determines from the TOEUSER bit
whether the TOE is a user TOE or a system TOE.
If the user TOE is not a 01 E TOE, PROCTOE builds
"and schedules an SRB (corresponding to the user
TOE),into the address space requesting the interval. If the
TOE specifies a user exit, an IRB is built by the SRB
routine and is scheduled by the Stage II Exit Effector.
The user exit will execute under this IRB. If the TOE
specifies a wait type request, the SRB routine posts the user.
Module
6
The Process TOE routine dequeues the top TOE on the
real timer queue and either does special TOE processing
for a system TOE or it schedules an SRB for a user TOE.
1
Extended Description
PROCTOE
IEAOTOOO
AECTLRTN
7
For any violations, PROCTOE passes control to SMF
via an SRB to check for a possible time interval
extension. To do this, PROCTOE builds a partial TOE
and then schedules an SRB to pass control to SMF.
This SRB will then use the Stage II Exit Effector to
schedule the IRB for the initiator's TCB under which
IEATLEXT will execute. PROCTOE then updates the
Job Step Timing TOE.
-<
I.f.l
IV
o
<.N
00
o
......
8
If the time interval is complete, PROCTOE clears
hardware error counts for the usable timer components in the PCCA. PROCTOE also updates the date in
the CVT and adds 24 hours to the TOEVAL field in the
midnight TOE.
9
10
PROCTOE enqueues the TOE on the real timer queue.
PROCTOE returns control tl) the calling routine.
IEAVRTIO
IEAOTEOO
t
Diagram 18-10. Timer Functional Recovery Routine (IEAVRTIl)
(part 1 of 2)
~
&1
"<
til
N
til
From R/TM
(lEAVTRTS)
Input
Output
'<
~
~
i
t""
;:
SDWA
SDWARCDE
- 1
~
Check for recursion and
initialize SDWA.
<:
g.
:I
(D
=
TFRRPARM
<:
til
N
~
'<
til
N
TFRRPARM
2
Save recovery information
depending on error condition.
3
Verify and enqueue System
TQEs for clock comparator
processing errors.
4
Re-initialize recovery SRB, if
error in scheduling
routine.
5
Stop the VARY operation,
if error in CPU hold routine.
6
Validate real TQE queue, if
dispatcher lock held or if TQEs
being enqueued or dequeued.
7
Verify that real TQE queue is
active.
8
Return.
o
.I
o
--J
'-'
~
00
:3
~
00
o
R/TM
(IEAVTRTS)
Diagram 18-10. Timer Functional Recovery Routine (IEAVRTIl)
(part 2 of 2)
Extended Description
Label
Module
The Timer Functional Recovery Routine (FRR)
checks for possible recursion or re-entry to the
recovery routine. If recursion has occurred, the Timer
FRR immediately returns to R/TM. Then the Timer FRR
initializes identifier fi~lds in the SOWA.
IEAVRTI1
IEAVRFRR
C"Il
(I)
ao·
=
N
a::
~
Q.
o
000)
o
"t:I
o·~
=
f'"
N
VI
5
IEAVRTI1
IEAVRTI1
IEAVEADV
IEAVEOVO
IEAVRTIO
IEAVRQCK
If the error occurs in the CPU hold routine, the Timer
FRR determines whether to cancel the VARY_process.
6
After the TFRR Parameter List has been recorded in
the SDWA, the Timer FRR determines whether the
error occurred when a dispatcher lock was held, or when
a TOE enqueue or TOE dequeue was in process. If one of
the conditions is true, it verifies the real TOE queue. If the
TPC is found to be invalid, the Timer FRR indicates the
invalid TPC and returns control to R/TM.
The Timer FRR records error information in the
TFRR Parameter Area and in the TPC for each type
of error for later recording in the SDWA.
If the error is in a clock comparator interruption, the
Timer FRR updates the system TOEs and re-enqueues
them.
Label
If the error is in the asynchronous recovery scheduling
routine, the Timer FRR marks the recovery SRB notin-use.
2
3
Module
4·
The Timer Functional Recovery routine (I EA VRTI1) proc·
esses program errors in timing components. It records error
information and checks the validity of system timer queues.
1
Extended Description
lEA VRTI1
I EAVRTIO
lEA VRTVR
I EAOTEOO
7
The Timer FRR verifies that the real TOE queue is
active.
8
The Timer FRR returns to R/TM through register 14.
t
Diagram 18-11. Set Specific Clock (SSC) Routine (IEAVRTOD)
(part I of 4)
<:f\
~
N
~
From VARY Command
Processor (lEAVCPU) or
Asynchronous Recovery
Input
'<
~
S
t""
1
Get space for TCWA.
2
Search for valid online clock.
3
If found, initialize TCWA for
two clocks.
4
Check status of new clock agai nst
online clock. Repeat steps 2 and
3 if online clock is not set.
5
Synchronize new clock to online
clock, if required.
Repeat the status check to verify
the synchronizing procedure.
Then go to step 9.
6
If a valid online clock is not
found, dequeue the midnight and
job step timing TOEs and check
new clock status.
ti
~.
I:"'"
0:
~
e.<
TCWA
=
:3('I)
.1:;0.
'<
r.t.l_
h)
~
('I)
if
~
~
~
Real Time Oueue
TOE
r-I-
I
T
Diagram 18-11. Set Specific Clock (SSC) Routine (IEAVRTOD)
E;xtended Description
Module
(part 2
of 4)
Label
SSC obtains storage for the TCWA (TOO Clock Work
Area) from subpool 245. If the GETMAIN is unsuccessful, SSC saves the return code in register 15 and indicC!tes
the VARY operation should be halted, or that recovery was
unsucces.sful, by returning a non-zero return code to the
caller.
2
Using the bit mask in the CSD indicating the active
processing units in th.e system, SSC finds an onli.ne
CPU. Then it tests the status byte in the PCCA (Physical
Configuration Communication Area) for a valid TOO clock.
t;I'.l
~
a
~.
::I
N
~
~
5'
Q.
So
~...
~
~.
::I
of"
!j
Module
Label
3
The Set Speci.fic Clock (SSC) routine (I EAVRTOD) proc·
esses requests to set a particular TOO clock. It attempts to
find a valid clock, synchronizes the new clock to the valid
clock, if found, and tests the validity of the synchronization.
It is called from the VARY command processor OEEVCPU)
and from the clock asynchronous recovery routine that is
located in module IEAVRTOD (entry point IEAVRCLA).
1
Extended Description
SSC initializes the PCCA address and the CPU address
in the TOO Clock Work area entries: one for the CPU
being varied online or being recovered, and one for the CPU
with the valid TOO clock.
IEAVRTOD IEAVRSSC
4
IEAVRSSC tests the new clock against the valid clock
for synchronization. If the valid clock is not set (return
code 4 from TOO Clock Status Test), SSC continues searching the PCCA entries for another valid clock.
IEAVRTOD IEAVRTST
5
If the return code from TOO Clock Status Test is 8,
12, or 16, SSC tries to synchronize the new clock to
the valid clock. Then it tests for success of the synchronization.
IEAVRTOD IEAVRSYN
6
IEAVRTIO
If a valid TOO clock is not found, SSC dequeues the
midnight and job step timing TOEs and disallows
external SET commands. Then it initializes a single TCWA
entry and checks the status of the new clock.
I EAVRTOD I EAVRTST
IEAOTDOO
IEAVRTOD IEAVRTST
;t
Diagram 18-11. Set Specific. Clock (sse). Routine (IEAVRTOD) (part 3 of 4)
00
o
C"Il
~
N
C"Il
'<
~
,
Process
Input
7
~
'e.
n
t'""
Output
Notify operator of TOO clock
status and process the replies.
MNIGHT
TQE
~
~
~
a-
8
Register 0
:3
"
Initialize the midnight and job
step TQEs and re-enqueue them.
v
(D
.01:0.
<:
C"Il
N
~
~
CVT
CVTCSD
w
~
DD
CSD
~
r6
JST
TOE
fJ
:
>9
CVTTPC
PCCA
~PCCATMSTI
Update the PCCA and the CSD
and release the "new" processing
unit, if VARY is caller.
CSD
CSDGDTOD
CSDGDCC
TPC
CSDGDINT
Real Time Queue
ITPCHDCCQ 111
..J>,
..".
TQE
t-----------.---v 10
LCCA
j,
t-I-
•
Ensure that the top TQE on the
Real Time Queue is being timed.
=!){LCCATIMR
I
Register 15
Register 14
l
..11.
y
11
•
Return.
Caller
"
li)l
Return Code
J
Diagram 18-11. Set Specific Clock (SSC) Routine (IEAVRTOD)
(part 4
of 4)
Extended Description
Module
7
lEA VRTOD I EAVRCOM
If the return code from TOD Clock Status Test is 0,
SSC issues message I EA888A; if the return code is
non-zero, SSC issues message I EA886A. Then it tests the
clock to be sure it is set.
8
If the new clock is set, SSC re-enqueues the midnight
and job step timing TOEs and notifies the System
Resources Manager that there is now a valid TOD clock
and clock comparator in the system.
Label
IEAVRTOD IEAVRTST
IEAVRTOD TOEINIT
9
If the caller is VARY, SSC initializes the timer
status bytes in the PCCA, updates the count of usable
TOD clocks, clock comparators, and CPU timers in the CSD,
and releases the new CPU from its holding state.
10
ssc ensures that the top TOE on the real TOE
IEAVRTIO
IEAVROCK
queue is being timed.
11
ssc allows external SET commands, frees the TCWA
space, and returns to the caller.
Error Recovery
When an SSC routine error is detected and passed by
R/TM, the ESTAE routine sets up information so that
R/TM will cause SSC to be re-entered at a point at which
resources can be cleaned up and a return can be made to
the caller.
c:n
n>
(")
S·
=
t..)
==
~
o
0.
....
o
o
"'0
n>
i3
S·
=
~
t..)
~
IEAVRTOD SSCESTAE
~
Diagram 18·12. TOD Clock Operator Communication Routine (IEAVRTOD) (Part 1 of 2)
From TOO Clo·ck
I:nitialization or
Set Specific Clock
o
se
~
..
N
fIl
-
'<
=.
e
£"r;.'
;
CVT
CVTDATE
CVTTPC
!<
J
TCWAGFLG ~~ ' - - - - -
~
I
59
~
Operator Reply
- 1
.....
Issue the message to the
operator that the TCWA flags
indicate.
I'
. Messageto
Operator
i
,/'~
I
(II
~
TCWARPLY
V--
CVTMSER
~
. TCWA
TPC
/TPcrCNA
~>,
;
~
.....
"
2
Process the reply and set the
clock if the reply is other
than 'U'.
3
Check for fai.lure of command
and repeat steps 1 and 2 if
fai lure occurred.
'<
fIl
N
::c
r
(II
~
~
MSRDA
il
1
-"-
%'j
MSTODWTO
q
4
II'
Display the time and date to
the operator.
:l
I
Operator Reply
i
t
1'..
) 5
Process the operator's reply and
repeat steps 2-4 if needed.
Register 14
I
I
,I
.....
il
to.
..> 6
Return.
II'
II . . .
y
[ll!"
Return Address
CVT
Message to
Operator
CVTDATE
Diagram 18-12. TOD Clock Operator Communication Routine (IEAVRTOD)
Extended Description
Module
label
Operator Communication issues the message that the
flags in the TCWA indicate. The flag settings depend
on return codes from the Clock Status Test routine.
Return Code
o
8 or 12 (1 clock set)
4 or 16
8 or 12
1 clock set)
(>
Message
IEA888A
IEA888A
IEA886A
IEA887A
If message IEA888A is to be issued, go to step 4.
2
Operator Communication processes the reply according
to the message sent:
Message
IEA888A
IEA886A
IEA887A
(I)
(D
n
g.
=
~
a::
(D
8Q.
o
.-.
o
"=
(D
;
g.
=
-
~
~
Valid Replies
CLOCK=nn,DATE=nn [,GMT] [,IPS=]
CLOCK=nn [,GMT] [,IPS=]
DATE=nn [,GMT] [,IPS=]
IPS=
CLOCK=nn,DATE=nn [,GMT] [,IPS=]
DATE=nn [,GMT] [,IPS=]
ID=nn [,IPS=]
CLOCK=nn,DATE=nn [,GMT] [,IPS=]
DATE=nn [,GMT] [,IPS=]
If a syntax error is found, the message is repeated until a
correct reply is made. When the operator enters a reply,
Operator Communication performs the indicated function
as requested by issuing an internal SET command.
Extended Description
3
The TOO Clock Operator Communication routine
OEAVRTOD) handles operator communication for TOO
clock status. The routine issues messages and processes the
operator's replies, issuing SET commands to update the
TOO clock and local time and date. It is called from
eitherTOD Clock Initialization located in IEAVRTOD
(entry point IEAVRINT) or Set Specific Clock located
in IEAVRTOD (entry point IEAVRSSC).
1
(part 2 of 2)
Operator Communication obtains a current TOO
clock value, calculates the local time, ar1d initializes
the date field in the CVT. It also calculates the GMT time
and date and, if prompting is to be done (indicated by bit
MSTODWTO), displays both the local and Greenwich Meantime values in message IEA888A.
5
If the operator accepts the values or if no prompting
is allowed, Operator Communication returns. If the
operator enters new values, Operator Communication sets
the clock or local time and date values accordingly with
the SET command, reissues message I EA888A, and processes
the reply until the values are accepted.
6
label
If the SET command fails, Operator Communication
issues the message and processes the new reply.
4
IEAVRTOD IEAVRCOM
Module
Operator Communication returns to the caller.
IEAVRTOD DELTA3
IEAVRTOD CUTODATE
t
Diagram 18-13. TOD Clock Synchronization Routine (IEAVRTOD) (part 1 of 2)
N
From TOO Clock
Initialization or
Set Specific Clock
o
~
CIl
N
!ill
In
Output
'<
~
9
i
r~
CVT
TCWA
1
Find a clock requiring
synchronization.
2
Notify operator to press clock
security switch.
3
Get varue from- '''mas:Cer'r clock
for settIng unsyncbrooiized clo-eks.
4
set unsyru:hroaJ:zed db'€ks. tCil' matm,
~
~
=-
9(D
~
'\
AI
Diagram 19-1. Dispatcher (IEAVEDSO)
(part 4
of 18)
Extended Description
2
Special exits require immediate response. The dispatcher checks first for this condition, and then saves
the status of the interrupted task, and obtains the dispatcher
lock.
3
The dispatcher determines the type of special exit, and
gives it control except for DSS. I n that case, control is
given to the Memory Switch routine to switch to the master
address space. Special exit returns control to the dispatcher.
tI'l
(D
~
5·
=
~
~
$a.
8:
SO
"0
o·~
=
~
CIt
-..l
Module
Label
t
Diagram 19-1. Dispatcher (lEAVEDSO) (part 5 of 18)
00
o
r
rI.)
"<
rI.)
w
rI.)
~
Process
Input
.~,
a
IEAGSMQ
t;.
~
E
@SRB.
t:
~IEAGSPL
~
I
~
<:
g.
~
c::
a
o
Output
GSMQ Processing
J\.
y
4
5
Save status and obtain dispatcher
lock.
~
~
r
Schedule
SRB on
GSPL
..
No work on queue.
r
Step 7
M
2-
IEAGSPL
iC
I
S
-
SCHEDULE
"
0l:Io
•
..
~
~
~W
w
~
~
@SRBs
Y-lJJ
c~
SRBs
GSPL Processing
JI.
y
6
Save status and' Obtain dispatcher
Jock.
7
Dequeue an SRB from the GSPL.
";t
y
III.
•
Dispatchable SRB on queue.
..
•
Non-dispatchable SRB on
queue.
Step 7
,.
..
A
Global SRB
Dispatcher
SCHEDULE
Schedule
SRB on
LSMQ
M
,~
•
III.
No SRB on queue.
Step 9
!
-
,
'---
I
"
~
Dequeue any ready work sti II on
GSMQ.
Ready work on queue.
•
1
:0
II
IEAGSMQ
I
IEAGSPL
"<
I
@SRBs
SRBs
~lJlJ
Diagram 19-1. Dispatcher (lEAVEDSO) (Part 6 of 18)
Extended Description
4
The dispatcher next checks the GSMQ (global service
management queue) for any ready work. The dispatcher saves the status of the interrupted program and
obtains the necessary locks if it finds SRBs on the GSMQ.
5
The dispatcher dequeues any ready work on the
GSMQ via the CS (Compare and Swap) instruction.
Work on the GSMQ will be placed, via the SCHEDULE
service, on the GSPL (global service priority list). If the
GSMQ has no ready work, the dispatcher next checks for
work on the GSP L, as indicated by step 7.
6
The third check the dispatcher makes is for ready work
on the GSPL. The dispatcher saves the status of the
interrupted program and obtains the necessary locks if it
finds ready work.
7
The dispatcher dequeues any ready work (the first dispatchable SRB) on the GSPL and gives control to the
global SRB dispatcher subroutine. If an SRB is not immediately dispatchable, it is dequeued and scheduled to the
LSMQ. If the GSPL has no ready work, the dispatcher next
checks for work on the LSMQ (local service manager queue),
as indicated by step 9.
{;I'.)
~
,r
g.
=
N
s::
~
g
c::;l.
....o
o
'-c::I
~
a
o·
=
.a::.
V.
\0
Module
Label
~
o
Diagram 19-1. Dispatcher (ffiAVEDSO)
(part 7 of 18)
~
~
N
tfJ
~
~
r-
ei(;.
r-
es:
~
<:
o
C
=
"'~
Input
.
."
IEALSMO
I
I----"
@SRBs
-lJJ
' .....
y
[}-I I
ASCB
8
9
£,
tfJ
~
~
~
:...,
IEALSMO
Save status and obtain dispatcher
lock.
~y-
., ,
~
Dequeue any ready work still
on LSMO.
.
•
Ready work on queue.
•
Address space switch indicated. '"
CCS
ASCBLOCK
J
ASCBASXB
QASCBSPL
ASCBSTOR
~
SRB
~
~ Segment
, ~&JO
~
ASXB
Address Space Switch Processing
10
~
...
Y)
?
11
Obtain the address space.
12
Check LSPL for ready work.
(IHSA
~
v
Save status and obtain dispatcher
lock.
13
I
I
:~
.,>
.D
ASCB
·ILSPL
SRBs
~.
Step 17
~
Yes
J
Schedule SRB
on LSPL
..
No
'\ LSPL
SCHEDULE
r
~
Register 8
@ASCB
>0
I
LSPL
CD
N
,
'
LSMQ Processing
SRBs
~
'<
Output
Process
Control Register 1
Step 12
r
I
@STOR
Segment
...... Table
Register 4
• >0
~I
@LSPL
Y
PSA
,
'I
)
'LSPL
PSAANEW
...
•
Ready work.
•
No ready work.
PSAAOLD
Step 17
r
I
Check whether the loca I lock
interruption 10.
',W
-
w
It
'--
I
",ic
=
...
r
Local supervisor
.
0 ispatcher, Step 3
Diagram 19-1. Dispatcher (IEAVEDSO) (part 8 of 18)
Extended Description
8
The dispatcher saves the status of the interrupted program and obtains the necessary locks.
9
The dispatcher dequeues any ready work on the
LSMO(via the CS instruction) and schedules it to be
placed on the LSPL (local service priority list). When
the LSMO has no ready work, control goes to step 12
if an address space switch has been indicated.
10
The dispatcher saves the status of the interrupted
program and obtains the dispatcher lock.
11
If ready work exists in the new address space, the
dispatcher updates the PSAANEW and PSAAOLD to
reflect the new address space, and loads the STOR (segment
table origin register) for that address space.
12
The dispatcher then checks the LSP L for ready work.
If the LSP L has ready work queued on it, control
goes to step 17; otherwise, processing continues at step 13.
13
By checking the local lock lockword for an interruption 10, the dispatcher can determine whether a
local supervisor routine was processing (Note: A local
supervisor routine would be a supervisory-type service, such
as ATTACH, performing a service needed at a local level,
such as by a problem program). If the dispatcher finds an
interruption 10, control goes to the local supervisor dispatcher subroutine.
{;I.l
(I>
ao·
=
!';J
~
~
5'
Q.
Sa
o
"0
(I>
~
o·
=
~
0'1
Module
Label
::
Diagram 19-1. Dispatcher (rnAVEDSO)
(part 9 of 18)
N
o
~
~N
~
'<
~
i-t:
~
~
~
;:
9('D
~
'<
~
N
i
>
II
14
t?~
Determine whether the local lock
contains this CPU's ID.
I~
I•It
I
i
,
ASCB Queue
ASCB
0
ASCB
[YLJ
,',
<
~
-'"
y 15
"
~
,,,"Md"&
d<'_W
,.
16
SRBs
-
12]
LSPL
•
Local lock available.
•
Local lock not available, continue.
•
End of queue.
•
Next ASCB.
LSPL~
ASCB
C
ID in local lock
Jo.
rvisor
Step 3.f
Step'
~
'
...
.
...
,.
Waitl
Dispatcher
Step'
..
Jo-I
y-'
Dequeue first dispatchable SRB
from the LSPL.
•
•
0
#
"
Ito..
Save status and obtain
dispatcher lock.
(17
1
..
Local
Dispa
Check ASCB queueJor end.
~
~
...
..
= CPU.
•
III.
Ready work on queue.
;
No
•
.
Local
Dispatcher
work on queue.
*
Local Supervisor Routine Processing
18
Determine whether this is a
local supervisor routine.
III..
;'
"
Local
Step'
Step:
rvisor Dispatcher,
terrupt 10) or
CPU 10)
Diagram 19-1. Dispatcher (IEAVEDSO)
(part 10 of 18)
Extended Description
14
If the local lock contains the CPU 10, this indicates
that a local supervisor routi ne received an interruption and status has not yet been saved. This routine can be
redispatched immediately (step 18), If the local lock does
not contain the CPU 10, the dispatcher attempts to obtain
the local lock, via a CS instruction. If the dispatcher obtains
the local lock, the task dispatcher receives control (step 19).
15
When the CS instruction fails, the dispatcher tests if
this is the WAIT ASCB. If this is the WAIT ASCB,
and a recursive search of the dispatching queues, the dispatcher gives control to the WAIT ASCB. If this is the WAIT
ASCB, but not a recursive search through the dispatching
queues, the dispatcher searches the dispatching queues for a
second time. If this ASCB is not the WAIT ASCB, control
goes to step 10 to dispatch the next ASCB.
16
The dispatcher saves the status of the interrupted
program and obtains the necessary locks.
17
The dispatcher dequeues any ready work on the
LSPL and gives control to the local SRB dispatcher.
If the SRB is a suspended SRB (from local lock or page
fault suspension processing), the dispatcher restores status
from the SSRB and redispatches the SRB. Otherwise, the
dispatcher uses the global SRB dispatcher to dispatch the
SRB. If the LSPL has no ready work, control goes to
step 18.
18
t"'-l
a5'
=
~
~
[
o
o'""
'0
~
~
5'
=
~
0\
~
The dispatcher determines whether a local supervisor routine should receive control, and gives control
to the local supervisor dispatcher subroutine, if necessary.
Module
Label
~
~
Diagram 19-1. Dispatcher (IEAVEDSO) (part 11 of 18)
~
o
fJ'l
~
.
t-.)
fJ'l
'<
~
i
i
(=;.
TeB Queue Processing
19
Dispatch the task.
r""
a:
~
-<
~
•
•
No task to dispatch, obtain
lock.
a
(D
,
~
Then
<
fJ'l
t-.)
~
f
(,0,)
~
.. Task
Dispatcher
Task can be dispatched.
-
It
I..-
."
...
...
IEAVELK
--."
Step 11
Diagram 19-1. Dispatcher (IEAVEDSO)
(part 12 of 18)
Extended Description
19
The dispatcher checks for ready work on the TCB
queue, and gives control to the task dispatcher to
dispatch ready tasks. The dispatcher tests the ASCBS3S
field of the ASCB to determine wheiher the stage 3 exit
effector has any asynchronous exits to process.
The dispatcher will always begin searching from the top
of the TCB ready queue. If it finds a dispatchable TCB,
it tests this TCB to determine whether the task is active
on another CPU. If the TCB is active, the dispatcher
searches for the next ready TCB.
The dispatcher does not save the status of TCBs active on
the current CPU; these TCBs can be redispatched after
restoring the registers and PSW. After there are no more
ready tasks left on the TCB queue, control goes to step 11
to process any ready work in any address spaces.
C'-l
(D
ao·
=
N
a::
(D
g
.0-
o
....
o
"0
~
o·
=
~
0\
CJI
Module
Label
b:
Diagram 19-1. Dispatcher (IEAVEDSO) (part 13 of 18)
0'1
o
.re
From
Dispatcher
(lEAVEDSO)
when ready
work has been
found
~
N
{I.)
'<
~
:I
Input
II
£
(I)'
t::
PSAHLHI
20
~
~
'<
~
PSANSTK
(11
•
Wait task
•
Unlocked task
Save FPRs in TCB prefix.
Save task TOE CPU timer
value, if one exists.
Clear task active and
CPU-id indicators.
Call the job step timing
subroutine.
I
ASCBLOCK
I
{I.)
:;tl
(11
i
PSATOLD
•
~
TCBTME
TCBACTIVE
•
PSATOLD
0
PSAHLHI
N
~
PSATNEW
Save Status Routine
'<
~
Output
ASCB
2"
:I
~
t
Process
0
ASCB
0
ASCBLOCK
Locked task
Save FPRs in IHSA.
Save FRR stack in IHSA.
Save CPU timer value in
IHSA.
Save PSATNEW/PSATOLD
in IHSA.
If CMS lock held, set
indicator in ASCB.
Compare and swap interrupt
ID in local lock.
Clear 'CPU locks held'
indicators (PSAHLHI).
Call job step timing
subroutine.
FPR
CPUTIMER
FPRs
FRRs
For all three modes
Clear PSATNEW/PSATOLD.
Decrement ASCBCPUS.
Return to caller.
To Caller
Diagram 19-1. Dispatcher (IEAVEDSO) (part 14 of 18)
Extended Description
20
When the dispatcher finds ready work of higher
priority than the current work or if the current work
is no longer dispatchable, the status of the current work is
saved and its elapsed job step time is calculated and
accumulated. The type of status saved and where it is saved
depends on whether the current work is the wait task, an
unlocked task, or a locked task. SRB status is never saved in
the dispatcher since a SRB is non-preemptable. When a SRB
returns to the dispatcher entry point, IEAPDSRT, the count
of active SRBs are decremented and the SRB mode bit is
turned off.
Whenever a SRB is suspended for a lock or a page fault, the
common suspend routine (lEAVSPCR) in lock manager
(lEAVELK) saves the SRB status and calls the job step
timing routine (DSJSTCSR) in the dispatcher (see step 21
below).
tI.l
(D
~
o·::I
~
a::
(D
g
~
o....
o
"0
io·
::I
f"
0\
-..J
Module
Label
~
Diagram 19-1. Dispatcher (IEAVEDSO)
(part 15
of 18)
00
o
....ra.
re
<
f'-)
~
~
""
;-
a
~
~.iII.IIIIII._III
•
TOO clock
«e.
n
DSJSTCSR call by
Dispatcher
(JEAVEDSO),
Common
suspend
routine
(I EA VSPCR),
or IEAVRTIO
Output,
Process
21
Job Step Timing Subroutine
A..
t:
!
~
=~
~
LCCA
•
If SRB mode
•
If RCT task, return
LCCAITOD
,.
w
Step
21B
LCCASRBM
ASCB
ASCBEJST
~
+ ASCBEJST
ASCB
B
If LCAAITOD :/= 0, then
LCCAITOD
-LCCADTOD
(I)
~
~
,
to caller
~
~
to caller
I
LCCADTOD
~
~
If TOO clock is damaged,
return
ASCBEWST
= ASCBEJST
return . . to caller
else
•
ASCBSRBT
Store TOD in ASCBEWST,
then
ASCBEWST
-LCCADTOD
~
+ ASCBEJST
= ASCBEJST
return
to caller
B. SRB time .
•. Store TOO in ASCBEWST,
then
ASCBEWST
-LCCADTOD
~
+ ASCBSRBT
= ASCBSRBT
return . . to caller
Diagram 19-1. Dispatcher (lEAVEDSO) (part 16 of 18)
Extended Description
21
Job step timing subroutine (DSJSTCSRI. Whenever the
dispatcher is switching away from current work, its
elapsed job step time must be accumulated. If the dispatcher
was entered from an interrupt handler, the time of day of
interrupt (LCCAITOD) will have been stored on interrupt to
eliminate the time spent iA the interrupt handler. The
dispatched time (LCCADTOD) will be subtracted from the
LCAAITOD to obtain the task time. This time will be
accumulated into ASCBEJST field. If the dispatcher was
entered from another caller, the dispatcher will first store the
TOO clock in ASCBEWST and then perform the above
calculation and accumulation. SRB time is accumulated in a
separate field (ASCBSRBTI. Time spent in RCT's task is not
accumulated to eliminate the swap out/swap in time. Job
step initiation/termination, SMF, and job step time limit
will use this accumulated time, initialize the value to zero,
and record the appropriate value in SMF records. -
t"/.)
(D
$?
o·
=
N
==
sa.
g
~
o....
o
"0
~
ao·
=
~
~
\C
Module
Label
of"
c:J
Diagram 19-1. Dispatcher (lEAVEDSO) (part 17 of 18)
&1
~
~
rn
I
'f
dispatcher
h
~
<
Register 1
i
r
($'
t::
~
SDWA
J
...
\"SDWA
~
"
~
a
22
Record the error.
23
Verify queues and control blocks
if DISP lock is held.
'"
"
i
(D
~
~
~
~
...)
~
S!.
PSA
r6
w
!.J
D
i
-
--y
•
SRB queues.
...
...
IEAVESCR
"
....-
•
~
<
,
..
SRB control blocks.
"'-
....--
•
ASCB ready queue.
.oIL
IEAVESRB
"
..
"
IEAVEQV3
....
•
24
If local lock held, verify
TCB queue and exit effector
queues.
Return to super FRR.
..
-,.
....
...
IEAVEEER
Diagram 19-1. Dispatcher (IEAVEDSO) (part 18 of 18)
Extended Description
Module
22
IEAVEOSR
The dispatcher FRR records the error in the SOWA.
23
The dispatcher FRR verifies the queues and control
blocks only if the dispatcher lock was held at the
time of the error. The FRR verifies:
• The SRB queue.
• The SR B control block.
• The ASCB ready queue.
The dispatcher FRR verifies the TCB queue if the local
lock was held at the time- of the error, and if the error was
not a OAT (dynamic address translation) error and if
control register 1 is valid.
The dispatcher FRR routes control to the stage 3 exit
effector FRR at this time.
24
t'I}
(I)
~
(S-
=
~
a::
~
6
~
o
'"'>
o
't:I
~
a
o·
=
~
~
The dispatcher FRR returns control to the Super
FRR.
Label
~
Diagram 19-2. Global SRB Dispatcher (IEAVEDSO) (part 1 of 2)
N
From the dispatcher,
step 7, to dispatch
a Global SRB
ofIJ
~
N
Input
fIJ
~
a
E
n'
E
CT
...
t"'"
8<
LCCA
@SRB
-
SRBPKF
'SRBPARM
~
SRBEP
:3('D
:;c
1
Indicate SRB mode and
increase the SRB count.
2
Set up the SR B PSW and
register values.
3
Trace the event using GTF or
Trace.
--"- SRB
~
~N
Register 5
i
~
w
:....
I~CCADSF21
Register 2
OR
ASCB
ASCBSRBS
4
Release any lock and give
control to the SRB via an
LPSW instruction.
Control to SRB
Diagram 19-2. Global SRB Dispatcher (IEAVEDSO) (part 2 of 2)
Extended Description
Module
The global SRB dispatcher subroutine of the dispatcher
gives control to the ready SRB that has been dequeued
from the GSPL by issuing an LPSW (load PSW) instruction.
1
The global SRB dispatcher"indicates SRB mode in the
LCCA and increases the count of SRBs in the
ASCBSRBS field.
2
Next, the global SRB dispatcher places values in the
PSW that will allow the SRB to gain control. These
values includ.e desired key, supervisor state, enabled, and
the SRB's entry point address. The registers contain:
• Register 0 - SR B address
• Register 1 - parameter list address
• Register 14 - return address in dispatcher
• Register 15 - entry point
3
4
Either the trace routine or GTF traces the occurrence
of the event.
The global SRB dispatcher releases the dispatcht'r
lock, and issues an LPSW instruction to give the
selected SR B control.
r/}
~
()
g.
=
~
a::
sa.
g
(:I.
....o
o
"C
~
~
o·
=
~
.!.J
w
IEAVEDSO
Label
t
Diagram 19..3, Local SRB Dispatcher (IEAVEDSO)
(part
1 ()f 2)
~
From the dispatcher,
step 17, to dispatch
a Local SRB
~.
{I}
~.
Output
~
~
~
9
~n'
Register 2
@$SRB
~.
~
~.
a-S
CD
~
'<
tI.l
N
~
1
Set SRB mode indicator.
2
Determine whether the SRB is a
suspend SRB.
Yes
EJ
No
3
J. ,
Step 3
Global SRB Dispatcher
(tEAVEDSO)
Restore Status from SSRB
(suspend Si={B Save Area.)
a) FPRs.
ir6
b) Normal Stack.
c)
-
Locks (CMS and Local, if held.)
d) Move GPRs and PSW to Low
Core Save Area.
4
Release Dispatcher Lock.
5
Free the storage used by SRB using
FREECELL or FREEMAtN
OR
6
Trace the event using GTF or Trace.
OR
7
PSA
LCCA
~
~
o
D
D
Restore registers and give control
to the SRB via an LPSW.
Control to SRB
Diagram 19-3. Local SRB Dispatcher (IEAVEDSO) (part 2 of 2)
Extended Description
Module
The local SRB dispatcher suproutine of the dispatcher
gives control to the ready SR Bs that have been dequeued
from the LSPL by using an LPSW instruction.
1
The local SRB dispatcher first indicates SRB mode in
the LCCA.
2
The local SRB dispatcher checks the SRBRMTR field
to determine whether the SRB represents a suspended
SRB (suspended for a page fault or suspend lock request).
Control goes to the local SRB dispatcher for SRBs not
representing suspend processing.
3
The local SRB dispatcher restores status from the
SSRB (suspended SRB) save area.
4
The local SR B ,dispatcher frees the dispatcher lock.
5
The local SRB dispatcher frees the SSRB with either
FREEMAIN or FREECELL, depending on how the
storage for the SSRB was obtained initially.
tI.l
aer
=
~
at:
a
5'
/:l.
~
o
Ie·
=
~
...,
VI
6
Either the trace routine Or GTF traces the occurrence
of the event.
7
The local SRB dispatcher gives control to the selected
local SRB by issuing an LPSW instruction.
IEAVEDSO
Label
t
Diagram 19-4. Local Supervisor Dispatcher (IEAVEDSO)
(part 1 of 2)
0'1
i
~
N
fI.)
From the dispatcher,
step 18A, to dispatch a
Local Supervisor Routine
Input
o
Process
'<
~
a
r-
eit;.
r"'"
J
~
g
~
~N
ASCB
{ASCBASXBI
~
~
-..,IHt
i
1
Save the status of the interrupted
program.
2
CPU affinity to another CPU
No
,J.
From the
dispatcher
(lEAVEDSO)
step 13 or
18
~
Obtain next ASCB.
3
w
~
Yes, obtain dispatcher
lock.
T
PSATNEW
O;spatcher.
step 15
Restore Status from IHSA.
PSATOLD
__ H)
a) CPU Timer.
PSATOLD
c-
From the
dispatcher
(lEAVEDSO)
step 14
b) PSATOLD, PSATNEW.
FRR Stack
c) Floating Point Registers.
D
d) FRR Stack.
e) Locks.
f) General Registers.
PSATNEW
4
Obtain the PSW from the IHSA.
5
Trace the event using GTF
or Trace.
6
Give control to the interrupted
local supervisor via LPSW.
Control to Interrupted
Local Supervisor Routine
Diagram 19-4. Local Supervisor Dispatcher (IEAVEDSO)
Extended Description
(part 2 of 2)
Module
The local supervisor dispatcher subroutine gives control to
interrupted supervisory routines that were performing a
local service for a single address space. The interrupted
supervisory routine receives control via an LPSW
instruction.
1
The local supervisor dispatcher saves the status of the
interrupted routine in the appropriate area.
2
The local supervisor dispatcher determines whether the
interrupted routine had CPU affinity, and if it can
process on this CPU. The local supervisor dispatcher stores
the interruption I D in the local lock if the routine cannot
be processed, and processes the next address space.
(.f.l
~
g.
o·
=
N
a::
~
g
~
o
~
o
"0
~
~
g.,
~
.!J
........
3
The interrupted routine has its status restored from the
IHSA (interruption handler save area).
4
The local supervisor dispatcher obtains the PSW from
the IHSA and moves it to the PSA.
5
Either the trace routine or GTF traces the occurrence
of the event.
6
The local supervisor gives control to the interrupted
supervisory routine by issuing an LPSW instruction.
IEAVEDSO
Label
~
OJ
Diagram 19-5. Task Dispatcher (lEAVEDSO) (part I
From the dispatcher,
step 19, to dispatch
a ready task
~
~
~
of 4)
Input
·cn
la
.~
ASCB
ASCBS3S
r-
--
-
1
Determi ne whether .any
asynchronous exits exist.
("l
INa
t"'"
;:
~
<:
So
=
a
QTCB
2
Yes
Determine whether any ready
tasks exist.
(\)
lNa
~
'
I LCCAGroR I
Input for Step 3
~
00
PSA
-"
r
J
2
FLCNPSW
r
~---
r
Flags
2
Entry
Point @
Flags
{
255
A
_
rv-.
~-
Entry
Point @
......
...
"- - 3.1
Flags
(SVC Table entries are
a doubleword)
~-
A
--
4
Get SVC number. If an Extended
SVC (SVC 109, 116, or 122) has
been issued, use extended SVC
routine (ESR) code in register 15
to get correct entry in ESR table.
Recoveryl
-...I
--0
"
RBOPSW
RBINTCOD
r
I
RBINLNTH
Not AuthorizecJ
.....
,.
ABEND Code
)f
r
Code - X'Q47'
TESTAUTH
TCB Save Area
..,.'
....-
•
Not authorized. Move
registers from
LCCA to TCB
Not A uthori zed
save area and
terminate the
To
L
Dispatcher ...routine.
~
...J\
y
Recoveryl
10..
,.
C
t..l
00
o
Termination
Management
Check authorization.
I
I
I
I
____ J
J
RB
_ _ _ ...J
I
1
N
Code - X'OF8'
Lock,
SRB, or
disabled state.
-<
t'I:
ABEND Code
Save registers, PSW, interruption
code, and instruction length.
I
I
SVCTable
Entry
Point @
Check for
Locks
SRBs
Disabled State.
•
•
3
FLCSVILC
FLCSVCN
<;::=
Lock, SR B, or
disabled state
•
FLCSOPSW
.,
A
-
e.
I
LCCA
...J\
"
ILC~SRBM I
~
I
r
LCCA
(0
~
(part 1 of 10)
Termination
Management
J
~:--"~
\,,:;:... ~
Diagram 19-8. SVC Interruption Handler (IEAVESVC)
Extended Description
(Part 2 of to)
Module
Label
IEAVESVC
IEAOSCOO
The SVC interruption handler sets up the proper operating
environment for a requested SVC (supervisor call) by
obtaining any necessary I~cks and initializing registers. The
SVC interruption handler routes control to the appropriate
SVC routine after setting up the operating environment.
1
The SVC interruption handler (IH) immediately saves
the requester's registers in the LCCA. The LCCA resides
in the SOA and acts as a temporary location to save the
requester's status. The SVC IH will later move the status to
a permanent location.
2
Requesters in the disabled state, that are SR Bs, or
that are locked cannot issue SVCs. Therefore, the
SVC IH passes control to RITM, which begins termination
of those requesters. The caller will be abnormally terminated
with an ABEND code of X'OF8'.
3
The SVC IH, after determining that the requester can
issue SVCs, saves the interruption code, and saves the
instruction length.
4
If screening is active for this task rrCBSVCS=l),
the SVC interrupt handler determines if the
caller can issue the SVC as indicated in the Subsystem
Screen Table. If the SVC cannot be issued, control is
given to the screening SVC rather than the SVC that
was req uested.
5
CI.l
g
g.
=
s::
N
~
::s-
o
Q.
o
~
o
'"
~
'"I
I»
g.
=
f"
00
-...J
If the Extended SVC Router (ESR) has been
invoked (that is, either SVC 109, 116, or 122
has been issued), the caller's ESR code in register 15
is used to obtain the appropriate ESR table entry.
The table entry provides the proper entry environment
(locking, type, APF authorization, etc.) for the
invoked service routine.
-<
CI.l
N
o
I.>J
00
oVI
f"
Diagram 19-8. SVC Interruption Handler (IEAVESVC) (Part 3 of 10)
00
00
oc:n
• Type 6 (Step 15).
PSA
~
'
w
be
~
"
VI
•
<
rJ)
' " t-I- - - - -......
~
ow
TCB
SETLOCK
ASCBTYP1
Diagram 19-8. SVC Interruption Handler (IEAVESVC)
Extended Descri}:)tion
4.1
(part 4
Module
of 10)
Label
If the SVC is non-preemptable (SVCNP=1), then the
task is made non-preemptable (TCBNONPR=1).
5
Based on the SVC type, this step branches to the
appropriate processing routine. Note that steps 8
and 9 show processing common to SVC types 1, 2, 3,
and 4.
SVCtype
Steps
1
2,3,4
6-9
10"12
15-16
6
~
~
Q
~
Type 1 SVC Processing
6
To process Type 1 SVCs, the SVr. IH must move the
caller's registers in the TCB and obtain the local lock.
A request is made conditionally, since the SVC IH cannot be
suspended (see the SETLOCK routine). Operation continues,
at step 7, if the local lock is obtained. Otherwise, the SVC
IH changes the RBOPSW in the requester's RB to indicate
that it will be redispatched to reissue the SVC instruction,
and gives the dispatcher control. The requester will eventually be red~spatched.
7
8
r.n
(D
g.
o·
=
~
a=
5
o
....
~
~
o
"0
!
(5'
:=
~
do
\0
The SVC IH indicates Type 1 processing in the
ASCBFLG1 field, bit ASCBTYP1.
Interruptions can now be processed, with the status
of any interrupted programs being saved in the I HSA
(interruption handler save area). The operating environment
for the requested SVC routine can now be set by the SVC
IH. As the first step, the SVC IH obtains any locks that the
SVC routine needs, as indicated by the SVC table.
00
S
of"
\C
I
Diagram 19-8. SVC Interruption Handler (IEAVESVC)
(part 5 of 10)
o
oCI:l
~
l-.J
CI:l
Process
Output
I
t"'"
o
«e.
Type 2, 3, or 4 Processing
~
t"'"
10
c;:
~
-<
~
51
Acquire an SVRB. The SVRB pool is
managed by the SVC FLIH. If an
SVRB pool element is available,
perform s~ep b. If not, do step a and
continue with b.
ASCB
;;3
l-.J
o
(D
a) Initialize SVRB pool.
~
<
CI:l
l-.J
00
,
~
o
W
00
-
W
S
Get pool.
Build SVRB pool.
Chain SVRB pool.
o
-..J
I
I
I
I
b) Normal Request.
Get an SVRB element.
Initialize SVRB.
Chain SVRB to TCB/RB queue.
Move the Registers from the
LCCA save area to the SVRB.
SVRB
RBLINK
TCB
I
i
!Wi
Wi
I
I
I
I
TCBRBP
RB
RBTCBP
Diagram 19-8. SVC Interruption Handler (lEA VESVC)
Extended Description
(part 6
Module
of 10)
Label
7
Steps 8-11 show Type 1 SVC processing, while steps
.
12-14 show Type 2, 3, and 4 SVC processing. Note
that steps 10 and 11 show processing common to all
SVC routines.
8
To process Type 1 SVCs, the SVr. IH must move the
caller's registers in the TCB and obtain the local lock.
A request is made conditionally, since the SVC IH cannot be
suspended (see the SETLOCK routine). Operation continues,
at step 9, if the local lock is obtained. Otherwise, the SVC
IH changes the RBOPSW in the requester's RB to indicate
that it will be redispatched to reissue the SVC instruction,
and gives the dispatcher control. The requester will eventually be redispatched.
9
-<
tf.)
t-J
o
!,H.
00·
o·
The SVC IH indicates Type 1 processing in the
ASCBFLG1 field, bit ASCBTYP1.
(A;
10
Interruptions can now 6e processed, with the status
of any interrupted programs being saved in the IHSA
(interruption handler save area). The operating environment
for the requested SVC routine can now be set by the SVC
IH. As the first step, the SVC IH obtains any locks that the
SVC routine needs, as indicated by the SVC table.
,~
tf.)
~,
=
N
~.
"""'
-<
til
N
o
c..J
00
o
-..J
to
\Q
I Diagram 19-8.
SVC Interruption Handler (IEAVESVC)
(part 7 of 10)
N
orI.I
~
N
1s
~.
Process
SVRB
12
j
~a
(D
~
~N
Indicate Type 3 or 4 SVC
processing.
S~ep8
IGCERROR
13
ABEND Code
Terminate caller who issues
invalid SVC.
00
§
Normal
,FRR Stack
14
Clear the SVC IH bit and restore
the pointer in the FRR stack
to the normal FRR stack.
PSACSTK
Code
To R/TMto
terminate
thecaUer
S
00
s
X'Fxx' - xx equals SVC
number
S
~
N
Diagram 19-8. SVC Interruption Handler (IEAVESVC)
Extended Description
(Part 8 of 10)
Module
Label
111
As the last step, the SVC IH sets the proper values in
input registers used by the SVC routine, and gives the
SVC routine control using the address in the SVC table.
Registers 0,1, 13 and 15 contain the same value as when
the requester issued the SVC.
12
Type 2,3, or 4 SVCs need SVRBs (supervisor request
blocks) built. The SVC IH obtains the storage for an
SVRB, moves the registers from the LCCA and initializes it.
The SVC I H obtains the storage for the SVRB in the manner:
• Attempts to use the GETCELL routine to obtain the
necessary storage for an SVRB.
<
CIl
N
• If the GETCELL fails, the SVC IH determines whether an
ABEND or ABTERM is in process. If so, the SVC IH uses
the GETMAIN routine to obtain the storage for a single
SVRB . .The address space will be terminated if this
GETMAIN fails. If no ABEND is in process, the SVC IH
will try to expand the SVRB cell pool via a GETMAIN. If
the SVRB cell pool cannot be expanded, the SVC IH
gives control to R/TM to abnormally terminate the SVC
requester with an ABEND code of X'OF9'. The SVC IH
will obtain a single cell for the SVRB from the expanded
SVRB cell pool if the attempt succeeded.
• After obtaining an SVRB, the SVC IH indicates whether
the SVRB was obtained by GETMAIN or GETCELL.
When the SVC routine completes, EXIT or Exit Prologue
frees the storage with either FREEMAIN or FREECELL.
13
CIl
(II
(')
g.
=
~
f(
~
[
a.
o
"0
~
ao·
=
~
~
w
The SVC I H suppresses attention exits from processing.
The TCBA IT bits indicate this.
o
W
00
~
~
IC
Diagram 19-8. SVC Interruption Handler (IEAVESVC)
(part 9 of 10)
c...J
Q
oell
y
I
~
•
.Process
ell
~
ell
'S
;-
Output
SVRB
s
t'
14
~.
Indicate Type 3 or 4 SVC
processing.
.....
r-'
~ RBSTAB1
Step 10
I'"
0-
~
a<
<:
ell
IGCERROR
s=
«11
15
~
'<
N
ABEND Code
Terminate caller who issues·
invalid SVC.
.
ell
~
oc...J
"..
ABEND
Code
I
X'Fxx' - xx equals SVC
number
I'"
00
&;
Normal
FRR Stack
!
I
F
R
~
16
"
Clear the SVC IH bit and restore
the pointer in the FRR stack
to the normal FRR stack.
PSA
PSASVC
y
PSACSTK
Completion Code
~
.. I
e
X'1FC'
I
oc...J
Oc
o
V\
Diagram 19-8. SVC Interruption Handler (lEAVESVC)
Extended Description
12
(part 8
of 8)
Module
Label
The SVC IH indicates in the requester's RB that the
SVC is either Type 3 or Type 4.
13
The IGCERROR entry point receives control when
the requester issues an SVC not listed in the SVC
table. This routine terminates the requester with a code of
X'Fxx', where xx equals the number of the invalid SVC.
14
The SVC IH FRR (functional recovery routine)
clears the SVC indicator in the PSA, sets the FRR
stack pointer to the normal stack, and terminates the caller
with a X'1 FC' completion code.
IEAVESVR
-<
til
~
<=>
IN
00
o
-....J
til
CD
~
5'
=
~
iC
~
c::;I.
a.
o
"0
i5'
=
~
I.Q
IN
~
w
<=>
o
til
~
I
Diagram 19-8. SVC Interruption Handler (IEAVESVC) (part 9 of 10)
Process
Input
Output
~
til
CVT (location 16)
,
~
i
Type 6 SVC Processing
15
Type 6 SVC
~
•
Save entry registers in TCB.
t""
•
Prepare registers for Type 6
SVC routine.
~.
;:
~
TCB
Register 4
<
I
~
:3
Tea add~ess
Register 5
(D
I Top RB address
~
'<
til
Register 6
~
I SVC Routine address
<=>
w
00
o
Register 7
--J
I ASCB address
Registers
o
Register 14
16
IEAVET6E: T6EXIT option
selected determines what step is
active.
T6EXIT return address
a. RETURN=CALLER or BR14
15
•
Save registers i~ the TCB.
•
Dispatch the task.
Exit
Prolog
(IEAVEEXP)
b. RETURN=DISPATCH
•
Exit to Dispatcher.
Dispatcher
(IEAVEDSO)
c. RETURN=SRB
•
Is an SRB in this address
space?
Yes, continue.
•
'"
ABEND
No"
. . CALL RTM
Save the task status.
•
Perform job step timing.
•
Take task out of task mode.
•
Dispatch the SRB.
Dispatcher
(IEAVEDSO)
PSA
--I
<
til
~
<=>
w
00
~
Diagram 19-8. SVC Interruption Handler (lEAVESVC)
Extended Description
14
(Part 10 of 10)
Module
Label
The SVC IH indicates in the requester's RB that the
SVC is either Type 3 or Type 4.
15
The IGCERROR entry point receives control when
the requester issues an SVC not listed in the SVC
table. This routine terminates the requester with a code of
X'Fxx', where xx'equals the number of the invalid SVC.
16
The SVC IH FRR(functional recovery routine)
clears the SVC indicator in the PSA, sets the FRR
stack pointer to the normal stack, and terminates the caller
with a X'1 FC' completion code.
IEAVESVR
<
tf}
l-.j
<=>
~
00
~
tf}
~
n
C'.
g
l-.j
~
~
[
o
.....
o
"0
...
~
g.~
4:-
~
:t
......
Diagram 19-9, I/O Interruption Handler (lEAVEIO) (Part 1 of 4)
From I/O New PSW
after Hardware stores
I/O Old PSW
~
--
~
N
CIl
~
~
PSA
(II
;I
PSAIO
i
(;'
t""
o
p
j...
v
1
FLCIOPSW
0:
~
o-<
3=t'D
(
PSA
IEAQIOOO
PSACSTK
Determine whether this is an
I/O recursion,
I/O processing
occurring
"v
LCCA
PSAAOLD
.. Go to Step 4
PSALCCAV
PSATOLD
r-
PSATOLD
~
N
LCCASRBM
~
LCCA
'" 2
v
Q
w
Store TOO clock value, indicate an
lOS interruption, save registers,
PSW, and establish recovery.
00
~
-
~ASCB
\
TCB
~
~
PSAID
v
'"
LCCAITOD
'"v
LCCAIOPS
Determine the type of program that
caused the I/O interruption and save
its status,
•
•
SRB.
•
Unlocked TCBs.
c:::-I
"-
Locally locked TCBs.
t::
ASXB
LCCAGPGR
v
3
ASCBASXB
~
IHSAGPRG
r
'...."
TCB
TCBGRS
~
r- TCBRBP
RB
...
4
...
Go to I/O Supervisor.
To DISMISS Entry
Point in IEAVEIO
.
rL
~
I/O Supervisor
IECINT entry
RBOPSW
Diagram 19-8. SVC Interruption Handler (IEAVESVC) (Part 10 of 10)
Extended Description
Module
Label
Type 6 SVC Processing
15
The Type 6 SVC processor saves the registers
stored in LCCA in the TCB and then sets up input
registers for the Type 6 SVC routine.
TYPE6SVC
Type 6 Exit Processing
16
a.
When a Type 6 SVC exists, there are three options:
RETURN=CALLER or BR14 results in registers 0,1,
and 15 being saved in the TCB and an exit made to
exit prolog to directly re-dispatch the task.
IEAVET6E
~
N
o
W
00
b. RETURN=DISPATCH results in a direct entry into
the dispatcher.
c.
c:n
(D
f)
g.
=
~
~
(D
[
o
0001
o
"0
~
g.~
~
~
t..I
~
RETURN=SRB results in a check of the SRB being
scheduled for this address space. If there is no SRB, an
ABEND is issued. If there is a SRB, the SVC IH saves
the task status (floating point registers and timing
datal, calls the dispatcher job step timing routine
(DSJSTCSRI, decrements the ASCBTCBS count, sets
PSATOLD to zero to take the task out of task mode,
and calls the global SRB dispatcher routine to
directly dispatch the specified SRB.
o-...I
~
~
o
Diagram 19-9. I/O Interruption Handler (IEAVEIO)
...
From 1/0 New PSW
after Hardwa re stores
1/00ldPSW
(I}
'<
t
(I}
N
(I}
'<
~
PSA
~
PSAIO
~(5.
~
~
'<
~
8"
:I
(II
o
I
I
...
} 1
--y
PSALCCAV
(I}
PSATOLD
~ LCCA
...
~~,
Go to Step 4
~TCB
LCCASRBM
N
<:>
W
00
o
,:;!
...
Determine whether this is an
1/0 recursion.
1/0 processing
occurring
r
;
;
[~,~
;
f!
;
,;,
...
v
2
Indicate an lOS interruption, save
registers, PSW, and establish recovery.
II
;;;,;,,;&~
3
:¥
ft;
If the interrupted program was a
task, store the TOD clock value.
II
~:;
:
f;~~
:
;;::
v
~
!;
4
I;
I~I:;;
be,
To DISMISS Entry
Point in IEAVEIO
,~
...
,.
Go to 1/0 Supervisor.
1/0 Supervisor
~
""
IECINT entry
PSATOLD
f;~
t;;
f£,
PSAAOLD
.
ii
~: ~
PSAID
~i
,~:
~
PSACSTK
v
it
~~;
~
'<
PSA
IEAOIOOO
FLCIOPSW
t:
(part 1 of 4)
~
N
LCCA
LCCAGPGR
LCCAIOPS
LCCAITOD.
<:>
w
00
S
Diagram 19-9. I/O Interruption Handler (lEAVEIO) (part 2 of 4)
Extended Description
Module
LabeJ
The I/O interruption handler (lH) saves the requester's
status prior to giving the I/O supervisor (lOS) control.
Furthermore, the I/O IH routes recursive I/O interruptions
directly to the I/O supervisor .
1
The I/O IH looks at the recursive bit (PSAIO) in the
PSA to check for a recursive entry. lOS immediately
receives control for recursive conditions. (I/O recursions
will occur only if lOS enables for I/O interruptions.) Otherwise, normal processing occurs at step 2.
2
The I/O IH sets the recursion hit in the PSA,
PSAIO, to indicate that it is currently processing
an I/O request. It then saves the registers and PSW, and
sets the FRR stack pointer to the I/O stack.
3
If the interrupted process was a task, the I/O
interrupt handler stores the TOO clock value
for job step timing.
4
lOS receives contr()1 to process the I/O request.
lOS reenters the I/O IH at the entry point
DISMISS.
til
(II
~
5'
=
~
is::
[
o....
o
"1:1
~
a
5'
=
~
..D
<.1\.
IEAVEIO
~
N
(:,
~
00
~
~
'"
Diagram 19-9. I/O Interruption Handler (IEAVEIO) (part 3 of 4)
0\
o
From
step 4
til
"<
til
N
til
Input
Output
Process
'<
!4
3
frj"
PSW
DISMISS
'" 5
.---_--.....,..-,)
t:::
t:r
~
'<
~
t\.
If interrupted program was an
SRB or a preemptable task
whose time interval has not yet
expired, reload registers and
PSW to return control.
2'
3
'<
til
N
o
LCCA
LCCASRBM
_
_ ...v 6
00
o
~
LCCAGPGR
LCCAIOPS
N
o
W
00
~
Move status to correct save area.
• Unlocked task- the interrupted
task's status is saved in the TCB
and RB .
W
<::
til
DReg,
To Interrupted
Program
~
~
I
--v
15
I
• Locked task - the interrupted
task's status is saved in the IHSA. ___L -_ _ _ _ _ _ _ _ _- '
PSA
PSAAOLD
t-----....--,\....--------.1
AseB
1
ASCBASXB
I
7
ASXB
If the interrupted process was the
wait task, accumulate the wait
time.
Step 7
H
IEAQWAIT
10..
"
I
Accumulate
CPU wait time
I
~IHSA
11HSAGPRG
IHSACPSW
8
Go to Dispatcher.
IEAVEDSO
Dispatcher routes
control to the
next ready
program
~RB
:
RBOPSW
I
ASXBIHSA
Diagram 19-9. I/O Interruption Handler (IEAVEIO) (Part 2 of 4)
Extended Description
Module
The I/O interruption handler (IH) saves the requester's
status prior to giving the I/O supervisor (lOS) control.
Furthermore, the I/O IH routes recursive I/O interruptions
directly to the I/O supervisor.
1
The 1/0 IH looks at the recursive bit (PSAIO) in the
PSA to check for a recursive entry. lOS immediately
receives control for recursive conditions. (I/O recursions
will occur only if lOS enables for I/O interruptions.) Otherwise, normal processing occurs at step 2.
2
The I/O IH stores the TOO clock value for CPU wait
time calculations. The I/O IH sets the recursion bit in
the PSA, PSAIO, to indicate that it is currently processing
an I/O request. It then saves the registers and PSW, and sets
the FRR stack pointer to the I/O stack.
3
The I/O IH handles the processing for SRSs, locked
TCSs, and unlocked TCSs. The processing differs, as
follows:
• SRSs - The requester's status is saved in the LCCA.
• Locked TCSs - The I/O IH saves the requester's status in
the IHSA.
• UnlockAd TCSs - The requester's status is saved in TCS
and RS.
4
{J'l
(p
a
~.
=
N
a::
(p
s-o
Po
e.
o
'0
~
5'
=
.p.
\0
~
lOS receives control to process the I/O request. lOS
reenters the I/O IH at the entry point DISMISS.
IEAVEIO
Label
~
'"
~
N
i
I
Diagram 19·9. I/O Interruption Handler (lEAVEIO) (part 3 of 4)
Process
Input
DISMISS
i
5
f
•
~N
b
IN
00
S
Determine the type of prog;r8m
returning from I/O supervisor.
•
SRB - Step 6 •
• Tea.
a-S~
c
Output
Step 7 •
Ct'U
wait time
I
PSW
LCCA
LCCASRBM
6
Reload reg,isters and PSW to
give SRBs control.
LCCAGPGR
To Interrupted
Program
~
N
b
IN
00
LCCAIOPS
7
Go to Dispatcher.
8
Clear the I/O indicator and
restore the FRR stack pointer
to point to the normal FRR stack.
IO
IEAODS
Dispatcher routes
control to the
next ready
program
S
Normal
PSA
I::~:K VI
Completion Codes
X'2FC'
k
Diagram 19-9. I/O Interruption Handler (lEAVEIO)
Extended Description
(Part 4 of 4)
Module
Label
5
SRBs do not have CPU wait time calculations done.
SRBs have their status restored by loading the PSW and
registers. The I/O IH resets the PSAIO bit, and restores the
FRR stack pOinter as it was before the I/O interruption
occurred.
If a task has not executed for a specific interval, the interrupt
processing time is deducted from this execution time.
Control is returned to the interrupted routine after its status
is restored.
6
Status is stored in a different area depending on the
interrupted process.
<
en
N
7
8
The wait task has CPU wait time calculations done by
the I EAQWAIT routine.
The I/O IH routes control to the dispatcher. The
I/O IH saves the registers and PSW and resets the
PSAIO bit.
en
(D
(')
g.
:=
~
:::
(D
g
c::;l.
o....
o
"1::1
5g.
:=
~
~
.....
o
W
00
~
.~
Diagram 19-10. External First Level Interruption Handler (lEAVE EXT) (part lof6)
00
From .External New PSW
afterH ardware stores
Externa 10 Id PSW
oCI.l
"<
CI.l
I>.J
CI.l
p
Output
'<
(Il
~
£r;.
C
r::r
~
<:
.0
IEAQXOO
l[D
'" 1
--v
LCCA
-
Save caller's registers.
....
~
'<
CI.l
I>.J
<0
c...I
,..
v
GTF
....
'<
E"
3(p
~ LCCAXGR1
...
OR
..
,..
LCCA
~---
r-----
r- -
2
~
3
PSA
Code
Routine
Timer - - - - - - - - X'10'
Comm Task - - - - - , X'0040'
X'1202'
External Call - - - - X'1201 '
Emergency Signal - - Malfunction Alert - - - X'1200'
LCCAITOD
LCCAXGR2
S
LCCAXRC1
..0lIl
00
B---
Trace
C
1-----
- - 4
....
Check for recursions.
No Recursions (Steps 3-7)
1 Recursion (Steps 8-10)
2 Recursions (Steps 11 -12)
•
•
•
Store status after the interruption,
move regs, set external interruption
indicator, set a recursion indicator,
and establish recovery. Store TOO
if in TCB mode.
PSA
e
-
·V
Timer (IEAOTIOO).
•
Communications Task (IEEBC1PE).
•
•
•
External Call (lEAVEXSI.
Emergency Signal (lEAVEES).
Malfunction Alert (lGFPXMFA).
-
if
~
PSAEXPS1
PSACSTK
External FRR Stack
Determine the type of the external
interruption and give control to the
appropriate second level interruption
handler (SLlH)
•
PSASUP1
...
,.
Appropriate
SLiH
j~
Step 5 - None
Step 10 - One
Step 12 - Two
Diagram 19-9. I/O Interruption Handler (IEAVEIO)
Extended Description
(Part 4 of 4)
Module
Label
5
SRBs do not have CPU wait time calculations done.
The wait task has CPU wait time calculations done by
the I EAQWAIT routine. SRBs and non-preemptable tasks
have their status restored by loading the PSW and registers.
6
The I/O IH resets the PSAIO bit, and restores the
FRR stack pointer as it was before the I/O interruption occurred.
7
The I/O IH routes control to the dispatcher. The
I/O IH restores the registers and PSW and resets the
PSAIO bit.
c;n
8
ow
<:
~
The I/O IH FRR (functional recovery routine) clears
the I/O interruption indicator, and points the FRR
stack pointer in the PSA to the normal FRR stack. It also
terminates the interrupted program, with a completion
code of X'2FC'.
c;n
~
(')
g.
::;s
~
~
(D.
[
~
o
'1:1
::!l
~
g.
::;I
f'o
I,Q
...,.;]
00
o
....
f"
\0
Diagram 19-10. External First Level Interruption Handler (IEAVEEXT) (part 1 of 6)
00
From External New PSW
after Hardware stores
External Old PSW
o
C"I'l
"<
t
C"I'l
N
C"I'l
o Regs
3
;
lD
S
OQ
n'
0:
;
;;
'<
<:
o
=
3
..
'<
('D
C"I'l
N
o
W
00
~
r~);
LCCA
~CCAIHR1
..
t~;
'~_---J}j-2.
""
:,
•
Check for recursions.
No Recursions (Steps 3 -7)
1 Recursion (Steps 8-10)
• 2 Recursions (Steps 11-12)
,';;,"~
I,
I
T race
.i
if
"If
Ii
-...., - -
-
-
-
-
,;
.
Routine
Timer - - - - - - - Comm Task - - - - External Call - - - - Emergency Signal- - -
Code
X'10'
X'OO4Q'
X'1202'
X'1201'
Malfunction Alert - - -
X'1200'
:
Vi
4
I
t
;;",,~,,;;;;;
;
LCCAXGR2
Timer (lEAOTIOOI.
•
Communications Task (tEEBC1PEI.
External Call (lEAVEXS).
•
Emergency Signal (I EAVEES).
•
Malfunct;on Alert (lGFPXMFAI.
r
_"--
PSA
PSASUP1
PSAEXPSl
I
•
LCCAXRC1
,,~:::::::::=i
";
Determine the type of the external
interruption and give control to the
appropriate second level interruption
handler (SLlH)
•
v
c-"
I
if in TCB mode.
-
- )
',"
move regs, set external interruption
rli
t}
indicator, set a recursion indicator,
';;
if
and establish recovery. Store T O D D :
PSA
B
c(
..'"
3 Store status after the ;nterrupt;on.
il
FLCEICOD
~~.J\. i-L-C-C-A-I-T-O-O---i
GTF
...
___
I~'
~
LCCAXGR 1
y
OR
f't:
,t
LCCA
,,~
...
,..
..
C'
i~'
~
Save caller's registers.
fi'
;
t
"1
IEAQXOO
r?}:"
1
1:;1'
Ii;:
I:>
-:]
):;
15
r"'
Out
~
'<
~
p
[;
W-----I
..........
,. t - - - - - - - I
.
~rr~oPriate
J~
Step 5 - None
Step 10 - One
Step 12 - Two
Y
t------f
rpSACSTK
External FRR Stack
Diagram 19-10. External First Level Interruption Handler (IEAVEEXT) (part 2 of 6)
Extended Description
Module
Label
The external FliH initially saves the status of the program currently operating in a temporary location in
the LCCA. The status will be moved later. The external
FLiH then tracks the interruption with GTF or trace.
2
The external F LI H can process two levels of recursions.
Steps 3 - 7 show processing for no recursions; steps
8 - 10 show processing for one recursion; and steps 11 - 12
show processing for two recursions. Note that all levels of
recursions use the function in step 4.
The external FlIH:
• Saves the TOO (time-of-day) value in the LCCAITOD
field if in TCB mode.
• Stores the PSW in the PSAEXPS1 field.
• Moves the register from the LCCAXGR1 field to the
LCCAXGR2 field (to prevent overlaying the LCCAXGRl
field in the event of a recursion).
• Sets the external interruption bit, LCCAXRC1, in field
LCCAIHR1, to indicate one level of recursion.
~
~
S"
:=
N
ac
i
~
o
I
~.
:=
to
\C)
\C)
• Sets the recovery indicator in field PSASUP1.
• Sets the current FRR stack pointer to the external
FliH FRR stack.
Label
The external FliH determines which one of the five
types of external interruption occurred. These interruptions, and how they occur, follow:
• Timer. Occurs when a selected timer interval expires.
• Comm Task. Occurs when the operator presses the
external interruption key on the operator's console.
IEAVEEXT IEAQEXOO
• External call. Occurs after a user issues a SIGP (signal
processor) via an RPSGN L request.
• Emergency signal. Occurs after a user issues a SIGP.
• Malfunction alert. Occurs if another CPU fails.
The external F LI H routes control to the appropriate
second level interruption handler (SlIHL Control returns
to the external FliH from the SLlHs at:
• For no recursions - entry point EXRTNl (step 5).
• For one recursion - entry point EXRTN2 (step 10).
• For two recursions - entry point REC2RTN (step 12).
3
Module
4
The external first level interruption handler (F II H) routes
control to the appropriate second level interruption handler
routine after an external interruption. The external FliH
saves the status of the program operating at the time of the
interruption. The external FLiH can handle recursions, when
external interruptions - either EMS or MFA - occur in an
external second level interruption handler. Two levels of
recursions can be processed by the external F LI H.
1
Extended Description
PROCESS
~
§
Diagram 19-10. External First Level Interruption Handler (IEAVEEXT) (part 3 of 6)
se
~
N
y
From
Appropriate
SLiH
o
Input
Output
C"'-)
'<
~
r-
PSACLHS
~
c:;.
status in the correct save area.
PSALCCA
t:
•
SRB or Spin-type routine.
•
Locally locked TCB.
•
Unlocked TCB.
,.
.... Step 7
~
~
~
[
(P
.r;..
'<
(
LCCASRBM
LCCASPIN
N
~
tN
~
.
'
,
:
"
I,
h c%<
TCB
--...
"
g:g
~
~
II"
LCCA
C"'-)
~
IP:PITE
EXRTNl
5 Check the type of routine and save
PSA
~
6
for wait TCB.
Perform wait time accumu1qting
"'1
.oIIl
IEAQWAIT
1
Timing
"III
f/N
''<,
+1
PSA
*,~
7
Clear exterQal interruption
indicator, recursion indicator,
and recovery.
~
ill,.
..."
IPSASUPl I
To Dispatcher for
TCB, or
interru pted
routine for SRBs
and spin-type
locks.
LCCA
I
LCCAIHRl
I
LCCA
8
Set recursion indicator, move
registers, save PSW, and establish
recovery.
9
Determine type of interruption.
"
lW
~
PSA
J
Step 4
1
··cs
"
PSAEXPS2
-".
PSACSTK
..
Diagram 19-10. External First Level Interruption Handler (lEAVEEXT) (part 4 of 6)
Extended Description
5
After receiving control from the appropriate SLlH, the
external FLiH performs these actions:
• For SRSs or spinning routines, the external FLiH clears
the recovery bit PSAEXT and the externai interruption
indicator LCCAXRC1, and returns to the interrupted program (via an LPSW instruction).
• For locally locked TCSs, the external FLiH moves the
registers from LCCAXGR2 and the PSW from PSAEXPS1
into the I HSA.
• For unlocked TCSs, the registers are moved into the TCS
and the PSW is moved into the RS.
6
If the interrupted routine was the WAIT TCS, the
external F LI H passes control to the Wait routine
(lEAQWAIT) to perform wait time accumulation.
7
The external FLiH clears the PSAEXT bit and the
LCCAXRCl field for SRSs or spinning routines. Control goes to the dispatcher for TCSs.
8
For one recursion, the external FLiH sets a recursion
indicator (a bit) in LCCAI HR 1. The routine also moves
the registers and PSW to LCCAXGR3, to prevent overlaying
them in case of another recursion. The PSW goes to
PSAEXPS2.
9
The external FLiH determines the type of interruption,
and gives the appropriate SLiH control (step 4). Control returns from the SLiH to EXRTN2 (step 10).
rI.l
(D
~
~r
=
t.J
==
(D
[
....
o
o
"0
~
~
o·
=
-~
o
Module
Label
~
S
Diagram 19-10. External First Level Interruption Handler (IEAVEEXT) (part 5 of 6)
.
oc:n
~
N
c:n
'<
Output
Input
~
a
EXRTN2
~f5'
10
Clear recursion indicator and
restore recovery.
IFLCEO~I
11
Establish recovery and determine
the type of interruption.
LCCA
REC2RTN
t""t
~
.5
-<
t
(D
~
~N
::c
(D
~
5
eN
~
PSA
ILCCAXGRll
Return to interrupted program
a nd restore recovery.
./\
To interrupted
program via
LPSW
Clear the external interruption
indicator, according to the level
of recursion. Clear the signal
service flags,
14
Restore the FRR stack pointer
to point to the normal FRR
stack.
Completion Code
X'3FC'
To R/TM to terminate the program
that received the external interruption
Diagram 19-10. External First Level Interruption Handler (IEAVEEXT) (part 6 of 6)
Extended Description
10
The external FLiH clears the recursion indicator,
and returns to the interrupted program, via an LPSW
instruction. Note that the interrupted program will be an
appropriate external SLiH.
Module
Label
Extended Description
EXRTN2
13
11
For second level recursions, the external FLiH determines the type of interruption, and gives control to
the appropriate SLiH (step 4). Control returns at entry point
REC2RTN (step 12).
12
The external FLiH second level recursion FRR
stack has been set at entry to step 11; it is reset at
step 12. The external FLiH returns to the interrupted
program.
The external IH has three FRRs (functional recovery
routines), one for each level of recursion. They all
clear various indicators, restore the FRR stack pointer to
point to the current FRR stack, and terminate the program
that received the interruption.
For no recui"sions, the first FRR clears the external interruption indicator, PSAEXT, clears the recursion indicator,
LCCAXRC1 in the LCCA, and clears any signal service
indicators in the PSA fields PSAIPCES and PSAIPCEC.
REC2RTN
(D
o·~
=
~
~
(D
~
~
o
o'""'
i
=-~r
=
~
o
w
IEAVEE1R
For one recursion, the second FRR clears the recursion
IEAVEE2R
indicator in the LCCA, LCCAXRC2, and the emergency
signal service routine recursion indicator, PSAIPCE2. Note
that the emergency signal primary indicator, PSAIPCES,
will not be cleared if it is not an emergency signal (EMS)
recursion. The external FLIH restores the FRR stack pointer.
For the second recursion, the last FRR clears the EMS
recursion indicator, PSAIPCE2.
IEAVEE3R
14
IEAVEE1R
IEAVEE2R
IEAVEE3R
All the FRRs point the PSACSTK field to the
normal FRR stack, and terminate the program that
received the external interruptions with a X'3FC' completion code.
til
Module
Label
t
Diagram 19-110 Program Check Interruption Handler (PC IH) (IEAVEPC) (part 1 of 12)
~
F rom Program Check
new PSW after hardware stores
the program check old PSW
~
"<
(I)
N
i
t"'"
10
~
n°
t::
~
~
~
2'
:I
(D
~
'<
I
"
,
w
" 1
v>
Save registers, ensure the correct CVT
pointer value, and determine the type
of program check.
•
•
.,
,~
I
tf,'
..
Recursion.
p
..
Address, segment, or translation
exception.
--,r
LCCA
...
,;
LCCAPGR1
Step 9
Step 10
PSA
.
•
(I),
N
2
~
t
Other, continue.
PSAPI
Move registers and PSW, set program
check indicator in the PSA.
r---V
LCCA
~
..
c.N
~
3
'-'
Perform necessary tracing.
~
GTF
,
LCCAPGK2
~
...
OR
.
LCCAPINT
Trace
".
LCCAPVAD
~
...
4
;
Determine whether the program check
was an MC or PER only.
Exit
Yes
5
Determine whether this is a page fault.
•
•
..
r
No, continue.
"
If not, go to step 8.
Otherwise, continue.
..
...
LCCAPPSW
Step 8
Return to
interrupted
program
.
Diagram 19-11. Program Check Interruption Handler (PC HI) (lEAVEPC) (part 2 of 12)
Extended Description
Module
Label
IEAVEPC
IEAOPKOO
Thtt program check IH (interruption handler) receives control from the program check NPSW after a program c .... eck
occurs, traces the program check via GTF or the trace
facility, and routes control to the appropriate routine. The
program check IH processes page faults by giving control to
real storage management, processes Me (monitor call instructions) and PER (program event recording) interruptions by
noting their occurrence and returning to the interrupted
program, and processes the remaining types of program
checks by routing control to R/TM.
1
The program check IH saves the registers in LCCAPGR1
and ensures that the CVT pointer points to the
CVT. Step 9 shows how the program check IH processes
recursions, and step 10 shows processing for address, segment, and translation exceptions.
2
The program check moves the registers from
LCCAPGR1 to LCCAPGR2, and the PSW from
FLCPOPSW to LCCAPPSW, saves the interruptions code
in LCCAPINT, and the translation address in LCCAPVAD
to prevent losing this information if a recursion occurs. The
recursion indicator in the PSA is also set at this time.
3
The program check IH gives control to GTF or, optionally, the trace facility, to record the ,occurrence of the
interruption.
4
re'
::I
~
a:::
i
o
""'
o
1
=-::Ie'
of"
~
The program check IH returns control to the interrupted program if either an MC or PER interruption
alone occurred. (A PER condition can occur with any other
program check,)
5
The program check IH determines whether a page
fault caused the program check. For page faults, control continues at step 6. If the program check was flot
caused by a page fault, control goes to step 8, to continue
processing.
~
i
Diagram 19-11. Program Check Interruptio-n :IIaBdier ~ilH) (tEAVEPC) (part 3 of 12)
7
ofI.I
~
N
Process
Input
fI.I
'<
~
~
Output
I) Determine whether super SPIE
processing is requested.
oic:;.
•
~
;:
~
cSuper SPIE.
'. Otherwise, continue.
xU
'1
~(
C
7
a
(II
'<
fI.I
N
:Rea:1 Storage
it?
<
Q
.a;:.
To caller's
:SPI Er.out ine
,..
Register 15
Code
J. __ .
r-
Management -To
PIX procesSing
(IEAVPJX}
Ha:md'ie 'the :page fault and perform
~
:processjng .(Step 13).
~
'!II
-
. - . - -----Ie--
--T;est retumoode.s from prx
f
w
~
8
~ To D1:S,pat.Cher
=O.
•
Betumcode
•
Return ,code =4.
•
Return'code = 8, C.
~
To lnterrupted
Program
+
+t
ToStep8
.ABEND
TeB
;Process norma! program dlec:iks:
•
Move lregtsters and psw.
•
Perform anySPtE processing if
necessary.
•
l:rdicateprogram check and give
control to RITM.
rL
I\..
I t
1i
£~
_I
To Step 11
R/TM
RS
~
Diagram 19-11. Program Check Interruption Handler (PC ill) (lEAVEPC)
Extended Description
6
The program check I H will determine whether control
should be routed to the caller's super SPJE routine.
If the caHer's super SPIE routine should receive control the
program check IH:
• Sets up the PIE and P1CA.
• Sets ,up the TeB and AB to enter the SPIE exit.
• Route control to the caller's super SP J E routine via an
LPSW instruction.
If thecaHer does not have a super SPI Erout1oe, pr.ocessing
continues at ,step 7.
7
Cantrolgoes to the P IX r,outine, part of Real Storage
Management" to perform the actual paging. PIXi:nteracts with the program dhec'k IH's suspend routine
(I EA VSUSP) to logically suspend the program that received
the page fault if this is a valid page fault and paging I/O .is
required.
PIX ,passes one of four return codes to the programchec'k
IH in register 15. These codes and the actions taken by the
program check IHfollow:
o-
The program was suspended. Control goes to the drspatcher, to dispatch the next ready unit of work.
4 - Either the real storage frame containing the page 'Was
reclaimed ora valid ,page has been referenced ior the
first time - no paging I/O was necessary. Control goes
back to :the program that received the page fault.
rI'l
~
g.
o·
=
~
~
~
g
t:Io
o
100)
o
'C
~
e.
o·
=
~
o
.....
8 - The page was not valid. This will be treated:asan
X'OC4'abend. Control goes to the next series of ,operationsin the program check IH.
C or greater - An internal error occurred in PIX. The task
will be abnormally terminated with a X'028'
code.
8
The,program check IH performs processing fOLnanDATtype program checks:
• For'unlocked TCBs, it stores the status of the interrupted
program in the TCB and RB.
• Any SPI E processing will be performed (step lH, if
requested by the caller.
• For all other cases, control goes to R/TM.
Module
Label
(part 4
of 12)
t
Diagram 19-11. Program Check Interruption Handler (pC IH) (IEAVEPC) (part 5 of 12)
i
~
~
Ul
'<
,
,
Process
Input
Output
r¢
~
LCCA
S"
....
~.
!LCCAPDATI
t:
01'>
f
~
;-
:
9
Process recursion
1st recursion for segment, address, or
translation exception.
•
Set control register 1 to address
of master segment table.
•
•
Indicate first recursion.
CRt
J
...
@Mastersegment
table
y
(D
01:>0
~N
:;0
m
l
LCCA
,,"'
..
Terminate the current address
space.
r'
y
LCCAPDAT
R1TM
(D
ife
CN
2nd recursion for segment, address~ or
translation exception.
~
•
...
Terminate the system.
r
PIE recursions
•
...
Process the original page fault.
r
MCH
System
Termination
Routine
I
Step 7
"
"
Other recursions
•
;
..
Give control to R1TM.
r
Register 1
...~
X'FFFFFFFF'
... r
RtrM
,-
"
,It
........; L...,;,;.-
1
Diagram 19-11. Program 'Check Interruption .Handler (PC HI) (lEAVEPC) (part 60f 12)
Extended :D.escription
9
Recursions in the.program check IH for address, segment, and translation exceptions imply that the interruptionhandlermay be unable to access critical data. There:fore, the first recursion will terminate the address space
while the second recursion will terminate the system.
APIErecursionmeans that a page fault has occurred while
trying to perform super SPI E processing. The program check
IH discontinues super SPIEprocessing,and process the
original page 'fault.
R/TM handles other program check recur.sions.
c;n
~
a
o·
=
~
a:
g-
,~
o.
o....
~
~
ao·
=
~
o
IC
Module
Label
t
-
Diagram 19-11. Program Check Interruption Handler (PC nI) (lEAVEPC)
(part 7 of 12)
o
o
fI}
~
Output
Process
N
fI}
10
'<
~
9
£n'
Process segment, address, or translation
exceptions.
Segment exception
• Set recursion indicator.
• Perform normal program
check processing.
~
~
LCCA
. "• • • Step2
Address exception
• Set recursion indicator.
<:
o
S
a~
.a:.
•
'<
Give R /TM control.
fI}
N
::c
~
i
Translation exception
• Validate control register 0 if it is not
valid.
~
~
~
TCB
11
12
•
Set recursion indicator if CR 0 is valid.
•
Give R /TM control.
Perform SPIE processing
•
Schedule SRB to enter at entry
point IEAVPSRB.
•
Give Dispatcher control.
Determine the validity
of the PIE/PICA.
Step 12
•
Not Valid.
•
Valid, set up for entry to user's SPIE
routine and return to interrupted program.
'14
liM
'\j, ............-~ •.
Diagram 19-11.
Pro~m
Check Interruption Handler (PC IH) (lEAVEPC)
Extended Description
10
Module
(part 8 of 12)
Label
The program check IH handles segment, address, or
translation exceptions in the following manner:
• Segment exception. First, it sets the recursion indicator
(to indicate any recursion conditions) in the LCCA. It
then performs normal program check handling at step 2.
• Address exception. Like segment exceptions, the program
check IH sets a recursion indicator in the LCCA. Then, it
sets a X'FFFFFFFF' value in register 1, to indicate to
R/TM that the interrupted program's status remains in the
LCCA. Control then goes to R/TM.
• Tanslation exception. It validates control register 0
with the default values if necessary. Then it sets
the recursion indicator, and gives control to R/TM
with a x'FFFFFFFF' value in register 1.
11
The program check IH readies the caller's SPIE
routine, as follows. First, it schedules an SRB. The
SRB will enter the program check IH SPIE subroutine at
entry point IEAVPSRB. (The task is set non-dispatchable
until the SRB rout/ine completes.) After scheduling the SRB,
control goes tothe dispatcher to dispatch the SRB at a later
time.
12
~
g.
:=
~
~
(D
[
o
....
o
"0
~
a5·
:=
-i""
The SRB enters at entry point IEAVPSRB. Here, the
program checks the validity of the PIE/PICA. Control
goes to R/TM to terminate the task if the PIE/PICA is not
valid. If the PIE/PICA is valid, the program check IH sets
the proper values in the TCB, RB, PIE, and PICA to give
control to the user's SPIE routine. Control then goes to the
disp~tcher, which dispatches the task to the caller's SPI E
routine.
IEAVPSRB
t
-
'Diagram 19~:ll.Program Check Interruption Handler(pCm) (IEAVEPC) (part 9 of 12)
N
o
.re
-<
'fI.)
'N
'fI.)
liuspena ~MDS ana
locally locked TCBs.
Input
,.
• 0iW
:=.
'.§
TCB
LCCA
/'
ips.
""
LCCAPGRS
i
II'
13
Perform page fault suspension.
~,A
~
)
'
(")
g.
=
N
a::
n>
[
o
....
o
"0
~
e.
5·
=
~
N
(,N
t
Diagram 19-13. Signal Service Routines -IPC (IEAVEDR) (part 5 of6)
N
..a:.
oCIl
~
N
Input
From steps 4, 10,
or system routines
issuing DSGNL
macro instructions
Process
Output
CIl
'<
~
c
:1
oic:;.
IEAVEDR
(Input from Steps 4 and 10)
Not a valid
PCCA address
12
Determine the validity of the
PCCA address.
13
Determine whether this is a multi·
processing configuration.
ABEND code
X'07B'
t"'I
~
.~
~
=
e
c
~
~
•
N
f
~
~
No, go to caller wjth
retu rn code = 16.
caller
14
Issue SIGP instruction and check
condition codes.
Reg 15
•
Successful.
•
Access to CPU blocked.
•
Unsuccessful.
•
CPU not operational.
I
~
~
o4812 16 -
]
To caller
(Step 5 for
IEAVERI;
Step 11 for
IEAVERP)
Recovery for Remote Immediate
15
Clear buffers and indicators.
Code]
Successful
Access blocked
Unsuccessful
CPU inoperational
Uniprocessor
PCCA
D
Diagram 19-13. Signal Service Routines - IPC (IEAVEDR) (part 6 of 6)
Extended Description
Module
12
IEAVEDR
The direct signal routine checks the validity of the
PCCA address, and gives control to ABEND for an
invalid address.
13
The direct signal routine checks to see if this is a
multiprocessing configuration. If it is not, control
goes back to the caller, with a return code of 16 in
register 15.
14
The direct signal routine issues the SIGP instruction
dnd receives a condition code. Control then returns
to the caller.
15
The signal services FRR (functional recovery routine)
handles errors occurring during the R ISGN L sending
processing (module IEAVERI). The signal services FRR
ensures that recovery occurs on the same CPU that the error
occurred. The signal services FRR then clears the EMS
buffer in the PCCA, clears the super bit, PSAIPCRI, and
clears the spin bit, LCCASIGP. Control returns to RITM,
which subsequently gives control to the caller's error
recovery routine.
f(l
~
o·
=
!'!
==:
(I)
[
o.....
o
"C
~.
~
g'
t'
N
VI
IEAVEIPR
Label
~
Diagram 19-14. External Call Second Level Interruption Handler (IEAVEXS)
(part 1 of 2)
N
0'\
From the External
First Level Interruption
Handler (lEAVEEXT)
to process an external
call interrupt
~
~
N
fI'l
'<
~
Input
Output
~
~f;'
r-'
6'
~
~
[
.,..
(II
'<
PSA
B·--~
l
Obtains the PCCA of the
receiving CPU.
2
Perform the service requested by
the RPSGNL macro.
PCCARBP
•
For memory Switch.
•
For SIO.
•
For RQCH ECK.
•
For GTF.
•
For MODE.
•
For MF/1.
•
Clear indicator.
fI'l
N
~
i
w
~
3
Return to caller.
PCCA
To External First
Diagram 19-14. External Call Second Level Interruption Handler (IEAVEXS)
Extended Description
The external call second level interruption handler (SLlH)
routes control to any of six service routines requested by
the RPSGNL (remote pendable) function. The external call
SLiH can pass control to these routines:
• Memory switch routine.
• Start I/O receiving routine.
~.
RQCHECK routine.
• Generalized Trace Facility routine (GTF).
• MODE routine.
• Measurement Facility (MF/1).
Control returns to the external call SLiH from these routines; the external call SLiH returns control to the external
call FLiH.
Module
Label
(part 2 of 2)
Extended Description
Module
Label
1
IEAVEXS
IEAVEXS
The external call SLiH locates the PCCA (physical
control communications area) of the CPU executing
by referring to the PSA (prefixed storage area).
2
The PCCA contains an indicator, in the remote pendable buffer (PCCARPB), of the service requested in the
RPSGNL function. The external call SLiH checks the
PCCARPB field, sequentially for each possible condition, to
determine which services should receive control. In each
case, the external SLlH:
• Determines the actions requested in the RPSGN L
function.
• Turns the indicator in the PCCARPB off.
• Branches to the appropriate service routine.
• Double-<:hecks the PCCARPB to ensure that no new
requests have occurred during the previous processing.
3
I:"Il
~
a
~.
=
!'!
a::
~
Q.
~
o....
o
"ia.
o·
=
~
~
~
Control returns to the external call F LI H.
of"
~
~
~
N
Diagram 19-1S. Emergency Signal Second Level Interruption Handler (IEAVEES)
(part 1 of 2)
From External First Level
Interruption Handler (lEAVEEXT)
to process Emergency Signals:
Output
en
«'
=-~.
i
1
PSA
Checks whether this is the first
entry into the emergency S LI H.
(IS'
t:'!
:it
~
•
First Entry.
•
Recursive.
~
=
e
~
~
'<
rI:l,
N
2
Obtai n the address of the
sending CPU's PCCA.
3
Give control to Recovery
Management Support. if
necessary:
~
i
~
IN
~
Processes
the request
~;
•
Parallel - clear indicator
and route control.
~
,
:/:
:;~
!
•
4
..
."
Receiving Routine
Performs
requested
service
Serial request - clear
indicator.
Clean up PSA fields.
External First Level Interruption
Handler (I EAV EEXT)
PCCA
t.:
""
Diagram 19-15. Emergency Signal Second Level Interruption Handler (lEAVEES) (part 2 of 2)
Extended Description
Module
Label
Extended Description
Module
1
1EAVEES
The emergency signal second level interruption handler
(SlIH) receives control from the external FliH and
routes control to a specified receiving routine to' process an
emergency signal (EMS),
The ~mergency signal SLI H checks the PSA SUPER
bit to determine whether this is a recursive entry, and
then indicates the type - either first entry or recursive
entry - in the same PSASUPER field.
The emergency signal SliH handles these types of requests:
2
• RMS (recovery management support)
• Serial
• Parallel
For RMS requests, the emergency signal SliH branches to
the RMS service routine, For serial requests, the emergency
signal S 1I H turns off an indicator bit after receiving control
back from the specified receiving routine; for parallel
requests, the emergency signal Sli H turns off an indicator
bit before it branches to the specified receiving routine,
Control always returns to the emergency signal SlIH,
The emergency signal SLiH indexes into the PCCA
vector table, using the PSASPAD, to obtain the sending
CPU's PCCA.
3
At this point, the emergency signal SliH processes
RMS, serial, or parallel requests. Control goes to RMS,
to process the request using the address in a VCON. To
process serial or parallel requests, the emergency signal
SLI H obtains the entry points for the specified receiving
routine from thePCCAEMSE field of the sending CPU's
PCCA. The emergency signal SLiH clears the PCCAEMSI
indicator to allow the sending CPU to proceed.
4
f(J
Q.
e'
:::t
~
ac
~
g
Q.
Q
....
o
1~
e'
:::t
....to
~
The emergency signal Sli H cleans up PSA fields, and
returns to the external FliH.
Label
t
Diagram 19-16. Stage 1 Exit Effector (IEAVEFOO)
(part 1 of 2)
CN
o
From SVC IH to
begin scheduling an
asynchronous
exit routine
Output
~
~
~
rt.I
a
~
i
•••••••••••••••11
•
b ....iLlifmm.
fIM:_:,
Process
-
iiii
IGC043
(;.
IGC043BR
t""
6'
~
1
i
GETMAIN
Routine
Obtain storage for an IRB.
II
(D
~
2
Obtain a work area if requested
with IRB.
3
.Obtain a save area if requested
with IRB.
'<
Reg 1
I RMBRANCH
Address of the IRB
72 Byte Problerm
.Program Save
Area
rt.I
~
~
i
RegO
[@o~i~r~utin;
]
IRB
CN
~
Reg 1
coPtio-;t;iu - T -
-r-
RBPPSAV
1/
I
I
I
JI_ - - - -
4
>
Initialize the IRB.
Size workarea )
For branch entries,
to caller via branch
For SVC entries, to
caller via Exit Prologue
~----
Work
Area
I
Diagram 19-16. Stage 1 Exit Effector (IEAVEFOO)
Extended Description
(part 2 of 2)
Module
Label
IEAVEFOO
IGC043
IGC043SR
The Stage 1 Exit Effector is called by supervisor or data
management routines. Its purpose is to create and initialize,
according to input parameters, an IRB (interruption request
block) to control a user exit routine whose future use is
requested by the caller.
1
The stage 1 exit effector calis GETMAIN to obtain
storage for the IRB from LSQA, subpool 253.
2
The caller may request a work area to be appended to
the IRB. This work area will be released when the IRS
is freed.
3
4
Stage 1 exit effector obtains storage for the save area
from the problem program's subpool 0, if requested.
The information placed in the IRS during initialization
includes the save area address, the entry-point address
of the user exit routine, the size of the RB, the PSW to be
loaded to start execution of the asynchronous exit routine,
and bits indicating whether the IRB should be freed by
EXIT.
CIl
(1)
S4.
5·
=
N
~
(1)
~
o
~
o
-.
o
'0
~
a5·
=
-f"
w
of'"
.....
Diagram 19-17. Stage 2 Exit Effector (lEAVEEE2)
(part 1 of 2)
~
N
From supervisor and
data management routines
to perform the second
step in scheduling an
asynchronous exit routine
~~
rI:l
'<
~
Input
S
{
t':
go
s
f
~
~N
'!:I!'
~
~
~
~
~
IEAOEFOO
RegO
[~,O~;SRB@
Reg 1
I
I
A,ddress of IOE,
ROE, or 0
IOE: Complemented addres$
ROE: True address, high-order
byte == X'OO'.
0:
Register 0 contains an
SRB@
Register 1
J.-
1
Calling routine has built on
IOE, ROE, or SRS. Oueue it
on the appropriate exit q'ueue.
J
2
Set the Stage 3 switch for the
and the Stage 2
switch for SET LOCK.
dispa~cher
Branch to
Caller
1%1
OAi
II
m,
ti
~
Address of IOE, SRB or ROE in
VI&..._tr_u_e_fo_r_m_ _ _ _ _ _ _ _..1
IOE on ASXBFIOE
ROE on ASXBFROE
SRB on ASXBFSRS
(See Stage 3 Exit Effector for
the queue structure)
Diagram 19-17. Stage 2 Exit Effector (IEAVEEE2)
Extended Description
Module
Label
1
IEAVEEE2
IEAOEFOO
The exit queue on which the Stage 2 Exit Effector
places the input queue element depends on whether
the queue element is an IOE (interruption queue element),
an ROE (request queue element), or an SRB (service request
block).
Type of
Queue
Element
Purpose
Type of
Exit
Queue
IOE
Supervisor routine wants to
schedule an asynchronous
exit routine.
ASXBFIOE
ASXBLIOE
ROE
Data management routine
wants to schedule an
asynchronous routine.
ASXBFROE
ASXBLROE
SRB
1/0 supervisor wants to
schedule an error recovery
procedure (ERP).
ASXBFSRB
ASXBLSRB
2
This indicates to the dispatcher that an asynchronous
event is available for scheduling and causes the dispatcher to call the Stage 3 Exit Effector.
The SETLOCK service checks the stage 2 switch (ASCBS2S)
when it releases the local lock.
en
~
a
o·
=
N
;s::
~
~
c:;l.
....
o
o
"'l:I
~
a
o·
=
t
eN
eN
(part 2 of 2)
t
Diagram 19-18. Stage 3 Exit Effector (lEAVEEEO) (part 1 of 4)
~
~
o
tI)
~
N
Branch from the
dispatcher to complete
scheduling an
asynchronous exit routine
Output
tI)
'<
~
3
TCB
t""'
cit;.
t""'
1
~
•
.$
TCBGRS
Dequeue IQEs, if possible
IQE dequeued .
___I ••• Step 4
~
TCBRBP
<:
o
=
=
RB or SIRB
~
~
'<
2
RBFACTV
Dequeue RQEs,if possible
tI)
N
•
:;::cI
~
RQE dequeued.
___I ••• Step4
RBOPSW
;-
RBGRSAVE
~
~
~
RBIQE
~
3
•
4
ASCB
Dequeue SRBs, if possible
SRB dequeued.
Queue the IRB or SIRB to
the TCB and dispatch the
asynchronous exit.
__..I... Step4
I
ASCBTCBS
I
Diagram 19-18. Stage 3 Exit Effector (IEAVEEEO) (part 2 of 4)
Extended Description
Module
The stage 3 exit effector is the last routine used to schedule
an asynchronous exit. The stage 3 exit effector dequeues
IOEs (interruption queue elements), ROEs (request queue
elements) or SRBs for asynchronous exit queues pointed
to by the ASCB. The dispatcher enters the stage 3 exit
effector as a subroutine.
1
Supervisor services use IOEs as a general interface for
requesting scheduling of an asynchronous routine.
For each IOE on the asynchronous exit queue, stage 3
exit effector does the following:
• It will first determine if the IOE can be dequeued at this
time. An JOE will not be dequeued if:
A. The IOE has been purged by DUMP (JOEPURGE=11.
B. The IRB (interruption request block) is already being
used (RBFACTV=11.
C. The task that the asynchronous exit is to process is
executing on another CPU.
D. The asynchronous exit is being scheduled to the error
task and an error recovery procedure is in process on
that task.
C"'-)
g.
=
N
a::
(I)
So
Q.
....
o
o
'e
(I)
3.o·
=
of"
tH
tit
SRBs on the queue represent requests by lOS to
schedule non-resident error recovery procedures. There
is a single system IRB per address space, and stage 3 exit
effector will try to schedule this SIRB for only the top SRB
on the queue. The SIRB will not be scheduled if the error
task is already executing on another CPU, or if an error
recovery procedure is in process in that address space. The
transfer control function is in process for the TCB that stage
3 is checking (TCBS3A=11. If this flag is not on, it is turned
on by stage 3. If the ERP can be scheduled at this time, the
top SRB will be enqueued to the task specified as the error
task in that address space.
A. The IRB must be placed on the RB chain of the specified
task. The IRB becomes the current RB for that task.
B; The saved registers of the previously current routine are
moved from the TCB to the IRB General Register save
area.
For each ROE on the asynchronous exit queue, a series of
tests will be made to determine if it can be dequeued at
this time. It will not be dequeued if:
A. Asynchronous exits are suppressed for the task
(TCBFX=1).
B. The task it is being scheduled to is active on another
CPU.
C. The IRB is already in use (RBFACTV=11.
Label
3
F. This is an attention exit being scheduled and either
all asynchronous exits or attention exits are suppressed
(TCBFX=1 or TCBATT=1) for the intended task or
any of the task's descendants in the task tree.
Data management uses ROEs as a special interface in
scheduling an asynchronous exit.
Module
D. The asynchronous exit is being scheduled to the address
space's error task and an error recovery procedure is
already executing on the error task.
For those ROEs that may be dequeued, the ROE will be
removed from the queue, and the specified IRB will be
enqueued to the TCB.
E. The transfer control function is in process for the TCB
that stage 3 is checking (TCBS3A=11. If this flag is not
on, it is turned on by stage 3.
4
• For all IOEs that can be dequeued, the IOE will be
removed from the queue, and the IRB associated with the
IOE will be enqueued to the specified TCB.
2
Extended Description
E. Asynchr.onous exits have been suppressed for the
intended task (TCBFX=11.
G. The transfer control function is in process for the TCB
that stage 3 is checking (TCBS3A=11. If this flag is
not on, it is turned on by stage 3.
(I)
(')
IEAVEEEO
Label
In order to schedule the asynchronous routine, stage 3
exit effector must do the following processing:
C. The IRBis marked active (RBFACTV=1) so that any
other requests for use of the same IRB will be deferred .
D. The address portion of the RBOPSW is set to the address
specified in the RBEP field. This ensures that the dispatcher
gives control to the asynchronous routine at the specified
entry point.
E. The RBIOE is set to point to the queue element that
scheduled the asynchronous routine (JOE, ROE, or SRB)
area so that the asynchronous exit gets control with
specific register contents.
F. If this task has been made ready and it previously was
not, the count of ready TCBs (ASCBTCBS) is incremented by one.
G. Registers are initialized in the TCB to set up for entry
to the asynchronous exit.
H. Stage 3/TCTL intersect flag is turned off (TCBS3A=O).
<:
C"'-)
N
otH
00
9
tw
Diagram 19 .. 18. Stage 3 Exit Effector (IEAVEEEO) (part 3 of 4)
0'\
o
~
r.f.l
N
r.f.l
Input
From dispatcher
recovery (lEAVEDSR)
Output
'<
~
§
Stage 3 Exit Effector Recovery
t'""
J6r;'
Co
~
~
~
[
Reg 1
~SDWA
5
iMd
iM&
./1
Verify and correct the
asynchronous exit queues.
•
Verify IOE queue.
•
Verify ROE queue.
•
Verify SR B queue.
Recorded
Errors
Verifies the
queues
~
~
'<
r.f.l
N
o
PSA
IQE
W
00
S
PSAAOLD
ASCB
ASCBAXB
ASXB
ASXBFIOE
ASXBUOE
ASXBFROE
ASXBLRQE
ASX8FSRB
ASXBLSRB
Diagram 19-18. Stage 3 Exit Effector (IEAVEEEO) (part 4 of 4)
Extended Description
Module
5
IEAVEEER IEAVEEER
The stage 3 exit effector recovery routine verifies and
corrects the Exit Effector queues (which consist of an
IOE queue, and ROE queue, and an SRB queue). It uses the
Oueue Verifier (lEAVEOVO) to perform this verification.
It calls the routine three times, once for each queue. After
each call, it will store a word of zeroes into the recording
area to delimit the end of the recorded output. The verification of each queue element is performed as follows:
• For an IOE, the Address Verification routine ensures that
the IOE address, the TCB address contained in the IOE,
and the IRB address contained in the IOE are all referenceable.
• For an ROE, verification includes ensuring thatthe ROE
storage and the IRB and TCB storage pointed to by
ROERRO and ROETCB are all referenceable.
• For an SRB, verification ensures that the SRB storage is
referenceable.
~
$l-
o·
=
~
~
(D
[
o
.....
o
1a
o·
=
,.
-
~
.....
Label
f"
Diagram 19-19. SCHEDULE Processing (IEAVESCO) (part 10f6)
IN
00
From the Dispatcher (I EAVEDSO)
to Process a
schedule request
o
t"I'.l
~
Input
Output
N
t"I'.l
'!
ar-
«i(;"
t""I
e:
~
~
CVT
IEAVESC1 Global
D
, GSMQ
a=-
1
Determine the priority of
the req uest.
2
Queue the SR B from the
GSMQ to the GSPL at the
appropriate priority"
~
~
'<
t"I'.l
N
~
~
Non-quiesceable priority
\
~ SRB
3
~
IN
~
Notify waiting CPUs to
process SR B ~
SRBPRIOR
System
priority
,
, SRB
To Dispatcher
OEAVEDSO)
SRB
Diagram 19-19. SCHEDULE Processing (IEAVESCO) (part 2 of6)
Extended Description
Module
Label
IEAVESCO
IEAVESCl
The Schedule service allows the requester to schedule
system services. These system services can be scheduled to
execute in any address space at either global or local priorities. System services scheduled at the global priority have
a priority higher than that of the address space; those
scheduled at a local priority have a priority higher than any
task in the address space.
The Schedule routine has two entry points - one for local
priorities, one for global priorities.
1
Schedule determines the address of the specific
priority level. Schedule indexes by the value in
SRBPRIOR into a table which contains the address of the
specific level (Global Priority Index Table).
2
Schedule queues the SRB from the GSMQ (global
service management queue) to the GSP L (global
service priority list! in FIFO order.
3
Schedule tests for CPUs dispatched to the wait task.
Waiting CPUs will be activated to dispatch the SRBs
on the GSPL. This will be tested by checking the count of
CPUs disPatched to tasks, ASCBCPUS, in the wait ASCB.
Schedule signals waiting CPUs (via RPSGNL, using the
external call) forcing an entry to the dispatcher.
~
a
~r
==
N
~
(D
io
o""'
't:I
Q
a
5'
==
t"
W
\Q
t
Diagram 19-19. SCHEDULE Processing (lEAVESCO) (part 3 of 6)
~
o
;;3
~
N
fIl
From the
Output
Input
'<
~
§
t""
Ji
o·
1:
~
~
~
[
(II
IEAVESC2 Local
LSMQ
D
~
ASCB
4
Queue the SRB to be
processed to the local SPL.
5
Notify the System Resource - . . . . L - - - - - - " J
Manager that a swapped out
address space has ready
System Res.
work.
Manager
6
Indicate ready work to
Memory Switch.
SRB
~
~N
Reg 0
~
i
Y6
w
:...
, SRBASCB
ASCB
ASCBSPL
Memory
Switch
To Dispatcher
(lEAVEDSO)
ASID
Code
Diagram 19-19. SCHEDULE Processing (lEAVESCO) (part 4 of 6)
Extended Description
4
Schedule locates the local SPL via ASCBSPL, from
the ASCB indicated in SRBASCB. Schedule locates
the priority level in the SPL by indexing by the value of
SRBPRIOR into the Local Priority Index Table (LPIT)
assembled in the schedule routine. Schedule queues the
SRB to the requested priority level at the end of the
queue.
5
Schedule notifies SRM (system resource managed
of work ready to be dispatched to an address space
already swapped out. This will cause an eventual swap-in
of that address space.
Schedule also notifies the timer supervisor, by turning off
ASCBTMLW, that the address space is no longer in a long
wait.
6
Schedule calls memory switch to determine whether
the ready address space has a higher priority than the
current address space. Schedule will indicate if the SRB has
CPU affinity, if necessary, by sending a complemented
value in register 1.
(I)
~
a
5'
=
~
~
~
~o
~
o
~
Q
=5'
='
-~
~
Module
Label
IEAVESC2
t
Diagram 19-19. SCHEDULE Processing (lEAVESCO) (part 5 of 6)
~
~
~
~
c:Il
'i
~
Input
~. . . . . . . . . . . . . . . . . . . . . . . . . .
F rom dispatcher
recovery
(lEAVEDSR) or
PURGEDQ
Schedule Recovery
PSA
r-
ei
IEAVESaV
IEAVESCR
LCCA
c:r
Output
Process
r-
az
!
LCCASMQJ
7
Verify the SRB journal queue.
8
Reschedule SRBs on the journal
~
c
g
~
~
®.~ !.:, .
~
~
queue.
i
:!'."
I.,~§
~
w
~
CVT
•
9
:.
SDWA
r
•.
th~ LSPL
the
Verify the GSPL and
for every address space
~
system.
In
~1
"1;'&.0
'.TY
I
.,
'"
..
•
~
A
"'~'"
I
'"
ASCB
To dispatcher recovery (lEAVEDSR)
or PURGEDQ recovery (lEAVEPDR)
SRB
$p
tt
____
Errors
Recorded
Diagram 19-19. SCHEDULE Processing (lEAVESCO) (part 6 of 6)
Extended Description
7
The Schedule FRR verifies the SRS journal queue,
which is anchored out of LCCASMQJ field and
removes SRSs with bad information. The journal queue is
used by Schedule to prevent losing SRSs that are being
processed.
8
9
Schedule FRR then re-schedules any SRSs remaining on the journal queue.
The Schedule FRR uses the Queue Verifier to verify
SRS queues - the GSPL, and the LSPL for every
address space in the system. Errors detected are recorded
in the SDWA; elements removed are also noted in the
SDWA.
~
o·~
=
~
~
~
[
o
.....
o
'1:;j
~
a
o·
=
~
~
w
Module
Label
-
Diagram 19-20. PURGEDQ Processing (lEAVEPOO) (part 1 of 4)
oen
Input
of"
~
~
~
From the SVC IH to process
PURGEDQ requests
Process
N
en
'<
Output
1
Check the validity of
the parameter list.
2
A lIow the active SR Bs to
complete processing if
request is for current
address space.
~
~
Abend Code
I X'17B' ABEND code]
r-
ei
n·
@ Parm List
r-
§=
~
~
c:
Internal Queue Used by PURGEDQ
a
InternalVVorkarea
CD
~
'eel when
the error occurred.
...
...
...
STATUS
....
IN
~
u
9
L---..
Record address of SRB if an
'RMTR was in control at time
of error.
Work area
10
Attempt to retry the PURGEDQ
request.
Exit
•
Retry.
To Step 1
•
No retry.
I
I
Exit
Give control
to caller's
recovery.
I
Recording
Area
~------
Diagram 19-20. PURGEDQ Processing (IEAVEPDO) (part 4 of 4)
Extended Description
Module
Label
7
Upon receiving control back from that routine, the
FRR issues the SETRP macro to set fields in the
SOWA for recording information and to indicate that the
error should be processed by the PURGEDO ESTAE
routine. It then returns to R/TM, which percolates the error
to the ESTAE.
8
The PURGEDO ESTAE routine receives control if an
error occurred anywhere in the PURGEDO mainline
function. It performs cleanup to ensure correct system
status. It starts SRSs, via STATUS, if they had been stopped
when the error occurred.
9
If an error occurred in an RMTR routine, EST AE
records (in the SDWA) the address of the SRS that
the RMTR was cleaning up.
10
The PURGEDO ESTAE routine determines if the
PURGEOO function should be retried. It sets up for
the retry to the beginning of the PURGEDO mainline if either
this error occurred for the first time during this in-v'ocation
of PURGEDO or if the error occurred during the processing
of an RMTR routine. If neither of these conditions is true,
then the error will be processed by the caller of PURGE DO.
tf.l
Q
g.
o·
=
~
s::
Q
g
~
o.....
o
"C:I
~
ao·
=
~
.....
~
......
IEAVEPDE
t
~
~
til
Diagram 19-21. SETLOCK Processing (lEAVELK) (part
1 of 14)
From supervisor routines
to obtain a lock, via
SET LOCK macro instructions
Input
Output
N
til
'<
I
Obtaining Locks
PSA
Completion Code
t"'"
cipr
PSACLHS
~
PSACLHT
-I-
I
c:
.$
~
I
PSACPULA
C
I
1-I
~
~
~
i
~
w
I
L_
Register 12
;;
Hierarchy mask of
locks requested
Determine if the CPU.already owns
the lock.
Owned
Register 14
[
Caller's return address
Register 13
=4
Return Code
Register 13
3
Try to obtain the lock and indicate
that this CPU owns it, if
obtained.
•
Return Code
If not obtained, continue.
=0
Lockword
To Caller
CPUID/or ASCB@
PSA
1
1
Caller
Register 13
Entry point address
for lock request
-]
No violation, continue .
Yes
2
I
@ of lock, or 0
X'073'
Violation.
I
Register 11
r
1-
Perform hierarchy violation check
for unconditional requests.
•
I
I
:3
~N
1
PSACLHT
PSACLHS
- -]
Diagram 19·21. SETLOCK Processing (lEAVELK) (part 2 of 14)
Extended Description
Module
SETLOCK provides the means for a user to obtain "locks"
that serialize the use of a resource. SETLOCK provides
13 locks:
IEAVELK
• OISP (for dispatcher lock)
• 10SCAT (for lOS channel availability lock)
• 10SUCB (for lOS unit control block lock)
• 10SLCH (for lOS logical channel queue lock)
• 10SYNCH (for lOS synchronization lock)
• ASM (for auxiliary storage management lock)
• SALLOC (for space allocation lock)
• SRM (for the system resource management lock)
, • CMS (for the cross-memory services lock)
• LOCAL (for local address space lock)
SET LOCK both obtains and releases locks. There are two
distinct methods of obtaining locks; conditional obtain and
unconditional obtain. SETLOCK will immediately return
control to the caller if no lock can be obtained for a conditional request; SETLOCK will not return control until the
lock is obtained for an unconditional request.
CIl
(D
s:a.
e·
=
N
a:
(D
[
o....
o
'"C
l.l
a.
~5"
=
f"
~
Label
Extended Description
Module
1
IEAVELK
SETLOCK determines whether the caller has violated
the locking hierarchy by:
• Requesting unconditionally a lock lower in the hierarchy
while a higher lock is held.
• Requesting the CMS lock while not holding the local
lock.
• Requesting a class lock when another lock in that class
is already held.
• Requesting a suspend lock while disabled.
SETLOCK abnormally terminates callers who violate the
hierarchy, with a X'073' completion code.
2
First, SETLOCK determines whether this CPU already
owns the requested lock. If this CPU owns it, SETLOCK
returns a code of 4 in registe~ 13, and returns control to the
caller. Otherwise, processing continues.
3
SETLOCK tries to obtain the lock. If the lock is available (the lockword contains 0), SETLOCK indicates
ownership by placing the logical CPUIO in the lockword,
setting the indicator in the CPU locks held string, PSACLHS,
and for class locks, by storing the address of the lockword
into the CPU locks held table, PSACLHT. SETLOCK will
then return to the caller with a zero return code. If the
lock is not available, proceed to step 4.
Label
;t'
Diagram 19-21. SETLOCK Processing (IEAVELK;) (Part 3 of 14)
CIa
c:>
i
~
w
fI)
Output
Process
1
9
i
t""
4
Perform the necessary processing if
the CPU cannot obtain the lock,
according to the type of request.
5'
~
•
For conditional requests.
•
For unconditional requests of
a suspend-type lock.
•
For unconditional requests of a
spin-type lock, issue the Window
Macro instruction, and check for
ACR processing.
•
Again try to obtain the lock.
~
;:
i
~
~
w
,.,
e.
I
w
~
Register 15
Return Code = 8
Diagram 19-21. SETLOCK Processing (IEAVELK)
Extended Description
4
• For conditional requests, SETLOCK will indicate a return
code of 8 and return control to the caller.
• For unconditional requests of suspend locks (local or
CMS), proceed to step 5.
• For unconditional requests of spin locks, enable for EMS
(emergency signal) and MFA (malfunction alert) interruptions via the WINDOW macro. (This is done to prevent
deadlock in case of failure on the other CPU.) SETLOCK
will then determine if an ACR (alternate CPU recovery)
condition has occurred. If so, it will route control to
R/TM. SETLOCK again attempts to obtain the lock in
step 3.
C"n
('I>
~
o·
=
~
s::
('I>
;.
o
~
o
.....
o
"0
~
~
o·
=
f'
VI
(part 4
of 14)
Module
Label
;t
Diagram 19-21. SETLOCK Processing (IEAVELK) (part 5 of 14)
(It
N
&i
"<
fIl
N
rn
-------
,~
Process
Output
~
f
i
i
5
Perform suspend prooessing when the
CPU cannot obtain the lock.
•
,.~ B
Acquire storage for SSRB.
~
...
~
[
~
CD
~
GETCEll
~
TCBGRS
~
f
-
r------------------
...
~N
w
TCB
~
~
~
GETMAIN
r
~
For unlocked TCB
•
~RB
Save register values and PSW in the
appropriate locations.
"
,
RBOPSW
For locked TCB
" IHSA
y
1-------------------IHSAGPRS
!
I
I HSACPSW
For SRB
~...
.... SSRB
ill ..
Tasks requesting the local lock
•
P.laoe the.ASCB or SSRB on the
lock suspend queue,
. I
r
... 1--___________----__
To Dispatcher
(tEAVEDSO)
....) (See Input
" for Step 17)
SSRBGPRS
!
I
~
~
."'--~
SSRBCPSW
'------------------....1
Diagram 19-21. SETLOCK Processing (lEAVELK) (part 6 of 14)
Extended Description
5
For callers in SRB mode, SETLOCK will acquire
storage from SQA for a suspended SRB (SSRB) in
which to save the suspend status. SET LOCK will then set
resume registers and PSW to cause reentry to SETLOCK.
The location of the saved status depends upon the mode of
the caller. SET LOCK places either the ASCB (for tasks
requesting the CMS lock) or the SSRB on the lock's suspend
queue.
For callers in task mode and owning no locks, SETLOCK
will exit to the dispatcher. For callers in SRB mode or
that own the local lock, continue at step 6.
f:I.)
(\)
(')
i·::I
~
~
(\)
[
o.....
o
"0
~
ae::I
~
VI
W
Module
Label
t
•u.
Diagram 19-21. SETLOCK Processing (lEAVELK)
~
~
N
(I.)
~
~
--- -
Input
~
~
PSACLHS
a
PSALCCAV
•
~N
--
1
,
,
6
(In PSA)
I
I
/
I
LCCA
::c
r
Output
Process
IEAVSPCR
FRR Stack
PSATNEW
(D
- -w
PSA
PSATOLD
E'
-
from the program check
I H suspend routine
in·
~
~--
(part 7 of 14)
(D'
LCCASRBM
~
~
LCCA
Perform common suspend processing
for SRBs and unlocked TCBs.
•
•
Save floating point registers.
•
Save CPU timer value.
•
Save FRR stack.
•
Decrease count of CPUs.
•
Indicate lock held.
•
•
•
Fill in SSRB fields.
Save PSATO LD and PSATN EW.
Clear lock and SRB indicators.
Perform job step timing.
PSA
0 0
0 0
0 0
IHSA
ASCB
TICB
IEAVEDSO
SSRS
Job Step
Timing
From SET LOCK
Releasing Spin -type Locks
7
Determine if the CPU still owns the
lock.
•
•
Lock now owned.
Lock owned, continue.•
To pr.ogram check
I H suspend routine
when entered from
this .routine~
Other entries
give control to
dispatcher
Owned
Lookword
0
.1 ·0
Not owned/Owned
by another CPU
To Caller
'~g'ister
Code
13
4 -Not owned
8 - Ow.ned by
another CPU
Diagram 19-21. SETLOCK Processing (lEAVELK) (part 8 of 14)
Extended Description
6
This is the common suspend routine, entered from
step 5 or from the program check I H suspend routine.
If suspending a locked task:
• save PSATOLD and PSATNEW in IHSAOTCB and
IHSANTCB
• decrease count of CPUs (ASCBCPUS)
• save floating point registers in IHSAFPRS
• save value of CPU timer in I HSACPUT
• save current FRR stack in IHSAFRRS
If suspending an SRB:
•
•
•
•
•
clear SRB mode indicator
set up SSRB for redispatch
save floating point registers in SSRBFPRS
save value of CPU timer in SSRBCPUT
save current FRR stack in SSRBFRRS
For all suspend processing:
• Perform job step timing via the dispatcher's job step
timing subroutine (DSJSTCR).
• If suspend lock is held, clear the lock held indicator in
PSACLHS.
• If the local lock is held, store the suspend I D
(X'7FFFFFFF') into the lockword to prevent any other
routine from obtaining it.
CI'.l
(D
Sl.
5·
=
~
a;::
....
(D
S
Q.
o....
o
"0
~
a5·
=
t
CII
CII
Return to the program check I H suspend routine for
entries from program check IH. Otherwise, exit to the
dispatcher.
Module
Label
Extended Description
7
SETLOCK releases locks when the caller issues the
SETLOCK macro using the RELEASE operand. Steps
7-9 describe release of spin locks, while steps 10-14
describe release of suspend locks.
Determine if the lock is held by this CPU.
• If lock is not held by this CPU, then return to the caller
with a return code in register 13. The return code equals
4 if no on& owns the lock and equals 8 if another CPU
owns the lock.
• If the lock is owned, the lock will be released by setting
the lockword to zeros.
Module
Label
t
Diagram 19-21. SETLOCK Processing (lEAVELK)
(part 9
of 14)
VI
O'i
oCIl
~
N
CIl
'<
~l
~
§
8
I
Update the lock indicators.
PSA
.....
...
S
PSACLHS
~.
Co
PSACLHT
~
~.
~
is''
!3~
PSA
:f
ii
PSASUPER
t:i . .
~
'<
tI.)
--y
PSACLHS
N
~.
i'
~
9
Determine the ret.urn environment.
Register 13
....
)
v
If ..
I
Code
=0
I
Return to Caller
fl
--"r • Enabled if no spin,
locks held, no
super. bits on, and
caller has not
requested a
disabled release.
• Disabled when
conditions above
not met.
.~.
~
~
From SETLOCK
macro to release
a suspend-type
lock
t~
,;
t~
. .>
Release of Suspend -type Lock
10
,~
Test for a hierarchy violation.
Completion Code
•
~£
:~
Hierarchy.violation.
..
~1
f'?
:~~
:~.'
:~,:
'''i
~::
~.~
....
"
11
Determine whether this CPU owns
the lock.
•
Not owned.
•
Otherwise, continue.
".' ,,,
+
-y
i,.'
I
"'
X '073'
ABEND
~
Register 13
...
--y
To Caller
;,
'i
,~,
I
if'
Code
4 - Not owned by
any CPU
8 - Owned by a
different CPU
I
Diagram 19-21. SETLOCK Processing (IEAVELK) (part 10 of 14)
Extended Description
8
Update lock indicators by clearing the bit in the locks
held string and clearing the entry in the locks held
table if this is a class lock.
9
Return to the caller disabled if any spin locks are
held, any super bits are set, or the caller requested
control returned disabled. Otherwise, enable the PSW.
Return to the caller with a zero return code.
10
SET LOCK tests for a hierarchy violation. The only
violation on a release occurs if the caller tries to
release the local lock while holding the CMS lock. If this
occurs, the caller will be abnormally terminated with a
X'073' completion code.
11
en
(1)
s:;
5'
=
N
~
(1)
[
o
.....
o
't:I
~
a
5'
=
~
VI
-...I
If this CPU does not own the lock, return immedi·
ately to the caller.
Module
Label
t
Diagram 19-21. SETLOCK Processing (IEAVELK) (part 11 of 14)
(II
00
o
II}
"<
II}
N
Input
II}
'<
~
12
~
3
~;:;.
Prepare the suspended routines
to become ready.
•
t'"'
...0:
~
.:!
<:
o
C
3~
"'"
~
II}
ASCBTCBS
ASCBCPUS
00
o
~
.
y
Schedule
"'-
...
to..
y
ASCB
N
oW
Reschedule suspended SRBs .
(For local lock, reschedule
only the top SRB, place the
suspend id in the local lock,
and mark the SRB as owning
the local lock.!
ASCBS2S
•
I
......
Remove suspended ASCBs .
y
I
Interrupt 10
I
N
W
00
otil
~
"
I
--j
I
---1..-_
-
13
Determine whether additional work
has become ready in the
address space.
......
Yes
y
Memory Switch
..If
PSA
E:j
"
14
to..
Update the PSACLHS.
y
Register 13
Caller
<
en
o
Memory Switch
I
Code = 0
I
Diagram 19-21. SETLOCK Processing (IEAVELK) (Part 12 of 14)
Extended Description
12
Module
Label
If this is a suspend lock, make ready the routines
suspended off the lock.
For local lock - dequeue and schedule the top SRB on
that lock's suspend queue.
For CMS lock - reschedule any suspended SRBs that
are on that locks suspend queue. Reset suspended
tasks by placing the "interrupt I D" into the local lockword for each address space on the CMS suspend queue.
SETLOCK invokes Memory Switch for each readied
address space.
-<:
13
For the local lock release invoke Memory Switchfor the current address space if there is ready work
to be processed in the address space.
SETLOCK checks for the following conditions:
• ASCBTCBS greater than ASCBCPUS
• ASCBS2S s~t to one.
14
f(l
~
(S'
=
~
fie:
(D
;.
8o
""")
o
"C
~
a(s'
=
~
VI
1.0
SETLOCK updates the PSACLHS, and returns to
the caller with a 0 in register 13.
{I)
~
o
~
00
g
t
Diagram 19-21. SETLOCK Processing (lEAVELK) (part
13 of 14)
Input
Process
0\
Q
otil
"<
fI'.)
'N
til
From
R/TM
'<
§
ASCB
Local Lock Suspend Queue
£
SSRB
(;.
ASCBFSLQ
t""
ASCBLSLQ,
~
~
SSRB
~
-
15
,"
Output
Indicate which CPU owns the
lock SETLOCK is waiting
for, if necessary.
..
SETRP Macro
SDWA
r
~
"'
--"
~
"
~
~
16
(D
~
"
<=>
w
00
CMSASBF
~
CMSASBL
CMSSRBF
V
h\
~
17
Release any locks obtained
by SETLOCK.
SETRP Macro
-----
y
SDWA
".
D
...
J.
0
y
7F-.-- F
CMSSRBL
~
/
..
ASCB1
CMS
t-.)
Jo./
~
r
D
.J\
Clean up SETLOCK indicators.
CMS Lock Suspend Queue
~
PSA
18
Clean up the suspend queues.
19
Determine whether to retry the
error or continue with termination.
./
1 ASCB2
., SSRB
SRBFLNK
r\
ASCBCMSF
V
7F--F
./
\(SSRB
\~SCB3
•
•
Retry - if SETLOCI< was
suspending and suspension
has completed.
Set completion code.
7F--F
.-/
--.
y
Completion code
t..
Continue with termination.
0
ASCBCMSB
RtrM
RITM
"
I
X'074'
I
Diagram 19-21. SETLOCK Processing (IEAVELK) (part 14 of 14)
Extended Description
Module
15
IEAVLKRR IEAVELKR
The SETLOCK FRR (functional recovery routine)
frees any locks that SETLOCK obtained before the
error occurred, cleans up any indicators set by SETLOCK,
and corrects the suspend queues in use when the error
occurred. The SET LOCK FRR then gives R/TM control
either to continue with termination or, if one of two conditions occur, to retry the failing operation. The two retry
condittons follow:
• A restart interruption occurred while one CPU spins on
a lock, or
• An error occurred after lock suspension processing had
completed.
If SETLOCK was spinning on a lock and a restart interruption occurred, it indicates to R/TM which CPU owns
the lock. The SETLOCK FRR uses the SETRP macro
instruction to indicate the CPU and to accumulate recording information in the SDWA.
~
~
~
o·
=
!':J
a::
~
g
c;::I.
o
....
o
'0
~
ao·
=
-~
Q\
Label
Extended Description
16
The SETLOCK FRR cleans up indicators in the PSA.
17
The SETLOCK FRR requests that R/TM, via the
SETRP macro instruction, release any locks obtained
by SETLOCK during its processing.
18
The SETLOCK FRR removes SSRBs from the CMS
lock suspend queue, SSRBs from the current local
lock suspend queue, and ASCBs from the CMS lock suspend
queue. It resets all routines suspended on the lock, so that
all these routines must re-request the lock .
19
Two conditions result in retry of the failing operation: a restart interruption occurs whi Ie one CPU
waits for a lock owned by another CPU; or an error occurs
during CMS lock or local lock suspend processing and the
suspend processing has completed. Any other errors result
in control going to R/TM with a X'074' completion code
and an indication to continue with termination.
Module
Label
i"
Diagram 19-22. Validity Check Processing (ffiAVEVAL) (part 1 of 2)
0\
N
~
~N
Branch from Supervisor
routines to
validate addresses
Input
C'Il
Output
1 Check whether starting address is on a
'<
=9
full word boundary.
oic:;.
P&N
c-~ C~de
Not on a fullword boundary.
To Caller
r-
J<
[
(D
nK ...
, _ _ ___
~
2
Obtain TCB address.
3
Determine the n umber of pages to be
validated, change protection key from
0, and establish recovery.
4
Refer to the specified pages
'
Branch entry from Memory
Delete, Memory Create, Swap,
or System Resource Manager
o
1:1)
~
Input
p
rocess
Outout
~
"
1:1)
'i
~
~n'
t"'"
~
'"''''
IEAVEACO
Reg 0
I
Code 0, 1, or 2
~
1
•
~
I
Determine the type of request:
••
0- MOVE
1-ADD
2 - DELETE
Reg 14
MOVE (to Steps 2-4>.
ADD (to Steps 3-4>.
DELETE (to Steps 5-6).
~
~
(D
oIlo>
'<
Reg 1
MOVE
+Parm list, or
ASCB being changed
1:1)
~
~
rI
I
I
(D
i
~
~
~
Code
0- Successful
4 - For MOVE: at least one ASCB
not found
For ADD: not used
For DELETE: the ASCB not
found.
+First ASCB
2
Dequeue given ASCB and insert
new dispatching priority.
Code
ASCB
MOVE and ADD
ASCBDP
I
3
Enqueue ASCB at given priority.
S
ASCBSEQN
------
~
Flags
+Last ASCB
4
I
Reorder ASCB sequence
numbers.
"ASCBFWDP
~ ASCBBWDP=O
Memory
Switch
ASCB
I
ASCBSEQN
DELETE
5
Sets
Code
CVT
Wait for processing in the ASCB
to stop.
~ASCBFWDP
V\
CVTASCBH-
6
Oequeues given ASCB.
CVTASCBL
ASCBBWDP
ASCB
~
/
to
\
!
\
ASCBSEQN
Caller
ASCBFWDP=O
ASCBBWDP
J
Diagram 19-23. ASCBCHAP Processing (lEAVEACO) (part 2 of 4)
Extended Description
ASCBCHAP alters the dispatching priority of ASCBs at the
request of the system resource manager, and adds or
deletes ASCBs to the ASCB queue for memory create·or
memory delete (see Obtaining a New Virtual Memory
(lEAVEMCR) and Deleting a Virtual Memory (lEAVEMDL)).
The ASCBCHAP routine has no SVC entry; it only has
branch entry. Only privileged programs use the
ASCBCHAP routine.
The ASCBCHAP routine obtains the global dispatcher lock
(if it is not alr~ady held).
1
2
ASCBCHAP determines the type of request according
to the code in register 1.
ASCBCHAP changes the priority of several ASCBs at
one time. This enhances performance. The parameter
list that register 1 points to contains the list of ASCBs being
changed. This parameter list must be in non-pageable storage, because ASCBCHAP refers to it with the globql dispatcher lock held. ASCBCHAP dequeues the ASCBs being
changed.
C"I.2
CD
sa.
!'
1:1
!'t
a::
ra.
CD
o
'a
q
a.
!'
1:1
of"
~
Module
Label
Extended Description
3
For ADD requests, ASCBCHAP refers to register 1,
which contains the address of the ASCB being added
to the ASCB ready queue. The ASCBDP field has the new
dispatching priority prior to entering ASCBCHAP.
4
To resequence the ASCB ready queue, ASCBCHAP
changes fields in the ASCB and CVT, as illustrated.
Memory switch (see Memory Switch (lEAVEMSO))
receives control to process the ASCB with the highest
dispatching priority.
5
For DELETE requests, ASCBCHAP refers to register
1, which contains the address of the ASCB being
deleted.
6
ASCBCHAP frees the global dispatcher lock, unless it
was already held upon entry.
Module
Label
;t
Diagram 19-23. ASCBCHAP Processing (lEAVEACO)
(part 3 of 4)
0\
0\
i
~
w
Input
Process
Output
CI'J
1
m
r-'
~
(is.
r-'
&
i<
t
(D
~
;
Reg 0
I
@
200 Byte Workarea
SDWA
I
IEAVEAC3
7
@SDWA
1
~SDWA
SDWARECP
1
SDWAVRA
.a:..
r--
'
3(D
W
00
~
~
~N
C::>
W
00
~
To 105
via branch
10SB
Diagram 19-24. Trace Processing (IEAVTRCE)
Extended Description
6
(Part 6 of 10)
Module
Label
SIO EVENT
System data is gathered into a trace record.
<
til
N
o
<..J
00
o
VI
til
~
n
g.
=
N
~
~
=-
8-
o
.....
o
...
"'0
~
~
cS-
=
~
0'1
100
~
f"
~
I
Diagram 19-24. Trace Processing (IEAVTRCE) (Part 7 of 10)
\C
~
o
~
"<
~
N
branch entered from DISPATCHER
and EXIT PROLOG (lEAVEEXP)
Input
Process
Output
~
'<
~
(D
3
I:"'"
o
!fl.
7
~
I:"'"
0:
~
-<
sa.
=
Dispatch -event (Task
related)
•
Perform step 1.
•
Bui Id trace entry.
DISP New
• reg15
3(D
ASID I
~
~
TCB
I ,e~
I
time
I
<:
~
~
(:,
w
00
0
VI
'<
~
N
(:,
I
~
00
o
~
TCBRBP
~
To IEAVEDSO 0'
IEAVEEXP
via branch
Diagram 19-24. Trace Processing (IEAVTRCE) (Part 8 of 10)
Extended Description
Module
1
IEAVTRCE TRDISP
Dispatcher event
System data i:s gathered into a trace record.
Label
Only the initial dispatch of the wait task is traced.
Subsequent dispatches of the wait task while the
system is waiting are not traced.
If a TCS is available (PSATOLD /0), the interrupt
information (I LC and code) is gathered from the top
RS's prefix and incorporated in the PSW.
<:
CI'}
N
(:,
W
00
~
CI'}
I'D
!?
o·
=
N
is:
I'D
ET
o
~
~
o
I'D
...
"0
o·~
=
~
0\C
V.
!
I
Diagram 19-24. Trace Processing (IEAVTRCE) (Part 9 of 10)
0\
1.0
0..
branch entered from
c
~
-<
en
Input
DISPATCHER
(IEAVEDSOI
Process
Output
N
en
'<
~
I'D
3
ro
ct9.
~
r-
8
a:...
Initial SRB dispatch event
•
~
Perform step 1.
old
ASID
•
o-<
C
3
I'D
reg 0
Build trace entry.
TCB
time
-<
tI'}
N
<::>
...
<.H
00
~
<
To IEAVEDSO
o
via branch
tI'}
N
<.H
00
o
~
9
SRB re-dispatch event
•
old
Perform step 1.
ASID
•
reg 0
Build trace entry.
TCB
To IEAVEDSO
via branch
time
~
Diagram 19-24. Trace Processing (IEAVTRCE) (Part 10 of 10)
Extended Description
Module
Label
8
Initial SRB dispatch event
System data is gathered into a trace record.
IEAVTRCE TRSRB1
9
SRB re-dispatch event
System data is gathered into a trace record.
IEAVTRCE TRSRB2
<:
CIl
N
Q
~
00
~
CIl
~
t'l
g.
=
~
:::
~
g.
8o
o....
1
;;
g'
f"
;:
\C
~
t
Diagram 19-25. Queue Verification (IEAVEQVO) (part 1 of 2)
--J
o
From supervisor
recovery routines
to verify a
queue structure
~
~
""
VJ
'<
fIl
~
r
Duplex
values
•
"
~N
VCONs
i
,
:....
,"'
-
.--
Not Valid - Use the
values from the CVT and
ASVTMAXU for the refresh
values.
Determine whether SETLOCK
wasprocesslng when the error
occurred.
Yes - Issue SETFRR so the
SETLOCK FRR gets
control when RITM
goes to the FRR routines~
"
...
,
¢
[
No -
Continue.
PSACLHS
I
Hierarchy mask of
locks held
-
I ___
____ .1..
Lock Refresh
2
~,
I
,
,
Refresh~values -
f--
w
Valid - Refresh the CVT
and ASVTMAXU.
1 - - - - !--
3
Ensure that the hierarchy mask
agrees with the contents of
the lockwords.
..
,..
SETLOCK
Recovery
~--o
ASVT
---
ASVTMAXU'
.
Diagram 19-27. Address Space/Lock Verification Processing (IEAVELCR) (part 2 of 4)
Extended Description
Module
Label
Address/lock verification processing consists of 3 modules
that correct errors in the addressing/locking mechanism.
The modules are entered from R/TM on every error before
any recovery routine receives control.
1
The low main storage refresh routine replaces the
current, and possibly inaccurate, values in the CVT
and ASVT with accurate, valid values from VCONs, and
duplex values in the GSDA (global system duplex area). If
the refresh values are not accurate, the low main storage
refresh routine uses copies of the CVT and ASVT values,
to refresh the GSDA and VCONs.
IEAVELCR IEAVELCR
2
IEAVELKR IEAVELKR
The lock refresh subroutine first determines whether
an error occurred during SETLOCK processing. If so,
a SETFRR is issued so the SETLOCK FRR will get control
when R/TM goes to the FRR routines. Otherwise, normal
processing continues.
3
The lock rttfresh subroutine ensures that the hierarchy
mask - the mask that shows the sequence of locks
held -'- agrees with the value in the lockwords. If it does not
agree, the lock refresh subroutine will ensure the agreement.
The subroutine may also seize the CMS lock if it determines
that the owner of the CMS lock was suspended because of
a page fault which was never resolved. Finally, the subroutine terminates the address space that owned the eMS
lock.
if
~
e'
=
~
iC
c
[
....o
o
~
Q
a
e'
=
~
-..I
-..I
t
Diagram 19-27. Address Space/Lock Verification Processing (rnAVELCR) (part 3 of 4)
......
co
~
~
N
~
i
a
i
n
ASVT Verification
t:
I~
=
~
4
CVT
....
~N
~
:..,
•
No bad entries•
•
Bad entries: Issue
SETFRR so that ASVT
Repair gets control.
....
RfTM
...
RfTM
...
;
CVTASCBH - {
ASCB
(D
Iw
Search for bad entries in the ASVT.
Dispatching
Queue
~
..
...
ASVT
From
ASVTFRST
ASVTRepair
"') 5
., v
1
Refresh the ASVT entries
for each ASCB on the ASCB
dispatching queue.
"
6
Remain all the available
entries in the ASVT.
~
,.
To RITM
ASCB
/'
.....
ASVTENTY-
v
ASVTENTY'~
ASCB
Diagram 19-27. Address Space/Lock Verification Processing (IEAVELCR) (part 4 of 4)
Extended Description
Module
4
The ASVT (address space vector table) verification
routine searches for invalid ASVT entries. If the
routine finds no bad entries, control returns to R/TM.
Otherwise, if bad entries are found, a SETFRR is issued so
the ASVT repair routine will receive control later.
IEAVEVRR IEAVEVRR
5
IEAVEVRR IEAVVFRR
The ASVT repair routine refreshes the entries in the
ASVT for each address space that is on the dispatching
queue.
6
ASVT repair chains the available entries in the ASVT
to show which ASIDs have not !'leen assigned to any
address space.
~
~
o·
=
~
~
(D
[
o....
o
"0
~
~
o·
=
~
.I,Q
....
label
t
!
o
~
.~
Diagram 19-28. Address Verification (IEAVEADV) (part 1 of 2)
From Supervisor
Routine
Input
Output
N
fIl
I
r-
~.
r~
~
~
a2'
RegO
LENGTH OF STORAGE RANGE I
Reg 1
1
r~@-SOWA
Reg 2
[iEGI-NNING
@
STORAGE RANGE
i&Jj
fA
V
1
Check if storage check occurred.
No - continue at step 4.
2
Insure SDWA storage error range
contains valid data.
Not valid - continue at
step 4.
3
Notify caller when input
storage range intersects with
storage error range indicated in
SDWA.
I
(D
~
'
w
•
w
•
N
RB
o
ASCBTCBS -1
(
suspend
macro
I
I
RBSCF + 1
-No
- Return.
1
I
.'"
ABEND
.
"
. . . . ._ '. . .nl'w'. . . . . . . .
i
-y
RB
o.
•
...
"
To issuer of
suspend
macro
"
ICseB
".
~I
(
RBSCF + 1
II
Co
-....J
.. T
~) To issuer of
Does previous RB exist?
- Yes
Increment suspend count in
previous RB.
PSAAOLD
ASCB
--v
I
--v
I
w'l
.
I . ') 3
1
Register 1
Suspended RB
L"}
".
~
Suspended TCB
't
!{TCB
=
~
>l+
~"
<
[:
I
Diagram 19-28. Suspend Routine (lEAVETCL) (part 2 of 2)
Extended Description
Module
Label
The Suspend routine (lEAVETCL) is a fast means for
placing a TeB in the wait state.
1
Suspend checks the contents of register 1. If it is
nonzero, then RB=PREVIOUS was requested and
processing continues at step 3. If it is zero, then
RB=CURRENT was requested.
IEAVETCL IEAVSUSP
2
Since the TCB will no longer be dispatchable, the
count of ready TCBs in the current ASCB must be
decremented by one (ASCBTCBS). Next, the suspend
count in the current RB (RBSCF) is incremented by one
to place the task in the suspended state. Registers 0
and 1 are initialized with the TCB and RB addresses,
respectively, and control is returned to the caller.
3
If no previous RB exists, the caller is terminated
with an abend code of 070 and register 15 is zeroed.
Otherwise, the previous RB is obtained and the RBSCF
field is incremented by one. Since this is done in the
previous RB, the ability to dispatch the task is not
changed. Registers 0 and 1 are initialized with the TCB
and RB addresses respectively, and control is returned to
the caller.
CI'.l
g
g
~
a::
(D
~
o....
o
ao·
't:S
::I
f'
IC
t""
<:
tIJ
~
o
~
00
9
PREVIOUS
~
....
....
Diagram 19-29. Transfer Control - Transfer Logical (TCTL) (lEAVETCL)
(part 1 of 4)
IC
N
orJ'l
~
From Issuer of
TCTL Macro
Output
Input
~
rJ'l
~
LCCA
[
b
'!9.
(')
1
If caller is not in SRB mode, issue
an abend. Otherwise,
proceed to step 2.
2
Set up to do transfer control.
LCCASRBM
t-
o:
~
i
(I)
-<
rJ'l
~
b
Register 4
I.N
4:00
TCB
'
~
00
o
'-I
t I
Diagram 19-29. Transfer Control - Transfer Logical (TCTL) (lEAVETCL)
(part 3 of 4)
\Q
.-
:.:a.
..
~
w
C'I.l
~
aSS
TCB
~.
TCB
.
1.>
t'"
~
7
Turn off intersect flags.
TCBXSCT
~
:v'"
~
_ TCBXSCT
~
-
a
~
S
00
(D
~
~w
9
PSA
PSA
---
(:,
CN
00
'"
§
"V
PSASUPI
PSACSTK
8
Reset FRR flags and FRR stacks.
'"
,)
PSASUPI
PSACSTC
-
CVT
:v'"
9
Go to normal SRB exit.
CVTSRBRT
I
Handles Normal SRB Exit
(JEAPDSRT Entry Point
in IEAVEDSO)
Diagram 19-29. Transfer Control - Transfer Logic (TCTL) (IEAVETCL)
Extended Description
7
Intersect flag TCBACTIV is turned off.
Module
(part 4 of 4)
Label
TCTL003
8
Flags PSADISP and PSATCTL are turned off and the
current FRR stack (PSACSTK) is set to normal
(PSANSTK).
9
The normal SRB exit routine (I EAPDSRT) in the
dispatcher is called.
<:
r:Il
t-..)
o
t.,)
00
S
r:Il
(D
(')
g.
=
t-..)
a::
(D
[
~
o
"t:I
ag'
(D
-~
\.Q
U.
f"
~
\0
~
~
..
oC"J':l
"<
C"J':l
N
C"J':l
Register 4
'<
;.
1
l
e
S
,
<;k
"
"
"
"
Resume
__ TCB
~.
>1
t""
0:
v
~
Turn on intersect flags.
If compare and swap fails, go
to Step 7.
..
r
~
e=
Step 7
~
N
<=>
C,N
(1)
~
00
Register 5
~
I
N
o
1
~
00
§
o
......
RB
--. RB
...
) 2
v
'"
~
Decrement suspend count.
'1
-----
PSAAOLD
1
I
ASCB
-"" ASCB
I\R
i
...
3
-v
..
1,>
If work is now dispatchable,
increment ASCBTCBS by 1.
/V"
ASCBTCBS + 1
<,'
",,--,
4
"
Register 14
I
0 or return
address
lh~'
I
...
;;>
If RETURN=NO specified
go to Step 13.
If HETURN=YES specified,
continue.
;
,,<
~
<-
",
~}
.L
~
..
Step 13
r
I-
RBSCF -1
Diagram 19-30. Resume Routine (IEAVETCL) (part 2 of 6)
Extended Description
Module
1
IEAVETCL IEAVRSME
Turn on TCB intersect flags (TCBS3A and TCBACT)
via a compare and swap. (If TCBS3A=1, the stage 3
exit effector is locked out. If TCBACT=1, the dispatcher
is locked out.) If an intersect flag is already on, the local
lock must be acquired after branching to step 7.
2
Label
The suspend count in the RB (RBSCF) is
decremented by one.
3
If the Resume was for the top RB and the unit of
work is not dispatchable, the count of ready TCBs
(ASCBTCBS) must be incremented by one.
4
If register 14 is zero, RETURN=NO was requested.
Therefore, Resume will attempt to do a TCTL to
the resumed TCB at step 13. If register 14 is a return
address, Resume will not do a TCTL to the resumed TCB.
(I}
a
c)"
=
~
a::
~
~
o
100)
o
't:I
i
-~
\0
~
<
C7.l
N
o
~
Co
S
t
.-'"
I Diagram 19-30.
Resume Routine (IEAVETCL) (part 30f 6)
00
o
.t"'-I
.
~
N
t"'-I
'<
From Mainline When
Intersect Flags are
Already On
~Lo
f5.
n
L-
0:
~
<:
I
Local Lock
I
..
5
Turn off intersect flags.
6
Return.
"> 7
v
To issuer of
RESUME
RETURN=YES
Obtain the Local Lock.
~
:3
c
01:0-
~
N
Q
eN
00
~
§
,..
v
'.
8
RBSCF
-V
9
TCB
TCBXSCT
'")
v
11
Register 14
.[
J
Try again to turn on intersect
flags as in Step 1. If the flags
are turned on, go to Step 3.
..
,
Step 3
...
.y
- If compare and swap fails,
continue.
10
Oor return
address
,§
Decrement suspend count
in RB(RBSCF).
~
N
Q
eN
00
o-...I
RBSCF-l
TCB
TCBXSCT
Release the Local Lock.
.
SRB Exit
,
If R ETURN=NO specified,
go to SRB exit.
A
If RETURN=YES specified,
continue.
,/
12
Return.
?
To Issuer 01
RESUME
RETURN=YES
j
Diagram 19-30. Resume Routine (lEAVETCL)
(part 4 of 6)
Extended Description
5
The intersect flags turned on in step 1 are turned off.
6
Return to the caller.
7
If the TCB was active or the stage 3 exit effector
was active for this TCB, the local lock is acquired.
8
The suspend count in the RB (RBSCF) is decremented
by one.
Module
Label
GETLOCK
GETLOCK
9
A second attempt is made to turn on the intersect
flags. If successful, control goes back to normS!
mainline processing.
10
Otherwise, the local lock is released.
11
If register 14 is zero (RETURN=NO was specified),
control is passed to the normal SRB routine. If
the caller was not in SRB mode, he is terminated. If
register 14 is not zero (RETURN=YES was specified or
implied) then go to the next step.
12
f:I)
(\)
(')
~.
~
a::
(\)
~
Q.
ao
1~.
-f"'
\ C)
\0
Return to the caller.
~,
~
o
w
00
S
~
....
\Q
;...
c:>
~
~
t"'-l
I
LCCA
..
t""I
ci.n
t""I
a:
....
LCCASRBM
1/
.
13 If caller is not in SRB mode,
7'
issue ABEND.
~
ABEND
;
<:
~
14 Otherwise set up to go to TCTL.
~
)
--v
.a:o.
~
~
s00
-s
~
TCBS3A
....
ASCB
TCTL
....
-y)
ASCBSTA
15 !f STATUS is active
(ASCBST A=ON), go to
TCTL to cause the SRB
to exit.
16 Otherwise, go to TCTL
to transfer control to the
resumed TCB.
...
T
.
-y
See Step 7
TCTL
See Step 4
I
~
I
o
~
00
c:>
-...J
Diagram 19-30. Resume Routine (lEAVETCL) (part 6 of 6)
Extended Description
13 Only SRBs are allowed to specify RESUME
Module
label
RESU006
RETURN=NO. If the caller was not in SRB mode,
it is terminated.
14 The following is done to be able to enter TCTl at a
special internal entry:
• Turn off TCBS3A.
• Disable I/O and external interrupts.
• Set up super FRR.
• Turn on DCAlTCTl to indicate transfer control is active.
<::
C"Il
N
15
16
C"Il
ttl
n
g.
=
~
~
ttl
~
o....
o
'C
~
g.
=
-f"
\0
!"'"
If STATUS is active, TCTl is entered at a point that
will cause normal SRB exit to occur.
If STATUS is not active, TCTl is entered to transfer
control to the resumed TCB.
<:>
c...l
00
o
-.I
4-192 OS/VS2 System Logic Library Volume 4 (VS2.03.807)
Task Management performs services for both
problem and system programs. These services fall
into three catagories: creating and deleting
subtasks, controlling the execution of tasks in one
or more address spaces, and providing
informational services for the requester.
Creating and deleting subtasks consists of the
following services:
• Creating a new subtask. The requester issues
an ATTACH macro instruction to perform this
service.
• Terminating or deleting a subtask. The
requester issues a DETACH macro instruction
to perform this service.
Controlling the execution of tasks in one or more
address spaces consists of the following services:
• Changing the dispatching priority of a
subtask. The requester issues a CHAP macro
instruction to perform this service.
• Allowing a program to stop executing until a
specified event or number of events occur.
The requester issues aWAIT macro instruction
to perform this service.
• Allowing a program to stop executing until
one of n events completes and be directly
informed which events have completed. The
requestor issues a sequence of EVENTS macro
instructions to perform this service.
• Signifying the completion of an event. The
requester issues a POST macro instruction to
perform this service.
• Providing a serialization mechanism for a
resource or resources. The requester issues
ENQ, DEQ, or RESERVE macro instructions to
perform this service.
• Specifying a program check interruption
routine. The requester issues a SPIE macro
instruction to perform this service.
• Handling the exiting procedures for programs
other than type 1 SVcs. The requester issues
an EXIT SVC to perform this service.
• Handling the exit procedures for SVC
routines. The requester uses EXIT Prolog to
perform this service.
• Manipulating the dispatchability indicators of
system control blocks. The requester issues a
STATUS macro instruction to perform this
service.
Providing informational services consists of the
following services:
• Providing programs with information from
system control blocks. The requester issues an
EXTRACT macro instruction to perform this
service.
· ~::g:ro:=:::~ ::~::~~: !~q:ster
issues a TESTAUTH macro instruction to
perform this service.
Creat;n, and Delet;n, S"btask,
Services related to creating and deleting subtasks
involve the TCB (task control block). When a
problem or system program issues an ATIACH
macro instruction, the ATTACH routine receives
control from the svc IH (interruption handler) and
creates a TCD. (See Supervisor Control, section 19,
for the description of interruption handling).
ATTACH then places the newly created TCBon1he
TCB ready queue in the appropriate address 'space,
according to the priority written on the ATTACH
macro. Figure 2-37 illustrates the task queue. It
shows the relationship between the address space
- represented by the ASCB (address :spacecontrol
block) - and the tasks running in it represented by the TCBs. Figure 2-38 depicts the
family subtask queue. It shows the relationship
between job step tasks and subtasks.
.•..
ASCB 1
ASCB 2
ASCB n
TCB
Two chaining fields indicate the relationship of tasks on the task queue:
TCBTCB
- Points to the TCB for the next lower task on the task queue.
TCBBACK - Points to the TCB for the next higher priority task on task queue.
Figure 2·37. The TeD Ready Queue
4·194
OS/VS2·System LOgic library Volume 4 (VS2 Release 3.7)
Four chaining fields indicate the relationship of subtasks on a subtask queue:
TCBOTC
- Points to the TCB for the task that attached this sUbtask.
TCBLTC
- Points to the TCB for the task last attached by this task.
TCBNTC
- Points to the TCB for the task previously attached by the task that attached this task.
TCBJSTCB - Points to the first TCB for the job step.
Figure 2-38. The TCB F.amily Queue
Section 1: Method of Operation
4-195
After the requester issues a DETACH macro, the
DETACH routine receives control from the .SVC IH,
and removes the pointers from other TCBs to the
deleted TCB. This effectively.takes the specified
TCB from the TCB queue.
Controlling Task Execution
Task management services control task execution
directly and indirectly. Direct control of task
execution means that the requester uses a task
management service to immediately alter the
execution of a task. Indirect control of task
execution means that the requester uses a task
management service to perform a service that alters
task execution sometime in the future.
POST also operate as a pair to indicate the
occurence of an event to the requester. The
EVENTS service routine first receives control from
the SVC IH through the Extended SVC router to
create an events table for the user. Then the
EVENTS service routine receives control from the
SVC IH to initialize the ECB. The ECB is initialized
with the WAIT bit on in the high-order byte; the
low-order three bytes contain the event table
address, with bit 32 turned on. EVENTS service
routine mayor may not wait on an EVENT-type
event to complete.
EXIT and Exit prolog perform the exiting
services for system and user programs.
EXIT performs the exiting procedures for system
and user programs; Exit prolog performs the
exiting procedures for SVcs.
Direct Control of Tasks
Requesters can use the following task management
services to alter immediately task execution:
• CHAP
• WAIT
• POST
• STATUS
• MODESET
• EVENTS
• EXIT
• EXIT Prologue.
The CHAP, STATUS, and MODESET services alter
the dispatching of tasks. (See the Supervisol
Control section for a discussion of task
dispatching.) Requesters alter the dispatching of
tasks to indicate or to cause changes in task
execution. After CHAP receives control from the
SVC IH, the CHAP routine replaces the value that
represents the dispatching priority in the TCB with
the new value that represents the changed
dispatching priority. Then, CHAP changes the
position in the TCB queue of the TCB to reflect the
changed priority. STATUS, after receiving control
from the svc IH, changes dispatchability indicators;
and MODESET, after receiving control from the SVC
IH, changes the mode or system key of the
requester.
The POST and WAIT services operate as a pair to
indicate the occurrence of an event to the
requester. The WAIT service receives control from
the svc IH, and then indicates a wait condition in
an ECB (event control block). The POST service
receives control from the SVC IH and "posts" the
occurrence of an event in an ECB. POST marks the
completion of an event, and WAIT waits for the
event. In effect, these two services control task
execution by synchronization.
A new service EVENTS has been added to
further enhance the synchronization previously
provided only by WAIT and POST. EVENTS and
4-196
OS/VS2 System Logic Library Volume 4 (VS2 Release 3.7)
Indirect Control of Tasks
Requesters can use the following task management
services to alter tasks at a later time:
• ENQ/DEQ/RESERVE
• SPIE
The ENQ/DEQ/RESERVE services·enable a
requester to gain control of the specified resources
needed to execute the requester's program.
ENQ/DEQ/RESERVER queue requests for resources
after receiving control from the SVC IH.
The SPIE service constructs an SCA (SPIE control
area) which contains information that enables a
task to regain control after a program interruption.
(See the Supervisor Control section for a
description of interruption types.) SPIE receives
control from the SVC IH after a SPIE service request
occurs. SPIE constructs the SCA, and sets indicators
in the TCB and RB of the requester.
Providing Informational Services
Two task management services, EXTRACT and
TESTAUTH, provide requesters with task-related
information, such as contents of control blocks,
and authorization of requesters. The EXTRACT
service enables a requester to extract control
information from the TCB, JSCB (job step control
block), or CSCB (command scheduling control
block) or combinations of those control blocks.
EXTRACT receives control from the SVc IH to
furnish the specified information for the requester.
TESTAUTH ensures that a caller of a supervisor
service has the necessary authorization to use the
service. (The Introduction to VS2 discusses
authorization.) TESTAUTH receives control from
the svc IH, or after a branch entry from a
supervisor routine.
Task
Management
Overview
(no diagram)
20,1
ATTACH
Processing.
(lEAVEATO)
-I:ro:j
DETACH
Processing
(lEAVEEDO)
CHAP
Processing
(lEAVECHO)
WAIT
Processing
(lEAVSY50)
POST
Processing
(lEAVSY50)
EVENTS
Processing
(lEAVEVTO)
I
ENOl·
RESERVE
Processing.
(lEAVENQ1)
20-8
120:S
DEQ
Processing
(lEAVENQ1)
ENQ/DEQ/
RESERVE
Recovery
UEAVENQ1)
.....
120-10
SPIE
Processing
(lEAVTBOO)
Figure 2-39. Task Management Visual Contents
I:Il
c
aeo
=
!:»
a::
r
c
Q
000)
o
"C:J
Q
aeo
=
~
\C
....,
20~15
(20-11
EXTRACT
Processing
(IEAVTBOO)
EXIT
Processing
UEAVEOR)
EXIT Prolog
Processing
(lEAVEEXP)
STATUS
Processing
(lEAVSETS)
MODSET
Processing
(lEAVMODE)
120-16
TESTAUTH
Processing
(IEAVTEST)
~
~
Diagram 20-1. ATTACH Processing (IEAVEATO) (part 1 of 8)
From SVC IH
~
Output
~
N
CI)
Register 15
~
Return Code
9
t"'"
00
04
08
OC
Successful
ATTACH issued from a STAE exit
Insufficient storage for SCB
Invalid ST A I exit routi ne or ST A I parameter
list address
14 - System task specified JSTCB =YES, was not
a job step task
18 - Both job step and non -job step tasks as
sub tasks invalid
8·
3
(')
r0-
ts:
CurrentTCB
8
...f
CIRB
..
p~
...
II TCBRBP
i
.
. . . =>
R
~
4
RB
,
SVRB
RBLINK
SCB built (via SVC 60) to
satisfy (E)STAI requests, or
to propagate a~y existing
(E)$TAI SCBs •
Completes TCB initialization.
to.
Builds and chainsSPQEs.
6
~
...
I
G+ ~pMvdor P.~nMW'
Lid
....)(8
..
I
P'
Supervisor
Parameter List
I
I
TCBANDSP
TCBTRN
SCBSCB
~SCB
GETMAIN
y
Register 15
~
Obtains Storage
in Subpool 255
Initializes new SVRB.
"
TCBFSM
TCBPKF
8
A·
..1>..>
r- IQEtRB
SCB
TCBEXT2
TCBATT
TCBRBP
TCBGRS2
y
5
GETMAIN
--v
to.
il
TCBECB
TCBPQE
IQE
TCBJSTCB
Obtains Storage
in Subpool 253
...
i
----(
J
TCBlaE
TeBSCB
TCBTCT
TCBJLB
Creates the
Necessary IRB
y
~
~
~
NewTCB
TCBJSCB
..
b) No ETXR parameter.
~N
I
..1>..
"
a) For ETXR parameter.
f
~
Obtains storage for new
TCB, and IQE and IRB if
necessary.
I
Exit Prologue
.... NewSVRB
I
y
...
"
~///LL.L
RBLINK
RBSIZE
RBSTAB
RBTCBNXT
RBOPSW
RBGRSAVE
RBEXSAVE
RBATTN
w
r-~
~//////
IRB
Diagram 2~ 1. AITACH Processing (lEAVEATO)
(part 4 of 8)
Extended Description
Label
Extended Description
ATTACH obtains storage for an I QE (interruption
queue element) and IRB (interruption request block)
when the request contains the ETXR parameter, as well as
the storage for the new TCB (task control block). Before
ATTACH builds a new IRB, the current TCB's subtask
queue is searched for an existing IRB with the same ETXR
address using the TCBIQE and IQEIRB fields. ATTACH
increases the RBUSE count by one if an IRB exists having
the same EXTR address, and then chains the IRB off of the
new IQE. ATTACH creates a new IRB, as well as an IQE,
and a TCB when one does not exist, using the CI RB
(Create IRB) routine .. The storage for these control blocks
resides in subpool 253.
GETCBS
5
4
STAIRTN
3
The SVC 60 (STAI/ESTAI) routine builds SCBs
(STAE control blocks) to satisfy any requests for
STAI or ESTAI on the ATTACH request. SVC60also
propagates any STAI/ESTAI existing SCBs from the
current TCB to the new TeB.
The ATTACH routine sets other fields in the new TCB
according to the parameters on the ATTACH request, to
zero if they are not explicitly set, or propagates the value
from the current TCB.
f
a
e'
::I
!':»
at
i....
o
o
1a
~
~
o
Module
The ATTACH routine builds a queue of SPQEs off of
the TCBMSS field according to the values specified in
the SHSPL, SHSPV, GSPL, GSPV, and SZERO operands.
New SPQEs are built from subpool 255. ATTACH builds
shared SPQEs for subpools 236 and 237 if these SPQEs
existed for the current TCB, and in accordance with the
NSHSPV or NSHSPL parameter. These shared SPQEs are
chained off the TCBSWA field.
6
The new SVRB contains control information:
• RBGRSAVE - contains caller's register 1 through
12. Register 1 contains the address of problem program
parameter list.
• RBEXSA VE - contains control information previously
stored in the current SVRB's RBEXSAVE.
• RBOPSW - contains entry point IGC042R 1.
The TCBGRS field contains the registers used by the
IGC042R1 entry point. ATTACH branches to EXIT prolog; control returns to ATTACH at entry point
IGC042R1.
Module
Label
SHARESP
GIVESP
SPCONTRL
SHARESWA
SWARTN
•N
Diagram 20-1. AITACH Processing (lEAVEATO) (part 5 of 8)
2
From Dispatcher
(lEAVEDSO) under newTCB
C"IJ
1
.g
t"""
.i
n·
~
CJ
l
...
i
~
N
Register 1
I+DCB, or 0
I
Process
TCB
j
'*1 " 7
m
-
Output
§'1l1,_
plioi'
8
Obtain problem program save area,
if necessary. Set indicator in
new TCB.
'lr--;:::======~I:II
.
...
~
Obtains Storage
in Subpool 250
C"
NewSVRB
i
•
~N
lito..
Register 0
LINK Routine
(IEAQCS01)
tu:s\;:t1~13
From
f
-
---,..
Problem
Program
Parameter
List
@ 200 Byte Workarea
@SDWA
SDWA
RBGRS1
RITM _
Register 1
1M
:....
Save Area
J
FRR Workarea
,.
IGC042R2
8
RBEXSA
Ensure that th~ FRR is processing
in the correct address space and
has not been previously entered.
~
.@._'••
-
RITM
6"'--":":":"::"':':":--~
1111
,;"
SDWAPARM
Current SVR B
Workarea
9
Set recursion indicator.
Current SVRB
10
\J'"t----'------I
Determine whether a validity
check error occurred, and reset
completion codes, if necessary.
~
I I
..
r
~
'
>l
RBEXSAVE
------.
RITM
~
Return Code=O
RBEXSAVE
Completion Code
6
42A - Invalid ECB
72A - Invalid Parameter List
Diagram 20-1. ATTACH Processing (IEAVEATO) (part 6 of 8)
Extended Description
Module
Label
7
Obtains a problem program save area from subpool
250 for SVAREA=YES requests, and places the
address of the save area into TCBFSA and RBGRS13. Then
the ATTACH re-entry routine initializes the RBEXSAVE
field in the SVRB for use by LINK.
IEAVEATO
IGC042R1
8
IEAVEATO IGC042R2
After receiving control from R/TM, the ATTACH
FRR (functional recovery routine) ensures that it is
operating in the address space used by the ATTACH
routine. If the FR R is processing in the wrong address
space, or if recursion has occurred, control goes to R/TM,
with a no-retry indicator.
9
10
The ATTACH FRR sets a recursion indicator in the
workarea of the current SVRB's RBEXSAVE field.
If a validity check error occurred, the ATTACH FRR
changes the completion code to X'42A', for an
invalid ECB (event control block) or X'72A', for an invalid
parameter list. Control then goes to R/TM, with a return
code of 0, indicating that there will be no retry of the failing
operation.
rIl
(D
~
o·
=
~
a::
(D
[
So
o
'"
"a.o·=
t
c:::>
eN
t
Diagram 20-1. A1TACH Processing (IEAVEATO)
(part 7 of 8)
2
o
rn
<
,(11.)
N
:Process
Input
Output
f
J
11
;~
RecoverTCB dispatching queue.
OQ
c·
.t:
'2"
~
~
E
g
"~
'<
,go
N
i
~
'W
':'"
Register·O
SDWAlndicator
Value4= X'12'
IGC042ES
12
:Re.gister 1
•
@:SDWA
'I I
NoSDWA.
Step 15
• Yes, one exists, continue.
'.Register 2
@ .ATTACH
Determines whether an SOWA exists:
Workarea,
if .no;·SDWA
SDWA
SDWA
13
SDWAPARM:
F:lB,EXSAVE'
Determine whetherFRHhas been
entered:
•
Ves.
•
No, continue.
SDWARCDE
I I
14
Set recording information and
15
Perform cleanup.
.step 15
LJ
ToRITM
Tca
D
Diagram 20-1. ATTACH Processing (IEAVEATO) (part 8 of 8)
Extended Description
Module
Labet
11
13
The ATTACH FRR recovers the TCB dispatching
queue by routing control to a CHAP recovery routine
UGC044R2). Control returns, and the ATTACH FRR gives
R/TM control with a return code of O. The SDWA contains
recording information. The variable recording area
(SDWAVRA) contains the contents of ATTACH's permanent workarea, which contains a code that isolates the portion of ATTACH processing in which the error occurred,
the addresses of the new TCB and the current TCB, and
other information. This is followed by the recording
information supplied by routine IGC044R2 (see the description of CHAP SVCL The recording area, SDWARECP, contains the module name (lEAVEATO), the CSECT name
GC0004B), and the FRR name (lGC042R2L
The ATTACH ESTAE routine next determines
whether the ATTACH FRR routine has already
received control by checking the recursion indicator in the
RBEXsAvE field of the current SVR3. If it has, no recording is done and control goes to step 15; otherwise, control
goes to step 14.
14
The variable recording area SDWA VRA is set to the
contents of the permanent workarea (from the current
SVRB's RBEXSAVE field), as described in step 11. The
recording area SDWARECP is set to the module name
(I EAVEATO), CSECT name UGCOOO4B), and ESTAE
routine name (lGC042EsL
o
12
The ATTACH ESTAE (extended STAE) routine
receives control from R/TM. First, the routine checks
register 0 for a non X'12' value. (A X'12' value indicates
that no SDWA exists.) If a SDWA exists, control goes to
Cltep 13; otherwise, control goes to step 15.
Extended Description
15
IGC042E5
IGC042ES
The following internal ATTACH subroutines perform
clean-up functions:
• RTN1
.RTN2
• RTN3
• LOCK
.UNLOCK
Control goes to R/TM, with a 0 completion code, indicating
that no retry of the failing operation will occur.
~
sa.
~.
::I
N
a::
~
Io
"'o"
"I:S
"=~.
':I
to
~
VI
Module
Label
~
N
Diagram 20-2. DETACH.Processing (IEAVEEDO) (part 1 of 8)
~
~
~
N
From SVC IH
to process
DETACH requests
Input
Process
Output
~
fIl
i
-
1
E
n·
II
Checks the validity of the parameter
word and DETACH TCB
address.
Register 1
"
I
r
..
ABEND
13E
23E
33E
43E
r
r-
ea
~
~
Ii:
~
Normal DETACH Processing
BI
TCB
TCBFLGS5~
"
~
~
N
~
TCBFEXTR
2
--.
If detach TCB has finished
processing.
..
--I
I
Iw
1
~
I
3
"
Frees IRB, IOE, and IRB problem
program save area if necessary.
.
r
~
"'
I
STAE = NO
Invalid Parameters
STAE = YES
Invalid ECB address in TCBECB
tr
Step 6
FREEMAIN
--I
-
Completion Code
~
IOE, IRB in
SP 253; IR3
problem program
save area in
SP 250
1M
TCB
TCBIOE=O
Problem Prog
Save Area
"
r
TCBFEXTR=O
TCBECB=
A
4
...
Terminates subtask if necessary.
r
ABTERM
...
"'
_-1
..
")l
I
lit
- ......
B
".
@of
workarea ECB
Diagram 20-2. DETACH Processing (IEAVEEOO)
(part 2 of 8)
Extended Description
Module
Label
Extended Description
Module
1
IEAVEEDO
DETACH processing frees subtask resources - the subtask
TCB, and possibly a problem program save area - still held
after the task has completed. End of task processing frees
these resources automatically, except when the creating
task had specified the ECB (used to indicate termination
of the task) or the ETXR (used to indicate the address of
an exit routine) operands on the ATTACH macro. DETACH
also provides a means for mother tasks to purge any subtasks not yet terminated.
Register 1 supplies the address of a fullword
containing the address of the subtask TCB
to be detached. If an abend code is necessary and
bit 0 of Register 1 is 1 (that is, STAE=YES was
specified), the abend code is 33E; if bit 0 of
Register 1 is 0 (that is, STAE=NO was specified),
the abend code is 13E. DETACH checks the
input, and passes control to ABEND to terminate
callers with invalid input.
The DETACH routine has defined a branch entry available
for certain privileged programs. The branch entry provides
two functions:
2
• Provides a directed detach for use by ABEND to detach
subtasks not belonging to the current TCB .
• Provides a clean-up routine for end-of-task (End-of-task
Resource Manager).
DETACH frees TCB resources if the TCBFC bit of the
TCBFLGS5 field is set to one. DETACH sets a return
code of 0 and returns to the caller (see Step 6). DETACH
will stop an active TCB by using the STATUS routine (see
ST ATUS Processing diagram).
3
DETACH checks for an ETXR (end-of-task exit
routine) for the TCB being detached. An ETXR exists
if the TCBIQE field does not equal zero and bit TCBFETXR
equals 1. DETACH uses FREEMAI N to free the IQE and
DETACH sets TCBIQE and bit TCBFETXR to zero if an
ETXR exists. If the IRB use count (RBUSE) equals 1,
DETACH uses FREEMAIN to free the IRB and its associated problem program save area. If the IRBuse count
exceeds 1, DETACH decreases the IRB use count by one.
4
til
(D
g.
::I
N
ac
(D
~
c:;I.
o
-.
o
"0
~
fa.
e'
::I
~
~
....,J
DETACH passes control to terminate the subtask.
Label
i
Diagram 20..2. DETACH Processing (IEAVEEOO)
~
Input
w
i
I
(part 3 of 8)
-
• iiiiAii'
I
5
it:
I
Detach the subtask.
.
. )(A
v
Allow subtask
to complete
~
~
..
r
WAIT
..
POST
f,
~
§
'f.,
CD
•
~N
For ATTACH
ECB only
,.
~
rI
vI
..L
.
w
ATTACH ECB
...)I1
Completion Code
(From TCBCMPC)
I
!..,.
6
.
,.
Frees TCB resources, removes
TCB from family queue.
,
7
Branch
Entry
Entry Code
O-EOT
1-ABEND
-r
m ...
.,..
...
IGC062R1
r
Register 0
Sets return code.
--_.-
Branch Entry for EOT and ABEND.
/-8
""
For ABEND clear TCBECB,
go to Step 2.
*' ;,.;
>'~
FREEMAIN
Problem
Program
Save Area,TCB
Register 15
')I
-YI
EXIT Prolog
(lEAVEEXP)
Code
1
0- Normal completion.
4 - Subtask terminated with code
33E, all subtask resources freed.
Diagram 20-2. DETACH Processing (IEAVEEDO) (part 4 of 8)
Extended Description
5
DETACH saves the TCBECB, resets with the address
of the workarea ECB, allows the subtask to complete
processing, and posts the TCB completion code if an
ATTACH ECB exists.
6
DETACH frees the TCB problem program save area,
located in subpool 250, if one exists, unchains the TCB
from the family queue, and frees the detach TCB.
~
~
o·
=
~
a:
(D
iSO
"C:S
~
ao·
=
~
~
\D
7
DETACH sets the return code for SVC entry
according to completion conditions.
8
ABEND processing is the same as normal processing,
3xcept the TCBECB field is cleared to zeros.
Module
Label
~
~
Diagram 20-2. DETACH Processing (IEAVEEDO) (part 5 of 8)
Q
~
~
~
...~
""
1
ar-
Process
Input
rI.l
,
:\
.'
~---,-'" - - - - ~-i
TCBFEXTR
TCBECB
n'
r-
~
Output
~·x
',.e.
.i.;;,S;~.:F(
Tca
~
~.
T
";
'~_J
TCBIOE
,
Checks the subtask for ECB
and ETXR.
.:
.'.~'
L
,
.:
'" ~.'.'.'
:~
ECB
.
I
}
9
POST
'"
~y
)
II.
S(
.r
I~:~
\;
...
I;:~
"
f..
<
~
,
Register 0
I
;
.~.
~
i
1
:.
~
w
~
@
200 byte workarea
]
~: ~
.;,
SDWAPARM"
V
;
. ';
.,
......
,
FRR Workarea
SDWA
;,
;
..ie, 10
,
I
;
.,:.
;.
Unchains
.
. TCB from the
dispatching queue .
•
For ECB or EXTR.
•
Otherwise,
"
i.~
.
\~DETACH
workarea
~~..
;;;
'
~{
DETACH
Workarea
:~
:~
t~
FromRTM...
>;i
,.
....
ECB
(2-15 for branch
entries)
Registers
0-15
To EXIT Prolog
(lEAVEEXP)
Step 6
11
.'~
y
RITM
II.
II
~
:
....). C
Invalid Address
Space
12
'.:
:;~,
Reset completion code
(23E or 43E) for invalid
parameter or ECB.
r
..
"
6
ASXBTCBS
I
ASXBLTCB
ASXBLTCB
Ensure that the FRR is processing
in the correct address space.
..
.3
f'·
til
s';
~;1
"y
~~
:0
y
: IGC062R2
f
Return @
II..
~
i •.-
Flags
TCBFEXTR=O
ASXB
l...J\.
,;
d.
;~
TCBECB=O
l
~ii
.~
Flags
@TCB
i"
+
~,l
>;~
:
,
TCBIOE=Q
~
:
@SDWA
TCBFC='J..
Effector
L
.;
Register 1
TCBACTN=Q
y
'"
:
Stage 2 Exit
II.
.,
(D
~
ETXR
J
Tca
>@
RITM
Diagram 20-2. DETACH Processing (lEAVEEOO)
(part 6 of 8)
Extended Description
9
DETACH gives control to the POST routine (see
the POST Processing (IEAVSY50) diagram) for
an ATTACH ECB, and gives control to the Stage 2
Exit Effector (see the Stage 2 Exit Effector (I EAVEEE2)
diagram) for end~f-task exit routine processing.
10
DETACH unchains the TCB from the dispatching
queue, and decreases the count of TCBs on the dispatching queue in field ASXBTCBS. DETACH clears
TCB fields TCBECB and TCBIQE, and TCBFEXTR
when either ECB or ETXR conditions exist for the detach
TCB, sets TCBFC to equal 1, but does not free the TCB
itself. If neither ECB or ETXR conditions exist, FR EEMAI N
frees the TCB and its problem program save area (if one
exists).
11
After receiving control from R/TM, the DETACH
FRR (functional recovery routine) ensures that it is
operating in the address space used by the DETACH routine.
If the FRR is processing in the wrong address space, control
goes to R/TM.
12
If DETACH was entered via SVC, field SDWACMPC
is set to X'23E' tor an invalid parameter or to X'43E'
for an invalid ECB address. Control then goes to R/TM with
a return code of 0 in field SDWARCDE. If DETACH was
branch-entered, an indicator is set and step 13 is done.
~
a~r
=
~
is::
(D
[
Q
o
"C
~
a
o·
=
~
~
'"""
'"""
Module
Label
t
-
Diagram 20-2. DETACH Processing (IEAVEEDO) (part 7 of 8)
~
o
~
f'-)
~
Process
Input
Output
It
f'-)
'<
=S
SDWA
13
t"'"
<2
n·
t:
Perform appropriate error
processing.
- I ~I
2"
~
~
From
RfTM
to
~
Retry
(D
~
~
~
Register 0
o or Completion Code
~
- - T - ,.-
J.--..
r- 14
I
I
~
CH
~
I
Register 4
@TCB
J.--
r-
I
I
I
L
-V
IGC044R2
I
II
I SDWARCDE
I
IRW
Return Code:
0- No Retry
4 - Retry
I~
RfTM
IGC062R3
I
:=c
i
~
Check register 0 for a completion
code:
_ _ _l1li1111"_ Step 16
•
Contains 0
•
Contains completion
code: continue.
TCB
-
,= 15
Terminate the originating task.
:>I
:;
t
TCBCMPC
~I------------~
~
..
@ D ETACH Workarea
...io..
DETACH
Workarea
,.
'" 16
iy~ v
Restore registers, cancel the
FRR, and return to the branch
entry caller.
Registers
0-15
To Branch Entry
Caller
Completion Codes:
X'43E' - Invalid ECB
X'53E' - Error before ECB
and ETXR
processing complete
Diagram 20-2. DETACH Processing (ffiAVEEDO) (part 8 of 8)
Extended Description
Module
Label
13
The DETACH FR R recovers the TCe dispatching
queue by routing control to a CHAP recovery routine
(lGC044R2). Control returns. If DETACH was branch
entered for end-of-task resource manager processing, the
terminating TCe is removed from the family queue; if an
invalid Ece was detected, ABTERM code X'43E' is passed
to retry routine IGC062R3. If end-of-task resource manager processing had not yet completed processing the endof-task ECB or EXTR, ABTERM code X'53E' is passed to
the retry routine. Otherwise, no ABTERM is indicated for
t"is routine. The DETACH FRR gives R/TM control with a
return code of 0 for SVC entries or 4 for branch entries. The
SDWA contains recording information. Field SDWA VRA
contains re.cording information as set by routine IGC044R2.
(See extended description of CHAP SVC for description of
this information.) Also, field SDWARECP is set to module
name (lEAVEEDO), CSECT name (lGC062), and FRR
name (lGC062R2). For branch entries, general register 0
contains a completion code of X'43E' to indicate a validity
check error, a X'53E' to indicate an error in end-of-task
processing, or 0 for no error. Control goes to R/TM.
14
The DETACH recovery retry routine checks register
o for a completion code. If register 0 does not con-
tain a completion code, control goes to step 16. Otherwise,
processing continues.
15
If a completion code exists, the DETACH recovery
retry routine terminates the originating task by
giving control to R/TM.
{;I'.I
g
g.
=
~
a::
(1)
g
~
o
~
o
'C
~
a
5'
=
~
....
~
w
16
Control returns to the caller that entered DETACH
via a branch.
IGC062R3
~
~
Diagram 20-3. CHAP Processing (lEAVECHO) (part 1 of 6)
.f;Io.
o
Ie
~
From SVC I H to
process a
CHAP request
Output
Input
~
rn
'<
=~
in°
Register 1
t
IGC044
To Fullword with
Address of TCB, or 0
1
Ensure that the input address is
valid (for non-authorized caller's) °
X'22C'
r61
X'12C'
~
- Address of parameter word
is invalid.
- TCB not a subtask, or task
already terminated.
~
~
InValid Caller
(D
.f;Io.
~
~
f
w
~
Register 0
Value to Add to
Dispatching Priority
Register 4
• Caller's TCB
-1
I
I
_..l..-_
TCB (after CHAP)
.2
Find the specified TC~ and set the
dispatching priority for the t a s k . .
.il
111
VI
-3
Re-order task queue if necessary.
..
all
I \Jtsu'> ....
1------""'4
Fullword
+ofTCB
to be
•
Chapped
Caller (via
Exit Prologue)
TCBFC
I "'UU,","'''
Diagram 20-3. CHAP Processing (IEAVECHO) (part 2 of 6)
Extended Description
The CHAP routine permits a problem program or system
program to alter its dispatching priority or the dispatching.priority of one of its subtasks. Thesubtask must belong
to·the issuer; that is, the subtask must have been attached
by a routine belonging to the caller's task, and its TCB
must therefore be on the caller's subtask queue. In addition,
an authorized caller can change the dispatching priority
of any task in the address space.
A program issuing the CHAP macro instruction may change
the dispatching priority of a specified task to any value
between 0 and the issuer's limit priority. The distinction
between dispatching and limit priorities follows in the next
paragraphs.
Although both priorities are specified as parameters of
the ATTACH macro instruction, they serve different functions. The dispatching priority determines the appropriate
position of a TCB in the task queue, and also the next
routine to be placed in execution by the dispatcher. The
dispatcher gives control to the ready TCB with the highest
dispatching priority.
In contrast, the limit priority is used by the CHAP routine
to determine the maximum value to which it may increase
the dispatching priority of the task.
r.I)
(D
g,
e'
=
~
a::
(D
[
o
~
o
"0
"ae'=
~
~
VI
Module
Label
Extended Description
Module
IGC044
1
IEAVECHO
If 0 is supplied in register 1, the dispatching priority
of the caller is to be changed. The address of the
caller's TCB was placed in register 4 by the SVC Interruption Handler (lH), and no validity check of the address is
required. The CHAP routine holds the local lock.
2
If a valid address is supplied in register 1 and if the
caller is not authorized, CHAP compares the specified
TCB address with the addresses of the TCBs that represent
the caller's subtasks. If the subtask is not found, CHAP
abnormally terminates the caller.
The CHAP routine does not make this test if the caller's
TCB (address in register 4) is the subject.
The dispatching priority is in field TCBDSP, and the limit
priority is in field TCBLMP.
3
CHAP queues the TCB according to its dispatching
priority, but at the end of the group with the same
priority level.
Label
of"
....N
Diagram 20-3. CHAP Processing (IEAVECHO) (part 3 of 6)
0\
i
~
N
~
From RrrM
nput
i
I
ir:
@SDWA
I,
Recover the TCB queue.
/
~
.t.
~
y
.
Not Valid
Verify current ASCB and ASXB
for no errors.
..
r
...
IEAVECAS
ASCBASXB
~
ASXB
f'
!
,
Register 2
@ Dump Header
I
..
I ...
) 7
Dump the SOA, LSQA, and
Trace Table.
..L
~
...
r
SVC DUMP
" ...""
Register 15
"'.1
y~
Verify
ASCB/ASXB
/'
I
SDWARCDE
.
ASCB
PSAAOLD~ \
;~;;;
r
~
PSA
SDWACMPC
RrrM
y
w
:...
-
...
...
...
.,.> 6
,
SDWA
From
ATTACH,
DETACH,
STATUS, or
FR R Workarea
SDWAPARM-
Ensure that the FRR is processing
incorrect add ress space.
I
~N
f
-
...
5
SDWA
Output
~
IGC044R1
-.;> 4
Register 1
Sf'
...f
I _~
@ 200 Byte Workarea
n
~
~
~
Register 0
Process
Return Code
=4
1~l;
.~
~ ..
Diagram 20-3. CHAP Processing (lEAVECHO) (part 4 of 6)
Extended Description
4
After receiving control from R/TM, the CHAP FR R
ensures that it is operating in the address space used by
the CHAP routine. If the FRR is processing in the wrong
address space, control goes to R/TM. If an invalid parameter
is detected, the CHAP FRR sets the SDWACMPC field of
the SDWA to a X'22C' completion code and control goes to
R/TM,' If "percolation" has occurred, the CHAP FRR specifies 'no recording' and control goes to R/TM. The return
code is zero for all three cases.
5
Then, the CHAP FRR calls routine IGC044R2 (an
external entry) to recover the TCB dispatching queue,
sets a 0 return code, and gives control to R/TM. Recording
information has been set in field SDWA VRA by routine
IGC044R2. In addition, field SDWARECP contains the
module name.(lEAVECHO), the CSECT name (lGC044),
and the FRR name (lGC044R1').
6
The CHAP TCB queues recovery routine verifies the
accuracy of the current ASCB and ASX B by goi ng
to IEAVECAS. If the ASCB and ASXB are not valid,
register 15 contains a return code of 4.
7
fI)
(D
sa.
e·
=
~
a::
(D
[
o....
o
"0
q
=-e·
=
~
.....
SVC DUMP dumps the LSOA, SOA, and trace table,
via the SDUMP macro instruction.
Module
Label
t
-
Diagram 20-3. CHAP Processing (lEAVECHO) (part 5 of 6)
co
o
~
~
....
)rocess
,
Output
,It
fIl
1
~
i
Register 15
Queue Empty
8
Recover TCB dispatching queue in the
current address
spare.
...
r""
J<
~
r
-"h
Return COde
)1
=8
I
IEAVEQV3
...
SDWA
e.
§
CD
.....
9
".
Scan TCB family queue in current
address space, and correct invalid
fields.
~
SDWAVRA
~
;f-
~
I
ASXB
w
~
10
.."
Update count of TCBs.
ASCB
"'
/
11
"v
Update count of ready TCBs.
<
,
"
"'
ASXBTCBS
ASCBTCBS
Diagram 20-3. CHAP Processing (IEAVECHO) (part 6 of 6)
Extended Description
8
The IEAVEQVO routine (entry point IEAVEQV3)
recovers the TCB dispatching queue. If the queue is
empty, register 15 contains a return code of 8.
9
The CHAP queues recovery routine corrects any
invalid fields in the TCB family queue. The SDWA
contains descriptive information about the errors found
and corrected. Field SDWAVRA contains the queue verify
routine name, lEA VEQV3, followed by recording information supplied by that routine. Following this recording
information is the name IGC044R2 and a four-byte
descriptor field. The format of the descriptor follows:
Byte
1
Bit
0
Description
Set to 1: errors were detected but not recorded.
Set to 0: all errors detected were recorded.
1-7
Reserved
Number of errors r:ecorded
2
0-7
3
0-7
Number of errors detected.
4
0-7
Return code from IGC044R2.
Following the descriptor is a 16-byte entry for each error
detected. The entry format follows:
Bytes
~
1-4
Desc,ription
NTC~ or L TC~ to indicate whether TCBNTC
or TCBLTC was updated.
5-8
Address of TCB with invalid field.
9-12
Contents of the invalid field.
13-16
The replacement address (new contents for
that field).
(')
go
:=
~
Recording terminates whenever SDWA VRA becomes filled
(indicated bv fields SDWAVRAL and SDWAURAL).
~
(II
[
a.
o
'0
~
=3·
:=
~
N
IQ
10
The count of ready TCBs in the ASCB (ASCBTCBS)
is updated to reflect the TCBs on the dispatching
queue. The total number of TCBs on the dispatching queue
is updated in the ASXB (ASXBTCBS). Control then returns
to the caller. CHAP itself, ATTACH, DETACH, and STATUS
all call routine IGC044R2 to recover the TCB queue.
Module
Label
;t
Diagram 204. WAIT Processing (lEAVSYSO) (part 1 of 2)
~
otil
~
t-J
From SVC IH to
process WAIT request
Input
til
~
§
r«i
tr
r~
~
~
~
(D
~
IGC001
Register 0
Number of events; sign bit
on for long WAIT
True FormAddress of ECB
t-J
Complemented FormAddress of ECB List
List of ECBs
~
S2.
i
r6
~
:.....
Branch
Entry
ECBs
Exit via Exit
Prologue for SVC
entry. Exit to
dispatcher for'
branch entry.
Register 1
Completion C~
1
Check the wait count.
2
Check list addresses and each ECB
address in the list (Supervisor key
callers are not checked). Check
individual ECB addresses.
3
Check whether number of
ECBs is less than wait count,
4
Determine if requester should
wait, and set ECB wait bit if this
is so. Set requester's RB address in
ECB. Set RBWCF to number of
events. Set RBXWAIT field.
Fbi
l i ' 0 , v - - - - 0 & ' - - - - - - -.......
5
Decrease count of ready TCBs.
"'~
.,*:
~7:
6
Checks for Long Wait request,
I
I
I
'<
til
OutDut
I
_ _ ..J
ill'
X'201' -Invalid ECB @
X'101' - Number of ECBs is less
than the wait count
"J!,1
X'301' - Attempt to set wait bit
wh ich is a Iread y set
I
I
I
I
I
r---
L __ _
ECB
Address of RS
)I
~w
uecrealit:
Exit via Exit Prolog (JEAVEEXP) for SVC entry.
Exit to dispatcher (J EA V EDSO) for branch entry.
~
~ A~""D""''''''''5
(:,
w
,.
Invalid
RiM
.,
If ECB is not an EVENTS
ECB or an extended ECB
but has been waited on:
....
EVNTENTP
ABEND
ABEND Caller
(Codes 402
and 502)
"-
ABEND
Code
702
User
Exit
Routine
IEAOVL01
a) Check if R B address is a
valid RB address.
..
b) Check if waiting RB is
authorized to change ECB.
0
00
~
EVNTLSTA
....
...
II
EVNT
b) Check if waiting RB is
authorized to change ECB.
If caller is wrong protect
key, if event table is full, or
if table address is invalid.
ASXB
TCB
.", Step 3
a) Check if table address is
a valid table address.
I
Post Exit
queue
..
If ECB is an EVENTS ECB:
TCBEVENT
I
EVNTTCBP
~
e
- 4
I
ECB
~
IEAOPT02
...
,..
~
Test Key
and
Alignment
ABEND
ABEND Caller
(Code 202)
I
v
ECB
I
I
Diagram 20-5. POST Processing (IEAVSY50) (part 4 of 12)
Extended Description
Module
Label
Extended Description
4
IEAVSY50
RBCHECK
5
An EVENTS ECB is determined by checking the low
order bit of a waited on ECB. If that bit is on, the
ECB is assumed to be an EVENTS ECB.
b) If the waiting RB is problem key (key 8-15), the ECB
address is passed to validity check to verify the waiting
TCB's authorization to change that ECB. If validity
check fails, the caller will be abended with '202'.
b) If an RB is waiting on this event table, it is chec;:ked for
problem key (keys·8-15). If it is problem key, the ECB
is referenced in the key of the waiting TCB. If the
waiting TCB was not in the proper key, the EVENT FRR
will receive control, change the completion code to
'402', and percolate.
b) The completion bit and completion code are stored
into the ECB.
~
(")
g.
1:1
!':»
ac:
a
[
o
o"'"
1a
e'
1:1
to
N
N
(/I
d The exit routine identified in the ECB extension is
invoked via a branch. This routine executes as a
closed subroutine of post. The interface to the exit
routine is described in the OS/VS2 System
Programming Library: Supervisor. Upon return,
control is given to step 11.
<:
~
<=>
w
00
Q
(/I
the table is full, in which case the user will be abended
with '502'. The complete bit and the completion code
are stored in the ECB, and control is given to step 3a .
a) The ECB and ECB extension are checked to ensure that
they pass all post restrictions. Failure to pass a
restriction results in a 702 ABEND. The reason code
associated with the abend identifies the cause of the
abend.
NOEVENTS
CI)
d The completed event is added to the event table, unless
It is assumed that an ECB extension exists when the
low order two bits of a waited-on ECB are on.
Label
a) The TCB RB queue is searched, comparing the RB address
in the ECB to that of the RB in the address space. If an
equal compare is made, the ECB is valid.
a) The event table address is taken from the ECB, and the
TCB address is gotten from the event table. The TCB
ready queue is searched for this TCB. When it is found,
the event table queue is searched for the event table.
If it is found, the table address is valid.
. 4.5
If the ECB is w~ited on and the low order bit is not on,
the ECB is a standard ECB.
Module
lEA VSY50
EXTECB
~
N
Diagram 20-5. POST Processing (lEA VSY50) (part 5 of 12)
N
0\
otil
'
(")
g.
=
~
a::
(D
[
....o
o
"0
~
~
cr
=
~
~
~
~,
Entry is because failure occurred during EVENTS
processing.
EVNTFRR
tw
I
Diagram 20-5. POST Processing (lEAVSY50) (Part 12.0 of 12)
w
o
or.n
"<
r.n
~
from R/TM
Input
Output
r.n
'<
~
EXECBFRR:
~
.r:-
~
(=).
r:-
0:
Register 1
L----,
~
~
=
3
(D
22
If error expected, change
completion code and go
to step 25.
SDWA
23
Parameter
Address
Prime SDWA variable
recording area and
indicate that recording
is to be performed.
SDWACMPC
SDWARCDE
24
The extended save area
indicator is zeroed to
indicate that the save
area is no longer in use.
25
Percolate the error.
~
ow
00
FRR work area
o
o
W
Oc
o
Ul
~
'
~
e'
=
~
a:
(I>
[
o....
o
'Eet
e'
=
~
~
~
Completion of events represented by initialized ECBs is
accomplished by the existing system POST facility.
Completed events are processed in POST-occurrence order
through issuance of the EVENTS macro to the appropriate
event table. When the user routine regains control after
issuing the EVENTS macro with the WAIT operand, register
one points to a list of pointers to posted ECBs. The posted
ECBs retain the current format (i.e., the high-order byte
contains a hex '40' and the low-order 30 bits contain the
completion code).
Module
Label
Extended Description
Module
1
IEAVEVTO IEAVEVTO
The caller's registers are saved in the EVENTS local
save area (WSALEVNT).
2
The registers are initialized to provide the standard SVC
interface, and the type-one SVC mainline (lGC125) is
called to do the processing requested by the caller of EVENTS.
(See processing that begins at step 5J Control returns to
step 3 from IGC125.
3
On return from the type-one mainline, a check is made
for a WAIT=YES request. If YES, the caller's resume
environment is in the caller's RBITCB. EVENTS will then
store register one in the TCB register one save area, purge the
FRR stack, disable, free the local lock, and branch enter the
dispatcher. Another task can then be dispatched, since the
caller's RB is in a wait condition.
4
If the caller did not specify WAIT=YES,
EVENTS will restore registers 2-14 and return to the
caller. (Caller's parameters have been processedJ
Label
i"
~
Diagram 20-6. EVENTS Processing (lEAVEVTO) (part 3 of 8)
~.
SVC entry or
internal branch
from within
EVENTS
~
~
~
Input
~
SCi-
~.
E:
~
TCB
Register 1
Register 0
I
It EVNTA
xOxxxxxx
~
r-
~
f
TCB
TCBEVNT
'<
~
~
i
~
~
(EVNTA
~
-
+ECB 1
t ECB2
1t
Update events table.
~
EVNTLNK
EVNTTCBP
" EVNTRBP
~
,
+ECB 1
+ECB2
+ECB M-1
Iso It
L-.
I
I
I
ECB M
i-
6
Do ECB initialization if requested
by ECB parameter in EVENTS
macro.
ECB
r-;XXXXX1
ASCB
I
I
ECB
00000000
ECB M
J
+ ECB M-1
SO
5
I
I
EVNTTCB
~
1-
I
EVNTLNK
~
T-· I
I
(D
.a:o.
•
IGC125
a
E
Output
~, '. f--.
1 __
RB
!-
7
Do wait processing if requested
by WAIT parameter in EVENTS
macro.
6
ASCBTCBS
RBXWAIT
ASCBSWCT
RBWCF
'\
v
To EXIT
Prolog
(lEAVEEXP)
if SVC entry or to caller if
internal branch from within
EVENTS Processing
Diagram 20-6. EVENTS Processing (ffiAVEVTO) (part 4 of 8)
Extended Description
Module
5
IEAVEVTO IGC125
If WAIT=YES or WAIT=NO (bits 0 and 1 of register 0)
are specified, bits 8-31 of register 0 (if bit 2 is off)
point to the last event entry that the caller has specified.
(If LAST parameter was not specified, the caller has
processed only one entry.) In either case, EVENTS moves
all unprocessed event entries to the top of the event table.
The assumption is that the top entry, or all entries up to the
last specified by the caller, have been processed by the caller.
Entries are placed in the event table, as; ECBs complete,
by Post if the ECB has been initialized to the EVENTS
format (X'80' in the high order byte and the event table
address plus one in the low order three bytes) . Entries are
also placed in the event table by EVENTS to initialize a
posted ECB if the ECB parameter was specified in the
EVENTS macro. The event entries are added to the event
table in FIFO order and the end of list indicator is moved
as events are added.
6
If ECB= is specified (bit 2, register 0 is on), the ECB
pointed to by bits 8-31 of register 0 is initialized to
the EVENTS format, unless the ECB has already been
posted, in which case the address of the ECB will be added
to the list of completed events.
[
~
1:1
~
a::
iSa
1a
~.
1:1
·t!oj
Label
Extended Description
7
If WAIT=YES or WAIT=NO have been specified,
EVENTS will check if there are any completed events
in the event table. If there are, the address of the first
completed event entry will be placed in register 1 as return
information for the caller. If WAIT=NO was specified and
there are no completed events in the table, register 1 will
contain binary zeros. Control will be returned to the caller.
If WAIT=YES was specified and there are no completed
events in the table, EVENTS will set the RB wait count
(RBWCF) to one to cause the caller to wait, store the RB
address in the event table (EVNTRBP) to indicate that this
table is waiting for an event to complete, and decrement the
count of ready TCBs (ASCBTCBS). If the count of ready
TCBs goes to zero, EVENTS will increment the short wait
count (ASCBSWCT). This latter processing is for use by the
System Resource Manager (SRM).
Module
Label
~
~
Diagram 20-6. EVENTS Processing (lEAVEVTO)
(part 5 of 8)
w
00
From Extended
SVC Router
(Part of SVC IH)
o
C"I)
~
Output
~
C"I)
'<
[~
~
ar-
~
rr
r-
*
.~
..!)
Register 0
I
~
~.
<:
f
80007FFF
I
I
(D
OOOOOOOO
Register 0
- 8
·f
TCB
Register 1
~
IEAVEVT1:
;~
;Ii
J TCBEVENT
Create a new event table
if requested.
TCBEVENT
GETMAIN
(EVNTA
I
TCB
00000000
~
EVNTLNK
Get event
table (SP253)
..
?,i
EVNTTCB
'<
C"I)
~
:::0
i
~
~f-'
w
If-'
~
EVNTLNK
Register 0
I
OOOOOOOO
Register 1
It
EVNTB
I
t
EVNTTCB
TCB
TCBEVNT
EVNTB
I(
EVNTLNK
EVNTTCB
4(-
'f'
'''
EVNTA
"
'(
Delete old event table
if requested.
Register 0
TCBEVENT
[xxxxxxxx
Register 1
xxxxxxxx
EVNTLNK
1
EVNTLNK
EVNTTCB
EVNTTCB
I
9
'ILl
Diagram 20-6. EVENTS Processing (lEAVEVTO)
(part 6
Extended Description
Module
8
IEAVEVTO IEAVEVT1
If register 0 bit 1 is on, a table create has been
requested. (EVENTS ENTRI ES=n was specified.)
Events will compute the table size based on the number of
entries requested. (There can be a maximum of 32,767
entries in an event table.) Get the table from SP 253 (task
related storage), initialize the event table header to contain
a pointer to the requesting TCS, set pointer to the first
valid event table entry, to the last valid event table entry,
and to the last active event table entry. EVENTS will queue
the new event table to the top of the event table queue
for the requesting TCS, and-return to the caller with
the table address in register one.
9
If register 0 is zero and register one contains a table
address, the EVENTS macro specified
ENTRIES=DELETE. (The caller wants to delete the event
table.) EVENTS will locate the table on the requesting TeS's
event table queue, dequeue the event table, and free the
event table.
til
~
a5·
::I
~
a::
~
[
o
....
o
'"C
~
a.
5·
::I
~
N
w
1.0
of 8)
Label
of"
~
Diagram 20..6. EVENTS Processing (lEAVEVTO) (part 7 of 8)
Q
&J
"r TCB@, or ECB~
;
238
338
438
638
738
838
II .....1 _ _ _.........
Meaning
Task already has or is waiting
forresouTce
Invalid minor name length
Caller not authorjzed fOT
function
Invalid parameter list
Out -of storage
Unexpected error
ENO denied due to resource
control block damage
When returning to calter:
Unpredictable
Resource in use:
Register 1
Unpredictable .
J
a) ABEND when ENOs are not being
processed for that resource.
Register '14
Unpredictable
J
b) Obtain, initialize, and queue OEL
when necessary.
,
OE Ls
CVT
c) Notify System Resource Manager
when necessary.
CVTSPSA
Global Workarea
Vector Table
I
WSAGNOD
ENO/DEO
GlobalVVork/Save
Area
d) Wait for resource to become
available, when necessary.
...i - - - - ,
....p~
6 Invoke STATUS to set "Step must
o
Parameter List
3
12
15
24
27
36
39
Return
Code
complete", when necessary.
J
7
1
Register 0
Set appropriate return code and ,return
to caller.
-
.~
Diagram 20-7. ENQ/RESERVE Processing (lEAVENQ 1) (part 2 of 4)
The ENO routine, working with the DEO routine, permits programs issuing the ENO
macro instruction or the RESERVE macro instruction to gain contiOl of a resource
or set of resources. The requested resource may be one or more data sets, records
within a data set, programs, or work areas within main storage. ENQ uses the symbolic
name of the resource to control access to the resource.
The ENO routine places in a resource queue all resource requests specified in the
caller's macro instruction. If no other ENO-issuing program is using any of the requested
resources, the ENO routine, via the Exit Prolog routine and the dispatcher, returns
control to the caller, and the caller is the owner of the resource(s). But ifany requested
resource is already in use by another ENO-issuing program, the ENO routine may place
the caller in a wait condition until the resource becomes available.
Extended Description
Module
1
IEAVEN01
ENO passes control to ABEND when the caller
issues invalid input .. Required authorization is
verified, when necessary, by invoking the TESTAUTH
macro.
2
When the ENO resource queue is not referenceable
(indicated by a flag in the ENO/DEO Global
Work/Save area), control is passed to ABEND. This
indicator is set during ENQ/DEO recovery when either
the major or minor OCB queue could not be repaired.
3
ENO'searches the resource queues to determine
whether the requested resource is already in use.
ENO searches the major OCB queue for a major OCB
that contains the specified qname. If it finds the qname,
at least one resource in the set of resources is in use, and
the routine then searches the associated minor OC.B queue
for the rname and scope.
Label
=
~
a::
(II
[
....
o
o
"0
~
a
e'
=
~
N
~
CN
a) When RET=CHNG or TEST was specified and the
resource was not in use, control is returned to the caller
with the appropriate return code (8 or 0 respectively).
b) A OEL, minor OCB, and major OCB or a OEL and a
minor OCB are obtained, initialized, and queued to the
appropriate queues. When a major aCB al ready exists
for this resource, one does not need to be obtained.
Another requester has access to the resource, as indicated by a major and minor OCB containing the
resource names and scope:
a) When ENOs are being stopped for the specified resource
(MINNOENO on in minor OCB), control is passed to
ABEND. This indicator is set during ENO/DEO recovery
when the OEL queue for this resource could not be
repaired.
ENOYMIN
b) This processing depends on the particular RET option
that the caller has specified, on the type of requestshared (S) or exclusive (E) - and on the types of OELs
already on the queue.
XGETOEL
When the caller desires to be placed in the queue for the
specified resource, a OEL is obtained, initialized, and
placed on the OEL queue for that resource. The OEL is
obtained either from storage previously used (and saved)
by ENO or by invoking GETMAIN. When all previous
OELs on the queue and the present OEL request are
both for "shared" control of the resource, the new
requester and the previous requesters may simultaneously
share the resource. Thus, a requester need not have its
OEL at the top of the "shared" group of OELs and still
be permitted to access the resource.
c) When this occurs and the scope of the resource is
SYSTEM or SYSTEMS and the current requester
is the first to wait for the resource, the Systems
Resource Manager is notified, by issuing a SYSEVENT.
The'absence of OCBs with the specified qnamername-scope attributes indicates that the requested
resource is not in use. If RESERVE was requested, and the
device obtained via the UCB keyword is a shareable direct
access device, and the requester has control of the resource,
ENO will increase the UCBSOC count. This causes the I/O
Supervisor to "reserve" the device when a user iss...es I/O
to that device.
ENOYEOL
6
XENDUP
XGETaEL
XGETMAJ
XHOLD
d) The requester's willingness to wait for the resource
is indicated by a RET option of HAVE, NON E, or the
omission of the RET operand. The RET option of
TEST never causes creation of a OEL. If RET is USE,
a OEL is created only if the requester can have immediate
access to the resource.
When the caller has specified 'SMC=STEP', ENO will
invoke STATUS to perform the "step must complete"
function.
X~ETMIN
Label
5
·XFINDMAJ
XFINDMIN
4
Module
These control b!ocks are obtained either from storage previously used (and saved) by ENOor by invoking GETMAIN,
ENOID
til
(II
a
e·
Extended Description
7
The appropriate return code is set and control is
returned to the caller.
f"
t
o
~
k)
~
Diagram 20-7. ENQ/RESERVE Processing (lEAVENQl) (part 3 of 4)
EN'Q Return Codes
RESERVE Return Codes
Hexadecimal
Hexadecimal
Code
COM
o
For RET=TEST, the resource was immediately available. For
RET=USE, RET=HAVe, or ECB=, control of the resource has been
assigned to the active task. For RET=CHNG, the status of the
resource has been changed to exclusive.
4
For RET=TEST or RET=USE. the resource is not immediately
available. For RET=CHNG, the status cannot be changed to shared.
For ECB=, the ECB will be posted when available.
~
~
~
ci(;'
r-t
~
~
~
8
~
(1)
,J:..
~
~
~
tr6
~
~
Meaning
20
For RET=TEST, RET=USE, RET=HAVE, or ECB=, a previous request
for contrOl of the same resource has been made for the same task. Task
has control of resource. For RET=CHNG, the resource has' not been
queued. If bit 3 is on - shared control of resource; if bit 3 is offexclusive control.
A previous request for control of the same resource has been made for
the same task. Task does not have control of resource.
Meaning
o
For RET=TEST, the resource was immediately available. For
RET=USE, RET=HAVE, or ECB, control of the resource has been
assigned to the active task.
4
For RET=TEST or RET=USE, the resource is not immediately
available. For eCB=, the ECB will be posted when available.
8
A previous request for control of the same resource has been made for
the same task. Task has control of resource. If bit 3 is on - shared
control of resource; if bit 3 is off - exclusive control.
20
A previous request for control of the same resource has been made for
the same task. Task does not have control of resource.
Diagram 20-7. ENQ/RESERVE Processing (lEAVENQl) (part 4 of 4)
DEQ Return Codes
Hexadecimal
Code
CI}
(D
g.
5·
=
~
i(
(D
[
o....
o
"0
~
a5·
=
~
tVI
Meaning
o
The resource has been released.
4
The resource has been requested for the task, but the task has not
been assigned control. The task is not removed from the wait condition.
(This return code could result if DEQ is issued within an exit routine
which was given control because of an interruption.)
8
Control of the resource has not been requested by the active task, or
the resource has already been released.
t
Diagram 20-8. DEQ Processing (IEAVENQl) (part 1 of 2)
~
From the SVC IH
to process
D EQ requests
o
~
~
N
Input
fJ'l
Parameter List
I
O;;rTCBAdd;----1
£-- ?i-
i
•
Minor
Length
Flags
t)'
Flags
•
~
~
<:
o
i
___
___
_ _ _ _ _ _ JI
Addr
of_UCB
Addr
~
~
Register 1
.+Para meter List I UCB
Register 3
__
FfEVT
1 UCBSQC
Register 4
Major
1+ Current TCSQCBs
Register 5
[+Current RS I I
'<
fJ'l
N
~
t
~
w
~
Register 6
Entry Point Addr
Register 7
Current ASCB
[+
I
4
Minor
~aCB.
1
Return Addr
CVT
Register 1
DEQ passes control to ABEND when the
caller issues invalid input.
ABEND Code
130
230
330
430
530
630
730
Resource not found:
•
If unconditional DEQ, ABEND
•
If conditional DEQ, set return code
and return to caller.
Resource found:
• Caller does not own resource
- Unconditional DEQ'with ECB =
not specified on ENQ, ABEND.
Caller owns resource.
- Dequeue and free resource control
blocks no longer needed.
~ti1Y"."·'I,
.'L_____J
- Notify System Resources
Manager when necessary.
Unpredictable
Register 14
Unpredictable
Register 15
o or parameter
list address
~
---15
" { L,1
Register 1
o
CVTSPSA
,
Unpredictable ~
QELs
CVTFQCB
I,',.
Register 0
.,
-Issue STARTIO when necessary to
release device.
'
Resource not found
Invalid minor name length
Not authorized for function
Invalid parameter list
Resource is being waited upon
0 ut of storage
Unexpected error
VVhen returning to CALLER:
- Conditional DEQ or ECB =specified
on ENQ, set return code and
return to caller.
•
Meaning
Code
Determine whether specified resource is
in ENQ resource queue.
I/
Register 14
\
3
........... , .
~UCB
(I)
~
1
2
Major Name
Minor Name
VVhen VVorking ABEND:
IGC048
Ret
Code
t"'"
~
Output
'
Global VVorkarea
Vector Table
I
NSAGNQDQ-L
~
ENQ/DEQ
GlobalVVork/Save
Area
~,
Return
Code
- Post next requester of this resource
when necessary.
27
- Invoke STATUS, when necessary,
to reset "Step must be Complete"
for caller.
Return
Code
~1"·.!.".'-----1
39
Return
Code
Return
Code
Return
- DEQ passes control to the caller
or to the readied requester.
Code
Diagram 20-8. DEQ Processing (IEAVENQl) (part 2 of 2)
When the program finishes using the resource(s), it issues a DEQ macro instruction,
which causes the DEQ routine to remove one or more elements from the request queue.
This may cause other waiting requests to gain control via the POST routine.
Extended Description
1
Module
Label
DEQ passes control to ABEND when the caller issues
invalid input.
2
DEQ searches for the QEl that represents a request
that should now be dequeued. It firsffinds both a
major QCB and a minor QCB containing the specified
resource names and scope. DEQ then examines the QEl
queue associated with the specified resource. If the caller's
"ICB address matches that stored in one of the QEls, the
caller has issued an ENQ for that resource.
3
When the specified resource request (QEl) is not found,
the caller is attempting to DEQ a resource that he is not
ENQed on.
IEAVENQ1
XFINDMAJ
XFINDMIN
DEQNQEl
(II
ao·
::I
~
~
b) When the caUer owns or shares the resource, the QEl is
dequeued and that storage is saved for future use Of freed
by invoking FREEMAfN.
DEQ examines the QCB queues to determine if any QCB
may be released. If there are no more QEls queued to the
minor QCB, the minor QCB can be released .. In this case,
DEQ removes the minor QCB from its queue and frees or
saves the space it occupies. It then examines the minor
QCB queue to decide whether the major QCB is needed
and can be similarly eliminated. If there are no minor
QCBs queued to the major QCB, DEQ removes the major
QCB from its queue and frees or saves its space. DEQ tlten
processes in a similar manner any other input parameters
that represent QEls to be dequeued.
"Reserved" QELs being
dequ~ued
from an owning group
Label
XUNCHAIN
XFREEQEl
XFREEMIN
XFREEMAJ
XDEQQEl
count reaches zero, the DEQ routine issues a "STARTtO"
instruction. This causes the I/O Supervisor to "release"
the shared direct access device.
b) When a conditional DEQ was requested, the appropriate
return code is set and control returns to the caller.
c;n
Module
will cause the UCBSQC count to be decreased. When the
a) When the caller has requested an unconditional 0 EQ
(RET=NONE), control is passed to ABEND.
4
Extended Description
When the specified resource request (QEl) is found,
this indicates that the caller does indeed have an ENQ
outstanding for this resource. DEQ scans the QEl queue to
determine whether the caller currently owns or shares the
resource.
DEQNGENR
a) When the caller does not own or share the resource,
tht;! input parameters are checked to determine the action
to be taken.
DEQNDEQ1
When an unconditional DEQ is requested (RET=NONE)
and the original ENQ did not specify the ECB parameter, control is passed to ABEND.
DEQPART2
When a conditional DEQ was specified or the original
ENQ specified the ECB parameter, the appropriate return
code is set and control returns to the caller.
DEQPART2
When the scope of the resource being DEQed is SYSTEM
or SYSTEMS, System Resources Manager (SRM) is notified that the resource is being released. If subsequently
that resource has other requesters, the SRM is notified
that once again the resource is being held. Communication to the SRM is via a SYSEVENT.
XRlSE
XHOlD
When additional r(!quests are outstanding for the resource
being DEQed and the resource is available for use, POST
is invoked to notify the appropriate requester(s) that they
own the resource.
XPOST
DEQ increases the UCBSQC count for all reserved QEls
going from a non-owning group to an owning group. This
causes the I/O Supervisor to "reserve" the shared direct
access device when a user issues I/O to that device.
(II
[
o
~
o
"0
~
a
~.
::I
~
t
-...l
STATUS is invoked to reset "step-must complete",
when the "RMC=STEP" parameter is specified. DEQ
passes control to the caller or to the readied requester.
XENDUP
~
Diagram20-9. ENQ/DEQ/RESERVE Recovery (IEAVENQl) (part 1 of 2)
N
&
FromRITM
Input
~
Register 1
N
CA
!f
~
9
'~
,OQ
'IEAVSRRl
I
@SDWA
Parameter List
~
o
p
V
~r
1
Update the SDWA.
2
Determine whether the error can
be handled by the FRR.
r""
~
~
•
Cannot be handled.
i
....
•
Error can beprooessed:
continue.
CVT
~
.
[;r
N
/
"l-
CVTSPSA
MajorOCBs
I~Minor
aCB•
3
CVTFOCB ...;
I
~
I
'Global
Workarea
.
ENO/DEO
Global Save Area
I)""
WSAGNODO .-
GSCOUNT
,.
,
,
GSOUEUE
.
...
'"
RrrM
Global Workarea
..
Attemptto fix majorOCB queue,
minorOCB queue"or OELqueue.
'11"
MinorQCB
OEls
eN
..
II"
f
c:
SDWA
4
Restor'e registers, set any ABEND
codes, and attempt retry.
..
R1TM
Diagram 20-9. ENQ/DEQ/RESERVE Recovery (lEAVENQl) (part 2 of 2)
Extended Description
Module
1
IEAVEN01
TheENO/DEO FRR updates the SDWA with
diagnostic-type information (I EA VEN01,
IGC048,IEASRR1).
2
The ENO/DEO FRR does not attempt to verify the
resource queues when:
• The LSOA cannot be addressed.
• The CMS lock was not held at the time of the error.
• The user passed an invalid parameter list.
3
The ENO/DEO FRR attempts to fix the major OCB
queue, minor OCB queue, or OEL queue, if necessary.
If the major OCB or minor OCB queue cannot be fixed, the
FRRindicates a serious error condition in the GSNOENO
area of the global save area. If the OEL queue cannot be
fixed, the FRR indicates a serious error condition in the
MINNOENO field of that minor OCB.
The variable area of the SDWA (SDWA VRA) is updated to
reflect the changes made to the resource queues as follows:
Hex Displ
+0
+4
+8
+C
+10
fI}
(D
a
+14
+18
~.
=
~
;c
~
8:o
....
o
"C
~
a
~.
=
~
~
I,Q
4
Contents
Count of number of corrections made to queues
Address of ENO/DEO module
Address resulting from last BAL instruction of
the ENO/DEO FRR
Type of control block damaged
X'10' - OEL
X'14' - mirior OCB
X'18' - major QCB
Beginning address of invalid address range
Ending address of invalid address range
Image of data contained within invalid address
range
The ENO/DEO FRR restores the values and gives
control to R/TM to attempt retry in ENQ or DEO.
The retry will cause the user to ABEND with either a X'738'
or X'730'.system ABEND code, indicating that an unexpected
error was encountered by ENO or DEQ, respectively.
Label
t
Diagram 20-10. SPIE Processing (IEAVTBOO) (part 1 of 4)
(.It
o
From SVC IH
o
~
~
N
Input
Output
~
Register 1
'<
~
a
+TCB,or 0
~(IS"
J
TCB
IGCOO01D
~~
I
1
Check for invalid calls:
I
oz
TCBPIE
I
~
TCBPKF
I
I
I
~
I
~
(D
TCBPMASK
~
I
~N
L __
~
2
Check Register 1 for a 0 value, or
PICAPRMK for a 0 value.
(D
f
w
~
F
\~
j..- PIEPICA
I~ ~,
.
•
Reset TCBPIE17.
•
Zero TCBP I E..
I I
I ]
Restore RBOPSWwith TCBPMASK.,__- -....
•
~-II--®
Completion Code
X'10E' - Invalid PICA Address
X'20E' - Invalid PIE Address
X'3QE' - Unauthorized user for
a program check
code 17.
I
t'""
Register 15
~ree the SCA and PIE if
necessary.
•
------...I.
I\...PICA
I PICAEXT I PICAPRMK
...
Register 1
Code
o - No previous PICA.
PICA Address - PICA exists.
Diagram 20-10. SPIE Processing (IEAVTBOO) (part 2 of 4)
Extended Description
SPI E processing completes the processing needed for a
user to specify a program interruption exit routine. The
initial processing - creating and initializing the fields of a
PICA (program interruption control area) - is performed
by executable coding produced by the expansion of the
SPI E macro. This processing places a program mask, the
address of the user's program-interruption exit routine,
and an interruption mask in the fields of the PICA.
If, after the execution of the SPIE routine, a programcheck interruption occurs in a program being executed for
the issuer's task, the user's exit routine processes the program interruption according to the information in the
PICA.
If an interruption occurs, the interruption supervisor stores
in the PIE the information needed by the user's exit routine
to handle the interruption. This information includes the
program check old PSW and registers 14-2.
For the interruption supervisor to pass control to the
correct error handling routine, it must be able to test for
the existence of a user routine. The main function of the
SPI E routine is to place in the TCB of the macro-issuing
program an indirect pointer to the user routine. If, after
a program-check interruption has occurred, the supervisor
finds an address in the pointer field, it passes control to
the user routine to handle the interruption. Otherwise, the
supervisor's Program Check IH schedules abnormal termination of the task whose error caused the program
interruption.
~
g.n
=
~
a::
(D
[
o....
o
"C:I
~
~
e'
=
~
~
U\
Module
Label
Extended Description
Module
Label
The SCA (SPIE control area) contains the SRB the program
check I H needs to schedule the user routine.
SPI E always refers to the PI E and PICA in the key of the
caller. Violations will result in a program check error. The
SPI E FRR (functional recovery routine) will convert the
program check to either a X'10E' or X'20E' ABEND code.
1
If the caller is in supervisor state, or is in a key other
than that indicated in the TCBPKF field, he cannot
use SPIE.
IEAVTBOO
TEST1
2
Whenever a caller issues a SPI E macro with no
operands, a zero PICA (in register 1) results from the
macro expansion. The saved program mask (TCBPMASK)
is used to set the program mask in the caller's PSW
(RBOPSW). Thus, a SPI E macro with no operands cancels
the effect of a previous SPI E macro.
SPCANCEL
t
Diagram 20-10.
u-
spm Processing (lEAVTBOO)
(part 3 of 4)
N
o
~
fa
1
Process
Input
Register 5
0-,,I
.+
i
n
t:
f
~
ABEND Code
X'017' Requests
4
I
!"
i
I
I
~N
I
~
f
J::: 3 Check for authorized caller.
I
If
RB
I .... " ' .
" ' ..
---
I
_J
~
~
,
Output
.......
=
I
!
r'
.
0
SCA
PIE
r-i
GETMAIN
~::::=-____________~'~ 71 ~~~:
A) Obtain storage for SCA and PIE.
In All Cases:
TCB
r
B) Chain the PICA, PIE,SCA, TCB.
.A
TCBPIE
-y
t...------
....
SCAPIE
~
- ------ --
TCRPMJ\~v
C) Save caller's program mask.
11
If'
C.o.I
]
Ie:
---..
Check TCBPIE field.
TCBPIE
PICA
~
~
....
If'
TCBPIE17
~
\..~
D) Set caller's program mask with _ _L....IL_ _ _ _ _Ll_ _ _...mL_ _.z..J~;::::::~=::___1
PICA program mask.
RBOPSW
E) Set the extended PICA indicator -..,---.:::.__-------1
for page faults.
eailer Via Exit
Prologue. Code
in Register 1 .
IEAVSPIE
From End
of Task
Termination
5
Checkpoint/
Restart
6
Free the SCA if one exists.
~J
. . ~/TM
,.
IEAVSPI
Perform CHECKPOINT or RESTART• •
To Caller of
if required.
,>,xw>:i\_ _ _ _:r""Iu@;tF;ii&MW\
Checkpoi nt/Restart
Diagram 20-10. SPIE Processing (IEAVTBOO) (part 4 of 4)
Extended Description
3
If PICAEXT does not equal zero, the TCBPIE17 bit is
set equal to 1 if the user is authorized~
Module
Label
TESTIE
The TCBPIE17 bit makes it possible to avoid inspection of
the PIE and PICA every time a missing page interruption
occurs. The TCBPIE17 bit equals 1 if the user has provided
an exit routine for this type of interruption.
4
If the TCBPI E field equals 0, this is the first time that
the caller has issued a SPIE macro. A new SCA and
P1E must be built.
SPN017
If the TCBPI E field does not equal 0, a PI E exists from an
earlier execution of the SPI E macro. The SPI E routine sets
various fields, and control returns to the caller. Register 1
contains the address of the PICA.
5
~
~
~'
::I
~
a:
[
o
~
o
ia
5'
=
f"
~
w
SPI E's resource management gets called at end-of-task.
If an SCA exists for the terminating task, it is freed at
this time. Control goes to R/TM.
IEAVSPIE
6
IEAVSPI
SPIE is called by CHECKPOINT/RESTART to save or
restore the status of the user's SP IE exit routines.
t
Diagram 20-11. EXTRACT Processing (lEAVTBOO) (part 1 of 2)
(II
~
From SVC IH to process
an EXTRACT request
oCIl
<:
CIl
l-.,)
CIl
'!
a
IGC00040+8 Entry
ic;.
r-
c:
~
~
2'
a
Parameter List
Register 4
Address of
Caller's TCB
(D
~
<:
Para meter List
CIl
Answer Area Address
:=0
(D
TCB Address, or 0
i
Extract
Field
1
Register 1
IGCOO01C
Checks for valid input.
Completion Code
X'128': Invalid answer area
X'228': Invalid parameter list
Invalid TCB
Determine whether the
TCB address supplied is
for a subtask or for its
own TCB.
X'328': Invalid subtask
specified
l-.,)
~
w
~
ASCB
D
Answer area (supplied by user)
Extract required information and
place it in the answer area.
vi)
Requested fields
Diagram 20-11. EXTRACT Processing (lEAVTBOO) (Part 2 of 2)
Extended Description
Module
Label
IEAVTBOO
EXFRR
EXABEND
EXTRACT processing permits a problem program or system
program to request information from its own TCB or the
TCB of a subtask. Through the ASCB and TCB, the JSCB
(job step control block) and CSCB (command scheduling
control block) can be referred to and certain information
can be extracted from these control blocks. The information
taken from the TCB, ASCB, or subsidiary control blOCk is
stored in a caller-specified list in the caller's region.
Note: On the system generation listing, the entry point
name for EXTRACT is I GCOOO4X, where X means a "12-0"
punch.
1
EXTRACT gives control to ABEND to terminate the
caller if any input parameters are not valid. The
EXTRACT FRR handles program checks and converts them
to appropriate ABEND codes.
2
3
EXTRACT considers either the input TCB or the
input TCB's subtask valid.
EXTRACT tests each bit of the extract field in the
parameter list. This field represents the FIELDS
parameter of the EXTRACT macro instruction. (See
OS/VS System Programming Library: Supervisor for
a list of the TCB fields that can be extracted.) For
each bit set, EXTRACT copies appropriate information into the answer area.
f(l
a
~.
=
N
f
[
o
o-t)
o
"CS
~
a
~.
=
~
N
VI
VI
EXLOOP1
EXTCB
;t
Diagram 20-12. EXIT Processing (IEAVEOR) (part 1 of 2)
VI
Q'I
From a user or system
program, except Type 1 SVCs,
to handle exiting from
these programs
o
til
~
t-J
Input
Output
til
~
Current TCB
9
~
&
()'
I:""
~
~
~
2'
a
IGC003
1
Perform the processing for user
program check routine.
(See extended description)
2
Complete any STATUS stop
requests.
~ RB
Stop SYNCH
Processing
~
t-J
o
~
~
~
00
'<
S
til
t-J
o
~
00
o
~
RBLINK
I
ASCB
,Next RB
f
RBWCF
~
- - - - - - --
3
Adjust task dispatchability and
count of ready TCBs.
4
Perform special processing based
on the type of R B that
represents the completed program.
5
Extended Description
EXIT, a type-1 SVC routin~, handles the exiting procedures for programs other than type-1 SVC routines.
Problem programs or system programs gain supervisorassisted linkage to the EXIT routine by issuing a RETURN
macro instruction; type 2,3, and 4 SVC routines obtain a
similar result by using an SVC 3 instruction. (See Exit
Prolog.)
./II
Processing for
Last RB
Free the completed program's RB
and do one of the following:
•
Return the SVRB to the
supervisor SVRB pool.
•
Free the SVRB.
•
Terminate the task because the
SVRB is invalid.
The EX IT routine determines the type of the exiting
program. The program can be a user program-check exit
routine, an asynchronous exit routine, an SVC routine, a
user program, or a supervisor routine operating under a
SIRB (system interruption request block). For each type of
exiting program, EXIT performs some special processing.
Dispatcher (lEAVEDSO) entry
point IEAPDS6
o
Diagram 20-12. EXIT Processing (IEAVEOR) (part 2 of 2)
Extended Description
Module
Label
EXIT considers the first-executed program of a task - the
program at the "highest control level" - as an end-of-task
condition. Accordingly, E):
~
...
r
Go to Step 4
Indialte that task alnnot
be redispatched.
0J
..
,.. Go to Step 4
IEAVEXPR
ci
00
Q
Indialte that task cannot
be redispatched.
IEAVEXSV
For tasks that
aln receive
control after
ASCB
Output
Proce
3
I ndicate that task can be
redispatched.
4
Determine SVC type.
~
.'
TCB
TCBATT
~,
TCBFLGS4
...
-"
1
PSATOLD
TCB
-----
-5
•
Type 1 SVC
•
Types 2, 3 & 4, continue:
TCBRBP
Last R B on chai n
RBATTN
11. ..
Performs
necessary EOT
processing
w ..
~RB
RBSCB
-'
Dispatcher
•
If task cannot be redispatched . •
•
If task can be redispatched.
ASCB
.'
"
- - - - - - - . -6 Return control
RBWCF
TCBPNDSP
TCBSTPP
~ ASCBTCBS
Otherwise, perform special processing.
(See extended description)
~'"
TCBRBP
r--V
EXIT Routine
(SVC 3)
Determine whether to do
End -of -task processing.
.
,
TCBATT
TCBFLGS5
TCBSTPPR
J-.
Go to Step 6
~
(lEAVEDSO)
~ who
Return to Caller
issued the SVC
<
Diagram 20-13. EXIT Prolog Processing (IEAVEEXP)
(Part 2 of 2)
Extended Description
Module
Label
5
EXIT Prologue performs the exiting procedure for SVCs.
The exiting SVC routine can provide information in
registers 0, 1, and 15. Exit Prologue returns these registers
to the SVC caller.
1
EX IT Prolog indicates the caller cannot be
redispatched by setting the "Force Dispatch" switch
in a register. Some routines cannot be redispatched after
EX IT Prolog processing; these routines pass control to
the Dispatcher.
2
Some supervisor routines that need entry into the dispatcher use the CALLDISP SVC (Type 1 ESR Code 8),
which enters here.
CI:l
~
n
g.
::s
N
:::
;.
~
o
Q.
o
-.
o
"0
~
~
c)"
::s
T-
N
V\
I.Q
Extended Description
Module
The EXIT Prologue routine gives control to EXIT if
the last RB on the RB chain represents the caller.
Label
GOTOSVC3
EXIT Prologue performs special processing for R Bs other
than the last:
IEAVEEXP
IEAVEXPl
Operation
A) Sets the type 1 switch.
IEAVEXSV
3
EXIT Prolog indicates that the caller can be redispatched after processing.
IEAVEXPR
4
Type 1 SVCs, indicated by the ASCBTYP1 field, complete EXIT Prolog processing by going to Step 6.
GOTYP1
B) Complete STATUS Stop
processing for the RB
unless other R Bs i ndicate that stops cannot
be done. Give control
to I EAVESSS to perform Stop SYNCH
processing.
C) Decrease the count of
ready tasks if the task
becomes nondispatchable.
D) Dequeue the RB and
mark it inactive.
E) Purge any SCBs by
giving control to
IEAVTSBP.
F) Move Registers 2-14
into the TCB from
the RB.
G) Return dynamic RBs
to the SVRB pool
(RBNOCELL=l) or
FREEMAIN
(RBNOCELL=Ol.
6
Fields
Read
TCBATT
TCBSTPPR
Fields
Modified
ASCBFLGl
(ASCBTYPl bit)
TCBATT
TCBSTPPR
TCBSTPP
TCBPNDSP
-<
CI:l
N
o
t..l
00
o
-..,J
RBLINK
RBWCF
TCBFLGS4
TCBFLGS5
RBLINK
ASCBTCBS
TCBRBP
RBSCB
TCBGRS
RBFDYN
RBNOCELL
Release all locks and disable; then if the "force dispatcher" switch is set or the task cannot be dispatched
(either the RBWCF in the top RBis non-zero or the
TCBFLGS4, 5 fields are non-zero, or the Stage 3 Exit
Effector Switch (ASCBS3S) is set) the dispatcher is entered,
unlocked, and disabled at I EAODS. Otherwise, the current
task is redispatched.
~
N
Diagram 20-14. STATUS Processing (IEAVSETS) (Part 1 of 6)
0-
o
From SVC IH
to process a
STATUS request
o
CI)
"<
CI)
Input
Output
-
t-J
CI)
'<
Register 0
~
~
I
3
t"'"
~
I I
Mask or
ASID
IGC079
~
Action
Code
1
Register 1
Check for valid input parameters,
vr2iil
M,i
Completion Code
]
(=S'
t"'"
X'014F' -
Invalid
a:
~
Invalid parameters
to STATUS
Register 1
-<
o
f ~it
It
I
C
3~
~
'<
CI)
t-J
(:)
(H
Address of TCB
(Optional)
-S
Reg;ster 13 Of 15
I
~-
Mask or ASID
2
---0
ASCB
TCBATT
\
Invalid TCB
Address
i,-
TCBJSCB
TCBJSTCB
ASCBCPUS
ASCBASXB ....
XMENTRY
~%1
ASXBFTCB
.-,.~-~:
I
Register 0
..... Wk¥,
I
• SRB
SRB
SRBPARMS
~
it·
~
Register 0
Register 1
Register 13
or 15
Get SRB Space
To Caller via BR 14
- 3
JSCBTCBB
If valid cross memory STATUS
request, create SRB and schedule
it to execute in the specified
address space.
From SRB
ASXB
JSCB
~'
To Caller via EXIT
Prolog (I EA V E EXP)
IGC07902
" TCB
00
J
"
__ ...1
Signal other CPUs for SET or
STOP request.
Register 15
Return Code
-~
4 = Invalid TCB address TCB
specified not a subtask
of caller.
Diagram 20-14. STATUS Processing (IEAVSETS) (Part 2 of6)
Extended Description
The STATUS routine, used by authorized callers, changes
the dispatchability indicators of TCBs, SR Bs, ASCBs, a
step, or system. This changes the dispatchability of the
indicated program. Problem program callers can use
STATUS to stop, STOP-SYNCH, or start a particular subtask TCB, or all its subtasks.
The STATUS routine can perform certain services in an
address space other than the one containing the caller. This
is called a "cross-memory" function. The requester indicates
the cross memory option by including the ASI 0 {address
space identified parameter in the input parameters. In these
cases, STATUS schedules an SR B to the specified address
space to complete the service.
Module
Label
Extended Description
Module
Label
1
IEAVSETS
IGC079
STATUS checks for valid input, and passes control to
ABEND to terminate callers of invalid parameters.
This occurs when a non-supervisor key routine attempts to
use a function other than STOP/START TCB or STOPSYNCH. The ABEND can also occur if an invalid mask is
given to STATUS or if the step-must-complete count or
stop count is 255 when STATUS is issued.
2
The STATUS routine gives control to GETMAIN,
which gets storage for an SRB. STATUS initializes
and schedules the SR B in the address space specified in the
ASI 0, and gives control to the caller. When the SRB gets
dispatched, control goes to Step 3.
3
Since STATUS changes the dispatchability bits for
TCBs, SRBs, ASCBs, a step, or system, no other CPU
can run in the same address space at that time. Therefore,
STATUS issues an RPSGNL macro with the "SWITCH"
parameter to ensure no other CPUs are running in the
same address space for STOP or SET functions. Before
issuing the RPSGNL macro instruction, however,
STATUS checks the entire COAL (common dispatcher
active list; that is, the number of currently active
dispatchers doing work) to,see if any unlocked dispatchertype functions are active (for example, TCTL). \f"any
dispatcher is active (COAL entry does not equal zero),
STATUS spins on this entry until it becomes zero,
en
(!>
~
o·
=
!':J
s::
(!>
g
Q.
o
-.
o
't:I
~
a.
0'
=
~
~
<:
tI.l
N
(:,
SIGPCPUS
~
00
S
~
N
Diagram 20-14. STATUS Processing (lEAVSETS) (Part
30(6)
0'\
N
7
~
'<
t:Il
N
t:Il
Process
Input
'<
~
,
(1)
4
\
:3
r-
~
(5.
Output
CSD
Processing depends on action code:
Code
I CSDSYSND
Action
r-
a:
~
a) 4,9
<:
o
•
Set or reset system
dispatchability bits
caIIIEAVEMSO.
:3
~
'<
S
00
t:Il
N
b) 1
Set or reset must complete
status.
c) 6, 7·, 14
Stop/Start, Stop/Synch
request.
-
Set or reset primary or
secondary dispatchability
flags in TCB.
e) 13
Stop or start SRBs.
I
I
~
--
I-
5
ASCBSRBS
ASCBSMCT
I
ASCBSSRB
"
I
ASCBTCBS
ASCBSNQS
ASCBSTND
®=:>
ASCB
ASCBTCBS
ASCBPXMT
ASCBXMPT
I
c
.....
d) 5,10,
11, 12,
3,8,
15,16
ASCB
I
C
(1)
--y
..
Adjust count of tasks in address space.
Free SRB for cross-memory requests.
.
,..
FREEMAIN
.....
,
.'calleror
Dispatcher
(JEAVEDSO)
6
')
v
TCB
TCBSTPCT
TCBSTPRR
TCBSTMCT
TCBSTP
TCBFX
TCBFJMC
TCBFLGS4
TCBFLGS5
TCBNDSP
TCBPNDSP
TCBSSSYN
RB
RBWCF
RBSSSYN
I
Diagram 20-14. STATUS Processing (IEAVSETS) (Part 4 of 6)
Extended Description
4
ST ATUS processes 15 different action codes.
Figure 2-40 lists the action codes and the fields
they change.
5
When the ASCBTCBS count in the ASCB reaches
zero, the Dispatcher will not dispatch any TCBs in
that address space. STATUS adjusts the count in the
ASCBTCBS field - increases if task becomes dispatchable,
or decreases if task is set non-dispatchable.
c;n
(!)
(")
g.
=
N
~
(t
[
o
.....
o
"0
~
a
c)"
=
~
N
0~
Module
Label
~
N
0\
Diagram 20-14. STATUS Processing (IEAYSETS) (part 5 of6)
>
,j;;o.
oC"'-l
"<
C"'-l
N
C"'-l
Input
Process
6---
'<
~
~
i
(5.
£:
~
~
<:
o
C
3
('I)
IEAVSSNO
-6
Stop non -quieseable SRBs active
in an address space being swapped.
I
'I
Returns when no
SRBs Active in
Address Space
Register 4
t~
Current TCB
, TCB
,j;;o.
'<
Output
TCBOTC
i"
TCB
IEAVESSS
TCBSSSYN
7
C".f}
N
::tI
('I)
(
,
TeBRBP
i
~
RB
w
Adjusts wait count for RBs in
initiating TCB of exiting task.
Adjusts count of ready tasks if
any become ready.
W7J
"'-
a/\
~caller
)
~
RBSSSYN
1/
I
IEATRSCN
Register 8
Address of Highest
Level Task
-8
Register 10
Address of Task from
which Search Starts
9
Register 10
Return the address of a single subtask.
(For STATUS, select the next subtask
and return to one of the steps above.
If there are no more subtasks,
exit.)
~.>'.
.........
Verify ASCBs and TCBs.
Give control to R/TM to continue
with termination.
:c
w
..
,0
.'
i/h'j
Caller via Register
14 for subtask'
via Register 11' for
nosubtask
Page address of
SDUMP header
in register 2
Address of
selected task
Diagram 20-14. STATUS Processing (IEAVSETS) (Part 6 of6)
Extended Description
6
The SWAP routine (see the swap-out Processor
(I EA VSOUT) diagram in Real Storage Management
section) branches to the STATUS routine to stop nonquiescable SRBs. STATUS sets the ASCBSNQS field
in the ASCB. STATUS next checks for SRBs running
in the address space ready to be swapped. STATUS
resets the ASCBSNQS and sets ASCBSTND fields if
there are SRBs running; it gives control to the caller
if there are no SRBs running. Control goes to the
Dispatcher if there are SRBs running. The Dispatcher
decreases the ASCBSRBS count when the running
SR B exits, and gives control to STATUS when the
count goes to O. This loop continues until there are
no more SRBs running in the address space.
7
Exit checks for a STOP SYNCH request by looking
at the TCB stop pending flag. If a STOP SYNCH
request exists; EXIT enters the STATUS routine. STATUS
decreases the RBWCF field of the requester's RB (requester
of STOP SYNCH) by 1. When the RBWCF field reaches 0,
STATUS resets the RBSSSYN and TCBSSSYN fields, and
increases the count of ready tasks in the ASCBTCBS field
of the ASCB.
t'-l
(1)
~
o·
=
N
a:
~
=&.
o
....
o
"0
Q
a
5·
=
i'"
~
Ul
Module
Label
Extended Description
8
When entered via the macro instruction STATUS SET,
MC, STEP, the STATUS routine sets the .caller's task
in "step" must-complete status. (If the request specifies
the RESET operand, STATUS clears the must-complete
status set previously.l The routine sets the must-complete
flag in the current TCB, the prohibit-asynchronous-exits
flag in the current TCB, and the step "must-complete"
dispatchability flag in other TCBs of the job step.
If the request indicates STEP, then all tasks in the job step
and the initiator are affected.
For STEP, the caller's task is always exempt from being
set nondispatchable.
9
The STATUS Recovery routine uses the CHAP recovery
routine (I GC044R2) to recover the TCB queues and
to verify the current ASCB.
STATUS passes IGC044R2 the address of the dump header
'IEAVSETSIGC079ththIGC079ththERRORthINthSTATUS'to
be used for SVC Dump of SQA, LSQA, and the Trace
Table.
STATUS sets recording parameters (SDWARECP) to
module name, I EAVSETS, CSECT name, IGC079, and
FRR name IGC079.
Module
Label
STEPMC
4-266
OS/VS2 System Logic Library (VS2 Release 3.7)
Code
Label
Locks Other
than Local
Fields Referenced
Fields Set
1
STEPMC
TCBJSTCB
JSCe3TCBP
TCBJSCB
TCBFJMC
TCBFX
TCBSTMCT
ASCBSMC
TCBSTP
3,8
NDSTEP
SDSTEP
ASXBFTCB
PSATOLD
TCBJSTCB
TCBFLGS 4, 5 (Pl
TCBNDSP (S)
4,9
NDSYSTEM
SDSYSTEM
ASCBPXMT
CVTCSD
ASCBXMPT
CSDSYSND
5,10
NDTCB
SDTCB
SAME AS 3,8
EXPLICIT TCB
SAME AS 3,8
-
11, 12
CMS
DISP
6, 7
STOP/START
TCBATT
TCBSTPCT
TCBSTPP
TCBPNDSP
TCBSTPPR
14
STOP,SYNCH
6&7+
TCBRBP
TCBFC
6&7+
RBSSSYN
TCBSSSYN
RBWCF
15,16
13
SAME AS 3,8
CALLER
ND,SD
SRBS
DISP
SALLOC
ASXBFTCB
ASCBSRBS
ASVT
TCBSRBND
TCBPNDSP
ASCBSSRB
ASCBSTND
PSAANEW
Figure 240. ST ATUS Action Codes and Fields They Change
Section 2: Method of Operation
4-267
t
Diagram 20-15. MODESET Processing (lEAVMODE) (part 1 of 2) -
Q\
00
From SVC IH
to process a
MODESET request
o
!ie
~
N
Input
Output
~
'<
I
9
£
Parameter List
Address of TCB
t"'"
i
~
I
~
~
Entry Point
@
'<
~
N
~
Code X'16B;~
&1111
ABEND
RBOPSW
RBOPSW
eN
:..,
2
Adjust mode if specified.
-
I
I
I
I
IL _
RB
~
(D
i
I 'I
I
I
Register 6
C
Determine whether the i n p u t . . .
is valid.
not valid
I
+RB
:I
(D
1
I
Register 5
~
--1-
I
Register 4
(S.
~--
Register 1
IGC107
Register 1
~
~}IJ I
1111·· -] II-J
5 67 8
- 3
Set key value to TCB key (TCBPKF) _ ....
_IiiI..-_____....
(KEY=NZERO specified) or set key
equal to 0 (KEY=ZERO specified).
11
15
Bits 8-11: Protection key
Bit 15:
Mode indicator
(1 = problem mode)
Register 1
Inverse of specified
operation, or unpredictable
Register 15
Completion Code
Register 14
I
Return
@
Caller via
Exit Prolog
(lEAVEEXP)
--
]
X'OO': Successful execution.
X'04': Null parameter list, reserved
bits used, or invali~ bit pair.
X'08': Undefined operation.
Diagram 20-15. MODESET Processing (IEAVMODE) (Part 2 of 2)
Extended Description
Module
By entering the MODESET routine through a macro
call, an authorized problem program or system program
can change its mode and change its protection key. In
this case, MODESET alters the RBOPSW, which controls
the calling task.
1
MODESET determines whether the input is valid,
and abnormally terminates callers that provide
invalid input, with a code of X'16B'.
CI}
(D
o·~
=
~
a::
(D
[
o
....
o
~
a
o'
=
~
N
0\
\C
2
MODESET changes the mode, as indicated by the
requester.
3
MODESET sets a nonzero key (value obtained
from TCBPKF field).
IEAVMODE
Label
~
~
Diagram 20-16. TESTAUTH Processing (IEAVTEST) (part 1 of 2)
-..l
o
From SVC IH to
process a
TESTAUTH
o
CI}
"<
CI}
Input
N
CI}
IGC119 Entry
'<
~
~
r"'
~
(;.
Supervisor
Routines
r"'
c:
~
IEAVTEST Entry
1
<:
g.
:3~
=
CI)
N
:;Q
~
i
~
t..l
~
./I,
Completion Code
X'l77'
not valid
F unction Code
~
'<
Register 1
Determine whether a request
is valid.
Register 15
2
RB
~-----0
~JSCB
IJOCBAUTH
IEAVAUTH
[--I
Register 0
[
Authorization Code
Determine the type of the request,
and process it:
Return Code
o-
Authorized
4 - Not authorized
If STATE CHECK
requested and the
spe.cified RB is in
supervisor state.
~
r-
a/h:
- - - - - b) If KEY CHECK
requested and specified
RB has a key less
than 8.
o
r-
c)
3
If APF CH ECK
requested and the
jobstep is APF
authorized.
Otherwise
Return to Caller
Code = 4
Return to
Caller
Code = 0
Return to
Caller
Code = 0
Return to
Caller
Code = 0
1
Diagram 20-16. TESTAUTH Processing (lEAVTEST) (part 2 of 2)
Extended Description
Module
Label
Extended Description
Module
Label
TESTAUTH processing is called by SVC routines or the
SVC IH to test whether a task has the authorization to
request a specific function.
TEST AUTH determines whether the requester passes
valid input. Control goes to ABEND to terminate the
requester if the input is invalid.
I EAVTEST
lEA VTEST
As input parameters, TESTAUTH accepts flags indicating
the request (or requests) desired. If the caller requests
APF, TEST AUTH accepts a function code and, optionally,
an authorization code. If no authorization co~e is specie
fied, TEST AUTH uses the job-step authorization, found
in the JSCB ·(job-step control block). The input paramo
eters are indexes to a matrix called IEAVAUTH, which is
built in the nucleus during system generation.
2
1
TEST AUTH compares the authorization code against
the first byte of IEAVAUTH, and compares the function code against the second byte. If either authorization
code or function code is greater than X'02', it is invalid.
The only valid codes for either parameter are 0, meaning
nonrestricted, and 1, indicating restricted.
For example, a supervisor routine with an authorization
code of 1 can perform both restricted (code 1) and nonrestricted (code 0) operations.
The authorization and function codes are the indexes to
the matrix in the third byte of IEAVAUTH. Using the
authorization code as the row identifier, and the function
code as the column identifier, TESTAUTH finds the
matrix element. Only if the authorization code is 0 and the
function code is 1 is the user unauthorized.
3
sr~
5'
=
~
ac:
~
[
o-.
o
~
Qi
a(5'
=
~
N
-.J
Control returns to the caller with a return code of 4,
indicating that the caller does not have authorization.
RETRY
4-272
OS/VS2 System Logic Library Volume 4 (VS2 Release 3.7)
Program Management
Program management services divide into three
categories: searching for and scheduling requested
modules; synchronizing exit routines to execute
during supervisor programs; and fetching modules
into storage.
Searching for and scheduling modules consists
of:
• Linking to a module. The requester issues a
LINK macro instruction to perform this
service.
• Loading a module. The requester issues a
LOAD macro instruction to perform this
service.
• Transfering control to a module. The
requester issues an XCTL macro instruction to
perform this service.
• Deleting a module. The requester issues a
DELETE macro instruction to perform this
service.
• Identifying alias names with modules. The
requester issues an IDENTIFY macro
instruction to perform this service.
The requester issues a SYNCH macro to
synchronize exit routines.
Program Fetch brings modules into storage. The
requester indirectly calls Program Fetch when he
requests a module not in virtual or auxiliary
storage. Program management services invoke
Program Fetch to bring the requested module into
storage.
Searching for and Scheduling
M~dules
Program management services find a module by
scanning control blocks from different queues.
These control blocks - the CDE (contents
directory element) or LLE (load list element) form different queues and directories; each queue
or directory describes a different part of storage.
Then, program management services schedule the
requested modules to be executed.
The queues and directories searched by program
management are:
• The JPA (job pack area) storage areas.
• The LPA (link pack area) storage areas.
• The auxiliary storage libraries.
JPA Storage Areas
The JPA (job pack area) in virtual storage contains
modules needed for the execution of jobs. The JPA
resides in subpools 251 and 252 of a region.
Problem programs, including TSO tasks, execute in
the JPA. Modules in the JPA may be executed only
by the user in whose region they are stored.
These are three JP A storage areas:
• The JPA.
• The job pack area queue.
• The load list.
The JP A: CDEs represent modules in the JPA.
Each CDE contains:
• The name of the module it represents.
• A pointer to the module's entry point.
• A use count that represents the total number
of successful requests for a module by
ATT ACH, LINK, LOAD, and XCTL macro
instructions. (The maximum use count is
32,757.)
If a caller has specified an alias entry point
within a called module, there are two CDEs for the
module. The major CDE contains the entry-point
name; a minor CDE contains the alias entry-point
name.
The Job Pack Area Queue: The CDES representing
a user's modules in the JPA are chained together
and are called the JPAQ (job pack area queue). The
JPA9 is in the LSQA assigned to a region. Each job
step in the system has its own JPAQ. The begiIHling
of the JP AQ is pointed to by the TCBJPQ field in
the job-step TCB.
The Load List: Each time the LOAD service
allocates a module to a requester, the use count in
the CDE is increased. Also, an LLE (load list
element) is created if one does not exist, and its
responsibility count (LLECOUNT) is increased. The
LLEs for each task in the job step are chained
toge~'er to form the load list, which is the first
queue the LOAD routine searches. Figure 2-41
shows the control blocks for modules in the JPA,
including LLES.
Section 2: Method of Operation
4-273
•
,
TCB for
Caller's Task
Caller's RB Queue
I TCBLLS I
"
,
""" """,
SVRB for
Contents Supervision
'""" ' ,
Caller's PRB
I
RBCOE
I
Job Pack Area Queue
r-COE--'
1.-----,
Load List for Caller's Task
II I
I
Load List
Element
~
I
I
l
Load List
Element
Ii
I
I
I
I I ~~~e~~st
I
1
J
Oelineates queue
----I~~
Pointer
*
II
I
COE
I
*
I
COE
I
I
Iii
I
I
1
*
COE
1
I
!
'~+-i-------i"'.J-""':'*---""1
I
COE for module loaded for caller's task
Figure 2- 41. Control Blocks For Modules in the JPA
4-274
i
1
COE for
Caller's Program
COE
L _____ --.J
Legend:
- - - -
I
I
L
OS/VS2 System Logic Library Volume 4 (VS2 Release. 3.7)
COE
L ____ J
..........
The need for a responsibility count in the LLE
separate from the use count in the CDE is not
readily apparent. Each time the LOAD service
successfully allocates a module, the requesting
routine may issue a DELETE macro when it no
longer needs the module. The DELETE routine
decreases the use and responsibility counts, and
frees the module and its storage ares if they are
both 0, meaning that there are no more outstanding
requests.
LPA Storage Areas
The LP A is an area in virtual storage containing
selected reenterable and serially reusable routines
that are loaded at IPL time and can be used
concurrently by all tasks in the system. Five LPA
storage areas are defined:
• Pageable LPA
• LP A Directory
• Modified LP A
• LPA Queue
• Fixed LPA
Page able LPA: An area residing in virtual storage
below the SQA (system queue area) and above the
CSA (common service area). The PLPA contains:
• Type 3 and,4 SVCS
• . Access methods and other read-only system
programs
• Any reenterable read-only user programs
(selected by the installation) that can be
shared by system users
LPA Directory: The LP A directory is a record of
every program in the PLP A. The directory is
created during nucleus initialization and consists of
LPA directory entries (LPDES) for each entry point
in the PLPA modules. LPDEs for major entry points
contain a CDE and a compressed extent list; LPDEs
for alias entry points contain the name of a related
major entry instead of a compressed extent list.
Modified LPA: The modified LP A is optionally
specified via the "MLPA=" parameter and contains
modules (from SYS1.SVCLlB, SYS1.LPALlB, and/or
SYS 1. LlNKLlB) that are to be temporarily included
in the PLPA as additions to or replacements for
existing modules. The modified LP A must be
specified at each IPL if it is to be used.
LPA Queue: The LPA queue is a record of all
fixed, MLPA, and currently active PLPA modules.
Entries in the LP A queue are chained contents
directory entries (CDES), one per entry point.
When an LPA module is no longer needed (use
count in CDE = 0), the control blocks that
represent it in the LPA are removed. Currently
active PLPA modules are still represented by LPDEs
on the LP A directory.
Fixed LPA: The fixed ~P A is an optional extension
of the link pack area and can be defined to
enhance system performance or to satisfy time
dependencies of modules. If a fixed LPA is present,
it is searched before the page able LPA. Fixed LPA
modules are represented by CDEs on the LPA
queue and are used in preference to identical paged
copies of modules in the PLPA. The fixed LPA is set
up during nucleus initialization and resides in
nondynamic, nonpageable low storage where the
fixed control program is mapped 1: 1 with virtual
storage.
Auxiliary Storage Libraries
When program management services cannot find a,
requested module in virtual storage, BLDL searches
the libraries on auxiliary storage. PDS DEs
(partitioned data set directory elements) represent
those modules on auxiliary storage.
Synchronizing Exit Routines
The SYNCH routine, after receiving control from
the svc IH (interruption handler), creates,
initializes, and schedules for execution a PRB
(program request block). This allows a supervisory
program to take a synchronous exit to a problem
program.
Fetching Modules into Storage
Program management services use Program Fetch
to load requested modules into storage. If LINK.
LOAD, or XCTL services do not ~ocate the
requested modules in virtual storage, these services
will give control to Program Fetch to bring the
module into virtual storage from auxiliary storage.
Section 2: Method of Operation
4-275
4-276
OS/VS2 System Logic Library Volume 4 (VS2 Release 3.7)
Program
Management
Overview
(no diagram)
LINK
f2!-q
(IEAVLKOO)
121 -2
CI'J
~
ll.
5-
=
I-.J
s::
~
g
Q.
o
-..
o
~
~
a5-
=
~
N
-...J
-...J
SYNCH
liiil
(IEAVLKOO)
LOAD
Searching
the LPA
Directories
(lEAVLK01)
(IEAVLKOO)
21
1
BLDLI
Program
Fetch
Interface
(lEAVLK01)
Figure 2-42. Program Management Visual Contents
DELETE
I
(lEAVLKOO)
12 1-3
Routing to
Searching
Routines
~
41
~
(lEAVLKOO)
I
21-9
XCTL
(IEAVIDOO)
(lEAVLKOO)
Overlay
Supervisor
(I EWSUOVR
and
IEWSWOVR)
r- -
~
Program
Fetch
(IEWFETCH)
01:00
~
Diagram 21-1. LINK Routine (lEAVLKOO) (Part 1 of 6)
...J
00
From SVC IH (JEAVESVC)
after a LI N K macro
instruction has been
issued to pass control
to a requested module Processing
o
~
"<
~
N
~
'<
~
3
Output
EBIII!lI8~!IiiiII~~
IGC006 Entry
Reg 15
t""
~
(;.
Address of parameter list
1 Check the validity
t""
of the input
parameters.
0.:
...
~
~
<
o
:3=-
ctl
01:00
'<
~
,.,
N
ctl
i
For DE
request only
From ATTACH
and XCTL to
Reg 9
I
Address of entry-point name
Reg 8
I
2 Set register 8
to
caller's JP AO address.
Reg 10
Address of DCB
~
~
~
Address of JPAO
From the dispatcher
(lEAVEDSO),
CDSETUP, and
LOAD to pass control
to or load a req uested
module
Same as for CDADVANS,
except Reg 8
Address of contents
directory to be searched
3
4
Search for the
requested module in
the contents directory
indicated in register 8.
If the module could not be found,
pass control to CDSETUP to direct
the search.
Address of CDE
Routing to
Searching
Routines
(lEAVLK01)
Step 1 (label
CDSETUP1)
Address of contents
directory last searched
Reg 9
I
Address of entry -poi nt name
Reg 10
Address of DCB
Step 5
l
~
Diagram 21-1. LINK Routine (IEAVLKOO) (Part 20f6)
Extended Description
Module
Label
IEAVLKOO
LXPREFIX
LINK creates the linkage to a specified load module for a
user. LINK uses Program Fetch to bring into virtual
storage those specified modules not already in virtual
storage.
1
LINK checks the input parameters for all users.
2
LINK places the address of the requester's JPAO
(job pack area queue) in register 8 to indicate to
CDSEARCH which queue to search.
3
til
(t
n
g.
=
N
a::
(t
g
c:lo
o
.....
o
"0
~
a
~.
=
~
N
'-l
IoC
The CDSEARCH subroutine searches for the
requested module in the contents directory
indicated in register 8.
IEAOCS02
4
CDSETUP1
If the module could not be found, CDCONTR L
passes control to CDSETUP1 to direct the search.
~
~
Diagram 21-1. LINK Routine (lEAVLKOO) (part 3 of 6)
~
From ALlASRCH
to determine whether
a module is available
ot"I'.l
~
~
Output
Processing
Input
t"I'.l
'<
~
£'n'
~
Name of requested
module
RegS
~
of contents
IIAddress
directory last searched .
:3(D
Reg9
C
5
Reg 0 and 1
r-'
a:
PLUSCONT Entry
(from ALlAS1)
~
1
t"I'.l
~
:;.:l
Reg 10
i
Address of DCB
~
CN
~.
Reg 11
~
Address of
requested CDE
• Cannot be used. Go to
Routing to Searching
Routines, Step 1.
1
Address of entry-point
name
'<
1
1---I
F rom Search ing
• the LPA
Directory, Step 3
and BLDL/
Program Fetch
Interiace, Step 3
to allocate the
requested module
§CDE
~-
ERRO"'RTAB
I~
~
!~
Completion code
X'406' - Not a LOAD
request, but load-only
module
- - - . Can be used later (being
fetched or is a reusable
module that is in use
and this is not a
LOAD).
CDE
• Can be used now.
Continue.
W/O ECB
CDMERGE Entry
6
SVRB
Determine whether the
module can be used
immediately.
r-----
- 7
I
Increase the use count in the CDE. _ _ _ _ _ _:_.L.______---'-__~
If a job step is being attached, set the JSCB
authorization on if the CDE is authorized.
I
I
I
I
I From
All other
requests:
IIEAVTRTS
..J
__••~I Build a PRB for the
F R R PGMMG Entry
requested module
and chain it behind
the Program Manager
~VRB.
8
Test whether the error occurred
in the same address space.
Dispatcher.
When the task is next
dispatched, the
dispatcher loads the PSW
from the new PRB.
Return to R/TM (I EAVTRTS)
to terminate the task
Address of requested
module
Diagram 21-1. LINK Routine (lEAVLKOO) (Part 4 of 6)
Extended Description
Module
5
The COALLOC subroutine of LINK considers three
conditions to determine if a module can be used
immediately:
Label
COALLOC
• Cannot be used.
• Can be used later.
• Can be used immediately.
When modules cannot be used, control goes to "Routing
to Search Routines (lEAVLK01)" to begin searching
for the requested module.
When the module can be used later, COaUECTL queues
the requests to be processed later, and passes control to
the dispatcher (IEAVEOSO).
coaUECTL
Processing continues when the module can be used
immediately.
6
LINK increases the use count in the COE (contents
directory element) to reflect that the requested
module can be processed.
COEMERGE
7
COEMERGE
LINK sets the JSCBAUTH field of the JSCB to
indicate authorization if the COE is authorized.
Error Processing
Error processing is the same for LINK, LOAD,
ATTACH, and XCTL.
8
C".I.I
(1)
Sl.
o·
=
N
a==
8:o
"""
o
"0
~
g.
::I
f"
N
00
FRRPGMMG determines whether the error occurred
in the same address space as that of the routine
currently executing.
If not, R/TM (Recovery/Termination Management) will
continue with termination.
IEAVLK03
FRRPGMMG
t
Diagram 21-1. LINK Routine (IEAVLKOO)
(part 5 of 6)
00
N
o
Input
Output
Processing
CI.l
~
N
Reg 1
C
CI.l
'<
~
ar-
Address of SDWA
SDWA
~
r;'
reT
Address
Parm List
I
~
~
~
(I)
Address
SVRB
0
;"
ABEND
Code
I
5 Words
J
of the LPAO or
:=
206 ABEND
Retry Ind;c
FPR Name
__ I
Module Name
I
I
CSECT Name
I
I
WTO Macro
I
I
IN
I
SVRB
f;f
C>
RBEXSAV
I
"I
SDWA
I
~
~
I~
JPAO.
1
1
X'O~5:
I
Via SETRP Macro
Regs
Parameter List
J
CI.l
N
Determine whether error occurred
dur;ng parameter check;ng and whether
ABEND code equals X'OC4:
X'OC10,' or X'OC1l.'
10 Ensure the validity
3(I)
'<
I
9
I
J
First}
Word
<:
o
6"
J
r--
~---...,
I
__ J
Via SETRP
11
Indicate an error condition so RITM
can record th e error.
2!!i!
Return to R/TM to
continue with termination,
as indicated in the SDWA
"'-.,
LPA Only
LPAO
truncated may need to
re-IPL system
Diagram 21-1. LINK Routine (IEAVLKOO) (Part 6 of 6)
Extended Description
Module
9
Invalid input data should have a 206 ABEND code.
FRRPGMMG checks the ABEND code in the
SDWA (system diagnostic work areal, and changes
X'OC4: X'OC5: X'OC10: or X'OC11.'
IEAVLK03
10
The CDEOVER subroutine ensures the validity of
the LPAO or JPAO. CDEOVER issues an error
message to the operator if necessary.
IEAVLK03 NXTTST
11
IEAVLK03 PERC
FRRPGMMG indicates an error condition so R/TM
can record the error. Control returns to R/TM to
continue with the termination.
en
(I)
(")
g.
=
N
a::
a
[
o
-..
o
"0
~
e-
o·
=
~
N
00
c...I
Label
t
~
Diagram 21-2. Routing to Searching Routines (IEAVLK01)
From the LINK Routine
(lEAVLKOO), Steps 4
and 5, to continue the
search for the
requested module
~
"I
Completion code
I
X'906' - Use count exceeds
or responsibility
count exceeds
WIO ECB
LLE
Increase the use count
in the CDE.
•
ERRORTAB
-,. Abnormally terminate .... L.....
..,.
• '*
the requester.
7
..
v'
CDALLOC
~
6
LINK Routine
(lEAVLKOO)
Step 3
Build and initialize the
LLE, when necessary.
See LINK Routine, Step 8,
fQr FRR processing.
---.
--,..
CDLDRET
...
ABEND
...
LLECHAIN
LLECDPTR
LLEUSE
IGCOOO1C
LLSYSUSE
I
RegO
Caller via the
Exit Prolog
(lEAVEEXP)
Relocated
entry-point
address
Reg 1
Size of
module in
doubleword *
* Authorization indicator
in high order byte.
I
I
Diagram 21-6. LOAD Routine (IEAVLKOO) (part 2 of 2)
Extended Description
Module
Label
4
The LOAD Routine brings a module containing a specified
entry point into virtual storage if no useable copies exist
in storage.
1
LOAD calls DALPRFIX to ensure that the input
parameters are val id.
2
The LOAD routine considers three conditions to
determine module useability:
Module
Label
CDALLOC
• Cannot be used.
IEAVLKOO
IGC008
• Can be used later.
• Can be used immediately.
LOAD places the address of the requesting JPAO (job
pack area queue) in register 8 in case LINK must
continue to search for the module. Then, LOAD sets the
lower order bit in RBCDFLGS equal to 1 to indicate a
load request.
IGC008
3
CDLLSRCH
LOAD gives control to CDLLSRCH to search for
the requester's load list. If CDLLSRCH cannot find
the load list, LOAD passes control to the LINK routine.
Extended Description
When a modu Ie cannot be used, control goes to the LI N K
routine, which begins searching for the requested module.
When the module can be used later, CDOUECTL queues
the requests to be processed later, and issues a WAIT
macro instruction.
CDOUECTL
Processing continues when the module can be used
immediately.
5
\.-OAD increases the use count in the CDUSE field of
the CDE.
CDMOPUP
LOAD passes control to the ABEND routine to terminate
the requester if the use count exceeds 32,767.
6
CDLDRET gets storage for an LLE (load list element),
if none already exists, and chains it to the caller's
load list.
CDLDRET increases the responsibility count in the LLE,
and if the count exceeds 32,767, gives control to the
ABEND routine to terminate the requester.
CD LOR ET also increases the system responsibil ity count in
field LLSYSUSE for system requests.
en
(I)
a5'
=
N
a::
(I)
[
....o
o
"Q
~
~
S·
=
~
N
\.Q
w
CDLDRET
,J:.
~
Diagram 21-7. DELETE Routine (IEAVLKOO) (Part I of 2)
'f
otil
~
From SVC IH (I EA VESVC)
after a DELETE
macro instruction
has been issued
Processing
Input
Output
IV
til
'<
Reg 0
I
~
~
3
r-
~
(1)
i
Ir TCB
w
t---~1t'I
~
~
SVRB
TCBRBP
RBLI~K
RB
3
I/""I~-----t
RBSTAB
---
~
4
Address of SDWA
Address
Parm List
I
I
I
Determine where the minor CDE
should be built and get storage in
subpool 255 for a major CDE.
6
Initialize and
chain the CDE
(and extent list if major CDE)
in CDE queue.
From
R/TM
(lEAVTRTS)
5 Words
SVRB
U
Reg 14
Return Address
~~
Check validity of ~
request.
5
I
Parameter List
o
@:=;>
~
Reg 1
SDWA
Search for duplicate module name.
~
6.1
~
@=;>
Exit Routine
(SVC 3)
(lEAVEOR)
FRRSVC41
..... - - - -
7
Indicate an error condition
via SETRP macro so RITM
can record the error.
8
Test whether the error occurred
in the same address space.
_
0/
Return to R/TM
(lEAVTRTS) to
terminate the task
~
~
X'10' ~ Caller is not
operating with
a PRB.
X'18' - Invalid parameter
list.
X'lC' - Invalid extent list
or modu Ie address.
X'04' - Entry-point name
and address
already exist.
X'08' - Entry-point name
duplicates the
name of a load
module currently
available.
ID~NTIFY.
X'14' - An
macro instruction
was previously
issued using the
same entry-point
name but a
different address.
X'OC' - Entry-point
address is not
within an eligible
load module.
X'OO' - Successful
completion.
X'24' - Unexpected
system error.
Diagram 21-8. IDENTIFY Routine (IEAVIDOO) (part 2 of 4)
Extended Description
Module
Label
4
The ID~NTIFY routine searches for and identifies a
module's embedded entry-point name (a name not
established by the linkage editod. IDENTIFY
creates a CDE (contents directory entry to represent
the embedded entry-point name.
1
IDENTIFY passes an error code in register 15 if
the caller is not operating with a PR B.
2
Vl
~
ao·
=
N
~
~
[
o
~
o
'1:S
Sl
a
o·
=
~
N
\0
....,
IEAVIDOO
YESPRB
A subroutine of IDENTIFY, MAJORCDE, builds
a major CDE. MAJORCDE performs the same
operations as IDENTIFY, which builds minor CDEs.
Steps 4-7 show the operations for both IDENTIFY
and MAJORCDE.
MAJORCDE
3
NOMIN
IDENTIFY (or MAJORCDE) passes control to the
I EAOCDSR subroutine to search for a duplicate
module name.
Extended Description
IDENTIFY passes an error code in register 15 if
the caller issues an invalid request.
Module
Label
XLINST
5
IDENTIFY builds the major/minor CDEs in the JPAO
(job pack area queue) or LPAO (link pack area queue),
depending on the location of the major CDE, and the
authorization of the caller.
GETCDE
MAJORCDE builds major CDEs in the LSQA.
NAMETEST
6
7
IDENTIFY chains the CDE in the CDE queue.
CDESETUP
MAJORCDE chains the CDE in the CDE queue.
NAMETEST
FRRSVC41 indiChtes an error condition so R/TM
can record the error.
FRRSVC41
8
FRRSVC41 determines whether the error ()ccurred
in the same address space with the routine currently
executing. FRRSVC41 will retry the routine if the error
occurred in the same address space.
FRRSVC41
If the error occurred in a different address space, R/TM
Will continue with termination.
SVC41PRC
t
Diagram 21-8. IDENTIFY Routine (IEAVIDOO)
(part 3 of 4)
I.C
oc
o
Processing
Output
C/}
"<
C/}
tv
C/}
'<
SDWA
9
~
~
3
Ensure the validity
of the LPAO
or JPAO
r-
Retry Indic
CDEOVER
WTO Macro
~
n"
Regs
r-
...eT
Ql
~
<:
o
2"
3~
~
'<
10
Set retu rn code.
CSECT Name
C/}
,.,
tv
CD
~
Ql
~
W
~
Return to issuer of
SVC Interrupt Handler
(lEAVESVC) via
Exit Prolog (I EAVEEXP)
..
LPAO truncatedmay need to re-IPL
system
Diagram 21-8. IDENTIFY Routine (IEAVIDOO) (part 4 of 4)
Extended Description
9
r;n
~
r:
g.
=
t-J
:::
~
&
c
000)
o
"0
~
~
o·
=
~
N
~
~
Module
Label
The CDEOVER subroutine ensures the validity
of the LPAO or JPAQ. CDEOVER issues an
error message to the operator, if necessary.
FRRSVC41
FRRSVC41 saves registers 6 and 13 in the SDWA.
SVC41PRC
10
SVC41RTY
FRRSVC41 sets a return code of X'24' and
returns to the caller.
of'"
g
Diagram 21-9. XCTL Routine (IEAVLKOO) (Part
~
~
~
rI.l
~
~
Input
~
£
Reg 15
...~
I
(S.
~
1 of 6)
From SVC IH OEAVESVC)
after an XCTL macro
instruction has been
issued, to pass
control to a
requested module Processing
Address of
parameter list
r
~
---I
..
Output
IGCOO7
I
I
I
[
I
.... ----
(1)
.a:.
1 Test for SVRB .
Yes
~GotoStep8
~
<
rI.l
t.,)
'"
2
Check validity of
request.
3
Get storage for new
PRB and initialize it.
(1)
i
PRB
~
,...
(,N
~
v
RBSTAB1
~--
--(3)
.-
LXPREFIX
.......
P'
GETMAIN
Obtain storage
for PRB
.III
...
...r....
v
CVT
I
~--
,--I
"
..L
---~
&----
.......
Update any SCB.
-.-
4
Test for PRB or IRB request.
TRRM Resource
Manager
Update
any SCBs
PRB
Diagram 21-9. XCTL Routine (lEAVLKOO) (part 2 of 6)
Extended Description
Module
Label
The XCTL routine creates the linkage to a specified load
module and ensures that the requester does not regain
control after the specified load module has been executed.
The specified load module executes with the same
protection key and in the same state as the requester.
The XCTL routine only performs the XCTL service for
requesters represented by an SVRB (supervisor request
block); it calls LINK to honor requests made by
requesters operating with a PRB (program request
block) or IRB (interruption request block).
1
Control goes to step 8 to process SVRBs.
2
The LXPREFIX subroutine checks the validity
of the request.
3
XCTL passes control to the GETMAIN routine to
obtain storage for a new PRB, (program request
block). XCTL initializes the new PRB with the
information in the old PRB.
The TRRM (task recovery reSOurce manager) updates
any SCB (STAE control block) associated with the
requester's PR B.
4
tf}
~
!l
o·
::
N
;:::
ic..
c-.
c
-=~
cw
S·::
~
r.:..
::
XCTL checks the RBSTAB1 field of the PRB to
determine the type of request.
IEAVLKOO
LXPREFIX
NOTSVRB
~
w
Diagram 21-9. XCTL Routine (IEAVLKOO) (part 30f6)
oN
@
Processmg
Input
"<
Output
IRB Processing
CI)
N
CI)
5
'<
~
I?
~
~;:;.
I'
<:
o
C
:3
~
6
I,"
~
If the requester is operating with a
PRB, chain the old PRB to the TCB.
Remove old PRB via SVC 3.
11
--------
---~,c,<
v
fl
t
~,"
N
:::0
~
Q
~
~
Old PRB
I":
~
• SVRB
~
.
The requester is operating with
an SVRB.
...
·I',
..
~
,
~
8
TRRM Resource
Manager
Remove or
Update SCBs
"'f
(,
New RB
,aid PRS
LINK Routine
(lEAVLKOO)
Step 2
SVRB Processing
7
t..I
j~,.~B
i ~:>
I{
~
CI)
RBOPSW
L
PR B Processing
~
1
j:
l"
r-'
0:
RB
LINK Routine
(lEAV. vnnl
Step ~
If the requester is operating with an
IRB, set the caller's resume
PSW to SVC 3, and call LINK.
• New RB
]
CDSEARCH
;:)t:arcn for the
requested module
in the LPA.
.Next RB
I
Entry-point address of
requested module
If the requested module is found,
initialize the new SVRB and exit.
Mark SVRB resident.
Exit Prologue
Removes Program
Management's SVRB .
~:
•
Dispatcher (lEAVEDSO)
,"
[:
jl<
~B
Diagram 21-9. XCTL Routine (IEAVLKOO) (Part4of6)
Extended Description
5
For IRB requests, XCTL sets the resume PSW
(RBOPSW field) to the address of an SVC 3
instruction to cause the requester to exit. Control
passes to LINK at entry point CDADVANS.
6
XCTL chains the old PRB to the TCB. The old
PRB now points to the SVRB. XCTL removes
the old PRB by using the SVC 3 instruction.
7
For SVRB requests, XCTL passes control to
CDSEARCH to search for the requested module
in the LPA (Link Pack Area) after regaining control
fromTRRM.
8
If found in LPA, XCTL sets the value in the resume
PSW (RBOPSW) to the entry·point address of the
requested load module, and marks the SVRB as resident
in the RBSTAB field, then exits. (Resident means that
the SVRB resides in the CDE queue.)
CIl
~
~
g.
::I
N
:::
~
[
....o
o
"0
~
~
~.
::I
~
w
o
w
Module
Label
IRBPROC
to
~
o
Diagram 21-9. XCTL Routine (lEAVLKOO) (part 5 of 6)
Processing
Output
f'-)
"<
f'-)
N
f'-)
l
8
9
Search the LP A
directory.
i
r-
a:
=e=J
~
~
~
I
Reg 1
I
X'806'
Requested module could not
be found
10
~
'<
If the module is not ~
found, abnormally
terminate the issuer
of the SVC.
ERRORTAB
Routine
ERRBLDL
I
--...
"
f'-)
Completion Code
ABEND
IGCOOO1C
N
'"
St
~
~
~
I
Reg 15
(p
~
I
11
J\.
Initialize the new
SVRB, and exit. Mark
the SVRB transient.
RBSTAB
--.
..
12 See LINK Routine, Step 8, for
FRR processing.
RB
....
81
Caller via
Exit Prolog
(lEAVEEXP)
"....
RBOPSW
RBCDE
I
i
Diagram 21-9. XCTL Routine (IEAVLKOO) (part 6 of6)
Extended Description
9
If not found in LPA, XCTL passes control to
IEAVVMSR to search the LPA directory.
Module
Label
PLPASRCH
10
If not found on LPDE, XCTL gives control to the
ERRORTAB subroutine to create the X'806' error
code prior to finally giving ABEND control to abnormally
terminate the requester.
11
If found on LPDE, XCTL sets the value in the
resume PSW (R BOPSW) to the entry·point address
of the requested load module, and marks the SVR B as
transient in the RBSTAB field, then exitso (Transient
means that the SVRB resides in the pageable LPA.)
~
g.
5°
=
~
~
~
go
8-
o
'"0)
o
"t:S
~
~
5°
=
~
w
o
til
FOUNDEM
.~
~
Diagram 21-10. Overlay Supervisor (IEWSUOVR and IEWSWOVR) (Part 1 of 2)
~
From requester via branch or
Second Level Interruption
Handler (lEAVESVC) to load
requested overlay segment.
o
CI.l
"<
CI.l
~
Input
Process
CI.l
'<
la
a
~(:)"
.....
§=
INPUT
Register 0
o indicates SEG LD
Nonzero indicates SEGWT
IGC037
1
Register 1
~
~
ENT ABentry address of
requested .overlay segment
2
[
If the requested overlay segment is
in virtual storage, and ENT AB is
prepared to branch to it,
go to ENTAB.
Issue a LINK to IEWSZOVR in the
overlay supervisor.
ENTAB,which
branches to the
requested overlay
segment
(D
~
'<
CI.l
~
~
a
I
~
--- ---- --- --- --- - INPUT
* Registers 1 and 2 same as above
Register 9
IEWSZOVR
3
Overlay segment number
w
~
II
Register 12
Address of SEGTAB
ECB
,------
•
Step 7 for BR or CA LL.
•
Step 8 for SEGLD or SEGWT entry.
4
If the overlay segment is being loaded
for a previous SEG LD request, wait
for the loading to complete.
5
Update status indicators
in SEGTAB and ENTAB.
6
Request loading of overlay segments
marked in SEGTAB; go to:
,
I I
+
Completion flag
If the overlay segment is in virtual
storage, go to:
SEGLD
•
Step 7 for BR or CA LL.
•
Step 8 for SEG LD or SEGWT
entry .
I .1 OVAL02
., Alter ENT AB entries to permit
unassisted branch to overlay
segments.
Error
8
Check for error conditions.
SEGTAB or ENTAB for branch to
requested overlay segment
Diagram 21-10. Overlay Supervisor (IEWSUOVR and IEWSWOVR)
Extended Description
Module
Label
Overray is a programming technique that minimizes the
virtual storage requirements of a program. When the overlay technique is used, a program is divided into overlay
segments, each of which can contain up to 524,288 bytes
of text. The overlay supervisor directs the loading of these
overlay segments as they are requested.
IEWSUOVR
I EWSWOVR
IGC037
When an overlay program is link-edited, the linkage editor
builds an SEGTAB (overlay segment table), and one or
more ENTABs (entry tables). It makes these tables part
of the overlay module.
There is only one SEGT AB in an overlay program. The
SEGTAE describes (1) the relationships of overlay segments in the program, and (2) which overlay segments are
in virtual storage or being loaded. The SEGT AB is the first
portion in the root overlay segment, which contains control information for the overlayprogram and remains in
virtual storage while the overlay program is being executed.
There can be an ENT AB in each overlay segment of the
program. The overlay supervisor uses the ENTAB to determine which overlay segment must be loaded when a branch
instruction or macro instruction refers to an overlay segment not in virtual storage.
C"I'.l
(I>
~
5'
=
N
:::
(I>
[
o
-.
o
'"0
~
~
5'
=
01:0-
W
o
.......
(part 2 of 2)
The overlay supervisor gains control when an overlay segment issues a SEGLO or SEGWT macro request (SVC 37)
for another overlay segment, or when an overlay segment
issues a CA LL macro (SVC 45) or branch instruction to an
address in another overlay segment not in virtual storage.
The caller enters the resident overlay module, IEWSUOVR.
This module checks the validity of the input parameters
and then issues a LIN K to module I EWSWOVR using its
alias name, IEWZOVR. If a usable copy of I EWSWOVR is
found, it is executed; otherwise, a copy is fetched into
virtual storage. I EWSWOVR marks the overlay segments
to be overlaid, determines which new overlay segments
should be loaded, and branches to Program Fetch to read
the overlay segments into virtual storage. A separate branch
to Program Fetch is made to read each overlay segment.
In both cases, the overlay supervisor examines the SEGTAB
to determine whether the requested overlay segment is
already in virtual storage, and whether all overlay segments between the requested overlay segment and the root
overlay segment are in virtual storage. All must be in virtual
storage, and if they are not, the overlay supervisor calls
Program Fetch to load them.
After the required overlay segments are in virtual storage,
if the caller has issued a CALL or branch instruction, the
overlay supervisor alters the ENTABs of the loaded overlay segments. The modified ENT ABs permit future
branches to loaded overlay segments without help from
the overlay supervisor.
Finally, depending on how it was called, the overlay supervisor passes control to the:
• Caller before loading is complete (SEGLO)
• Caller after loading is comJ:?lete (SEGWT)
• Branch address in the requested overlay segment after
it is loaded (CALL or branch instruction).
~
c:w
Diagram 21-11. Program Fetch (IEWFETCH) (Part 1 of 10)
~
From the Program Fetch
interface in the LINK
routine (lEAVLKOO)
to load a module
from auxiliary
storage.
~
"<
CI:l
'-J
tI:)
'<
~
Input
Out
3
i
INPUT (from LINK routine)
IEWMSEPT
Reg 5
1
Obtain virtual storage for
the module.
2
Build an extent list.
fir
~
~
~
<:
o
C
3Q
~
[
Address of PDS DE
Address of DCB
Reg 9
'<
N
Reg 10
Address of CD E
tI:)
~
~
~
tN
~
Indicates extent
list has been
created
Reg 7
C
[
st
CDE
[S~bpoOI no. for module
Extent/Note List
REG 13
Address of Program
Fetch work area
Note list begins
3
Read and initialize the note
list (overlay program on'ly).
Diagram 21-11. Program Fetch (IEWFETCH) (part 2 of 10)
Extended Description
Module
The Program Fetch routine, which is a single module in
the nucleus, loads modules for supervisor routines. It
transfers modules into virtual storage from libraries
(organized as partitioned data sets) on direct access
storage devices. Program Fetch reads a module into a
continuous block of virtual storage, and relocates
address constants in the module. It can process
several load requests concurrently.
I EWMSEPT
The subroutines of program management that search
for requested modules and the overlay supervisor
use Program Fetch to load modules.
The searching subroutines of program management
enter Program Fetch after a LINK, LOAD, XCTL,
or ATTACH macro instruction has been issued, and a
usable copy of the requested module is not available
in virtual storage. For this type of entry, Program
Fetch transfers the entire module from auxiliary
storage to virtual storage.
The overlay supervisor enters Program Fetch after a
SEGWT, SEGID, Or CALL macro instruction, or
after a branch instruction has been issued for an
overlay segment that is not in virtual storage. For
this type of entry, Program Fetch loads only the
requested overlay segment.
In loading a nonresident module or an overlay segment,
the major phases of Program Fetch processing are:
til
(II
a
cr
=
N
~
(II
go..
....o
o
"0
~
~
o·
=
.a:;.
~
o
\C
• Initialization. Program Fetch initializes a fetch work
area, builds an extent list, and (if the module is in an
overlay structure) fetches the module's note list.
Program Fetch gets virtual storage for the load module.
• Loading. Program Fetch calls channel programs that
transfer text records, R LD records, and control
records into virtual storage.
• Relocation. Using the RLD records, Program Fetch
changes the values of the address constants in the
loaded program from relative load module addresses
to absolute virtual storage addresses.
• Termination. Program Fetch checks the completion of
I/O operations, calculates the relocated module entrypoint address in virtual storage, initializes the overlay
segment table (if the module is in overlay structure),
sets up a return code, and returns control to the caller.
Label
Extended Description
1
Steps 1-5 are the initialization process performed
by Program Fetch. During initialization, Program
Fetch calls GETMAIN to get the virtual storage it needs
for module loaoing.
2
The extent Iist contains the virtual storage address
of and the length of each section of a module
eligible for loading. Program Fetch issues a GETMAIN
macro instruction to obtain storage for an extent list
(and a note list if the module is in overlay). GETMAIN
returns the extent Iist address and Program Fetch places
it in the CDE.
3
If the module being loaded is in overlay, Program
Fetch initiates channel programs that read the
note list into storage (storage obtained during extent list
processing). The linkage editor placed the note list in
the overlay module. The note list contains the relative
disk address (TTR) for reading each overlay segment of
the module. The TTR of the note list is obtained from
the PDSDE, converted to an absolute disk address, and
used in the channel program request to read the note list
into virtual storage. Before the note list is read, Program
Fetch builds a note list prefix that it uses when called
to load an overlay segment.
Module
Label
~
CoN
Diagram 21-11. Program Fetch (IEWFETCH) (part 3 of 10)
o
f'-)
~
N
segments
Input
f'-)
l
~
INPUT (from overlay supervisor)
r-
~
r;.
Reg 3
r-
Address of Progra m
Fetch work area
~
~
~
c
~
[
Address of note list
f'-)
'"
f
CoN
~
I EWBOSV
Reg9
~Iay~~ment number
,
Output
Program Fetch Work Area
4
Initialize the Program Fetch
work area for module loading
and the SRB and 10SB to
support 105 (non-VIO only).
5
Prepare channel program for reading
module records.
Address of DeB
Reg 8
(D
N
Process
Reg 7
[
=
<:
.
From the Overlay
Supervisor to load
requested overlay
o
Diagram 21-11. Program Fetch (IEWFETCH) (part 4 of 10)
Extended Description
Module
Extended Description
Label
4
In addition, Program Fetch requests storage for
another work area if the DCB (data control block)
does not refer to SYS1.LlNKLlB, SYS1.SVCLlB,
or JOBUB or if the DCB is not associated with a
system request. Program Fetch also sets a switch
in the Program Management work area to indicate
whether the program module is being loaded from
a library authorized by the Authorized Program
Facility (APF).
Program Fetch initializes a work area whose address
is furnished by the caller. It places in the work area
information that it will use to load the requested module.
This information consists of:
• An input/output block (108). The lOB provides
information that the EXCP Processor needs for its
interface with the VIO processor when the program
module is being loaded from a VIO data set.
• An input/output supervisor block (lOS8) and a service
request block (SRB). The 10SB provides information
the I/O Supervisor needs when the program module is
being loaded from a standard (nonVIO) data set. The
SRB provides the structure under which the I/O
requests issued by Program Fetch are scheduled by the
I/O Supervisor.
• Two event control blocks (ECBs). One ECB is posted
by the SRB termination routine when the I/O request
is complete. The other is posted by the system pagefix
routine when requests issued by Program Fetch to fix
real storage are complete.
• Three channel programs. The channel programs are
similar. They are used to overlap the reading of one or
more module records with the relocation of address
constants pointed to by a previously loaded R LD
record.
• Three RLDbuffers. Each buffer is 260 bytes long and
is capable of holding an RLD record, a control record,
or a composite control and R LD record.
en
(t
~
S·
=
IV
• A buffer table. This table contains a 12-byte entry for
each R LD buffer. Each entry contains:
• A pointer to the next entry.
:::
• The address of an RLD buffer.
[
• The address of a channel program.
~
c
-.
o
"0
~
~
S·
=
~
~
-
• A text table. This table is used in CCW translation, and
contains:
• The address of the text CCW currently active in the
channel program.
• The virtual location at which the above CCW is
reading text data.
Module
Program Fetch builds a DCB in the work area; the
only valid field in this DCB is a pointer to the DEB.
Before copying the DEB into the work area,
Program Fetch calls the DEBCHK routine to check
the validity of the DEB. The DCB and DEB are
used for all I/O requests.
5
Preparing for Execution of a Channel Program:
Program Fetch passes to the I/O supervisor an
absolute disk address at which the first I/O operation
is to begin. It does this by:
• Obtaining the relative track and record address (TTR)
of the first text record from the data set directory
entry, or obtaining the TTR of the needed segment
from the note list.
• Converting the relative address to an absolute address,
via a branch to a "convert" routine that is resident
in the nucleus.
• Placing the absolute disk-seek address in the Program
Fetch input/output block (lOB) or lOSB, for later
use by the I/O supervisor.
The absolute disk-seek address used for subsequent I/O
requests is obtained from count data which is read while
loading the text records.
The extent of the module's virtual storage area (text
buffed to be fixed is calculated for each I/O request.
This provides real storage for the text CCWs that are
introduced in the channel program switching process.
The buffer begins at the point when Program Fetch is
currently loading text records, and continues for a
length of 18K bytes, unless the end of the module is
encountered first.
Program
Fetch
Label
~
8
Diagram 21-11. Program Fetch (IEWFETCH)
(part 5 of 10)
N
o
til
~
N
til
...,~
Process
Input
Output
'<
~
9
E
n·
r-'
~
~
Virtual Storage for Module
Address of DeB
~
'Load module
or overlay
segment
<:
o
'-...::
.-/
8(D
=-
' - Note list
.-/
Address of note list
f'
"-
) 6
"
Initiate I/O operation. Read module
records into virtual storage.
~,.~>
~
'<
til
N
~
j
7
Switch to next channel program.
;
(D
if
~
<
,~
,~
~
~
-
,f
'--
-"
I"
Address constant
Diagram 21-11. Program Fetch (IEWFETCH) (part 6 of 10)
Extended Description
6
Program Fetch starts a channel program by issuing a
STARTIO macro instruction to obtain branch
linkage to the I/O supervisor. The SRB address is
provided as an operand of the macro instruction.
Prior to issuing STARTIO, Program Fetch uses the
PGFIX macro instruction to fix its work and the te~t
buffer in real storage. In this manner, page faults are
avoided when the I/O supervisor or appendages
address the fixed storage.
Other areas referenced during the I/O request are in the
fetch work area (fixed for the duration of the loading
operation) or are resident in the system nucleus. After
these areas are fixed, all Fetch CCWs are translated and
an IDAL is built for the text CCW if necessary. The
19<:al lock is held while this is done to prevent an
address space swap from occurring. An address space
swap would cause the real storage addresses referred to
by Program Fetch to change.
The text CCWs are retranslated each time a new block of
text is to be read. They are translated from information
in the text table. For text CCWs that cause page
boundaries to be crossed, an IDAL is created. All real
addresses are obtained using the LRA instruction.
til
(D
o·~
=
N
~
~
S
o
....
Q.
o
"C
~o·
-.s
.j::.
~
~
The I/O supervisor issues a Start I/O instruction, followed
by a Stand-Alone Seek command. The Stand-Alone Seek
command moves the access arm of the direct access device
to the seek address contained in the 10SB. The I/O
supervisor, via a Transfer in Channel command, then
passes control to a fetch channel program, whose address
the Program Fetch routine placed in its 10SB. The fetch
channel program causes the first text record to be read
into virtual storage. The I/O supervisor returns control
to Program Fetch to wait for posting of an event control
block by the SRB termination routine. Such posting
indicates that the I/O is complete either because the
module or segment has been completely read or because
a permanent error has occurred.
Module
Label
t
-
Diagram 21-11. Program Fetch (IEWFETCH)
(part 7 of 10)
~
o
Ie
<:
CIl
N
CIl
Process
'<
~
~
r-
8
r~
9
•
Output
Scan buffer table for R LD records.
~
(=5.
=
~
<:
o
3
C
(D
~
Virtual Storage for Module
Check validity of address constant (adcon)
locations.
J
CIl
N
"i
(D
~
~
II
Add ress of 0 CB
Address of note list
li,1~---~
Address constant
,..
Replace relative adcon address with virtual ---'-----------"""'--t\.
storage address.
'<
~
i
Diagram 21-11. Program Fetch (IEWI'ETCH) (part 8 of 10)
Extended Description
8
Switching of Channel Programs: Each channel
program reads a text record followed by an RLD or
control record, or it reads only the R LD or control
record. When a text record is not followed by a control
record, the next channel program switches to singlerecord mode. The single-record mode continues until a
control record is encountered causing a switch to tworecord mode.
A CCW in each channel program causes a programcontrolled interruption (PCI). The PCI causes the I/O
supervisor to pass control to the Disabled Interrupt Exit
(DI E) routine. The appendage examines the current RLD
buffer to determine the channel program switching
required, and operates as follows:
• Ifthe current RLD buffer"contains an RLD record, the
NOP CCW in the current channel program is altered
to TIC the CCW, which reads a control record or RLD
record into the Program Fetch work area. The TIC
address is translated using the LRA instruction.
~
(II
~
o·
=
~
a::
a
[
....
o
o
'e
~
o·
=
~
~
VI
• If the current R LD buffer contains control information,
the text CCW in the next channel program is
initialized. Before chaining is attempted, however, the
extent of the read is examined to determine whether it
exceeds the text buffer fixed for the current I/O
request. If the fixed limits are exceeded, the current
channel program is not altered and a "buffer full"
condition is set. If the text buffer is not exceeded, the
current channel program NOP is altered to TIC to the
next channel program to read a text record, and a
control or RLD record after the text CCW and TIC
address have been translated.
• If the current RLD buffer contains an RLD record
with the end-of-module indicator, the "end" flag is
set. If the buffer contains a control record with the
end-of-module indicator, the next channel program is
prepared to read a text record only and the "end" flag
is set.
Module
Label
Extended Description
In all the above cases, {he buffer table is examined to
determine whether an RLD record was read by the
previous channel program, and, if so, the RLD record is
passed to the relocate subroutine. Control is then
returned to the I/O supervisor.
The Post Status routine (for normal exits) is entered by the
I/O supervisor when the channel program has terminated.
The appendage returns control to the I/O supervisor to
schedule the SRB termination routine when channel end
is due to the fact that:
• The entire module or segment has been loaded.
• An invalid record type or an invalid address has
been found.
• A permanent I/O error has occurred.When channel end occurs because the note list has been
read, the Post Status routine (for normal exits) resets the
channel program to begin reading the program module text
and returns control to the I/O supervisor to restart the
channel program.
When channel end occurs because the next block of text to
be read will lie partially or entirely outside the limits of the
currently fixed real-storage buffer area, the Post Status
routine (for normal exits) frees the currently fixed area and
fixes the new area beginning at the location where the next
block of text is to be read. The exit routine then completes
translation of the text CCW and returns control to the I/O
supervisor to restart the channel program.
When none of the above conditions is present, channel end
occurred because the TIC instruction was stored by the DIE
routine after the channel had fetched the NOP CCW. In
this case, the Post Status routine (for normal exit) returns
control to the I/O supervisor to restart the channel
program.
Module
Label
f'
w
Diagram 21-11. Program Fetch (IEWFETCH) (part 9 of 10)
0 '\
~
~N
fIJ
Process
Output
~
ar-
Step
11
Test for completion of loading.
~
12
Allow channel program to finish .
~
13
Initialize SEGTAB for overlay program.
14
Calculate module's relocated entry point
address.
15
Set return code in register 15.
ei(S.
Co
.$
=
:3
(D
,a:.
'
~
~
~
0\
o
CD
LOGREC Buffer
{I}
<:
{I}
N
{I}
'<
~
~
t"'"
cir;.
t"'"
...0:
e:
'<
• Processing a storage
check in a global routine
that has established
an FRR.
• Invokes RTM1 for
software repair:
CALLRTM
TVPE=MACHCK
....
.
Information
about
hardware
error
~
RTM1
EED
®IEAVTRT1
...
,..
• Sets up environment
for MACHCK entry.
®IEAVTRTM
~
<:
o
01EAVTRTH
• Ca lis lEA VTRTH
(Hardware error
processor).
~
C
3CD
.• Preserve hardware
data in EED's
(RTM's internal
control blocks).
"
l
• Ca II appropriate
repair routine.
~
'<
EED
Registers
and PSW
at time of
MACHCK
Repair
Status
Information
{I}
N
~
CD
;Q)
~
t.J
~
• Returns to caller
(MCH) with pointer
to WSACRTMK.
...
• Passes back poi nter
to re-entry data
(stored in
WSABRTMK).
...
• Record hardware
error to LOGR EC.
• Establish
environment for
re-entry to RTM in
WSACRTMK.
WSACRTMK
"-
.
Registers
and PSW for
re-entry to
RTM1
-~ ~
(To Part 2)
This depicts the processing for a "hard" type madline check in a global routine which has
FRR recovery. It shows the interfaces and control flow between the machine check
handler and RTM1 for both hardware error processing and the resulting software recovery
attempt by the FRR. It alludes to the fact that software recovery will continue in task
mode, because in this example the FRR does not recover the error.
The use of EEDs allows the LOGR EC buffer to.be available for further possible machine
checks and is the mechanism of passing information to RTM1 and RTM2. The information
in the global SDWA used by RTM1 recovery was obtained from the EEDs. RTM2 will
obtain an SDWA but will also use EED's as its source of error data to be passed to
recovery routines.
Figure 2-47. Hardware Error Processing (Part 1 of 2)
The RITM CPU-related work save area (WSACRTMK). is used by RTM1 to alter the
registers and the PSW that MCH will r.eload - thereby determining whether MCH will
resume the interrupted process ('soft' error), or reenter RTM 1 for software recovery
('hard' error).
(From
Part 1)
A
WSACRTMK
i MCH
i
EEDs
SDWA
I--
Regs and
PSW
~MACHCK
Altered
by RTM1
........
r
I r-VI
~®
•
MCH
Load registers and
PSW from
WSACRTMK (causing
re-entry to RTM 1 type MACHCK RE-ENTRY) for
Software Recovery
I
~
"
CZ)
•
Sets up environment
for MACHCK
re-entry.
®
IEAVTRTM
~.
Attempt system
recovery since error
(MACHCK) occurred
in a global routine.
IEAVTRTS
•
•
•
~.
Exits to the
Dispatcher.
Sets up task for
entry to RTM2 by
altering RBOPSW.
~
DISPATCHER
-----r
The task will be
dispatched eventually and
execute the SVC 13 wh ich
will cause RTM2 Task
Recovery!Termination
Services to be invoked.
~
(")
g.
=
N
:::
a
S
Co
o
-.
o
-=~
g.
~
=
~
~
N
......
.
'---'"
TCB
•
EEDs
II
I'
-l'\"
Continuewith-term.
RB
•
Figure 2-47. Hardware Error Processing (Part 2 of 2)
~.
SVC 13
F~R _li
R ou tes to F R R to
l:Jiiiijiiiii.~
attempt recovery for ..
routine that suffered
•
MACHCK.
Records the error.
Returns with a
'Continue-withtermination'
indicator
Information
"Pe colates"
r
~
~
N
00
TCB
Legend:
Task Issues SVC 3
~
~
PRB
VoISP IIEAVEDSOJ
"
;
g.
=
t
(N
Figure 2·50. Retry
Free RTM2 work area.
Clear TCB flags.
Branch to exit prologue.
Prolog
(IEAVEEXP)
~,
RB
(Retry RB)
,
RBOPSW=
CVTEXIT
~
~
~
RTM1
N
i
~
N
CIJ
'i
(D
:I
~
• Process dump data set
for current & SNAP.
• Find daughters & SNAP.
• ResetTCB flags in current
and daughters.
'!S.
(")
Co
...
cr
~
<:
a
=
:I
(D
• Initialize term exit processing
until all term exits have been
entered.
SNAP
EXIT
• Free
Resources
(Term. exit processing)
IEAVTAS1
~
'<
CIJ
N
::tI
(D
~
~
~
~
~
• Initiate task termination until
each subtask has
'EXITED'.
• Free RTM2 work area.
• Clear TCB flags.
Resource Mana
•
•
•
•
•
Exit Prolog (JEAVEEXP)
This illustrates the flow of control throughRrrM when a job is cancelled.
The CANCEL request is indicated by specific completion codes set in- the TCB by
RTM1 (code='x22'). The CANCEL process is distincitive 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
give n contro I.
Figure 2-51. Cancel
Find deepest subtask.
Detach subtask.
Purge resources.
Massage RB queue for exit.
•
Installation Resource
Managers.
IBM Resource
Managers.
CD
tI.l
a
(5'
=
~
a::
a
6'
~
~
o
'g
!(5'
=
Since the MEMTERM process circumvents
all TASK recovery andTASK 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) Paging supervisor when it determines
that it cannot swap in the LSQA for an
address space,
2) Address space create when it determines
that an Address Space cannot be
initialized,
3) The RTM or the supervisor control
FRR when they determine that uncorrectable translation errors are
occuring in the address space,
4) The RTM2 when it determines that
task recovery and termination cannot
take place in the current address space;
5) The RCT when it determines that the
address space is permanently deadlocked,
6) The RTM2 when all tasks in the address
space have terminated (lEAVTRTE),
This is the only requestor of normal
address space termination
(j.e. COMPCOD=O).
7) Auxiliary Storage Management recovery
routine, when it suffers an indeterminate
error from which it cannot recover,
while handling a swap-in or a swap-out
request.
S) Auxiliary Storage Management
recovery routine, when it determines
that uncorrectable translation errors
are occurring while ASM is using the
control register of another address
space to update that address space's
LSQA.
CD
BALR
-
CALLRTM
TYPE=MEMTERM
ASID=
COMPCOD= 0 (Normal)
:f 0 (Abnormal)
v
2
L Ptr to ASCB Queue
3
Store completion code in
ASCB with/matching ASID
(or current).
Schedule SRB to post address
space termination task in
master address space (Use of
SRB routine is serialized by
compare and swap).
/I..
ASID
IRTCTFASB
of address space(s)
to be terminated.
\
dress
ace Termination SRB
st RTCTM ECB - Th is
a( tivates the Address Space
TI rmination Task in the
aster Address Space.
M
-~
ASCB on Queue
ASCB
~
Dispatcher
(IEAVEDSO)
ASID
Completion
Code
~
CN
00
~
S
SRB on
Dispatch
Queue
IEAVTRT1
The process of terminating an address space (memory)
is one which cannot be isolated to one task, module
or logrcal unit of rode. This presents the many parts
of the function into a coherent picture of the process,
by showing control flow and data flow.
The multiple dispatches, tasks, and address spaces
involved would otherwise be hidden elements.
~
Figure 2-52• The Process of Terminating an Address Space (part'1 of 2)
~
o
Return to caller.
Note: Since callers 4, 5, and 6 above are
task-related and running in the address
space to be terminated, they will set themselves non-dispatchable after issuance of
CALLRTM,
°
G loba I SR B Dispatcher
IEAVTRTM
ASCB
Queue
I
IEAVTRT1
Via Branch Table go to
'TYPE' processor.
TYPE=MEMTERM
Put ASCB of address space to
be terminated on address
space queue.
RTCT
V\
RTM1
1
CN
~
o
,
Step 1
Step 2
Steps 3, 4
Steps 5, 6, 7
Identifies the
Requesters
The Request Format
Initiate the Request
Process the Request
to
CH
CH
RTCT
~
RTCTFASB
ASCB Q Ptr
£
t::::::;l
"<
RO
~ ';'ASCB
r.f)
t-j
POST
r.f)
'<
l
~
9
~
($'
~
--y
<:
o
=
~
~
I
~
Address Space
IEAVTMTC
0
~RT~
r.f)
t-j
Q
CH
00
1
Dequeue last ASCB on address space termination
queue (QUEUE MODIFICATION SERIALIZED
via compare and swap,)
2
Get Local Lock-.CMS lock-.Dispatcher lock.
3
Set address space indicater by ASCB
non-dispatchable.
4
MP-Wait for task and SRB activity for this
address space to stop in other CPU.
o
r- - - - - - - - - -..,
I Resident task attached :
I by IEAVTMSI.
I
(Master scheduler
I
I initialization at IPL).
I I
I It remains inactive until ,...J
I
L,:~~:.:ork~ _ _ ~
IEAVTMTR
~I------------------------------~
I
'<
-..J
0
ME~TER~
Options
Terminator Processor Task
o
ASID
=!3
(D
ltto Dequeued ASCB
Address Space Termination
Controller Task in Master Address Space
ASCB
~
'<
l
R1
RTCTMECB
Re~ident
t"'"
~
-
,.oN
ASID
t"'"
B1
/
Next ASCB
5
Free locks.
6
Call SVC 1/0 Purge.
Purge 1/0 for that address
space.
7
~
Attach subtask to handle remainder of purges
for the address space (Pass ASCB in R 1).
9
If the address space termination ASCB queue
pointer is not zero, then process steps
G) -
,
Otherwise, task waits for work
(wait on RTCTMECB).
WAIT
Figure 2-52. The Process of Terminating an Address Space (part 2 of 2)
2
Indicate MEMTERM options
in R1.
4
IGC0001 F
S
to
Set RO to point to this
terminating address
space's ASCB.
3
I.
IEAVTERM
Call RSM (real storage resource ~
management) to free all real
~
and auxiliary storage.
G)
1
! ATTACH
SVC13
SVC 13 - to invoke the
services of RTM2.
EXIT to dispatcher.
-
.,
BR 14
...
1'-
Return
to Caller
.1
Perform
Address
Space
Purges
ABEND Macro
SVRB
I RBEXSAVE
SNAP Macro
IEAVTRTC
Provide Dump
Options for
ABDUMP
-"-
~
...
RTM2WA
")I
v
SNPPARMS
J..--
CALLRTM Macro
RTM2WA
I SNPPARMS
~
t=
"...
SETRP Macro
SDWA
I
SDWASNPA
LSQA, CB, ENO,
TRT, ALLPA, SPLS
CB, ENO,
TRT. ALLPA, SPLS
~
~
r
..JI...
I
00
~
~
g
!'!
3:
r
~
Read Parmlib
Members and
Set 0 ptions in
RTCT
IEEMB815
Process Options
,'
.....
I
IEAVTABI
"'V
CHNGDUMP Command
XSA
XAL
v
on CHNGDUMP
Command'and Set
Options in RTCT
This provides an overview of all data
areas related to- ABEND/SNAP dumps,
the sources from which the dump options
are obtained. the key modules involved
and the complete scheme of data flow.
It ties together the function of system
initialization requestors dump options
and operator intervention as all parts
of the process.
0.
2-
ii
g
~
~
w
VI
Set Up for
SNAP Processing
..J-.
-y
SNAP
ISNPPDATA
SNPDCB
SNPSTCBA
~
Dump
Requested
Areas
t=
IEADMDOO
I
ISNPFLAG
SNPSDAT A
SNPSTOR
IEAABDOO
I
SNPIOET
~IEAVTABD
Figure 2- 53. ABEND/SNAP Dump Processing
I
n.s
>
~RTCT
bJf
Control Flow
Data Flow
RTCTSAP
RTCTSUP
RTCTSAO
f-~
RTCTSUO
[ii
•
selection is as follows:
1. CHNGDUMP options completely override any other request.
2. Lacking CHNGDUMP options. the options specified on the ABEND, CALLRTM
or SETRP macros are merged with the options in IEAABDOO or IE_ADMPOO.
3. If no options were specified on the ABEND, CALLRTM or SETRP macros,
the options specified in IEAABDOO or I EADMPOO will be used. If no options are
specified via CH NG DUMP, AB END, CA LLRTM, SETRP, I EAABDOO or
IEADMPOO no dump will be taken.
For ABEND dumps the requestor (via ABEND, CALLRTM, and SETRP) and
installation (via SYS1.PARMLIB members IEAABDOO and IEADMPOO) have been
given the ability to tailor dumps to the needs of the installation and the individual
maintenance requirements of each type error_ In addition, the CHNGDUMP
command provides the facility to temporarily override options specified by the
requestor and/or installation.
~
®
~
IN
0\
o
tn
"
",.
,+ 4K Buffer
Process SVC
Dump information
specified by
operator at IPL
time.
"
I
,
> I.
IEAVTSDR
'.'
'0,
(From Part 1)
~
(From
Part 1)
CHNGDUMP Command
®~IEEMB815
XSA
XAL
;
I
>
Process SVC
Dump options
specified on
CHNGDUMP
command.
SVC DUMP (JEAVADOO)
,oil
C
D
~
Determine if SVC DUMP should be scheduled to
the SVC dump task or performed immediately,
based on number of ASID's in the PARMLIST.
J(A
----"f
RTCT
~
r-----v
RTCTSDO
(To Part 1)
lJl
~
~
§'
~
3:
;.
~
=
~
Sa
~
te
~
=
=
.....
w
W
-.J
®B
Either no ASID's in PARMLlST, or both
ASlD's in PARMLIST. (6th word)
"" ~
Perform SVC dump and return control to the
current caller (either SVC dump tasks or user) .
••
Figure 2- 54. SVC Dump Overview (Part 2 of 2)
(or 0)
0 Targ.tASID
0
l
.'
~
,
B >
/
Dump Data
Set Table
"I
, SVC SLIH
f-
RTCT
MP
.....
01
4-338
OS/VS2 System Logic Library Volume 4 (VS2 Release 3.7)
R/TM
Overview
(no diagram)
I
~
RTMl
Overview
(IEAVTRTM)
1
~
RTM2
Overview
(IEAVTRT2)
I
~
Address Space
Termination
(IEAVTMTC)
lE.L
RTMl
Initialization
(IEAVTRT1)
~
Process
Hardware Errors
(IEAVTRT2)
~
Processing
SLiH Requests
(IEAVTRTM)
~
Reschedule
RTM1
(lEAVTRTM)
til
(I>
a5·
=
~
~
R/TM
Services
(no diagram)
~
\b
I
I
~
I
~
RTM1
Cleanup
Processing
(IEAVTRTM)
I
~
N
~
(I>
~
~
o
.....
o
"0
~
;.
o
=
f"
~
~
\0
Routing
to FRRs
(IEAVTRTS)
RTMl
Recursion
Processing
(IEAVTRTR)
I..-
--
Figure 2-55. Recovery/Termination Management Visual Contents (part 1 of 3)
SystemDirected
Task
Termination
(IEAVTRTM)
Reschedule
Locally Locked
Task or SRB
(IEAVTRTM)
I
l1ll!.
RTMl
Exit
Processing
(IEAVTRT1)
~
c:w
~
R/TM
Overview
(no diagram)
o
o
{I)
"<
{I)
~
N
{I)
~
~
I
I
r""
T22-1
ci5·
122-12
122-24
r""
a:
~
~
R/TM
Services
(no diagram)
Address
Space
Termination
(lEAVTMTC)
RTM2
Overview
(IEAVTRT2)
RTM1
Overview
(lEAVTRTM)
2'
9(1)
\b
~
c:b
'<
{I)
N
~
i
rtl
~
~
f
122-13
RTM2
Initialization
(IEAVTRT2)
1
1
Recursion
Processor 1
(lEAVTRT2)
Recover Task
Processing
(tEAVTAS1)
122-14-
122-17
122-16
ABDUMP
Processing
(tEAVTABD)
1
122-15
Recursion
Processor 2
(lEAVTRTE)
Figure 2-55. Recovery/Termination Management Visual Contents (part 2 of 3)
122-=18
Synchronizing
Failing Tasks
(lEAVTRTC)
122-21
T!2-19
Task Purge
Processing
(lEAVTSKT)
I
1
I
I
Address
Space Purge
Processing
(lEAVTMMT)
-r
122-20
Task Purge
Resource
Managers
(IEAVTSKT)
122-22
Address
Space Purge
Resource
Managers
(tEAVTMMT)
122-23
RTM2 Exit
Processing
(lEAVTRTE)·
R/TM
Overview
(no diagram)
I
~
RTM1
Overview
(lEAVTRTM)
~~
122 -25 1
STAE/ESTAE
Processing
(lEAVSTAO)
Alternate CPU
Recovery
(ACR)
Overview
(lEAVTACR)
FRR Stack
Initialization
(I EAVTSI N)
=
122-30
~
a::
a
SNAP Dump
Processing
(lEAVAD01)
8:o
.....
o
"0
~
I»
g.
=
~
c:w
~
1-0
Figure 2-55. Recovery/Termination Management VisualContents (part 3 of 3)
I
122-29
122-33
SVC 51
Overview
(IEAVADOO)
SETFRR
(SETFRR)
I
til
a
o·
R/TM
Services
(no diagram)
Address
Space'
Termination
(lEAVTMTC)
RTM2
Overview
(IEAVTRT2)
I
I
CHNGDUMP
(lEEMB815)
I@iliJ
SVC DUMP
Processing
(IEAVADOO)
I
~122~
Schedule
Dump
Processing
(lEAVTSDX)
j
122-34
Recording
Processing
(lEAVTRER)
~
CM
e
Diagram 22-1. RTMI Overview (IEAVTRTM) (part 1 of 2)
From a branch entry
after a supervisor
state routine issues a CALLRTM
macro instruction
&1
~
~
til
'<
~
a
~n
RTM1
Work Regs
i
t:':
1
2"
~
~
=-:3
(II
~
'<
til
~
:;0
(II
i
~
CM
~
RTM1
Work Regs
Set up the common interface from
the RTM1 entry points.
i
lID
D
D
">2
..
,.
Process hardware errors.
I"
IEAVTRTH
.
Hardware Error
....
...
Current
FRR Stack
'
I
0-
(I -/ 3
.'
'\
Perfor~ second I~vel interruption
operatIon processing.
--v
II
'!
0-
-y'>
,.
..
SLiH Mode
..
Reschedule
....
...
4
Process any rescheduled RITM
requests.
,..
~
...
5
...
,.
Perform clean-up processing.
RTM1
Work Regs
D
..."
~
...
0-
-y
!
6
Exit to the appropriate routine.
Retry routine.
Machine check handler.
Interrupted program.
Dispatcher.
SRB exit.
Exit prologue.
caller.
•
•
•
•
•
•
•
Clean -up
..-
.-
Diagram 22-1. RTMI Overview (IEAVTRTM) (part 2 of 2)
Extended Description
The RTM1 service of recovery termination management
(R/TM) provides a recovery interface with other supervisory
routines. When a supervisor routine - principally the interruption handlers - detects an error situation, it passes control to RTM1, via the CALLRTM macro instruction, to
initiate recovery from the error. RTM 1 records the error both hardware and software - to SYS1.LOGREC via the
recording service.
RTM1 does not perform the recovery function itself; it
routes control to functional recovery routines (FRRs)
established by locked, disabled or SRB routines. These FRRs
are placed on an LIFO FRR "stack" by a SETFRR macro
instruction issued by the routine requesting protection. The
macro expansion places the FRRs on predefined stacks, that
is, the FRR is placed on an appropriate stack based on its
functional path through the supervisor (however, the "Super"
FRR is placed on each stack by NIP processing). The following list shows the stacks:
•
•
•
•
•
•
•
SVC-I/O-dispatcher stack
Machine check stack
Program check stack
External interruption handler 1 stack
External interruption handler 2 stack
External interruption handler 3 stack
Restart interruption handler stack
Additionally, a normal FRR stack contains the recovery
status for other paths through the system.
RTM 1 receives control for 12 reasons. These are for:
CI)
~
(")
g.
=
N
a::
~
g
Q.
....
o
C
'g
Qt
5·
• Program checks.
• Restart operations.
• SVC errors.
• Page I/O errors.
• Machine checks.
• DAT (dynamic address translation) errors .
• Abnormal termination (ABTERM) requests for a task
with an AS I D (address space identifier) specified.
=
of-
~
~
~
*Module IEAVTRT1 contains labels; the column under
"Segment" refers to label names.
Module
Segment
Extended Description
Module
• Abnormal termination requests for a task in the current
address space.
• Address space termination requests.
• Reentry for abnormal termination requests.
• Reentry for machine checks.
• Branch entries for abnormal termination requests.
1
RTM1 creates a common interface for its sub-functions
from the various entry point data and establishes recursion control for service routine requests.
IEAVTRT1
2
IEAVTRTM
When either MCH (machine check handled or ACR
(alternate CPU recovery) indicates a hardware error,
control goes unconditionally to the hardware repair function, module IEAVTRTH (see M.O. diagram, Processing
Hardware Errors (I EA VTRT2)). Hardware repair performs
software repair, if necessary, and attempts to record all
hardware errors on SYS 1. LOG R EC (modu Ie lEA VTRTM).
3
The program check IH (interruption handled, SVC
IH, the restart IH, and the machine check handler
(MCH) all can request RTM1 to perform second level
interruption handler processing (SLIH mode). When RTM1
processes an SLI H mode entry type (that is, TYPE=PCF LI H,
MACHCK reentry, SVCERR, RESTART, DATERR) it continues the processing of the interruption. SLI H mode
functioning determines the state of the system at the time
of the interruption, so that recovery from the interruption
may be attempted in either system mode or task mode.
4
RTM 1 performs reschedule processing for a service
routine entry (that is, the CALLRTM request was for
ABTERM, MEMTERM, or PGIOERR). The reschedule
function may also be performed as part of SLIH mode processing. This would occur if the action indicated by routing
to FRRs required a reschedule service of if the CPU had
been in task mode when the error interruption occurred.
5
The clean up function frees any resources no longer
necessary before determining the appropriate type of
exit.
6
RTM1 creates the final exit linkage based on an
indicator established in IEAVTRTM.
IEAVTRT1
Segment
t
Diagram 22-2. RTMI Initialization (IEAVTRTl)
o
Input
~
~
{Il
(part I of 4)
From RTM 1 Overview (I EA VTRT1)
to initialize RTM 1.
Process
Output
<:
{Il
N
1
{Il
'<
~
3
Perform initialization based on the
type of entry:
•
r-
,
Flags
>,
Flags and Comp Code
RO
I
'"
)
y
,
,
2
-'"
Process second level interruption mode
entries:
•
•
•
Set an indicator for the particular
type of interruption.
•
Subsequent errors detected by
recursive entries to RTM 1.
"
Entry pt - Function ID
I
I
R2
[@ 1st half PSW
Indicate completion codes for the
interruption.
R3
@2nd half PSW
I
R4
I
Registers not saved.
@ FRR Stack
R13
~ @ Registers
.
at
I
Y
interruption
I
I
I
,
i
R5
6
"
v
)t
@ Dump options
I
Diagram 22-2. RTMI Initialization (IEAVTRTl) (part 2 of 4)
Extended Description
Module
Segment
RTM1 processing receives control via the CALLRTM
macro instruction. The expansion of this macro instruction locates the correct entry point address into RTM1
from the RTM1 branch table (pointed to by the
CVTBTERM field of the CVT). RTM1 initialization
combines the various entry point data to create a common
interface for RTM1 processing.
1
RTM1 initialization consists of saving registers, indicating completion codes, and establishing a recovery
environment based upon the type of entry. RTM1 performs three types of initialization; one based on requests
made by the interruption handlers; another based on a
service request for an RTM 1 service; and the last for
machine check interruptions.
2
til
g
g.
::s
~
at
[
SO
!
~.
::s
to
w
~
VI
IEAVTRT1
RTM1 initialization prepares the following entry
points for SLiH mode:
1. Program check entry point - used by the program check
I H when an invalid page fault or program check occurs.
When the program check IH passes RTM1 a completion
code, the registers and PSW have been saved by the program check I H in the primary save areas of the PSA and
LCCA (logical configuration communications area).
When RTM1 does not receive a completion code, initialization processing builds one from the interruption code
and the error information in the secondary save area in
the LCCA. (The "Supervisor Control" section describes
the program check I H, and the different save areas used.)
PROGCK
2. Restart entry point - used by the restart I H after the
operator has requested R/TM processing. The subsequent
handling of a restart request in R/TM is tailored to "Ioop
breaking" logic, that is, a looping program c.annot be
allowed to retry, and a validly spinning program is allowed
to request R/TM to interrupt the program that owns the
resource being waited upon. The restart IH has saved the
registers in the LCCA and the resume PSW in the PSA.
RESTART
Extended Description
Module
Segment
3. SVC IH entry point - used whenever an SVC is issued by
a routine that is locked, in SRB mode, or is under supervisor control (non-dispatchable supervisory functions).
If the SVC was an SVC 13, RTM1 interprets the entry
point as an explicit request for ABEND processing. RTM1
Interprets entry from any other SVC to be an error. The
SVC IH has saved the registers and the PSW. (See the
"Supervisor Control" section for a complete description
of the SVC I HJ
SVCERR
4. DATERR entry point - used by the program check IH
when a recursive translation exception occurs during
either the program check IH's processing, or RTM1's
FRR processing. Before calling RTM1, the program
check I H has attempted to circumvent any further translation fa"ilures by altering the STOR (segment table
origin register) which points to the master address space's
segment tables. If errors occur again, the program check
IH places the system in a disabled wait state. RTM1 does
not allow normal recovery processing to occur during
DATERR processing since the non-common areas of
the failing address space are no longer addressable. If
a supervisor control routine was in control when the
original error occurred, then its FRR will be 'given control,with a special indication to warn it that private
areas are no longer addressable. The super FRR may
recover the address space or terminate it (via
MEMTERM). If a super FRR is not available, RTM1
bypasses all recovery, records the incident "and terminates the address space.
DATERR
5. MACHCK reentry - used when RTM 1 set up MCH
(machine check handled or ACR (alternate CPU
retry) for re-entry into RTM1 after RTM1 was initially enter~d for a machine check. RTM1 uses this
entry to attempt software recovery processing if a
machine check caused software damage.
MACHCK
~
~
Diagram 22-2. RTMI Initialization (lEAVTRTl) (part 3 of 4)
0\
o
til
"<
,
til
N
til
.R'
'<
~
~
Register 1
F lags
I
~
~.
§=
~
,..R_1_ _ _ _ _ _ _ _...
j
J
I
I
.. 3
.)
v
I
•
•
Re ister 4
'<
I
til
N
~
i
~
@ SR B or TCB
Register 5
@ RB or 0
I
~
(,,0.1
~
I
I
Register 2
IRegister
ASID
15
t
IRegister
Entry pt @
3
I
I
Dump Options
I\.
Process service mode entries.
1
~
,~
I F lags and Comp Code I
j
•
Register 14
Return @
~
~
.
Register 1,3
I @ Save Area
t"'"
I
I
g&
i~ifa
I
iJ•.
a
.
I
~
~
.
~
I
~
{
,
ii
I nd icate completion code.
IR@13Caller's Regs
Set an indicator for the type of
service requested.
I
~
,..R_4_ _ _ _ _ _ _ _'""'I
1 @ FRR Stack
I
\
•
I~. I
I~
Save caller's registers.
RO
Entry pt - F unction
ID
I
l
~
Subsequent errors h a n d l e d '
by an FRR.
it
~
I.
• R2
~
ASID or 0
I I .,..--J.V\.~rL-@:--T-C-B-,
~
I·
~
$)
R3
o-r-S-R-B-----,'
L . . -......
I
R5
o.J"'--D-u-m-p-o-p-t-i-on-s-,--"')
RB or 0
Y lL....._ _
' _ _ _ _ _ _...J
...
I
;
i
I\.
-----"'-------1.........1"')
4 Process machine check mode entries.
v
Register 1
I
I
Register 13
i
.
I
I
Register 14
I
I
Register 15
I
'
I
.,
•
Save registers.
•
.
.
Establish recovery via FRR.
I
----------,
--------IL-.Jl\.l'\.r--
v
,..R_
s _ _ _ _ _ _ _-...
I @ LOGREC buffer I
RO
, . . - - - - - - - - -...
Entry pt ID
R13
I
.
I
1,..;..@~Sa-ve-A-re-a---1
~
,.
" R 4
'
@-FR-R-S-ta-ck----.I
r--I
To RTM1 Overview
(lEAVTRTM)"
. . . .-~. . .&~. . . .- . . . . . . . . .-~
Diagram 22-2. RTMI Initialization (IEAVTRTl)
Extended Description
3
(part 4 of 4)
Module
Segment
RTM1 initialization prepares the following entry
points for service mode:
1. PG IOE R R entry point - used by the reset subroutine
of real storage management when an error occurs while
processing a page fault. The routine that suffered the
paging error is forced to issue an ABEND instruction
(SVC 13) to cause linkage to R/TM for recovery and
termination services. Initialization processing for this
entry point passes the address of the TCB or SRB that
suffered the error. If a task suffered the error, the
address of the RB is also passed.
PGIOERR
2. ABTERM entry points - used by key 0, supervisor
state routine~ to set a task up for entry to RTM2 for
ABEND. There are two types of ABTERM entry:
ABTERM with ASID option; and ABTERM without
ASID.
ron
(p
n
g.
=
~
:::
~
8:
c-.
o
-g...
III
g.
=
.a::.
~
.a::.
......
Extended Description
XABTERM
ABTERM without ASI D is a request to terminate a
task in the current address space. RTM 1 saves the
caller's registers and PSW. and performs the ABTERM
request.
CABTERM
Segment
3. MEMTERM entry point - used to request scheduling
an address space termination. Since there are no
specific lock requirements, the caller must provide
a register save area. R/TM will perform the address
space termination. RTM1 performs a MEMTERM
asynchronously with dependencies on locks and the
dispatcher. Therefore, control mayor may not return
to the caller, depending on the lock status when the
caller issued the request.
MEMTERM
4. ABTERM reentry -:- used when RTM1 scheduled itself
as an SRB during a previous entry when the caller
requested ABTERM with the ASID option. When
entered at this entry point, RTM1 is operating as an
SRB in the specified address space.
IEAVTRTX
4
ABTERM with ASID is a requ.est to terminate a task
in an address space other than the current one. RTM1
schedules itself as an SRB into the specified address
space to perform the ABTERM request. RTM1 saves
the caller's registers in a caller-supplied save area.
Module
MCH (machine check handled and ACR (alternate
CPU recovery) use this entry point when requesting
hardware recording and hardware damage repair. The
caller passes the address of a LOGREC buffer which contains all the information about the error. If RTM1 subsequently determines that software recovery is warranted,
it will establish the appropriate software interface.
.
IEAVTRTN
~
eN
0l:Io.
00
o
~
~
~
Diagram 22-3. Process Hardware Errors (lEAVTRTM)
From RTM1 Overview
(lEAVTRTM) to process
hardware errors.
Entry State: Supervisor State,
Key 0, E.C. Mode,.
Input
Disabled
1<
..
'"iC'
C'Il
'i
RTM Work Regs
~
ic:;.
MCH
LOGREC
Buffer
r-
J
Error Word
~
(part 1 of 4)
Process
I~
'.
.."')
MCH
Stack
Recovery
Information
Area
Output
IEAVTRTH
1
•
•
•
>c,~
c
a
c
"I
Process machine errors.
..
Acquire EEDs.
..
Call clock repair.
"
..
0l:Io.
r
.
~
S'
~
eN
~
EED
Repair
Status
D
"')
2
v
Real Storage
...
Record hardware error.
Recording.
~
..
;
Facility
'"
'v"
4
MCH
LOGREC
Buffer
.
v
@
MCH
LOGREC
Buffer
Repair
Status
MCH Stack
Recovery
Information
Area
See
input
to
step 2.
Reconfiguration
Routine
'"
RTM Work Regs
WAS-ACRTMK
Environment
EED
I-i
i
I
t'
Repair
Routine
Ca II rea I storage
reconfiguration.
~
Clock
r
-1\.
3
..
Complete software information
for return to MCH.
-
~~
~~
\_
t
~
..
)
Environment
EED
I
ToR/TM.
module
IEAVTRTM
Repair
Status
EED
WSACRTMK
D
Diagram 22-3. Process Hardware Errors (IEAVTRTM)
(part 2 of 4)
Extended Description
Module
Segment
MCH uses RTM1 as a subroutine to attempt the-repair of
clock and storage errors, and to record all hardware errors.
The main body of RTM1's hardware error processing is
contained in the module IEAVTRTH. During the time
RTM1 is working with the LOGREC buffer, MCH protects
RTM1 from any further entry for new machine errors. When
RTM1 processes ACR (alternate CPU recovery) errors, ACR
provides protection from new machine check entries by
disabling machine checks during the RTM1 process.
1
For ACR and "hard" errors (that is, machine checks
where hardware recovery has not been able to recover
the operation) RTM1 obtains two EEDs (extended error
descriptors) to pass on information concerning the error.
~
~
i·
~
~
(p
[
o
~
o
'C
ae'
(p
.,.=
.,.
~
\,Q
Extended Description
For ACR and timer errors, the clock repair routine (module
lEA VRCLS) receives control to recover software ti ming
functions.
CLOCKREP
For storage data checks or storage key failures, the RSR (real
storage reconfiguration) routine (module lEA VRCF) receives
control.
RSRECON
To attempt repair upon return from RSR, repair status is
placed in the LOGREC buffer and in the EEDs.
BLDPLIST
Segment
2
RTM1 places a record of the hardware failure on
SYS1.LOGREC via the recording facility for both
"hard" and "soft" errors (that is, errors which were successfully recovered by the hardware).
RECORDNG
3
SOFTINFO
The WSACRTMK contains the registers and PSW thai
MCH needs to restore when RTM 1 subsequen1ly returns
control to MCH. For "soft" errors, the routine the machine
check handler interrupted has sustained no software damage
and may resume its processing at the point of interrup-
IEAVTRTH EEDREQST
Module
tion. In this case, the information in the WSACRTMK consists of the registers and PSW at the time of the machine
check. For a "hard" error, the routine in control at the time
of the mach ine check did suffer software damage; RTM1 must
be reentered to perform software recovery. Therefore, the
PSW RTM1 placed in the WSACRTMK points to the machine
check reentry point (I EAVTRTN) in IEAVTRT1. The registers in the WSACRTMK contain the values RTM1 expects
on reentry.
~
~
Diagram 22-3. Process Hardware Errors (IEAVTRTM) (part 3 of 4)
til
o
o
{I)
"<
{I)
Process
Input
Output
N
c;n
From RfTM
to handle
'<
~
(I)
3
~()'
Register 0
[@ FAR Wo;k Area
t"'"
~
~
B
3=(I)
~
',';
",,'
,
til
N
til
'<
...
,.
~
s
1
£'
Refresh critical data and the restart
PSW.
'"
'.
...
(S.
r-
Addressing
i
r
0:
...
~
~
IEAVELCR
~
Verification
Processing
,
1{
=-9
2
Process possible recursion:
('I>
~
<:
~
til
N
~
if
D
D
w
~
v
"v)
•
I t~ :
RTM1A
~
•
•
)
I
i"--
-
-I/"
t
!\.
~
...
-
4
"
RECVRRTM
~
SDWA
Determine whether system recovery is
needed.
--".
Route control to the appropriate
control program recovery routine.
v
LCCA
DD
RTM1
Work Regs
") 5
v
D
lli
...
Process retry, resume or continue
.
.
with
termination.
•
SDWA
~
,.
Unexpected recursion.
'"
~ 3
r-
'----
PSA
Expected recursion, or one covered
by an FRR.
...
Regs
'~
Non-recursive entry.
•
•
v
Retry.
Resume.
Continue with termination.
.
I~
To RTM1 Overview
(lEAVTRTM)
Diagram 22-4. Processing SLIH Requests (lEAVTRTM)
Extended Description
(part 2
Module
of 2)
Segment
This chart illustrates the flow of control during RTM1's
SLI H processing.
1
IEAVTRTM REFRESH
2
RTM1 continues SLIH processing for non-recursive
entry into RTM1; for anticipated recursive entry;
or for recursion covered by one of RTM1's FRRs. Otherwise, RTM1 processes an unanticipated recursive entry by
routing control to a recovery routine (RECVRRTM in
module I EAVTRTR) that determines whether any recovery
of this recursive error can be performed.
RECURSE
3
SYSTATE
Whenever RTM1 performs SLIH processing, RTM1
first attempts to t:efresh critical common fixed constants. RTM1 refreshes low storage (via IEAVELCR) and
attempts, on its own, to refresh the restart new PSW.
RTM1 determines the system state at the time of the
interruption by examining indicators in the PSA and
LCCA. The succeeding flow of control during SLI H mode
processing depends on the system state (system mode or
task mode).
Extended Descri ption
til
=
N
==
~
R
o
~
o
"t:I
Io·
=
~
~
w
Segment
4
For errors in global, local, SRB, or supervisor control
code (that is, the state determined in step 3 is system
mode), control program recovery must be performed. To
effect this recovery, routing FRR processing (module
lEA VTRTS) receives control and routes control to any
appropriate recovery routine (FRR) associated with the
failing routine.
SYSRCVR
For errors in task mode when the interrupt occurred,
RTM1 skips this step and the following step and sets the
work registers to reschedule the interrupted task for entry
to RTM2.
SETUPABT
5
SYSRCVR
RTM1 analyzes the output from routing to FRRs.
For retry requests, control goes to R/TM's clean-up
and exit J')rocessing. For valid resume requests, RTM1
establishes an· interface to the reschedule CPU function.
Otherwise RTM1 continues with termination, setting its
work registers to establish the correct interface to the
reschedule function.
DATPERC
For DATERR entries to RTM1, RTM1 establishes the
address space termination interface.
When the system is in SRB mode, RTM1 establishes the
ABTERM interface to terminate the task associated with
the failing SRB.
ao·
Module
SRBPERC
t
Diagram 22-5. Routing to FRRs (lEAVTRTS) (part 1 of 8)
.
~
~
~
~
~
CI.l
'<
~
3
i-t::
nput
From RTM1 Overview
(lEAVTRTM) to route
control to an F R R
r
M1
Regs
~
~
~
2"
9(D
~
',
Obtain and initialize the
.SDWA.
--v
...
~
~
RTM1
Work Area
Global
SDWA
(D
~
RTM1 Regs
t...
....
~
i
Output
For unlocked SRBs:
Interrupted
FRR Stack
PSACSTK
Process
ASXB
......----,;VJ----I
----I
ASCBASXB
Local SDWA
)I
6
GETMAIN
Obtain
storage for the
SDWA
.......}.
L -_ _----J_
\
\
Interrupted
FRR Stack
RTM1
Work
Area
Diagram 22-5. Routing to FRRs (lEAVTRTS) (part 2 of 8)
Extended Description
RTM 1 routes control to FRRs (functional recovery routines
(lEAVTRTS» defined by supervisor routines to protect
themselves from errors. The function provides the interface
and control between failing supervisor routines and their
FRRs. The FRRs reside on "stacks." Allocated as predefined
areas in SQA (system queue area), consists of a header (used
to control the contents of the stack), a workarea (used by
RTM1 when performing FRR routing), and a fixed number of
FRR entries. (See Initializing FRR Stacks (lEAVTSIN».
Each FRR stack defines a path through the supervisor as
follows:
CI'.l
~
p.
c·
::I
~
:::
~
S
Co
...o
o
"0
~
i3
5'::I
~
~
VI
VI
Module
Segment
Extended Description
• External interruption handler 3 stack. Defines the path
through the supervisor for an external interruption when
one recursion has occurred already and is being processed
and this is the second one. Supervisor functions processing
external interruptions place their FRRs on this stack.
• Restart interruption handler stack. Defines the path
through the supervisor when a restart interruption occurs.
Supervisor functions processing restarts place their FRRs
on this stack.
• Normal stack. Defines the path through the supervisor
used when processing normal requests for supervisor
services made directly (or indirectly) by problem programs.
• SVC/I/O-dispatcher stack. Defines the path through the
supervisor used when servicing SVC interruptions or I/O
interruptions, or during dispatcher processing. (One stack
can be used for all of these three functions, since the processing for anyone function is not dependent on the processing of the other two functions.) Those supervfsor
functions servicing I/O or SVC interrupts as well as those
functions comprising the dispatcher place their FRRs on
this stack.
When an error occurs in a supervisor funct:on covered by an
FRR, routing to FRRs gives control to the appropriate FRR
defined on the stack protecting that function. Routing to
FRRs supplies the FRR receiving control with a complete
description of the error in the SDWA (system diagnostic
work area). Routing to FRRs acquires an SDWA based on
the system state at the time the error occurred:
• Machine check stack. Defines the path through the
supervisor taken when a machine check interruption
occurs. Supervisor functions processing machine
checks place their FRRs on this stack.
• Global SDWA - associated with the FRR stack defining
the supervisor path that failed when the system operates
physically disabled (globally locked or supervisor control
mode).
• Program check stack. Defines the path through the supervisor taken when a program check occurs. Supervisor
functions processing program checks place their FRRs on
this stack.
• Local SDWA - associated with the supervisor path that
failed when the system operates logically disabled (locally
locked).
• External interruption handler 1 stack. Defines the path
through the supervisor when an external interruption
occurs, and there are no recursio!1S. Supervisor functions
processing external interruptions place their FRRs on this
stack. (See the M.O. diagram, External Interruption
Handler (I EAVE EXT) in the Supervisor Control section
for a complete description of the external interruption
handler and its method of handling recursions.>
• External interruption handler stack 2. Defines the path
through the supervisor when an external interruption
occurs for a second time, while the external interruption
handler is processing a previous interruption. Supervisor
functions processing external interruptions place their
FRRs on this stack.
Module
• GETMAIN SDWA - an SDWA obtained via a GETMAIN
request and associated with the supervisor path that failed
when the system operates only in SRB mode.
1
Routing to FRRs acquires all SDWA, and initializes it
with error informations obtained from the input regis-
ters. These registers contain values set in the RTM1 mainline
module (lEAVTRTM), as shown in M.O. diagram, RTM11
Initialization (IEAVTRTM).
IEAVTRTS
Segment
~
CN
Diagram 22-5. Routing to FRRs (lEAVTRTS)
(part 3 of 8)
(It
0\
~
~
N
Process
Input
fI)
i
a
RTM1
Regs
~.
~
fI)
N
i
'8
jS.'
.:~
:> 2
....
Perfor~ SLIP
v
RTM1
Regs
J
processing.
RTM1
FRR
Stack
~
'<
PSA
J
f
"
Output
PSA
i
i
9
(~ive
\
~~WA
RTM1
FRR
Stack
RTM1
Work Area
RTM1
Work Area
Active
.. SDWA
CVT
CVT
r6
I
I
CN
~
IMRTMS
CVTRTMS
I
It:k*
~}\~
~S ~
Interrupted
~FRRStack
I
PSA
/~
r__-----"
.
LCCAPDAT
Prog Check
IH's FRR
v
RTM1
Work
Area
Stack
ICVTR~D I
RTM1
Regs
~
~
:" t I Appropriate
~
FRR
'"
Work Area
Lltl
Active
SDWA
CVT
LCCAPSG1
,3
",
"
Route control to
the appropriate
FRRs.
'c'-:-
V
LCCA
,IT
" :.,' •
~: ~
~
,-
GTF
Trace the
event
:PSA
)
I
Interrupted
FRR Stack
Diagram 22-5. Routing to FRRs (IEAVTRTS) (part 4 of 8)
Extended Description
2
«:IJ
~.
::I
~
at:
is.
o
I
~.
::I
~
w
VI
.....
Segment
SLIPPER
SLIP (serviceability level indicator processing) uses the
CVTRTMS field of the CVT as input to determine
whether additional serviceability processing should occ.ur.
This field contains indicators set manually when additional
serviceability is desired for system errors. R/TM determines
the serviceability level requested (modules IEAVTRTR and
IEAVTRT2). SLIP processing takes an SVC dump, or
places the system in a wait state.
IEAVTRTR SLIP
IEAVTRT2
I EAVTRTR I EAVTRTL
3
I EAVTRTS ROUTE
Control goes to the appropriate FRR via an LPSW
(load PSW) instruction, passing the SDWA as input.
Routing to FRRs gives control to GTF (generalized trace
facility) to trace the FRR recovery event.
a
Module
TRACEFRR
t
Diagram 22-5. Routing to FRRs (IEAVTRTS)
(part 5 of 8)
U\
oc
~
~
N
""~''',"'
t;I.)
'<
~
a
~()'
Active SDWA
Interrupted
FRR Stack
RTM1 Regs
'" 4
v
V?"""
I
Record the request.
~
,\
I \
1\ I
a-
s
......
RTM1
I
"
v
!,~
,
t::
Er
~
~
~
WorkArea
Recording
Routine
...
...
,'/',':;"
:
(1)
~
,
PSA
'<
Active SDWA
s';
~
t;I.)
N
?;
I
SDWARCRD
AI
~
'" 5
ri-V
(1)
i'
RTM1
FRR Stack
r6
~
,""
Perform valid resume or
retry requests, or continue
with FRR recovery.
•
I
~
RTM1
Regs
tj
iV
..... Step6
...
---.
Continue with FRR
recovery.
Interrupted
FRR
OR
Stack
...
GETMAIN
~
RTM1 Regs
RTM1
Work Area
....
Interrupted
FRR Stack
---.
l--P"
Active SDWA
/~
SETLOCK
..oil
p,,,~#=,
....-
..
,
New
SDWA
T
RTM1
Work Area
Function
Code
I
~
Retry/resume/FRR
recovery exhausted.
;
•
SameSDWA
as input
-> 6
v
RTM1
Regs
JI..
Return control to the
appropriate routine.
.....
~
•
•
Recursion.
...
Step 1
RTM1.
--.a.. To RTM1
,~IJ
~
"
6
,.
Overview
(lEAVTRTM)
I
..)
Interrupted
FRR Stack
//
~
RTM1
Work Area
Active
SDWA
Diagram 22-5. Routing to FRRs (lEAVTRTS) (part 6 of 8)
Extended Description
4
Routing to FRR processing conditionally records the
SDWA describing the error and the actions taken if:
Module
Segment
Extended Description
RECORD
When FRR recovery continues, routing FRR processing prepares to route to additional FRRs on the stack. This is called
'percolation,' and it means continue with termination. Since
the FRR stack defines a supervisor path that failed, however,
and since each FRR corresponds one-to-one with a function
in the path, the FRR executes in the same system state as the
function it protects. When an FRR must continue with termination, the FRR receiving control (to continue the termination) must clean up or request the clean up of any resources
associated with the function it protects. Because of a potential change in system state resulting from clean up, routing
FRR processing involves:
• The FRR that received control requests recording.
• No FRRs exist on the stack defining the supervisor path
that failed.
• The FRR that received control had an error while attempti ng recovery.
5
Routing to FRR processing honors valid requests from
the FRR to:
• Resume processing of the interrupted supervisor path at
the point immediately following the interruption.
• Retry the interrupted supervisor path at a point specified
by the FRR.
• Continue with FRR recovery when the FRR in control fails
to completely recover from the error.
CHKRCDE
• Locating the next FRR to receive control, in a LIFO
manner, and adjusting the stack header to indicate the next
FRR to receive control.
• Releasing any locks as specified by the FRR requesting to
continue with termination.
Routing FRR processing returns to M.O. diagram,
RTM1 Overview (lEAVTRTM), to honor resume
or retry requests, or afterall FRRs on the stack have
been exhausted.
For recursive entries where an FRR has had an error, FRR
recovery continues.
CJ'.l
g.
=
N
a::
(1)
[
o....
o
"C
a
5·
=
~
~
VI
I,Q
Segment
• Insuring that the SDWA contains valid error information.
6
(1)
(")
Module
EXIT
t
Diagram 22-5. Routing to FRRs (lEAVTRTS)
(part 7 of 8)
0\
o
o
~
~
N
tI.l
'!
5;
~n·
t"""
~
~
~
:3
(I)
Input
Register 0
(@ FRR Work Area
From module
IEAVTRTSto
handle errors
occurring during
schedule FRR
function
Process
Output
Register 1
@SDWA
SDWA
SDWA
7
Perform error retry or continue
with termination for:
~
'<
•
GETMAIN failure.
~
•
SLIP failure.
~
•
GTF tracing failure.
~
•
Software error recordi ng
failure.
tI.l
N
i
c.w
To module IEAVTRTS to retry
the function that failed, or to
RrrM to continue with
termination.
Diagram 22-5. Routing to FRRs (lEAVTRTS) (part 8 of 8)
Extended Description
Module
7
IEAVTRTR
The routing to FRR function protects itself from errors
with several FRRs. These FRRs protect against:
Segment
An FRR protects SLIP processing. The FRR retries all
errors except OAT and restart errors. Retry will occur at
the point past SLIP processing. For OAT and restart, the
FRR indicates continue with termination.
• Failures occurring in GETMAIN processing.
• Failures occurring during SLIP processing.
• Failu,res occurring while software errors are being
recorded.
RCOVSLP1, RCOVRGTF, and RCOVRCRO may set up
ABORT processing for double errors occurring in
IEAVTRTS processing. (See the M.O. diagram RTM1
Recursion Processing (I EAVTRTR), for a description of
ABORT processing.)
~
~
~
o·
=
N
a==
g
~
o
~
o
"'c:::I
;
g.
=
~
~
0'1
'"""
RCOVSLP1
RCOVGETM
SLlP2FRR
An FRR protects routing to FRRs from an error occurring
while GTF traces another FRR's actions. The FRR retries
all errors except OAT and restart errors. Retry will occur
at the point past GTF processing. For OAT and restart, the
FRR indicates continue with termination.
RCOVRGTF
The SOWA contains indicators explaining what happened
during the FRR processing.
RCOVRGTF places the following messages in the variable
recording area of the SOWA:
• Retry lEA VTRTS after GTF failure attempting to trace
SOWA returned by FRR.
• Percolate on OATERR or restart error occurring while
attempting to trace SOWA via GTF.
RCOVGETM places the following messages in the variable
recording area of the SOWA:
An FRR protects software error recording of errors being
already handled by another FRR. The FRR retries all errors
except OAT and restart errors. Retry will occur at the point
past software error recording. For OAT and restart, the
FRR indicates continue with termination.
• Percolate on OATERR or restart error occurring while
attempting to acquire SRB SOWA via GETMAIN.
Segment
This FRR receives control if the SLlP2ACT entry for
SLIP fails. This FRR frees resources obtained by SLIP,
and indicates continue with termination.
The SOWA contains indicators explaining what happened
during this FRR's processing, as follows:
• Retry IEAVTRTS after failure in GETMAIN attempting to
acquire an SRB SOWA for use by IEAVTRTS.
Module
The SOWA contains indicators explaining what happened
during the FRR processing.
• Failures occurring while GTF traces an event.
When an error occurs during GETMAIN processing while
attempting to acquire an SOWA for an unlocked SRB
mode failure, this FRR gets control if GETMAIN recovery
is unsuccessful. The FRR retries all errors except OAT
(dynamic address translation) and restart errors. Retry will
occur at the point in routing to FRRs where the local SOWA
is acquired for this SRB failure. OAT and restart errors cause
continue with termination to be requested by this FRR.
Extended Description
The SOWA contains indicators explaining what happened
during the FRR processing.
RCOVRCRO places the following messages in the variable
recording area of the SOWA:
• Retry IEAVTRTS after failure in software recording
facility attempting to record the SOWA.
• Percolate on OATERR or restart error occurring while
attempting to record the SOWA.
RCOVRCRO
~
CH
Diagram 22-6. RTMI Recursion Processing (lEAVTRTR) (Part 1 of 4)
0'1
N
From RTM1 Overview
(lEAVTRTM) to process
recursive entries into RTM1
not handled by FRRs
Process
otil
'<
til
N
til
'<
Input
•
-
Output
'I
F't~,~,!",~.,:~~.~.".",,""',,"'0:',~~~"'o:'::-:-~'0""';""';:c;b""'\-u"'o:'"2""'v>,",""·.:b,""'~;;J""':;:;"";~""'~""1h"'~"c~"":;Ji""'0t~-%(%""lj,l:o"'j:;"'»""kl"'~i-«:-~0'''''.f,.''''~,:..."
~
3
~;:;.
RTM1WA
1
C
~
~
-<
o
RT1TLPID
:3=(D
Determine whether logical phase ,recovery
can occur.
•
No, perform Abort processing.
•
Yes, perform logical phase
recovery processing.
,J:.
<:
til
N
~
Step 2
Step 3
@ error information
(D
;11:1
~
CH
~
Register 0
Entry type
Abort Processing
Register 7
@ current stack
2
Terminate RTM1 processing.
•
Clean up the FRR stack.
•
Free locks.
•
Exit to dispatcher or SRB
dispatcher.
To dispatcher or SRB
dispatcher (lEAVEDSO)
Diagram 22-6. RTMI Recursion Processing (IEAVTRTR)
Extended Description
In certain paths through RTM1 processing, recursions cannot
be processed by FRRs (functional recovery routines). For
example, the phase of the module that actually routes control to FRRs (module IEAVTRTS) cannot be protected by
an FRR - if this phase does not work, it cannot route to an
FRR to protect itself. To handle these situations where
certain phases cannot be protected with an FRR, RTM1 uses
LPRRs (logical phase recovery routines). To use LPRRs,
RTM1 tracks its processing. The tracking information consists of two items:
• An LPID - a logical phase 10 that identifies the LPRR
that can process the recursion.
• An LPN - a logical phase number that identifies the phase
of RTM1's processing in control at the time of the error.
Recursion processing routes control to the LPRR identified
by the LPID.
til
~
~
c·
=
~
:::
i
Q
o'""'
"0
S
5=
t-
w
0\
W
(pad 2
Module
of 4)
Segment
Extended Description
Module
1
IEAVTRTR RECVRRTM
After an RTM1 process, IEAVTRTM has discovered
a recursive condition, control goes to the recursion
processing routine. Recursion processing first determines
whether a logical phase identifier exists, by checking the
RT1TLPID field of the RTM1WA. Any time an RTM1
logical phase uses an LPRR for recovery, it sets the
RT1TLPID to a non-zero number. The recursion processing
routine gives control to the correct LPRR if it finds a nonzero number in the field. If it finds a zero, this means that
no specific LPRR exists, and the Abort LPRR must receive
control .
2
The Abort processing routine handles recursions by
performing clean up processing. Abort processing
releases any locks and resets any FRR stack pointer values.
In general, Abort processing removes any traces of the
original error. Control goes to either the dispatcher or the
SRB dispatcher, depending on the mode at the time of error.
Segment
ABORT
t
Diagram 22-6. RTMI Recursion Processing (lEAVTRTR)
(part 3 of 4)
~
~
<
en
en
N
I
Low Level Processing
~f)'
RTM1WA
" 3
"
r
r-
RT1TLPN
~
a
(D
~
'
3
Put EED address in ASXB
(SSRB).
Interrupt
psw
OR
I
-
J
.'
4
Put completion code/flags in
ASXB (SSR B).
lJl
-
, Icompr
IHSA (SSRB)
!L
.
I~
~
r
~
EED
Code
r
,
t
j
.....
SVC 13
an S~ B
routine
!!
r-r-
Interru
Registers
r-
L
~
I
_
pt
Interrupt
PSW
-
-
SSRB
Used in
}
rescheduling
---..
""'-"'"
_
....J
5
Alter resume
psw.
I
-I
h
To RTM1 Overview
(IEAVTRTM)
Resume PSW
I
-
I
~I
Y
-
-
Diagram 22-9. Reschedule Locally Locked Task or SRB (lEAVTRTM) (part 2 of 2)
Extended Description
Module
Segment
When an error occurs during page fault processing for a
locally locked task (or SRB routine) RTM1 sets the task
to be redispatched from the IHSA (or the SSRB) with
an SVC 13 instruction as the first instruction to be
executed. When the SVC IH subsequently becomes dispatched, it will issue a "CALLRTM TYPE=SVCERR"
macro instruction since it would appear that an ineligible
routine (Le. locked task or SRB routine) has issued an
SVC.
1
2
RTM1 zeroes the EED and sets the 1.0. field to
indicate a register type.
The registers and PSW in the IHSA for a task
(I HSAGPRS and I HSACPSW and in the SSRB
for an SRB - SSRBGPRS and SSRBCPSW) stored at the
time the task (or the SRB) was pre-empted by the page
fault are preserved in the EED.
r.Il
~
o·~::I
~
~
~
g
Q.
o
~
o
"0
io·
::I
~
W
-..I
~
IEAVTRTM SCHDRTM1
SCHDRTM1
Extended Description
Module
Segment
3
RTM1 alters register 0 in the IHSAGPRS (or
SSRBGPRS for SRBs) field to point to the EED
(this becomes input to the RTM1 upon re-entry).
SCHDRTM1
4
RTM1 places the completion code and options flags
in the register 1 slot in the I HSAGPRS (or
SSRBGPRS for SRBs) field.
SCHDRTM1
5
SCHDRTM1
RTM1 alters the I HSACPSW (or SSRBCPSW for
SRBs) field to point an SVC 13 instruction within
the RTM's module (this technique allows the RTM1 to
uniquely identify the re-entry as a reschedule function as
opposed to another routine issuing the ABEND macro
instruction),
~
W
'-I
Diagram 22-10. RTMI Clean-up Processing (lEAVTRTM) (part 1 of 2)
~
From RTM 1 Overview
(lEAVTRTM) to
clean up resources used
by RTM1 processing.
ofJ'J
~
N
Input
II ..
fJ'J
'<
~
o
Process
JijEH"'~~~~iIJ5iiiiiD
ut
('D
a.
RTM1
E
t)'
t-
~
~
i
('D
~
~N
::tl
('D
i
~
w
~
RTM1WA
D
,RTM1WA
o
Free RTM 1 resources:
•
EEDs.
•
LocksacquiredbyRTM1.
•
SDWA.
•
Program check recursion
indicators.
•
RTM1 recursion indicators.
IEAVEEXP
2
Free the failing system
routine's locks.
Exit Prolog
RTM1 Regs
,
3
Determine the type of exit .
...
TO.RTM1
...
.
EXIt
Processing
(lEAVTRT1)
Diagram 22-10. RTMI Clean-up Processing (IEAVTRTM) (part 2 of 2)
Extended Description
Module
Segment
This illustrates the functions performed by RTM1 during
clean-up processing.
1
The clean-up processing frees any locks, EEO"s or an
SOWA acquired during the RTM1 processing, which
are no longer needed.
IEAVTRTM SYSCLEAN
2
,Clean-up frees all locks currently held by the failing
routine. Exit Prologue (EP Name=IEAVFRLK) performs this fl,lnction.
3
Recursion indicators in the RTM1WA or the current
FRR are deleted. Control is returned to the entry
point/exit point processor with an indication of the type
of exit to effect.
til
(D
a5·
=
~
a=
~
~
....
o
o
1o·
=
~
~
v:
EXIT
t...,
Diagram 22-11. RTMI Exit Processing (IEAVTRT1) (part 1 of 2)
Q\
o
t:Il
"<
From RTM1 Overview
(lEAVTRTM)
to exit.
Input
P.rocess
t:Il
N
t:Il
1
;
RTM 1 Work Reg
~(i;'
Exit Type
Indicator
~
,...
.,.>1
Determine type of exit.
RTM1WA
~
~
o<
c
a
(D
Retry
,...
Registers
Y
.a:o.
0-14
'
,...
@
.,.
CVT
if
a) On exit type=retry, exit to
retry routine that contains
the address to come back to
for retry.
b) On exit type=dispatcher,
go to dispatcher
(lEAVEDSO).
~
w
+ Dispatcher
+SRB Exit
+ Exit Prolog
~
")
.,.
'")
LCAA
LocS
Restart
Restart
Regs
v
OPSW
MCH Parms
I
MCH RegS/A
I
I I
. type=SRB, go to
cl On eXIt
SRB Exit (tEAVEDSO).
d) On exit type=EXIT
PROLOGUE, go to Exit
Prolog (tEAVEEXP)..
"') e) On exittype=RESTART
v
RESUME to the RESTART
OLD PSW, resume
Interrupted Process.
") f) On exit type=MCHEXIT,
v
exit to MCH (tEAVTRTM).
Caller's Reg Save Area
I
I
">
v
g) On exit type=RETEXIT,
return to caller (issuer of
the CALLRTM macro).
-
To items
indicated
in 1 a-g
Diagram 22-11. RTMI Exit Processing (IEAVTRT1) (part 2 of 2)
Extended Description
Module
Segment
IEAVTRT1
IEAVTRTZ
RTM1 routines exit from a common exit routine within
module lEA VTRT1.
1
RTM1 exit processing uses the exit type determined
by the module lEA VTRTM to perform the appropriate exit procedure, as follows:
a. Exit processing loads registers 0 through 15 from the
RTM1 work area. Register 15 will now contain the
retry address. Finally a branch on register 15 is executed.
~
a
(5'
::I
~
a:
a
8:o
o
'e
Io·
::I
-ttoN
-...I
-...I
b. The dispatcher's exit point is placed in register 15 from
the CVTODS field of the CVT. A branch on register 15
is executed.
RT1EXIT2
c. The SRB exit point is placed in register 15 from the
CVTSRBRT field of the CVT. A BR 15 instruction is
executed.
RT1EXIT4
d. Register 15 is loaded with the contents of the CVTEXPRO
field in the CVT. This points to the exit prolog routine,
via a SR 15 instruction.
RT1EXIT6
e. Registers 0-15 are loaded from the restart save area
(LCCARSGR). A LPSW instruction is issued to cause the
restart old PSW to be loaded.
RT1EXIT8
f. A pointer to the interrupt PSW and registers is placed in
the MCH parameter list. Register 2-0 (all but Register 1)
are reloaded from the MCH save area. A branch on
register 14 is executed.
RT1EXITC
g. Registers 0-14 are reloaded from the register save area
and a branch on register 14 is executed.
RT1EXITE
f'
~
.....
00
Diagram 22-12. RTM2 Overview (IEAVTRT2) (Part 1 of 4)
From the SVC IH (lEAVESVC)
to perform SVC 13
(ABEND) processing.
oen
"( c
SDWA
I
I
~
to'
Locate the correct RB.
~~B
RTM2WA
Modify the RB queue.
Update the SDWA.
To RTM2
Overview
(lEAVTRT2)
RTM2RETR
'1 '
J.
B. Continue with termination
•
Permit a change of the
completion code.
•
•
Free the SDWA.
•
Return to step 1 to
process remaining exits.
RTM2WA
C>@~B
'~
RTM2WA
J,.
D
D
I
A. Retry
~'"
---
SDWA
SDWA
Retry or continue with termin~tion,
according to the requested action.
SCB
J~4('
,V
~
~
Output
~
•
•
•
RTM2WA
,
II"
;
Indicate continue with
termination.
f
..... Step 1
,.
Diagram 22-16. Recover Task Processing (ffiAVTAS1) (part 4 of 4)
Extended Description
Module
Segment
5A
IEAVTAS3
FINDRB
If retry can be performed (this is not term exit
processing), RTM2 selects a retry RB. For
STAE/ESTAE retry, the SCB contains the RB address.
For ESTAR retry, RTM2 uses the oldest RB. For
STAI/ESTAI, RTM2 performs retry under the PRB for
the last STAE/ESTAE or STAI/ESTAI exit routine if one
exists. Otherwise, RTM2 purges the RB queue until only
PRBs remain and the STAI/ESTAI retry routine will run
under the newest PRB left on the queue.
RTM2 prepares the RB queue for retry. Resources are
purged and open, embedded data sets are closed. RBs
to be purged (those between the retry RB and the
ABEND SVRB) have their resume PSW pointed to EXIT
and their wait count zeroed. If register update was
requested on the retry, the retry register values are
inserted to ensure that the correct registers are passed to
the retrying RB. If register update was not requested,
RTM2 initializes error registers to be passed to the
retry RB. In either case, if a dump is also requested on
the retry, the register and PSW fields in the dump will
contain the retry information rather than the values at
entry to ABEND. The registers and PSW at entry to
ABEND can still be found in the RTM2 work area.
This work area resides in LSQA and is pointed to by
the TCBRTWA field of the TCB.
RBPRGE
RTRYSDWA
According to the user's request, RTM2 either updates the
SDWA to be passed to the retry routine, or frees it. Task
Recovery returns control to RTM for further preparation
for retry.
tf.)
~
~
g.
=
t-J
:::
~
g
Q.
o
-.
o
"0
~
;
g.
=
~
t..I
IC
58
RTM2 saves information to be passed to the next
exit during percolation (changed completion code
or a serviceability indicator) in the RTM2 work area and
frees the SDWA. In addition, RTM2 initializes percolation
information in the RTM2 work area.
IEAVTAS3
SCBPERC
~
CN
Diagram 22-17. ABDUMP Processing (IEAVTABD) (part 1 of 4)
\0
t-.)
S5
~
From RTM2
Overview (IEAVTRT2)
to display storage
Input
o
Process
t-.)
til
1
a
t"'-
Input (From RTM2)
RTM2WA
RTM2DPWA
RTM2DPPL
~
C;.
~
~
~
Storage List
~
'
~~
II
o
w
00
~
successful completion.
4 - DCB not opened, undefined page reference on DCB.
8 - TCa not valid, undefined page reference on TCB,
insufficient storage, invalid parameter list, a subtask is
a jobstep TCB. read for JFCB or JFCBE failed and
the dump was canceled.
12 - DCB type incorrect, DCB incompatabilities with
options specified on dump related DO statement.
9
Close dump data set, free DCB storage, turn off the
dumped flag indicator (TCBFS=O) if an ABEND was
in progress, dequeue from dump data set, and set subtasks
dispatchable if an ABEND was in progress.
ADCLEAN
+
~
Diagram 22-18. Synchronize Failing Tasks (IEAVTRTC) (Part 1 of 2)
I,Q
0'1
From RTM2 Overview
(I EA VTRT2) to
synchronize failing tasks.
o
CI)
~
~
CI)
'<
~
t"'"
~
o·
t"'"
&
0--RTM2WA
3
~
~
<
----
-1
•
•
~
=
:3
(lI
~
~
o
~
Determine whether this is a cancel
request or an unrecovered task.
TCB
r-
;>... 2
~TCB
,
Unrecoverable task.
"
~
IEAVWAIT
•
TCBABWF
-
y
1CBFMW
II..
...
TCB
TCBFA
TCB
Step 2
11..
~
~~
Step 3
...
Wait for all subtasks of the failing
task in RTM2 processing to
complete.
~
00
o
...
Cancel request.
-"
...
,
Go to step 3.
WAIT
TCB
Step 3
I
3
r-
Stop subtasks of the task from
any further processing.
..
,
TCB Family Queue
'"
IEAVSETS
v
TCBABWF
I
STATUS
I
~
~- ~ 4
...
.. 5
....
'" TCB
I nd icate that a II the subtasks are
non -recoverable.
v
TCBFA
Purge resources for the tasks.
•
I/O.
•
Partially loaded programs.
II..
~
,
~
,
.
,
SVC 16
IEAPPGMA
....
...
•
Paging I/O.
,
~
....
IEAPTERM
I
Diagram 22-18. Synchronize Failing Tasks (IEAVTRTC) (part 2 of 2)
Extended Description
Module
Segment
RTM2 allows subtasks undergoing RTM2 processing
indicated by the TCBRTM2 field to complete. Note
that for unrecoverable tasks, control will go to step 3,
and the tasks will be set non-dispatchable.
RTCSTACK
RTM2 waits for all the tasks in RTM2 to complete processing before terminating them (except for CANCEL
requests). RTM2 stops all the tasks in the failing task's
TCB family queue from any processing, including
asynchronous exit processing. This prevents any additional
termination requests for this TCB family queue. Then,
RTM2 gives control to special purging routines (not the
resource managers described in M.O. diagram Address
Space Purge Processing (lEAVTMMT)) to clean up task
3
RTCCSUB
RTM2 synchronizes failing tasks for one of two
reasons: there has been a CANCEL request from
the system or operator; or the task cannot be recovered
(M.O. diagram Recover Task Processing (lEAVTAS1)
shows recovery processing). RTM2 checks the completion
code of the task, in RTM2CC, for a X'n22' value, with
the n being any alphanumeric value, and with the last
2 characters being "22." This completion code indicates
a CANCEL. For CANCEL requests, RTM2 performs
steps 3,4, and 5, in that order. For unrecovered tasks,
RTM2 performs steps 2, 3,4 and 5, in that order.
A cancel request must come through RTM1 using the
CALLRTM macro.
g.
=
N
::
~
g
Q.
o
....
o
"0
~
ic)"
=
~
w
'"
-...I
Segment
2
1
C"'-l
Module
RTM2 synchronizes the termination of tasks in a TCB
family queue to allow all the tasks to receive termination
processing. RTM2 allows these subtasks to terminate and
to have storage displays. This aids in debugging.
RTM2 stops any further processing of the subtasks by
giving control to the STATUS routine, with the
request to make the subtasks non-dispatchable. The subtasks will be made dispatchable to finish RTM2 processing.
Note that except for cancel requests, the subtasks will be
allowed to finish RTM2 processing first.
4
RTM2 sets the TCBFA field in each TCB of the TCB
family queue to indicate that these tasks cannot be
recovered.
resources.
~
('l
Extended Description
IEAVTRTC RTCTLRCR
5
RTM2 now performs initial purging of some of the
tasks' resources to prevent any contention for system
resources. For example, a task set non-dispatchable while
performing a FETCH request would not complete loading
the requested program. No new FETCH requests would be
honored. Also, no other tasks could use that requested
program either. Therefore, the RTM2 calls the partially
loaded program purge routine to purge such resources. The
same example would hold for I/O operations and paging
I/O operations also. For non-CANCEL requests, control
goes to M.O. diagram RTM2 Overview (lEAVTRT2).
RTCINPRG
...
\N
Diagram 22-19. Task Purge Processing (lEAVTSKT) (part 1 of 4)
\0
00
From RTM2 Overview
(lEAVTRT2) to process
task resource purges
oC"Il
~
N
Input
Output
C"Il
'<
Register 1
~
~(i.
RTM2WA
It
r
t:':
~
.$
<:
o
2"
:3
(D
~
'<
C"Il
N
::0
(D
i
~
Flags
•
.t
@TCB
I'
1 TCB
~
ASCB
~.
J
•
Step must complete.
Resume
processing
after
recursion
Selected TCB
TCBFBYT1
•
Subtasks exist.
Register 0
~
TCBPGNL~
TCBFLGS5
TCBLTC
r-oI
TCBABWF~
TCBNDSP1
~
1
1
Register 14
1 Return @ I
Register 15
IEntrypt @I
Register 7
TCBDART~ 1+
ASXB
J
ASXBTCBS
-
Flags
r
ASCBASXB
Yes
Check conditions for
normal termination.
@ASCB
t
\N
~
Determine whether this
is a recursive entry.
( @RTM2WA
J
J
-Flags
TCBFJMC - Must
Complete
CSECT, lEA VTR MC
TCBECB
ASCB
-0--
r-I
RTM2WA
Resource
Manager
Save Area
Set the correct sequence
for abnormal processing.
First
{
Sample Task Structure}
Showing First Two
Tasks To Be Selected
Diagram 22·19. Task Purge Processing (IEAVTSKT) (part 20f4)
Extended Description
Module
For a normally terminating task, task purge processing checks the terminating task for "step must
complete" status, for open data sets, and for existing
subtasks.
• For tasks having "step must complete" status, terminate
with an E03 ABEND code.
Task purge processing will remove the resources of the
lowest task in the TCB family queue first, and then ascend
the queue to the current task, removing their resources.
• If subtasks exist, task purge processing terminates the
task being terminated with an X'A03' ABEND code.
RTM2 will then regain control as a result of the SVC 13
instruction issued,to terminate the task.
Task purge processing receives control from the mainline
RTM2 routine, IEAVTRTE, shown as M.a. diagram
RTM2 Overview (I EA VTRT2). Input for task purge
processing comes from M.a.-diagram RTM2 Initialization
(lEAVTRT2) which shows the creation and initialization
of the RTM2WA.
Task purge processing performs recursion processing.
as described in M.a. diagram Recursion Processor 1
(IEAVTRT2) .
The RTM2TRRA field contains the addresses of routines
that handle recursions for processes in steps 3, 4, and 5.
• If a CANCEL recursion occurs for step 3, restart step 3
by selecting the lowest task in the family and detaching
it. For any other type of recursion, terminate the
address space.
• If a subsystem resource managerfails, skip the failing
subsystem resource manager on a recursive entry. If
more than 2 failures occur, skip all the subsystem
resource managers, and go to step 5.
rIl
a
15'
::s
~
a::
~
0-
o
~
o
."
i15·
::s
~
~
IQ
• If an IBM-defined resource manager fails, skip it on any
recursive entries and continue processing the others.
Extended Description
2
Task purge processing removes the resources used by a task.
RTM2 uses the task purge processing function to route
control sequentially to installation-defined and IBM-defined
resource manager routines to remove their task related
resources.
1
Segment
3
IEAVTSKT
The terminating task may have active subtasks. In
this case, task purge processing follows down the
TCBlTC chain until it finds the lowest TCB (as indicated
by a 0 in TCBlTCL Task purge processing then issues a
DETACH (see the Task Management section for a description of DETACH processing) for that TCB, with an indicator to perform termination purging. DETACH will
terminate the task if it is still active. Task purge processing detaches all the subtasks, and then purges the
resources for the current task.
Module
Segment
~
Diagram 22-19. Task Purge Processing (IEAVTSKT) (part 3 of 4)
o
o
rIl
~
~
rIl
...
Input
Register 1
@RTM2WA
.~
~
ij=
'-"'<
,
~
(D
~
@ASCB
~. ~
' 1 in the ASCB). Address space purge processing does not free the address space if:
• ASID = 0 - system wait task
• ASID = 1 - master scheduler
Address space purge processing clears the EST AE routine,
and gives control to the caller (module IEAVTRTE).
Module
Segment
IEAVTSDR
IEAVTRTl1
IEAVEN02
IFGOTCOA
ISTRAMA2
IEDOOT01
IEDAY8
IEAVMED2
IEFJRECM
IEFIRECM
IEFAS4E5
IEARPOST
IEAVGFAS
IEAVELKO
OLTOA
ICB2AIR
IEAVTMRM
IEAVTPMT
IEAVEMDL
-<
til
N
o
t..)
00
S
t
o
Diagram 22-22. Address Space Purge Resource Managers (lEAVTMMT) (Part 1 of 10)
From Address Space Purge
Processing (I EA VTMMT) to
clean up address space-related
resources when
an address space terminates
o
CJ':)
"<
CJ':)
~
CJ':)
'<
~
Input
3
r-
~
(5'
t::
~
.$
o<
C
3(1)
RMPL
D
..
Process
Output
.....
v
1
Clean address space-related
resources for IBM resources when
an address space terminates.
RTCT
A)
Clean SVC dump resources.
~
•
~
c
~
/'\.
Zero SVC dump request
fields in the RTCT.
y
~
00
Q
,::J
TOE
B)
Clean timer resources.
•
Free TOEs and trmer
SRBs.
Joy
D
TimerSRB
D D
OCB
C)
Clean ENO resources.
•
Free OCBs and OELs.
Jo..
y
OEL
D D
I\~essage
•
Print messages.
:[::J
"name, name FAILED IN 'STEP MUST
COMPLETE'STATUS"
6
"RESOURCE NAMED, name, name
MAY BE DAMAGED"
"FAILED IN 'STEP MUST COMPLETE
DUE TO abend code"
Diagram 22-22. Address Space Purge Resource Managers (IEAVTMMT)
Extended Description
Module
The IBM-defined address space clean up resource managers
free any resources held by an address space during processing. The address space purge processing routine, module
IEAVTMMT, routes control to these resource managers
after establishing an interface. Control goes to each address
space resource manager sequentially until all of them have
performed their clean up processing.
1
The address space purge routine routes control to
each of the IBM-defined resource managers. After one
resource manager completes its processing, control returns
to the address space purge routine, which routes control
to the next resource manager. This continues until all the
resource managers have performed clean up.
IEAVTMMT
A. The SVC dump resource ma'nager issues·ST ATUS to
set the system di~patchable if a dump Was in progress
in the failing address space.
IEAVTsDR
The address space purge routine sets supervisor
trace active.
rn
..
Free SRBs associated
with any "cross-memory"
requests.
y
~
,
~
a
RTM2WA
I
r-'
~
C:;.
RTM2FLX
r-'
c;:
~
<
~
9CD
~
'<
RTM2RTRX
RTM2EOTX
RTM2ABX
RTM2MTR
y
:;
~,;
~:
-
RTM2LTX
p
f'-l
N
-
RTM2PRX
:;0
-
CD
i
~
-
RTM2DWX
RTM2CVX
j'
(oN
~
-
r---
Retry
Normal EOT
Abnormal EOT
Address space
termination
Termination of
last task
Termination of
a permanent
task
Subtask waiting
Convert-tostep
V'"
-
-
;""-1
i
t
RB
RB
TCB
I- -
o
p
-V
t...)
IJ
!....,
t...
A
,
y
2
Exit accordi ng to the indicator set
in the RTM2F LX field:
•
Retry.
•
Normal EOT.
•
Abnormal EOT.
•
Address space termination.
•
•
•
•
Last task.
.
Step 2
r
...
Step 3
r
...
Step 3
r
...
Step 4
"
...
Step 5
r
...
Permanent task.
.. Step 6
...
Subtask waiting.
Step 7
r
...
Convert-to-step.
Step 8
r
TCB
Process retry operation by freei ng
the RTM2WA, setting appropriate
fields, and releasing locks.
.;,.
...
.
r
...
RTM2WA
D
i~
~~
~~i"">0~
'"
:~
IEAVELK
SETLOCK
i~
...
,.
;)
...
i~
i
...
!
IEAVSETS
STATUS
..
IEAVEEXP
P
To Dispatcher
(lEAVEDSO)
-
If
'--
..
...
Exit Prolog
y
~
Diagram 22-23. RTM2 Exit Processing (lEAVTRTE) (part 2 of 6)
Extended Description
Module
Segment
RTM2 exits to either exit prolog or STATUS (see the
M.O. diagrams for Exit Prolog and STATUS for a description of their processing), depending on the settings of the
RTM2FLX field of the RTM2WA, after task termination
or address space termination.
1
2
Exit processing determines the type of exit.
The current RTM2WA is freed; the TCB flags are
cleared if no RTM2 SVRBs will remain on the RB
queue after retry; and the registers that will not be altered
by Exit (15,0,1) are reloaded from the SVRB. Then
control is passed to the Exit prolog.
til
ito·
:=
~
a::
a
5
Q.
o
~
o
"0
S
g.
:=
of?"
~
~
IEAVTRTE
RTECMEX
RTEFREWA
t
Diagram 22-23. RTM2 Exit Processing (lEAVTRTE) (part 3 of 6)
N
N
oCI'.!
"<
CI'.!
N
CI'.!
'<
~
§
i
,
I~ ~
.
3
~:
~.
;,
.
l""'
Process normal and abnormal
EOT operations by freeing the
RTM2WA, setting appropriate
fields, and releasing' locks.
~
~
~
El(1)
TQ Dispatcher
(JEAVEDSO)
.~
~
CI'.!
N
..
.
""...
\
,L
. -") 4
~
~
..
(1)
i
Process address space termination
requests by freeing the
RTM2WA, setting appropriate
fields, and releasing locks.
..
""...
IEAVEEXP
Exit Prolog
.
...
"-)(
...
IEAVELK
"
SETLOCK
CN
~
to..
To Dispatcher
(lEAVEDSO)
Via
.,~
\
,
,,~
"') 5
..
..L
"
...
CALLRTM
Process the last task in an
address space.
...
..
...
...
To Dispatcher
(lEAVEDSO)
...
...
)(
IEAVELK
\;1
...
rIl
y
SET LOCK
..
~
e-
'<
ml
IEAVEEXP
Exit Prolog
IEAVTMTC
Address Space
Termination
..
IEAVSETS
"
STATUS
,
Diagram 22-23. RTM2 Exit Processing (IEAVTRTE) (part 40(6)
Extended Description
Module
Segment
3
The TCBEOT flag is set to indicate all RTM2 processing is complete for this task. All RTM2 work areas
are freed, and control is passed to the Exit prolog.
4
5
The RTM2WA is freed and control is passed to the
Exit prolog.
The memory is terminated using CALLRTM
TVPE=MEMTERM. The current task is set nondispatchable to await completion of memory termination.
I:Il
a
5·
=
!'!
a:
sa-
g:
~
o
'tS
a5·~
=
~
~
N
1M
RTELTEX
~
J:.
Diagram 22-23. RTM2 Exit Processing (lEAVTRTE) (part 5 of 6)
~
~
~
~
~
til
~,
Process
Input
Output
l
~
Ar
r""
Ii
n·
1'...)
6
'" TCB
Process a fai ling resident task.
..
'"
r""
a=
L
!<
...-
TI
..
-,.
~
a
To Dispatcher
(lEAVEDSO)
(D
~
TCB
'<
I
til
~
:=
TCBAECB
i
r----
- ---
-- 7
..L
Pos~ the waiting subtask,
...
-,.
..L
w
..
.,..
~
Tca
To Dispatcher
(lEAVEDSO)
Jobstep
.... TCB
....
) 8
'"
I
TCBECB
ECB for EOT
... I
",.,
TCB
")
IEAVSY50
'"
/'
~
TCBAECB
ECB
I
IEAVSETS
1
Jobstep
TCB
TCB
)
...
,..
....
I
I
,.
)I
....
Process oonvert-to-step
operations.
TCBDARNP
STATUS
...-
~
RTM2WA
IEAVSETS
POST
...-
~
POST
STATUS
...-
free RTM2WA, and set
the task as non-dispatchable.
~
t::s
... 1 IEAVSY50
'"
IEAVTRTM
I-
RTM1
iMTNA
To Exit Prolog
(lEAVEEXP)
I
I
Diagram 22-23, RTM2 Exit Processing (IEAVTRTE) (Part 6 of 6)
Extended Description
Module
Segment
6
When a resident. (assembled in) task ends, normal
processing (which includes freeing the TCB) is impossible. The end-of-task ECB is posted to indicate completion,
and the task is set permanently non-dispatchable using
TCBDARPN.
7
The ECB that the subtask is waiting for (located by
TCBAECB) is posted. The jobstep task sets itself
non-dispatchable to await ABTERM. RTM2 will be
entered from the top for the STEP ABEND. This is not
rGgarded as a recursive entry.
RTESWEX
8
RTECONV
RTECNVEX
The current RTM2WA is queued to the jobstep TCB.
Then the jobstep task is abnormally terminated with
a 200 completion code. The subtask terminates by branching to the exit prolog. If the jobstep TCB is already in
RTM2 processing it may be nec~ssary to wait for it to
complete critical processing before terminating it.
~
(D
a5·
=
!':J
ac:
sa.
[
~
o
."
a
5'
=
•~
~
(,A
~
4:loo
Diagram 22-24. Address Space Termination Processing (lEAVTMTC) (Part 1 of 4)
N
0\
oC"I'l
~
N
C"I'l
'<
=-
From RTM1, via a posted ECB,
to terminate an address space
t
Process
..".
CVT
ECB
~
E
;;.
Outout
CVTRTMCT
t"""
1
~
"
Reset the address space termination
ECB.
v
0
10
I
RTCT
~
.5
CVTABEND
") 2
~
[
(1:1
SCVT
@Address
Sp• ."Term.
Queue
(
4:loo
~N
oc.u
00
~
v
Dequeue the ASCBs representing the
address space to be terminated.
~
N
ASCB
3
ASCB
r--... ASCB
•
•
4
Set address space
non-
-..J
Diagram 22-25. STAE/ESTAE Processing (IEAVSTAO) (part 2of6)
Extended Description
Module
The STAE/EST AE routine creates and, initializes an SCB
(STAE control block) to represent an abnormal interruption exit routine. The STAE/ESTAE routine can
create, cancel, propagate, or overlay an SCB, according
to the action codes passed as input. The ST AE routine
receives control from the SVC IH or via branch entry.
Control returns to the caller.
IEAVTSIN
1
IEAVSTAO
The STAE/ESTAE routine validates both branch
entered and SVC entered requests. ESTAE abnormally terminates invalid callers, passing a X'13C' ABEND
code to the ABEND routine. The value in register 15
explicitly states the reason for the termination. STAE
processing does not terminate callers requesting STAE,
STAI, or SVC-entered ESTAE.
2
The STAE/ESTAE routine obtains a work area
from the FREESCB queue for branch entries or
uses an area in the STAE/ESTAE SVRB for SVC
entries. If the FREESCB queue is full, a GETMAIN
is issued for four cells from subpool 255 and added to
the FREESCB queue.
CI:l
(I)
("l
g.
=
~
s::
(I)
g
(:l.
o
.....
o
't:S
~
~
g.
=
~
~
w
Segment
Extended Description
3
Module
Segment
The STAE/ESTAE routine performs requested
service, as indicated in register O.
• For create requests, the ST AE/ESTAE routine
obtains a cell for an SCB. The newly created SCB is
chained in the SCB queue, pointed to by the
appropriate TCB. STAE/ESTAE indicates the caller
owns the SCB by setting an indicator in the RBSCB
field of the caller's RB.
For STAI or ESTAI requests, STAE/ESTAE also
propagates the STAI or ESTAI SCBs via propagate
processing.
.For cancel requests, the STAE/ESTAE routine .
dequeues the SCB from the specified TCB, returns
the cell to the FREESCB queue, and zeroes the
RBSCB indicator in the caller's RB if the caller
does not own any more SCBs.
• For overlay requests, the STAE/ESTAE routine initializes the existing SCB with the new values.
• For propagate requests, the STAE/ESTAE routine
obtains cells, copies the SCB information from the
appropriate SCB (addressed by the TCB pointed to
in register 4), and chains the SCB to the TCB being
attached.
~
N
<=>
~
00
S
t
Diagram 22-25. STAE/ESTAE Processing (IEAVSTAO) (Part 30f6)
!oN
~
i
~
~
o
Process
ut
ell
'<
f4.
(11
:3
£c=r
t""
f
~
~
~
(11
~
~
~
S
00
§
Register 15
4
Return control the caller.
Return Code
ESTAE/ESTAI/ESTAR
To Caller
(Branch
entry or
Exit
Prolog
(lEAVEEXP)
'00' - Successful STA or ESTA request.
'04' - ESTAE OV has been requested and the
last SCB is:
1. Non-existant,
2. Not-owned by user's RB or
3. Is not an ESTAE exit
In this instance an ESTAE Create will
be performed.
'oc' - Invalid cancel request.
'10' - Unexpected error.
'14' - Insufficient storage.
STAE/STAI
'00'- Successful ST A or EST A request.
'04' - Insufficient storage.
'00' - STAE issued in a STAE exit or
- cancel or overlay request with no SCB
onO.
'oc' - ST A ~ not issued by attach or
- STAI request with missing TCB operand.
'10' - Cancel or overlay and SCB is not a STAE
SCB or is not owned by requestor's RB or
- Unexpected error encountered while
processing the request.
~
~
b
00
!oN
S
Diagram 22-25. STAE/ESTAE Processing (IEAYSTAO) (Part 4 of6)
Extended Description
Module
Segment
4
STAE/ESTAE returns control to the oaller, with
return codes indicating the results of the request in
register 15.
~
N
(:)
W
00
S
Cf.l
~
II
0"
=
N
a=
~
g
Q.
o
....
o
"0
~
~
o·
=
~
J:.
w
w
~
~
Diagram 22-25. STAE/ESTAE Processing (lEAVSTAO) (Part 5 of6)
w
From R/TM end-of-task
processing (I EAVTSKT)
orXCTL
to clean
Process
SCB
~
~
"<
V}
Input
~
Output
V}
~
~
3
~
~
n·
Register 0
o or @ RB
issuing
EXIT or XCTL
~
~
IEAVTSBP
-<
5
~
<:
o
=
3
~
Purge SCB s from the SCB
queue for:
•
•
RB
~
'<
N
o
Register 15
Return Code
End -of-task.
7
XCT L req uests.
~
Return Cells
to
FREESCBQ
0- Successful
4 - Error occurred.
V}
Transfer SCB for an XCTL
request, if eligible.
W
00
o
~
Reg!ster 4
To R/TM
(lEAVTSKT)
orXCTL
@TCB
SCB queue mod ified to
delete SCBs.
Output for step 2 shows
SCB queue.
TCB
From R/TM
(lEAVTRTS)
Register 15
.SDWA
D
6
Recover from any error.
•
Continue with termination.
•
Retry.
To R/TM
(lEAVTRTS)
Return Code
4 - Error occurred.
I
<
V}
N
0w
00
~
-.....I
Diagram 22-25. STAE/ESTAE Processing (lEA VST AO) (Part 6 of 6)
Extended Description
Module
Segment
Extended Description
Module
Segment
5
IEAVTSBP
TRMPROCS
6
IEAVTSBP
TRRMFRR
TRMFREE
• Continue with termination for memory switch conditions.
The SCB task recovery resource manager (TRRM)
removes or transfers an SCB to another RB as follows:
• RBs issuing EXIT have their SCBs purged.
• RBs issuing XCTL have their SCBs transferred or
purged. The SCBs will be transferred if the caller issued
the XCTL with the YES option.
• For end-of-task requests, or if an ATTACH request fails,
the TRRM purges the entire SCB QUEUE. The TRRM
purges SCBs by returning the SCBs created by ESTAE/
STAE processing to the FREESCBQ. The TRRM purges
SCBs created by BRANCH entries by zeroing the SCB
field in the SVRB. TRRM dequeues the SCBs from the
SCB queue. (See the output from step 2, which shows
the SCB queue.) Finally, the TRRM sets the RB indicator to indicate that no SCB is'owned.
til
(tI
s:.
5'
=
N
a:
(tI
g
c:;l.
o-.
o
"0
~
I\)
g.
=
~
~
~
VI
The FRR attempts to recover from any errors that
occur in the TR RM. It performs recovery as follows:
• Zero the SCB queue pointer in the TC~ if the caller
requested a purge of all SeBs of the task.
• For storage key failures and storage data checks, the
FRR scans the queue for an SCB within the range indicated in the SDWA .. If an FRR. is found within the range,
the FRR zeroes the queue pointer in the TCB.
• Dequeues all seBs owned by RBs for RB EXIT and XCTL
requests when no SeBs fall within the range indicated
in the SDWA.
For retry requests, the F RR returns to the caller, with
a return code of 4 in register 15.
-<
til
N
o
~
00
S
t
w
Diagram 22-26. Alternate CPU Recovery (ACR) Overview (lEAVT ACR) (Part I of 4)
0'\
F rom the externa I
interruption handler
after a failing CPU issues
EMS or MFA to signal
its immanent failure.
o(I.)
~
~
(I.)
'<
Input
Output
,-process
~
2
3
t"""
Failing CPU's Control Blocks
Register 1
it=;.
PSA
'" 1
t"""
§=
Of
~
MCH
LOGREC
Buffer
<:
o
3(D=-
"
~
§
D
External SLiH
(lEAVEES)
or
(lEAVEEXT)
~
00
PSA
Logical
Data
CSD
~
e
LCCA
....
Perform ACR pre·
processing to save CPU
status, set ACR state,
and resume interrupted
work of good CPU.
CVT
t:;CRIN
PROGRESS"
~
Save Area
PCCA
PCCAVT
LCCA
LCCAVT T""""'"
Input for R/TM
Dispatcher
(lEAVEDSO)
or
SETLOCK
(lEAVELK)
DEAD
DEAD
...
t----II\ I GOOD
2
y
or:
LCCA
,~
@PFCA
@ P~CA
PSA
@PSA
PHYSCCA
"
Recovery
CPU PSA
~
!II
"
.)3
Route failing CPU's work
through RTM 1 for
recovery.
'l!-
"'
@PSA
PHYSCCA
I -11--------1
IEAVTRT1
...L
PSA
1-1
MCHLOGREC
Buffer
~
Perform i ntermed iate
processing to resolve lock
conflicts and dispatch
appropriate CPU's work.
@ LCCA/
11
~
IPsAl
~
@ LCCA I
ACR CPU
Related
If
R/TM
Dead CPU
Saved
Logical
PSA Data
Recovery
CPU
Saved
Logical
PSA Data
Diagram 22-26. Alternate CPU Recovery (ACR) Overview (IEAVTACR) (part 2 of 4)
Extended Description
Alternate CPU recovery (ACR) recovers the system on the
remaining CPU when one CPU in a multiprocessing environment fails. ACR quiesces the operation of the failing
CPU and attempts to recover as much processing as possible - ACR keeps the system operational.
ACR processing begin"s when a CPU receives a signal, via an
EMS (emerge'ncy signal) or an MFA (malfunction alert), of
another CPU's imminent failure just before it stops operation.
(See the M.O, diagram Signal Service Routines (lEAVERJ)
in the Supervisor Control section for a description of how
CPUs signal one another') ACR initially receives control
from the external interruption handler and proceeds to
recover the failing CPU's work by giving control to R/TM
as if a machine check occurred. R/TM routes control to any
FRRs defined by the abnormally terminated process. These
FRRs free resources associated with the terminating functions. This provides as much recovery function as possible.
As ACR processing continues, it cleans up resources associated with the failing CPU and frees them, where possible,
for use by the system. The failing CPU is logically disconnected along with any devices affiliated with that CPU.
ACR gives control to the dispatcher to again begin normal
system operation.
Module
Segment
Extended Description
Module
1
IEAVTACR
ACR uses the LCCA and saves the PSA data of the
failing CPU in the ACR save area. ACR extracts all
logical fields from the failing CPU's PSA and saves them in
the failing CPU's ACR save area. ACR then sets the" ACR
in progress" indicator in the LCCAs of both the failing
and recovery CPUs. The CSD also contains an "ACR in
progress" indicator. Then, ACR marks the failing CPU
offline by setting indicators in the CSD (common system
data). The CPU remaining in the system continues processing its own work by returning control to the external
interruption handler so the system continues processing.
Work for the remaining CPU will be dispatched. When the
recovery CPU enters the dispatcher, or when a lock conflict arises, ACR will resume processing.
2
An entry from SETLOCK or the dispatcher causes a
suspension of the currently executing work and a
dispatch of the previously suspended work. Dispatching
of the appropriate CPU's work will be accomplished by
saving the logical data of the current PSA in the corresponding ACR save area and restoring the logical data of
the suspended CPU's PSA back to the current PSA. Processing of work can then resume.
3
CI}
a
e'
=
~
a:$l
5'
o
....
o
'"0
Q.
Q
5'
=
~
~
~
-...I
The first entry from SETLOCK or the dispatcher
causes the failing CPU's work to become the work
to be dispatched. ACR treats this work as a machine
check condition, by routing control to RTM1 with the
machine check indication. FRRs defined for the terminated process will receive control to provide some level of
recovery (including the releasing of locks held or the retry
of a process, if appropriate).
Segment
ACRPREP
ACRLKSPI
t
Diagram 22-26. Alternate CPU Recovery (ACR) Overview (IEAVTACR) (part 3 of 4)
w
00
o
fIl
"<
fIl
~
fIl
1
~
r""
cits·
r""
a:
~
4
Perform ACR post
processing.
.
~
....
c
a
---..
~
P'
~
....
'2 :;:,:~
I} ~~t~ies
RTM1
Work
Area
~
MCH
Stack
:
"IBI----.
RTM 1
Work
Area
ft
@Recovery
Envlronment Area
II
Output
Global
SDWA
I.
Global
SOWA fo~
Normal
Stack
~.~
~
FRR
Entries
!
Stack
Header
IftRTM1
Work Area
I'
@Super
FRR
I}FRR
0
Entries
J
Work
Areas
0
~
0
~
~
Work
Areas
for
Normal
Stack
Diagram 22-27. FRR Stack Initialization (lEAVTSIN) (part 2 of 2)
Extended Description
Module
2
The initialization routine locates a recovery stack
in the recovery environment area for initialization.
3
The initialization routine places the address of the
recovery stack into its appropriate slot in the RSVT.
4
The recovery stack is initialized as follows:
1) The address of the first entry - 32 (if the normal stack)
The address of the first entry (if not the normal
stack)
2) The address of the last FRR entry
3) The FRR entry length
4) The address of the current entry .
• Initialization zeroes the FRR address field in the first
entry of the stack for the normal stack; otherwise, it
initializes this FRR address field with the address of the
super FRR (obtained from the CVTI. The remaining
fields in this entry are zeroed.
tD
~
g.
=
N
3:
~
go
c.
C
-.
o
1;
g.
=
~
.i..
~
b) All FRR entries from the second entry to the last entry
are zeroed.
IEAVTSIN
The global SDWA associated with this stack is zeroed. The
work areas associated with the global SDWA consist of
two types:
a) A 72-byte save area is zeroed.
b) A 200-byte FRR work area is not zeroed.
• The four words in the stack header contain
(Il
The initialization routine zeroes the remaining portions of the stack as follows:
a) The RTM1 work area portion of the stack is zeroed.
table (RSVT) in the PSA (prefix storage areal. VARY
CPU and system initialization use IEAVTSIN.
The first word of the RSVT points to the recovery
environment area.
Extended Description
5
The I EA VTSI N macro instruction expands inline to initialize all FRR recovery stacks in the system and identify
each such stack by initializing the recovery stack vector
1
Segment
6
Return to caller occurs if all recovery stacks have
been initialized; otherwise, control returns to
step 2 to initialize the next recovery stack .
Module
Segment
t
""
Diagram 22-28_ SETFRR (SETFRR) (part 1 of 2)
~
oen
~l-..J
~
l
...
v
en
'<
~
Work Register 1
(tI
3
1
~~.
A
t""
~
....
Work Register 2
;:;t""
0:
;
-<
o<
3(tI
I
RSVT
C
~
I-
PSA
V
'
I--
~~OR
~OR
~>-OR
Establish addressability
to the FRR stack.
f
~
~
Diagram 22-28. SETFRR (SETFRR) (part 2 of 2)
Extended Description
Module*
The SETFRR macro instruction expands inline and alters
the contents of an appropriate FRR stack based on given
options.
1
One of the two input work registers «ontains the information needed to establish addressability to the FRR
stack.
2
The other work register contains the information
necessary to examine the "stack header" - the first
four words of the FRR stack. SETFRR determines the
stack status as follows (and only for the ADD, REPLACE,
or DELETE options):
A - If the first and fourth words of the stack header are
equal the FRR stack is empty.
B - If the second and fourth words of the stack header are
equal the FRR stack is full.
3
Five mutually exclusive options can be performed by
SETFRR, as follows:
• ADD - The FRR address supplied as input is added to
the stack and the current FRR entry pointer is updated
to point to this new FRR address. If the stack is full,
a X'07D' ABEND will occur if the caller requests another
FRR to be added .
• REPLACE - Performs a replacement of the FRR address
pointed to by the fourth word of the stack' header by the
input FRR address. If the FRR stack is empty, an addition equivalent to A is performed.
t"I}
a
o·
::I
~
~
sa.
g
Q.
o
1"0)
o
Io·
::I
f"
..a;:..
..a;:..
w
Module·
Segment
• ,DELETE - Removes an FRR address from the stack by
adjusting the fourth word of the stack header to point
to the preceding FRR entry. If the stack is empty this
delete function is a NOP.
SETFRR
• PURGE - Adjusts the stack header to reflect an empty
stack (i.e., setting the fourth word equal to the first
word of the stack headed.
• FLUSH - A special option to be used only by the
Dispatcher, purges the normal FRR stack (making
it empty) and zeroes RITM recursion indicators in the
RTM1 work area portion of the normal FRR stack.
4
An option~1 parameter register or storage location,
when specified as input, becomes the receiver of the
address of the parameter area associated with the FRR
address for which the "ADD" or "REPLACE" option is
to be executed.
Notes:
1) Stacks depicted represent normal FRR stacks. Supervisor control FRR stacks have the first word of the
header pointing to the first FRR entry rather than
the address of the first entry - 32.
2) SETFRR operates on a supervisor control FRR stack
identical to that described for a normal FRR stack.
* SETFRR expands inline; it has no service routine module.
Segment
~
~
~
Diagram 22-29. SVC 51 Overview (IEAVADOO) (part 1 of 2)
~
o
tI)
~
FromSVC IH (lEAVESVC)
to process an SVCDUMP
(SVC 51) request
Input
Process
N
tI)
'<
l'4.
3
E
;;.
t:
go
~
~
~
CD
~
'<
tI)
N
~
CD
;~
~
!.N
~
CVT
TCB
SVRB
DDD
DD
D
ASCB
1
Process formatted dump requests.
Formatted
Dump
Parm List
Process unformatted dump requests
synchronously_
Unformatted
Dump
SRB
Schedule the SRB to post the
Dump task.
IEAVTSDX
I
ISchedu~e Dump
Processing
ToSVCIH
(lEAVESVC)
Diagram
22~29.
SVC 51 Overview (lEAVADOO)
(part 2 of 2)
Extended Description
An SVC 51 instruction provides linkage to both the SNAP
function and to the SVC DUMP function. Both functions
require Register 1 to point to a parameter list.
The difference between a SNAP and SVC DUMP parameter list is in byte 1 of the first word (B) and byte 0 of
the third word (C)'
B=X'OO' ,C=X'OO'
B=B'01 ...... '
B=X'SO'
B=X'OO' ,C=X'SO'
OSIVS2 Release 1 SNAP Parameter
List
OS/VS2 Release 2 SNAP Parameter
List
OS/VS2 Release 2 SVC DUMP
Parameter List
INVALID - OSIVS2 Release 1
SVC DUMP Parameter List
Module
Segment
Extended Description
Module
1
I EAV ADOO SDTOP
The "SNAP DUMP Processing" M.O. diagram
describes the processing of a formatted dump.
2
Ca lIers of SVC DUMP must be authorized by APF
or have control program key. If the caller is not
authorized he will be abnormally terminated with
completion code 133.
SVC DUMP provides two services, a Synchronous Dump
and a Schedule Dump. The distinction between the two
dumps is in the 6th word of the parameter list. D is the
first halfword, and E is the second halfword of the 6th
word.
D=X'OOOO' ,E=X'OOOO' - SYNCHRONOUS DUMP
D=X'OOOO' ,E=ASID - SCHEDULE DUMP
D=CURRENT ASID,E=ASID - Target of SCHEDULE
DUMP, process as if a
SYNCHRONOUS DUMP
request.
A Synchronous Dump will be taken now off the current
TCB.
A Schedule Dump results in a branch to the Schedule
Dump routine.
If an invalid parameter list is passed, the caller is abended
with a 233 completion code.
3
SVC DUMP processing (I EA VADOO) describes
the processing for a dump scheduled to the dump
task in each address space.
tI.l
(11
ll.
g'
~
~
a
[
o
"'"
o
1e'
=
t
~
Segment
SDTOP
~
~
Diagram 22-30. SNAP Dump Processing (lEAV ADO!) (put 1 of 6)
o
Input
~
From SVC 51 Overview (lEAVADOO)
Output
&..Process
,
~
N
;
,,OJ
CI.l
'<
rI>
"
I
@CVT
~
r;'
1
v
CVT
I\.~
t""
-y
0:
A
~
<:CI.l
II.
0
,:;
v
:,
GETMAIN
~@ Current TCB I
@SNAPSVRB
TeB
I
Error during GETMAIN.
}i
:,:
To SVC 51
Overview
(IEAVADOO)
r
"
i
Register 15
I
'/
~
,>C
I
...
SVRB
(1)
;;~'
.,::
Register 5
•
ABDAREA
,.
'"
N
.,;,'
'.
IEAVGMOO
~
Register 4
;:~.
]I
y
~
(1)
.'
"
Obtain storage for the SNAP
work areas and initialize them;
check DCB.
~
~
:)~.
SVRB
Register 3
it""
,x
~
~
'.
~
'-'
;;
Meaning
X'04' X'OS' -
No DCB
GETMAIN failure
X'OC' -
Invalid DCB
;::i<:;+:l;'~:';
,.
:t
;~;
Code
(RB
':1
I
Return Codes
:'1
,:'
.~:
,
.:,
,31;
;~
i!
:;,,\
I\.
2
-v
•
Change into caller's key,
if necessary.
@ Parm List
,I
•
Parm List
Storage List
D
,."
..
y
~
• 'j:.?.;
...
Obtain (via ENQ) the dump
data set.
;"
•
,
:
r
~
'"
.:,'
'
IEAVMODE
IEAVENQ1
ENQ
;
II.
,
Set tasks non -di spatchable.
IEAVSETS
~
';
'"
"
", ",,:LL: \ \\ \tf; "''C, ':n.·:J\z,·i~
-L
I
Return Code
X'08' -
Invalid TCB
I
~i
;'
i
MODESET
'"
Register 1
I
)y
Validity check the parameter
list.
STATUS
. i.C: :.,oJ·""
'>'
";::
'.
':;-r,';:'Lf:J:;
Diagram 22-30. SNAP Dump Processing (IEAVADOl) (part 2 of 6)
Extended Description
Module
The SNAP dump routines produce a formatted dump of
various areas of storage, depending on the parameters. As
shown in M.O. diagram SVC 51 Overview OEAVADOO),
SNAP receives control via an SVC 51 macro instruction.
The main SNAP module, I EAV AD01, does initialization
for and then routes to various formatting routines. These
routines format the dump.
1
The SNAP routine obtains storage, via GETMAIN,
for an ABDAREA. The ABDAREA contains the
information used by the format~ing routines. Control goes
to the caller if an error occurs during GETMAIN processing.
2
SNAP processing does not validity check the parameter list for calls from ABEND, nor does SNAP
enqueue upon the dump data set for calls from ABEND.
The enqueue process has already been performed by
ABDUMP.
STATUS is issued if the task being dumped is not the
current task.
tf)
(\)
(")
6'
::I
N
a::
(\)
g
Q.
o
......
o
"t:I
...
(\)
~
c)"
::I
~
~
~
-...I
IEAVAD01
Segment
t
Diagram 22-30. SNAP Dump Processing (lEAVADO}) (part 3 of 6)
~
&5
~
'N
>
ff
I~
~
3
r-
ABDAREA
A
to.
t§.
Ii :
t:
v
(")
3
Process the dump according to
the dump options.
•
g"
~
~
J\.
..
Display jobname, stepname.
~
IEAVAD02
~
...
=-
:I~
•
.j:".
' 4 The SRB posts the dump task
From
Dispatcher
(lEAVEDSO)
---.
N
i
r
RTCT
lC
~
:....
...300
..J\.
) 5
SDUMP
Parm List
v
Perform the dump.
Via
SDUMP
r
~
...
Gcs
ASCB
CVT
ECB
IEAVADOO
SVC Dump
Overview,
Step 2
RTCT
CVT
J
6
...
Clean up resources.
v
RTCT
[J[J
(
......
To Dispatcher
(lEAVEDSO)
.-
/'
Diagram 22-320 Schedule Dump Processing (lEAVTSDX) (part 4 of 4)
Extended Description
tI.)
a
5°
=
~
s::
go
~
Q.
e.
o
't:I
~
5°
=
~
~
-
4
The SRB, created in step 3, posts the ECB for the
dump task located in the address space being dumped.
5
The resident dump task receives control.
6
After cleanup, control returns to the caller.
Module
Segment
SCHSRB
IEAVTSDT
:t
Diagram 22-33. CHNGDUMP Routine (IEEMB815) (part 1 of 4)
01
N
From Module I EE0403D to
change dump options
otil ,
"<
til
N
til
'<
~
5;
r-
~
(:).
Register 2
I
.$
(
I
@XSA
t"'"
~
....
XSA
<:
o
~1
..
Get storage for work area and
initialize it.
------
..
...
...
y
Work Area
v
R14SVC34
IEAVGMOO
R14SAVE
GETMAIN
Work Bits
I
=
a
~
XSASAVE
01:0
'<
til
N
::c
~
i
~
w
:....
'-'
I
XAL
r1
D
Command Buffer
2
I
=
Validity check keywords and options:
CHNGDUMP Work Area
•
Check delimiters.
•
Check keywords.
•
Check options.
R14 SVC 34
.....
y
I
I
Work Bits
R14 SAVE
XSASAVE
CHNGAREA
RTCHWORK
RTCT
CVT
..
v
RTCTSAO
3
Initialize the RTCT with options
from CHNGDUMP work area.
@RTCT
")
"
RTCTSDO
RTCTSUO
RTCTABD
It
-'--
Diagram 22-33. CHNGDUMP Routine (IEEMB81S) (part 2 of 4)
~
Extended Description
The CHNGDUMP routine processes the CHNGDUMP
operator command which overrides any dump options
that exist in the system. These options vary according to
the type of dump originally requested. For SYSABEND
and SYSUDUMP requests, the dump options which exist
in the system are a result of merging all of the following:
• IEAABDOO or I EADMPOO SYS1.PARMLIB members.
• Options indicated on the ABEND macro instruction
requests.
• Options indicated on the CALLRTM macro instruction
requests.
• Options indicated on the SETRP macro instructions
requested by recovery exits.
For SVCDUMP requests, the dump options which exist in
the system are those indicated on the SDUMP parameter
list passed to the SVCDUMP routines.
The XSA (extended save area) of the SVC 34 SVRB acts
as the communications area between the SVC 34 router
module (I E E0403 D), and the various command processors,
such as CHNGDUMP.
~
~
~
c:r
=
t-.J
3':
~
[
o
o
"g
~
S·
=
~
~
0-
~
Module
Segment
Extended Description
Module
Segment
1
The CHNGDUMP routine obtains storage from subpool 229 for the work area.
IEEMB815
CHDINIT
2
CHNGDUMP performs a loop to" check each option
as set off by delimiters, as follows:
CHDCNTRL
• Scan the parameters for any delimiter, and then call the
appropriate delimiter subroutine.
• The delimiter subroutine determines whether the parameter is an option or a keyword. For keywords, the subroutine checks their validity; for options, control goes the
option handler subroutine.
• The option handler subroutine verifies the option and
places it in the work area.
3
If no errors occurred in the processing described in
step 2, the CHNGDUMP routine sets the RTCT values
as requested by the CHNGDUMP command.
CHDCDSS
~
~
~
Diagram 22-33. CHNGDUMP Routine (IEEMB81S) (part 3 of 4)
o
~
Output
Process
N
c-n
'<
~
~
r-
)
maao to
~
'<
I:I.l
N
:;c
i
~
Output
Process
.
v
Register 0
1
....
Perform emergency recording
when the system fails.
-y
(mRTMa
RTCT
RTCTRCB
Length of Record
@ Last Record
RTMRCB
....
)
v
2
Reserve space for and build the
record.
I--
3
Give control to the recording task.
....
v
CVT
CN
I
I
Register 1
I
0
i
~
Flags
(part 1 of 4)
D
. .) A
v
RTMRCB
V
RCBFLGS
-
--
•
Recording task active.
•
Recording task not active;
schedule the SRB.
.." Step 4
RTMRCB
"
v
RCBFLGS
RCBSRB
t
I
I
Diagram 22-34. Recording Processing (lEAVTRER) (part 2 of 4)
Extended Description
Module
Segment
Extended Description
Module
1
IEAVTRER
Recording processing writes the records that R/TM creates
in the course of its processing. Recording processing builds
the record in the RTMRCB (RTM record control block) to
contain recording information. Then, the recording task
writes the record, via SVC 76.
The recording request routine first determines
whether the caller is the system termination routine.
I n this case, it returns the address of any records directed
to SYS1.LOGREC to the caller. This means that WTO
(write-to-operator) records are lost.
Recording processing consists of two separate modules; the
recording request routine which builds the record in the
RTM RCB; and the recording task, which actually writes
the record. Th~ recording request routine receives control
after a system routine issues the RECORD macro instruction. This routine uses the input information to build the
record. After this routine finishes its processing, it gives
control to the recording task. The recording task receives
control when the recording request routine schedules an
SRB (service request block), which posts the ECB the
recording task is waiting on.
The recording request routine places a return code of 4 in
register 15 if no records remain to be written to
SYS1.LOGREC.
R/TM creates records for hardware and IBM-software
errors when requested by ESTAE routines or FRRs.
2
The recording request routine reserves the storage
necessary to build the record in the RTMRCB. It
then constructs a record header with the recording information from the parameter list.
FINDSPCE
3
SCHEDSRB
The recording request routine can now give control to
the recording task. The recording task receives control,
to asynchronously write the records. The recording request
routine schedules an SRB to post the waiting recording
task.
The recording request routine returns control to the caller
who issued the RECORD macro instruction.
til
(I>
n
g.
=
t-J
~
(I>
[
o
-.
o
-=;
g.
=
~
J;.
0'1
"
Segment
f"
~
Diagram 22-34. Recording Processing (lEAVTRER)
(part 3 of 4)
00
G5
~
N
~
'<
=a
E
n·
Co
From Dispatcher after the schedu
receives control and post the reco
task. (ECB =RTCTRECB)
..
.......
\.
Recording Task
JI..
v
4
g'
Wr ite the record.
•
~
Buffer
"
Obtain a buffer and move the .
record into it.
y
..
o<
=
i
GETMAIN
~
~
....
~
~
N
•
:;c
..
Write the record via SVC 76 .
~
r
~
i
SYS1.LOGREC
Recorder
....
~
ECa
~
~
Copy of
Record
5
Indicate that the record has been
written and free the buffer.
.
"
y
POST
~
....
Post's Record
Written
....
--"
r
~
Frees Buffer
....
--"
r
~
....
6
FREEMAIN
MCHWTO
Routine For Hardware
Errors
Return to wait state
(ECB =RTCTRECB).
~Waits..te
I
I
Diagram 22-34. Recording Processing (lEAVTRER)
Extended Description
Module
4
IEAVTRET REBUF
The recording task first obtains a record buffer by
issuing GETMAIN for storage equal to the length of
the RTMRCB, and moves all records into this buffer. The
recording task gives control to SVC 76 to actually write
the records from the buffer to SYS1.LOGREC.
5
The POST routine posts that the record has been
written, if requested.
The recording task then frees the buffer obtained in
step 4.
For all records written, the recording task gives control to
the MCH (machine check handled WTO routine.
The MCH WTO routine then determines whether to write
a message to the operator, In all cases, however, the MCH
WTO routine notifies the operator for hardware errors.
6
fIl
a
0'
=
!'!
a::
a
8:o
....
o
~
a
g.
=
~
~
\0
(part 4 of 4)
The recording task returns to the wait state to
wait to be posted again.
Segment
WRITERCD
POSTER
4-470
OS/VS2 System Logic Library Volume 4 (VS2 Release 3.7)
Index
ABDUMP 4-392,4-381
ABDUMP initialization (See OS!VS2 System Initialization
Logic)
abnormal end of task 4-330
ABTERM request 4-370
access control block (see ACB)
access method, pseudo (see pseudo access method)
account tables (see ACT)
ACR introduction 4-322
ACR overview processing 4-436
address, return, for TIME requests 4-6
address space (see also memory)
dispatching 4-85
lock verification 4-176
master scheduler, reschedulingJR/TM in 4-368
priorities in 4-84
switching 4-84
termination
conditions in super FRR 4-172
in purging timer queue elements 4-17
processing 4-333, 4-426
requester routine 4-428
verifying 4-176
address validity checking 4-162
~ffinity (see CPU affinity)
allocate from groups picked by algorithm (see IEFAB478
object module)
allocate function control (see IEFDB410 object module)
allocation queue manager (see IEFAB4FA object,module)
allocation queue manager request block (see AQMRB)
allocation work area (see ALCWA)
alternate CPU recovery (ACR)
in synchronous timer recovery 4-36
introduction 4-322
overview processing 4-436
APF (see authorized program facility)
ASCB (address space control block)
in ASCBCHAP process sing 4-164
in dispatcher 4-56
in dispatchin& the wait task 4-82
in establishing timer intervals using STIMER 4-8
in exit processing (lEAYEOR) 4-256
in exit prolog 4-258
in EXTRACT processing 4-254
in global SRB dispatcher 4-72
in I/O interrupt handler 4-94
in memory switching 4-84
in POST processing 4-222
in program check interrupt handler 4-112
in PURGEDQ 4-144
in purging timer queue elements 4-16
in routing to FRRs 4-354
in resume routine 4-191.6 (VS2.03.807)
in RTMI rescheduling 4-366
in SCHEDULE processing 4-140
in SETLOCK processing 4-154
in stage 3 exit effector 4-134
in STATUS processing 4-260
in supervisor routine dispatching 4-76
in suspend routine 4-191.0 (VS2.03.807)
in SVC interrupt handler 4-88
in task dispatching 4-78
in TQE processing 4-22
in TQ E purge routine 4-16
in validity check processing 4-162
in WAIT processing 4-220
ASCB priority
adding 4-164
deleting 4-164
in ASCBCHAP processing 4-164
ASCBCHAP processing 4-164
ASM (see auxiliary storage manager)
ASVT (address space vector table)
in address space lock verification 4-176
in TQE processing 4-22
repairing 4-178
verifying 4-178
ASXB (address space extension block)
in CHAP processing 4-214
in DETACH routine 4-210
in I/O interrupt handler 4-94
in rescheduling locally locked task or SRBs 4-372
in routing to FRRs 4-354
in stage 3 exit effector 4-134
in supervisor routine dispatching 4-76
in validity check processing 4-162
asynchronous exits (see exit asynchronous)
asynchronous timer recovery 4-38
ATTACH processing 4-198
attributes, user (see VAPS)
authorization checking (TESTAUTH) 4-270
authorization for CHAP 4-214
authorized program facility (APF)
TESTAUTH routine 4-270
automatic priority group (see APG)
auxiliary storage manager I/O request area (see AlA)
available queue element. (see AQE)
BASEA (see MSRDA)
BLDL/program fetch interface 4-288
broadcast data set (see SYS l.BRODCAST)
calculating a time interval
in checking a time interval using TTIMER 4-10
CALLRTM macro instruction
in initialization of RTM 4-344
overview 4-342
CANCEL command
R/TM processing for 4-332
cancellation
time limit checking 4-16
cancelling a time interval
in checking a time interval using TTIMER 4-10
CDE (contents directory entry)
in BLDL/program fetch interface 4-288
in DELETE routine 4-294
in IDENTIFY routine 4-296
in LINK routine 4-278
in LOAD routine 4-292
in program fetch 4-308
in routing to searching routines 4-284 .
in searching the LPA directory 4-286
changing dispatchability indicators 4-260
changing system mask with MODESET 4-268
channel availability table (see CAT)
CHAP processing 4-214
check, machine
in synchronous timer recovery 4-36
checking timer components 4-36
checking timer interval using TTIMER 4-10
clock, TOO (see TOD clock)
clock comparator
in asynchronous timer recovery 4-38
in timer functional recovery routine 4-24
interruption type 4-18
setting ·4-20
coefficients, resource (see resource factor coefficient)
command, reconfiguration (see reconfiguration commands)
communications task
FRR
use of 4-415
comparator, clock (see clock comparator)
components, timer
checking machine-check validity
in synchronous timer recovery 4-36-4-37
error count of component in error in CSD 4-37
in establishing TQE using STIMER 4-9
initialization verification
Index
1-1
•
in synchronous timer recovery 4-36-4-37
verifying usability of 4-9
condensed dump (VS2.03.80S)
function 4-393-4-395 (VS2.03.80S)
control, common allocation (see common allocation
control)
control blocks (see data areas)
conversion, time interval unit 4-10
conversion, timer unit
in establishing timer intervals using STIMER 4-8
in processing TIME requests 4-6
corequisite publications iv (preface)
CPU affinity
in dispatchin~ local supervisor routines 4-76
CPU dependencIes, in memory switching 4-84
CPU hold routine error recovery
in timer FRR 4-24
CPU recovery, alternate
in synchronous timer recovery 4-36
introduction 4-322
overview processing 4-436
CPU signaling (signal service routines-IPC) 4-120
CPU timer error recovery 4-38
CPU timer interruption type, determining 4-18
cross-memory post requests 4-222
CSCB (command scheduling control block)
in EXTRACT routine 4-255
CSD (common system data area)
in set clock comparator routine 4-20
in setting a specific TOD clock 4-26
in signal service routines (IPC) 4-120
in status processing 4-262
CVT (communication vector table)
in address space lock verification 4-176, 4-178
in ASCBCHAP processing 4-164, 4-166
in emergency signal second level interrupt handler
4-128
in ENQ/DEQ/RESERVE routine 4-242
in memory switch processing 4-84
in processing TIME requests 4-6
in PURGEDQ processing 4-144
in restart interrupt handler 4-116
in RTMI exit processing 4-376
in SCHEDULE processing 4-138
in set clock comparator routine 4-20
in SVC interruption handler 4-90
in timer SLIH (second level interrupt handler) 4-18
in TOD clock operator communication routine 4-30
in TOD clock status test routine 4-34
in TOD clock synchronization routine 4-32
in TQE dequeue routine 4-14
in TQE enqueue routine 4-12
in TQE processing routine 4-22
in XCTL routine 4-300
CVTDATE field, use of in TQE processing routine 4-22
data definition (see DD function control) 4-12
DCB (data control block)
in BLDL/program fetch interface 4-288
in program fetch (building a DCB) 4-311
in routing to searching routines (use of DCB operand)
4-285
DEB (data extent block)
BLDL/program fetch interface, in 4-288
DEQ macro instruction (see ENQ/DEQ/RESERVE
routine)
dequeueing TQEs (timer queue element)
in checking a time interval using TTIMER 4-10
in TQE Dequeue routine 4-14
in TQE Purge routine 4-16-4-17
DETACH processing 4-206
.
device allocation/unallocation (see allocation/unallocation)
devices, generic (see generic allocation control)
DF code on restart interrupt 4-116
DIE TQE 4-3, 4-22 (VS2.03.807)
direct access data set (see DADSM)
direct signal routine 4-125
directory, LPA searching 4-286
dispatchability, changing (STATUS processing) 4-261
1-2
OS!VS2 System Logic Library Volume 4 (VS2.03.807)
dispatcher
local supervisor dispatcher 4-76
processing 4-54
SRB
queues 4-54
task dispatcher 4-78
wait task dispatcher 4-82
dispatching
local SRBs 4-74
local supervisor routines 4-76 '
priority, changing
in CHAP 4-214
the wait task 4-82
with address space switch 4-85
DOM (delete operator message) ID entries
double-threaded queues, verifying for a supervisor recovery
routine 4-170
DSS
action on restart interrupt 4-116
dump, ABEND, processing overview 4-335
dump, SNAP, processing overview 4-335
dump, SVC, overview 4-336-4-337
DWWIN
dynamic support system (see DSS)
ECB (event control block)
in DETACH routine 4-208
in overlay supervisor 4-306
in POST processing 4-222
in WAIT processing 4-220
ECB parameter on DETACH 4-208
ECCDB
EED
in processing hardware errors 4-348
in rescheduling locally locked task or SRB 4-372
in R/TM clean up processing 4-375
in RTMI rescheduling 4-366
in system directed task termination 4-370
embedded entry point, in IDENTIFY 4-297
emergency signal SLIH 4-128
emergency signal interruption det~rmination 4-98
end of task (see EOT)
ENQ/DEQ/RESERVE routine 4-242
ENQ macro instruction (see ENQ/DEQ/RESERVE
routine)
enqueueing a TQE 4-12
EOT (end of task)
abnormal (ABEND) 4-330
determination in exit prolog 4-258
invocation by EXIT processing 4-257
normal 4-328
EPAL (external parameter area locate mode, see EPA)
EPAM (external parameter area move mode, see EPA)
enqueue, of TQE 4-12
error processing (see also error recovery ESTAE processing)
abnormal end-of-task (ABEND) 4-330
for hardware errors 4-326
for page I/O errors 4-324
hardware 4-348
error recording
in timer functional recovery routine 4-24
error recovery. (see also error processing, ESTAE
processing)
clock comparator
in asynchronous timer recovery 4-39
in timer error recovery 4-24
CPU timer
in asynchronous timer recovery 4-39
Timer FRR 4-24
TOD clock
in asynchronous timer recovery 4-39
error recursion (see recursion processing of errors)
error, user exit
in checking a time interval using TTIMER 4-11
in establishing timer intervals using STIMER 4-9
in processing TIME requests 4-7
errors, hardware, processing of 4-348
ESR (extended SVC routing) 4-86-4-87, 4-44
establishing timer intervals using STIMER 4-8
ESTAE
in TIME service routine 4-7
service routine 4-430
ETXR parameter
on ATTACH 4-201
on DETACH 4-207
event table, description of in EVENTS routine
4-237-4-239
EVENTS processing 4-234
error processing 4-240-4-241
synopsis of 4-196
EVENTS ECB
processing in POST routine 4-225
exclusive control (see XCTL routine)
exit, asynchronous scheduling in stage-3 exit effector
4-134
exit, attention (see attention exit)
exit effectors
stage 1 4-130
stage 2 4-132
stage 3 4-134
stage 3 switch, checking 4-132
use in task dispatching 4-78
exit handling"(see EXIT routine)
EXIT prolog
EOT determination 4-258
force dispatch switch 4-259
passing control to EXIT routine 4-259
processing 4-258
EXIT routine 4-256
exit processing, RTMI 4-376
exit, asynchronous, processing in task dispatcher 4-79
exit, user error
in checking· a time interval using TTIMER 4-11
in establishing timer intervals using STIMER 4-9
in processing TIME requests 4-7
extended SVC routing (ESR) 4-86-4-87, 4-44
external call second level interrupt handler 4-126
external first level interrupt processor (see also external
interrupt processing)
codes 4-98
processing 4-98
external old PSW 4-99
external parameter area (see EPA)
external parameter area locate mode (see EPA)
external parameter area move mode (see EPA)
EXTRACT macro instruction processing 4-254
faults (see page faults)
fetch (see program fetch)
first level interrupt handler
external 4-98
FLIH (first level interrupt handler)
external 4-98
force dispatching switch, setting in exit prolog 4-259
frame (see page frame)
freeing TQE space in TTIMER routine 4-10
FRR (see functional recovery routine)
FRR stack
in dispatching local SRBs 4-74
initialization 4-440
in I/O interrupt handler 4-95
in restart interrupt handler 4-118
in routing to FRRs 4-354
full analysis (see system resources manager)
functional recovery routine (see also termination conditions)
routing to 4-354
SLIP processing 4-356-4-357
"SUPER" (supervisor control) 4-172
use by LINK routine 4-282-4-283
use by SPIE 4-251
use by XCTL 4-304
generation data group (see GDG)
global SRB
dispatcher 4-74
GMT (Greenwich Mean Time)
in processing TIME requests 4-6
timer interval requests in STIMER routine
GSMQ (global service manager queue)
in dispatcher 4-54
in PURGEDQ 4-144
in SCHEDULE processing 4-138
GSPL (global service priority list)
dispatching global SRBs 4-72
in PURGEDQ 4-144
in dispatcher 4-54
in SCHEDULE processing 4-142
4-9
hardware error processing 4-348, 4-326
hardware status bytes, timer, checking 4-39
high order synchronization in TOD clock status test routine
4-35
HIPO (see Method-of-Operation section)
housekeeping (see JFCB housekeeping)
ICB2AIR object module
function 4-406-4-407, 4-416-4-417
IDENTIFY routine 4-296
IEATLEXT object module
function 4-23
lEAVEACO object module
function 4-164, 5-52
lEAVEATO object module
function 4-198
lEAVECHO object module
function 4-214
lEAVEDR object module
function 4-124
lEAVEDSR object module
function 4-172
lEAVEDSO object module
function 4-54
lEAVEEDO object module
function 4-206
lEAVEEEO object module
function 4-134
lEAVEEE2 object module
function 4-132
lEAVEES object module
function 4-128
lEAVEEXP object module
function 4-258
lEAVEEXT object module
function 4-99
IEAVEEIR object module
function 4-103
lEAVEE3Robject module
function 4-103
lEAVEFOO object module
function 4-130
lEAVEIO object module
function 4-94
lEAVEIOR object module
function 4-98
lEAVEIPR object module
function 4-125
lEAVELCR object module
function 4-177
lEAVELK object module
function 4-148
lEAVELKR object module
function 4-161
lEAVEMSI object module
function 4-126
lEAVEMSO object module
function 4-84
IEAVENQl object module
function 4-242
lEAVEOR object module
function 4-256
lEAVEPC object module
function 4-104
lEAVEPCR object module
function 4-115
lEAVEPDR object module
Index
1-3
function 4-145
lEAVEPDO object module
function 4-144
lEA VEQVO object module
function 4-170
lEA VERER object module
function 4-119
lEA VERES object module
function 4-116
lEA VERI object module
function 4-120
lEA VERP object module
function 4-122
lEA VESCR object module
function 4-142
lEAVESCO object module
function 4-138
lEA VESPR object module
function 4-172
.
lEA VESVC object module
function 4-86
lEA VESVR object module
function 4-93
lEAVETCL object module (VS2.03.807)
function 4-191, 4-191.6 (VS2.03.807)
special entry 4-81 (VS2.03.807)
lEA VEV AL object module
function 4-162
lEA VEVRR object module
function 4-178-4-179
IEAVEVTO
function 4-234
lEA VEXS object module
function 4-126
lEA VIDoo object module
function 4-296
lEA VLKOO object module
function 4-278, 4-290, 4-292, 4-294, 4-300
IEAVLKOI object module
function 4-286-4-289
lEA VLK03 object module
function 4-280-4-281
lEAVMFRR object module
use of 4-415
lEA VMODE object module
function 4-268
lEA VPFTE object module
IEAVRTIO object module
function 4-18
IEAVRTIl object module
function 4-36, 4-17, 4-24
IEAVRTOD object module
function 4-38, 4-34, 4-32, 4-30
lEA VRToo object module
function 4-10, 4-8
IEAVRTOI object module
function 4-6, 4-9
lEA VRT02 object module (VS2.03.807)
function 4-11 (VS2.03.807)
lEA VSETS object module
function 4-260
IEAVSSNQ (entry name)
function 4-266
lEAVST AO object module
function 4-430
lEAVSY50 object module
function 4-222
lEA VT ABD object module
function 4-392, 4-381
lEA VTACR object module
function 4-436
lEAVTAS 1 object module
function 4-388
lEA VT AS2 object module
function 4-388
lEA VTAS3 object module
function 4-390
lEAVTBoo object module
function 4-250, 4-254
lEAVTCTL object module (VS2.03.807)
1-4
OS/YS2 System Logic Library Yolume 4 (VS2.03.807)
function 4-191.0 (VS2.03.807)
lEAVTEST object module
function 4-270
lEAVTMMT object module
function 4-410
lEAVTMRM object module
function 4-416
lEAVTMTC object module
function 4-426
lEA VTMTR object module
function 4-428
lEAVTRCE object module
function 4-168
lEAVTRER object module
function 4-466
lEAVTRET object module
function 4-468
IEAVTRTC object module
function 4-380-4-381
lEA VTRTE object module
function 4-380-4-381
lEAVTRTH object module
function 4-348, 4-342
IEAVTRTM object module
.
function 4-366, 4-370, 4-352, 4-371, 4-343
IEAVTRTR object module
function 4-360-4-361, 4-356-4-357, 4-362-4-363
lEA VTRTS object module
function 4-354
IEAVTRTI object module
function 4-344, 4-376, 4-342
lEAVTRT2 object module
function 4-382, 4-385
lEA VTSDT object module
function 4-460
lEAVTSDX object module
function 4-458
lEA VTSIN object module
function 4-440
lEAVTSKT object module
function 4-398
IEAVOPTOI object module (YS2.03.80S)
function 4-222,4-223 (YS2.03.80S)
lEAVOPT03 object module (YS2.03.80S)
function 4-222,4-223 (VS2.03.80S)
IEEMSER (see MSRDA)
IEFIRECM object module
function 4-415
IEFJRECM object module
function 4-415
IGCOO3 4-328-4-329
IGC125 object module
function 4-234, 4-236
IHSA (interrupt local supervisor save area)
in dispatcher processing 4-56
in dispatching local supervisor routines 4-76
in external call FLIH 4-100
in I/O interrupt handler 4-94
in program check interruption handler 4-112
in rescheduling locally locked tasks or SRBs 4-372
in SETLOCK 4-152
incorrect address for MIC or STCK request in a TIME
request 4-6-4-7
initialization
timer component
in synchronous timer recovery 4-36-4-37
initiator resource manager
function 4-415
input stream (see converter)
input options for MF/l (see options,MF/l)
installation performance specifications (see IPS values)
in-stream procedures (see JCL statements)
'instructions (see also macro instructions)
integrity (see data set integrity processing)
interprocessor communications 4-120
interrupt handlers (see supervisor interrupt handler, SLIH,
FLIH)
SVC . 4-86
interval, timing
calculating
in checking a time interval using TTIMER 4-10
cancelling
in checking a time interval using TTIMER 4-10
converting unit 4-10
in establishing timer intervals using STIMER 4-8
I/O interrupt handler 4-94
I/O interruption processing 4-94
I/O old PSW 4-94
I/O supervisor, going to from I/O interrupt handler 4-94
IPC (interprocessor communications) 4-120-4-125
IPS scanner message module
flowchart 4-466
IQE (interrupt queue element)
in ATTACH routine (obtaining storage for IQE) 4-200
in DETACH routine (freeing IQE) 4-206
in stage 2 exit effector 4-132
in stage 3 exit effector 4-134
IRB (interruption control block)
in DETACH routine 4-206
in stage 1 exit effector 4-130
in stage 3 exit effector 4-134
in XCTL routine 4-302
ISTRAMA 1 object module
function 4-404-4-405
job control language (see JCL)
job step allocation (see step allocation)
job step time limit, checking in TQE processing routine
4-23
journal (see job journal)
JSCB (job step control block)
in LINK routine 4-278
in TESTAUTH routine 4-270
JSXL (job scheduling exit list)
in LOGON
scheduling 4-378
LCCA (logical communications configuration area)
in dispatcher 4-54
in dispatching local SRBs 4-74
in external call FLIH 4-98
in global SRB dispatcher 4-72
in I/O interrupt handler 4-94
in memory switching 4-84
in program check interruption handler 4-104
in restart interrupt handler 4-116
in resume routine 4-191.6 (VS2.03.807)
in routing to FRRs 4-354
in RTM2 initialization 4-344
in SCHEDULE processing 4-138
in SETLOCK 4-148
in SLIH processing 4-352
in supervisor interruption handler 4-86
in synchronous timer recovery 4-36
limit priority, use of by CHAP 4-215
LINK macro instruction (see also link routine)
functional recovery routine 4-282-4-283
macro instruction parameters, processing according to
4-284, 4-288
processing 4-278
use of BLDL/program fetch 4-288
use of the searching routines 4-284, 4-286
link pack area (see LP A)
link routine
branch to in XCTL routine 4-302
LLE (link list entry)
in delete routine 4-294
in load routine 4-292
LOAD processing 4-292
loading modules
in LOAD routine 4-292
in program fetch 4-308
local time
processing TIME requests 4-6
TOD clock operator communications 4-31
locally locked task, rescheduling 4-372
lock manager (see SETLOCK)
locking services/considerations
for address space 4-176
refreshing lock 4-176
verifying 4-176
log data set (see system log)
log hardcopy (see hardcopy of system log)
log, system (see system log)
logical reconfiguration (see reconfiguration commands)
LOGON (see also LOGOFF)
ESTAI exit
loading 4-380
scheduling
error processing in RTM2 4-380
low storage verification and refresh 4-176
LP A (link pack area)
directory, searching 4-286-4-287
LPDE (link pack directory entry)
in searching the LPA directory 4-286
LRB (LOGREC record block)
in synchronous timer recovery 4-36
LSMQ (local service manager queue)
in dispatcher 4-54
in PURGEDQ 4-144
in SCHEDULE processing 4-138
LSPL (local service priority list)
in PURGEDQ 4-144
in SCHEDULE processing 4-138
machine check
in synchronous timer recovery 4-36-4-37
major name
in ENQ/DEQ/RESERVE 4-243
major QCB 4-242
manipulation of channel command control blocks by
program fetch 4-311
master address space, rescheduling R/TM in 4-368-4-369
master JCL
master TOD clock value calculation 4-32-4-33
MCH (machine check handler) use of RTMI
4-348
MCH logrec buffer 4-349
memory (see also address space, cross memory, virtual
memory)
priority, changing 4-164
switching 4-84
termination purges 4-410
MF/l
interval notification 4-22
MFA (malfunc.tion alert) interrupt processing 4-98
midnight value in TQE 4-22
minor QCB 4-242
minor name (rname)
in ENQ/RESERVE 4-243
MODESET routine, processing 4-268
mounting a volume (see volume mount & verify)
MP (see multi-processor system)
MSRDA or BASEA (master scheduler resident data area)
in TOD clock operator communication 4-30
MSS
MSS cleanup
in address space purge resource managers 4-416-4-417
in task purge resource manager 4-406-4-407
multi-unit generic (see MUG)
new address space (see address space)
normal EOT processing 4-328-4-329
notification
of address space termination or task termination
4-400, 4-424
obtaining space for TQE (timer queue elements)
in establishing timer intervals using STIMER 4-8
Operation (see Method of Operation Section)
operator TOD clock communication routine 4-30
operator console (see console)
operator restart interrupt handler, functions 4-116
Organization (see Program Organization Section)
override processing in interpreter
overlay supervisor 4-306
Index
1-5
page free request (see PGFREE)
page I/O error processing 4-324
page load (see PGLOAD)
parse (see IKJPARSE)
path, device (see device path)
PCCA (physical communications configuration area)
in asynchronous timer recovery 4-38
in emergency signal second level interrupt handler
4-128
in external call second level interrupt handler 4-126
in memory switching 4-84
in setting a specific TOD clock 4-26
in setting clock comparator 4-20
in signal service routines 4-120
in synchronous timer recovery 4-36
in TOD clock synchronization 4-32
in TOD clock status test 4-34
in TQE dequeue 4-14
in TQE enqueue 4-12
in TQE processing 4-22
PCCAT (physical communications configuration area vector
table)
in TOD clock status test 4-34
in TQE dequeue 4-14
PCCAVT (see also PCCAT)
in memory switching 4-84
percolation
in recovering a task 4-3904-391
PFK (see program function key)
PICA (program interruption communication ar~a)
in program check interrupt handler 4-110
in SPIE routine 4-250
in SYNCH routine 4-290
PIE. (program interruption element)
in program check interruption handler 4-104
in SPIE routine 4-250
in SYNCH routine 4-290
pool (see quick cell)
POST
error handling 4-229-4-233
processing 4-222
SRB processing for cross-memory post 4-226-4-229
post exit processing (VS2.03.80S)
function 4-222, 4-233 (VS2.03.80S)
PRB (program request block)
in LINK routine 4-280
in XCTL routine 4-300
priority (see CHAP) 4-214
processing TIME requests 4-6
processors, command (see command processing)
program check interruption handler 4-104
program fetch processing
interaction with LINK macro 4-288
interface to BLDL 4-288
processing 4-308
use 4-306
programmed timer
in establishing timer intervals using STIMER 4-8
programmer, writing to (see WTP)
prolog
exit 4-258
prompting exit (see pre-prompt exit, LOGON)
PSA (prefixed save area)
in dispatcher 4-54
in dispatching local SRBs 4-74
in dispatching local supervisor routines 4-76
in emergency signal second level interrupt handler
4-128
in external call first level interrupt handler 4-98
in external call second level interrupt handler 4-126
in I/O interrupt handler 4-94
in memory switching 4-84
in program check interruption handler 4-104
in restart interrupt handler 4-116
in routing to FRRs 4-354
in RTMI initialization 4-344
in SETLOCK 4-148
in SLIH processing 4-352
in stage 3 exit effector 4-134
in supervisor ,interruption handler 4-86
1-6
OS/VS2 System Logic Library Volume 4 (VS2.03.807)
in task dispatching 4-80
in validity check processing 4-162
in wait task dispatching 4-82
PSAANEW 4-84
PSAAOLD 4-84
PSW (program status word)
external call old 4-98, 4-126
in dispatching the wait task 4-82
in global SRB dispatcher 4-72
in I/O interrupt handler 4-94
in MODESET routine 4-268
in rescheduling locally locked tasks or SRBs
in SLIH processing 4-352
in SPIE routine 4-250
in SYNCH routine 4-290
in validity check processing 4-162
vait 4-82
PURGEDQ processing 4-144
purging SRB
in purging timer queue elements 4-16
purging timer queue elements 4-16
QCB (queue control block)
in ENQ/DEQ/RESERVE routine
QEL (queue element)
in ENQ/DEQ/RESERVE routine
queue verification 4-170
4-372
4-242
4-242
RB (request block) (see also VM & V request block)
in ATTACH routine 4-198
in exit prolog 4-258
in exit routine (lEAVOR) 4-256
in external call first level interrupt processing 4-98
in identify routine 4-296
in I/O interrupt handler 4-94
in MODESET routine 4-268
in POST processing 4-222
in program check interruption handler 4-104
in recovering a task. 4-388
in routing to searching routines 4-284
in RTM rescheduling 4-366
in SETLOCK 4-148
in SPIE routine 4-250
in status routine 4-260
in supervisor interruption handler 4-86
in SYNCH routine 4-290
in system directed task termination 4-370
in TESTAUTH routine 4-270
in WAIT processing 4-220
in XCTL routine 4-300
real frame (see page frame)
real TQE (timer queue element)
in timer error recovery 4-24
in TQE dequeue processing 4-14
in TQE enqueue processing 4-12
recording, error (see error recording)
recording task, asynchronous 4-468
recovery, error (see error recovery ESTAI)
recovery, FRR (see functional recovery routine)
recovery/termination (R/TM) 4-319
abnormal EOT (ABEND) 4-330
CANCEL command processing 4-332
cleanup processing 4-372
dump processing 4-335-4-336
hardware error processing 4-326
normal termination processing 4-328-4-329
overview 4-319
page I/O error processing 4-324-4-325
restart interrupt handling 4-116
retry 4-331
task recovery processing 4-388
terminating of an address space 4-333-4-334
recursion processing of errors
in SUPER FRR 4-172
remote pendable signal routine 4-123
requests, allocation
requests, region (see region requests)
requests, timer interval
in establishing timer intervals using STIMER 4-8
rescheduling
locall)" locked task or SRB 4-372
.
of R/TM in master scheduler address space 4-368
resources available
in ENQ/RESERVE routine 4-242-4-243
resource manager
for address space purge 4-411
for task purge 4-:403
resources manager (see system resources manager)
resources unavailable
in ENQ/RESERVE routine 4-242
restart (see also checkpoint/restart, DSS)
interrupt handler processing 4-116
restart interrupt handler 4-116
restarting (see restart)
resume processing (VS2.03.807)
function 4-191.6 (VS2~03.807)
retry
processing in recovering a task 4-388, 4-390
R/TM processing for 4-331
RF code in lockword in restart interrupt handler
4-116-4-117
RMPL (system resources manager parameter list)
in purging timer queue elements 4-16
RMS service routine, branching to from emergency signal
SLIH 4-128-4-129
routing
to searching routines (see also LINK routine) 4-284
to FRRs 4-354
RPSGNL macro instruction, processing in external call
SLIH 4-126
RQE (request queue element)
in stage 2 exit effector 4-132
in stage 3 exit effector 4-134
RSM (see real storage manager)
RTCT (recovery termination table)
in RTM rescheduling 4-366
R/TM (see recovery termination)
R/TM rescheduling in master scheduler's address space
4-368
RTMI cleanup 4-374
RTMI entry point processor 4-376, 4-344, 4-342
RTMI exit processing 4-376
RTMI initialization 4-344
RTMI overview 4-342
RTMI SLIH mode
services Eerformed 4-366, 4-370, 4-352, 4-371, 4-343
RTMIWA (RTM work area)
in clean up 4-374
in processing SLIH requests 4-352
in RTMI exit processing 4-352
RTM2 initialization 4-382, 4-385
RTM2 mainline controller 4-380-4-381
RTM2 overview 4-378
RTM2WA (RTM work area)
in recovering a task 4-388
SCA (SPIE control area)
in program check interruption handler 4-104
in SPIE routine 4-250
in SYNCH routine 4-290
SCB (STAE control block)
in ATTACH routine 4-198
in recovering a task 4-388
SCHEDULE macro instruction (see also PURGEDQ)
processing (scheduling SRBs) 4-138
scheduler (see job scheduler)
screen image buffer (see SIB)
SDWA (system diagnostic work area)
in ASCBCHAP processing 4-164
in asynchronous timer recovery 4-38
in checking a time interval using TTIMER 4-10
in ENQ/DEQ/RESERVE routine 4-242
in establishing timer intervals using STIMER 4-8
in identify routine 4-296
in LINK routine 4-278
in processing TIME requests 4-6
in PURGEDQ processing 4-144
in recovering a task 4-388
in routing to FRRs 4-354
in RTMI cleanup 4-374
in SCHEDULE processing 4-138
in SETLOCK 4-148
in SLIH processing 4-352
in setting a specific TOO clock use 4-26
in super FRR processing 4-172
in timer error recovey 4-24
searching TCB queue (in task dispatcher) 4-78
searching the LPA directory (lEAVLKOO) 4-286
second level interrupt handler (see SLIH)
security TESTAUTH processing 4-270
security switch on TOO clock, effect of releasing 4-33
service mode entries, processing in RTM 1 initialization
4-346
set clock comparator routine 4-20
SETDIE routine (VSl.03.807)
function 4-11.0 (VSl.03.807)
SIB (screen image buffer)
signal processor (see SIGP instruction)
signal routines (part of interprocessor communication)
direct signal routine 4-125
remote pendable signal routine 4-123
signalling other CPUs (signal service routines) 4-120
SIGP instruction
use in signal services routines 4-120
single line message (see WTO)
single thread queues, verifying
with header 4-170
SIRB (system interrupt control block)
in stage-3 exit effector 4-134
SLIH (second level interrupt handler)
emergency signal 4-128
external call 4-126
processing for RTMI 4-352
RTMI initialization, done to satisfy a request from a
SLIH 4-344
timer 4-18
SLIP (servicability level indication processing) 4-356-4-357
SLIP processing
function 4-360-4-361, 4-356-4-357, 4-362-4-363
SNAP dump processing 4-335
space, address (see address space)
SPIE routine 4-250, 4-254
FRR 4-251
SRB (service request block) (see also dispatcher)
cancelling in PURGEDQ routine 4-144
exit entry in dispatcher from POST 4-226global
dispatching 4-74
in dispatcher 4-54
in global SRB dispatcher 4-72
local
dispatching 4-74
in memory switch 4-84
in PURGEDQ processing 4-144
in rescheduling locally locked task or SRBs 4-372
in rescheduling RTM 4-366
in SCHEDULE processing 4-138
in stage 2 exit effector 4-132
in stage 3 exit effector 4-134
in status routine 4-260
in timer SLIH (second level interrupt handler) 4-18
in TQE processing 4-22
purging 4-16
removing 4-144
rescheduling 4-372
SSRB
in dispatching local SRBs 4-74
in program check interruption- handler 4-104
in rescheduling locally locked task or SRBs 4-372
in SETLOCK processing 4-148
stack, FRR ( see FRR stack)
STAE (set task asynchronous exit)
for SYNCH and LINK routine 4-280-4-281
service routine 4-430
for TTIMER 4-11
STAE/STAI relationship to recovery/termination 4-331
stage-l exit effector ~ 130
Index
1-7
stage-2 exit effector 4-132
stage-3 exit effector 4-134
STATE CHECK processing in TESTAUTH 4-270
statement (see JCL statement)
STATUS action codes 4-266
status, console (see console status)
status routine
processing 4-260
status, TOD clock
messages and return codes 4-31
testing for synchronization 4-34-4-35
STATUS STOP 4-266
STEPL (STAE exit parameter list)
STIMER processing 4-8, 4-10
STOP MONITOR command
storage, low, verifying 4-176
storage management (see real storage manager, virtual
storage management, system resources manager)
stream, input (see converter)
subsystem interface
resource manager
function 4-415
subsytem name, determination of 638
supervisor control
authorization checking in TESTAUTH 4-270
FRR 4-172
overview discussion of 4-41
supervisor interruption handler
determining SVC types 4-86
processing 4-86
suspend processing (VS2.03.807)
function 4-191.0 (VS2.03.807)
SVAREA parameter on ATTACH 4-203
SVC dump, scheduling 4-458
SVC dump
overview 4-336
processing 4-452
SVC dump resources manager 4-411
SVC dump task, posting of 4-460
SVC interruptions (see supervisor interruptions handler)
SVC routing 4-87
SVC 3 4-328
SVC 13
in system directed task termination 4-371
rescheduling 4-373
SVC 109 (see extended SVC routing)
SVC 116 (see extended SVC routing)
SVC 122 (see extended SVC routing)
SVCIH (see supervisor interruption handler).
SVRB (supervisor request block)
in ATTACH routine 4-198
in BLDL/program fetch interface 4-288
in checking a time interval using TTIMER 4-10
in identify routine 4-296
in LINK routine 4-278
in load routine 4-292
in SVC interruption handler 4-86
in SYNCH routine 4-290
in XCTL routine 4-300
switch address spaces, indicating need for in memory switch
routine
4-84
SYNCH macro instruction processing 4-290
synchronization check in timer SLIH 4-18
synchronization of TOO clock
allowing checks for 4-34
setting to match master clock 4-32
synchronous exit processing (SYNCH routine) 4-290
synchronous timer recovery routine 4-36
System Activities Measurement Facility (see MF/l)
system directed task termination 4-370
system log data set (see system log)
system mask, changing with MODESET 4-268
System Measurement Facility (see SMF)
system parameter library (see SYS1.PARMLIB)
system reconfiguration (see reconfiguration commands)
system recovery manager (resource managers)
for address space purge 4-411
for task purge 4-403
system resources manager (SRM) (see also workload
manager)
1-8
OS/VS2 System Logic Library Volume 4 (VS2.03.807)
interface
with SCHEDULE processing 4-140
with timer 4-22
interval notification 4-22
timer interface 4-22
system, stopping (see stopping)
system termination conditions 4-319
system trace (see trace, system)
system trace termination (see trace termination)
SYS1.LOGREC
recording 4-466
task
creation (ATTACH) 4-198
dispatcher
asynchronous exit processing 4-79
function 4-78
locally locked, rescheduling 4-372
purge processing 4-398
recovery 4-388
termination
abnormal (ABEND) 4-330
conditions for 4-320
in purging timer queue elements and timer SRBs
4-16
normal 4-328
system directed 4-370
TQE queue
placing element on 4-12
removing elements from 4-14
wait task dispatcher 4-82
task management
overview 4-193-4-197
task recovery processing 4-388
TCAM cleanup
in address space purge resource managers 4-412-4-413
in task purge resource mangers 4-404-4-405
TCB (task control block)
in ATTACH routine 4-198
in CHAP processing 4-214
in checking a time interval using TTIMER 4-10
in delete routine 4-294
in DETACH routine 4-206
in dispatcher 4-54
in exit prolog 4-258
in exit routine (lEAVOR) 4-256
in external call first level interrupt handler 4-98
in EXTRACT routine 4-254
in identify routine 4-296
in I/O interrupt handler 4-94
in LINK routine 4-278
in load routine 4-292
in MODESET routine 4-268
in POST processing 4-222
in program check interruption handler 4-104
in purging timer queue elements 4-16
in routing to searching routines 4-284
in RTM rescheduling 4-366
in SETLOCK 4-148
in SPIE routine 4-250
in stage 3 exit effector 4-134
in status routine 4-260
in supervisor interruption handler 4-86
in SYNCH routine 4-290
in system directed task termination 4-370
in task dispatching 4-78
in timer SLIH (second level interrupt handler) 4-18
in TQE dequeue 4-14
in TQE enqueue 4-12
in validity check processing 4-162
in XCTL routine 4-300
TCWA (TOO clock work area)
,
in setting a specific TOO clock use 4-26
in TOO clock operator communication 4-30
in TOO clock status test 4-34
in TOD clock synclironization 4-32
termination, address space 4-426
purging timer queue elements 4-16
termination, task
abnormal (ABEND) 4-330
ip. purging timer queue elements and timer SRBs. 4-16
normal 4-328
system directed 4-370
terminator (see initiator/terminator)
TESTAUTH routine 4-270
text, internal (see converter, internal text)
TIME macro instruction processing 4-6, 4-9
error checking 4-7
time limit checking, canceling
in TQE purge routine 4-16-4-17
time
GMT specified for TIME requests 4-6
interval unit conversion in TTIMER 4-10-4-11
local
obtaining from a valid TOD clock for TIME requests
4-6-4-7
time wait limit, checking for a job step 4-23
timer, checking hardware status 4-39
timer components
checking in synchronous timer recovery 4-36-4-37
error count of component in error in CSD 4-37
in establishing TQE using STIMER 4-9
interruption types
clock-comparator 4-19
CPU timer 4-19
synchronous check 4-19
SLIH, processing of 4-18-4-19
timer, CPU
error recovery, asynchronous timer 4-38-4-39
interrupt type 4-19
timer error recovery
asynchronous timer recovery 4-38-4-39
synchronous timer recovery routine 4-36
timer FRR 4-24-4-25
timer EST AE processing
TIME service routine 4-7
timer interval
checking 4-22, 2-198
establishing TQEs using STIMER 4-8
timer second level interrupt handler (see timer SLIH)
timer service routines 4-3-4-38
timer SLIH 4-18-4-19
timer supervision overview 4-3
timer unit conversion
in establishing TQEs using STIMER 4-9
in processing TIME requests 4-7
timing intervals
calculating remaining interval in TTIMER 4-10
cancelling in TTl MER 4-10
setting (STIMER) 4-18-4-19
TIOT manager control routine
TaD (time-of-day) clock
high-order synchronization, test for 4-35
in processing TIME requests 4-6
in set specific clock (SSC) routine 4-26-4-27, 4-29
in asynchronous timer error recovery routine 4-38-4-39
manager 4-38, 4-34, 4-32, 4-30
master value calculation 4-33
operator communications 4-30-4-31
security switch 4-32-4-33
setting local time and date 4-31
status
messages 4-31
return codes 4-31
test 4-34-4-35
synchronization routine 4-30, 4-32, 4-34, 4-38
task-type request to STIMER 4-9
TPC (timer work area)
in asynchronous timer recovery routine 4-38
in processing TIME requests 4-6
in set clock comparator routine 4-20
in set specific clock (SSC) routine 4-26, 4-28
in STIMER service routine 4-8
in synchronous timer recovery routine 4-36
in timer FRR 4-24
in timer SLIH (second level interrupt handler) 4-18
in TaD clock operator communication routine 4-30
in TaD clock status test routine 4-34
in TaD clock synchronization routine 4-32
in TQE enqueue routine 4-12
in TQE processing routine 4-22
in TQE purge routine 4-16
TPCA (see TPC)
TQE (timer queue element)
dequeuing because of TTIMER CANCEL 4-10-4-11
in timer FRR 4-24-4-25
in TQE dequeue routine 4-14-4-15
enqueuing
in timer FRR 4-24-4-25
in TQE enqueue routine 4-12-4-13
freeing space for in TTIMER service routine 4-10-4-11
in TTIMER service routine 4-10-4-11
in establishing TQEs using STIMER 4-9
in TQE purge routine 4-16-4-17
in set specific clock (SSC) routine 4-26-4-29
in set clock comparator routine 4-20-4-21
in synchronous timer recovery 4-36-4-37
in timer SLIH (second level interrupt handler)
4-18-4-19
midnight field, updating 4-22.;.4-23
processing routine 4-22-4-23
real, queue
dequeueing in TQE dequeue routine 4-14-4-15
enqueueing in TQE enqueue routine 4-12-4-13
verification in timer FRR 4-24-4-25
task queue
de queueing TQEs from 4-14-4-15
enqueueing TQEs on 4-12-4-13
TQETYPE indicator
in TQE dequeue 4-15
in TQE enqueue 4-13
trace, system (see also trace termination)
processing 4-168
TSO LOGON (see LOGON)
TTl MER processing 4-10
unit affinity (see allocating affinity requests)
unit, allocating request to (see allocating requests to units)
unit, timer conversion
in establishing timer intervals using STIMER 4-9
in processing TIME requests 4-7
unset TaD clock, testing for 4-34
user error exit
in checking a timer interval using TTIMER 4-11
in establishing timer intervals using STIMER 4-9
in processing TIMER requests 4-7
user, swapping (see swap-in, swap-out)
validity checking an address or address range' 4-162
values, IPS (see IPS values)
volume serial number (see VOLSER)
volume, specific allocation (see specific volume allocation
control)
volume unload control (see IEFAB494 object module)
volunit table
VSM (see virtual storage management)
VSPC (VS2.03.805)
post exit processing 4-225,4-233 (VS2.03.805)
SVC screening 4-46,4-47 (VS2.03.805)
VT AM cleanup
in address space purge resource managers 4-412-4-413
in task purge resource managers 4-404-4-405
WAIT macro instruction processing (see also POST)
4-220
wait PSW 4-82
wait task, dispatching 4-82
wait TQE interval requests in STIMER 4-8
write-to-programmer (see WTP)
XCTL service routine 4-300
FRR 4-304
XMPOST
processing 4-222-4-223
XSA (extended save area)
in manipulation of command control blocks
4-308
\ Index
1-9
I-tO
OS/VS2 System Logic Library Volume 4 (VS2.03.807)
OS/VS2
System Logic Library
Volume 4
SY28-0764-0
READ.ER'S
COMMENT
FORM
Your views about this publication may help improve its usefulness; this form
will be sent to the author's department for appropriate action. Using this
form to request system assistance or additional publications will delay response,
however. For more direct handling of such requests, please contact your
IBM representative or the IBM Branch Office serving your locality.
Possible topics for comment are:
Clarity
Accuracy
Completeness
Organization
Index
Figures
Examples
Legibility
(')
s.
g
."
o
0::
»
0'
:::I
,
OQ
5'
CD
What is your occupation?
Number of latest Technical Newsletter (if any) concerning this publication:
Please indicate your name and address in the space below if you wish a reply ..
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.)
SY28-0764~O
.
o
s..
~'
."
o
a:
Your comments, please ..•
l>
o::l
This manual is part of a library that serves as a reference source for system analysts,
programmers, and operators of IBM systems. Your comments on the other side of this
form will be carefully reviewed by the persons responsible for writing and publishing
this material. All comments and suggestions become the property of IBM.
Fold
(JQ
,...
. ~.
'<11
I
- - - - - - - - - - - - - - -----~
Fold
-
:"""
First Class
Permit 81
Poughkeepsie
New York
,I
I
I
I
Business Reply Mail
~o
•
postage stamp necessary if mailed in the U.S.A.
Postage will be paid by:
I nternational Business Machines Corporation
Department D58, Building 706-2
PO Box 390
Poughkeepsie, New York 12602
-----------------------~
Fold
Fold
U
...c
"
a
C
......
to
~
C
llrn~
(!)
International Business Machines Corporation
Data Processing Division
1133 Westchester Avenue, White Plains, New York 10604
(U.S.A. only)
IBM World Trade Corporation
821 United Nations Plaza, New York, New York 10017
(International)
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 : 2012:06:08 20:06:39-08:00 Modify Date : 2012:06:10 06:02:04-07:00 Metadata Date : 2012:06:10 06:02:04-07:00 Producer : Adobe Acrobat 9.51 Paper Capture Plug-in Format : application/pdf Document ID : uuid:e80e21de-1eef-4459-8263-1d195ae1b017 Instance ID : uuid:52cc27ce-fad0-4cf3-ba2e-b91f0d565bd4 Page Layout : SinglePage Page Mode : UseNone Page Count : 534EXIF Metadata provided by EXIF.tools