SY28 0763 0_OS_VS2_System_Logic_Library_Vol_3_Rel_3.7_Jul76 0 OS VS2 System Logic Library Vol 3 Rel 3.7 Jul76
User Manual: SY28-0763-0_OS_VS2_System_Logic_Library_Vol_3_Rel_3.7_Jul76
Open the PDF directly: View PDF 
.
Page Count: 632
| Download | |
| Open PDF In Browser | View PDF |
5Y28-0763-0
File No. 5370-36
Systems
OS/VS2
System Logic Library
Volume 3
VS2.03.804
VS2.03.807
VS2.03.810
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:
Scheduler Improvements
Supervisor Performance #2
IBM 3800 Printing Subsystem
VS2.03.804
VS2.03.807
VS2.03.810
The selectable unit to which the information applies, is noted in the upper comer-of the page.
First Edition (July, 1976)
This is a reprint of SY28-071S-0 incorporating changes released in the following
Selectable Unit Newsletters:
SN28-2683 (dated May 28, 1976)
SN28-2692 (dated May 28, 1976)
SN28-2698 (dated May 28,1976)
This edition applies to Release 3.7 of OS/VS2 and to all subsequent releases of OS/VS2 until
otherwise 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-0001, 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, Publications Development,
Department D58, Building 706-2, PO Box 390, Poughkeepsie, N.Y. 12602. Comments become
the property of IBM.
© Copyright International Business Machines Corporation 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-071 S
Method of Operation diagrams for
System Resources Manager (SRM)
System Activity Measurement Activity (MF /1 )
JOB Scheduling
-Subsystem Interface
-Master Subsystem
-Initiator /Terminator
-SW A Create Interface
-Converter /Interpreter
-SW A Manager
-Allocation/U nallocation
-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 S 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 acronynts, 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/VS2 System Logic Library Volume 3 (VS2 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 System Initialization Logic,
SY28-0623
VS2.03.807
Contents
3-1
Section 2: Method of Operation . .
3-3
System Resources Manager (SRM)
3-5
SRM Interface . . . . . .
3-5
Locking Considerations
3-6
Method-of-Operation Diagrams
3-6
6-1. SRM Interface (IRARMINT)
3-6
..
6-1. SRM Interface (IRARMINT) (VS2.03.807)
3-9.2
6-1 A. SRM Service Routine (IRARMSRV) (VS2.03.807)
3-9.6
6-lB. Obtain/Free SQA Storage (IRARMI04) (VS2.03.807)
3-9.8
6-1C. Requeue SRM TQE (IRARMI05) (VS2.03.807)
SYSEVENT Processor . . . . .
· 3-11
List of SYSEVENTs (VS2.03.807)
· 3-11
6-2. SYSEVENT Processor . . . . . . .
· 3-12
SRM Control . . . . . . . . . . . . .
· 3-23
6-3. SRM Control (IRARMCTL) . . . .
· 3-24
6-4. Timer Action Analysis (IRARMCAT) .
· 3-26
6-5. Deferred Action Processor (IRARMCEN)
· 3-28
6-6. Algorithm Processor (IRARMCEL) . . .
· 3-30
6-7. Periodic Entry Point Scheduling (IRARMCET)
· 3-32
6-8. Full Analysis (IRARMCAS)
· 3-34
6-9. Partial Analysis (IRARMCAP) . .
· 3-36
6-9. Swap Analysis (IRARMCAP)
· 3-36
6-10. Control Swap-In (IRARMCSI)
· 3-40
6-11. Control Swap-Out (IRARMCSO) . . . . .
· 3-42
6- 11 A. Select User for Swap-In (IRARMCPI) (VS2.03.807)
3-43.0
6-1 lB. Select User for Swap-Out (IRARMCPO) (VS2.03.807)
3-43.2
6-11 C. User Evaluation (IRARMCVL) (VS2.03.807)
3-43.4
Resource Use Algorithms
· 3-45
Storage Management . . . . .
· 3-45
I/O Management . . . . . . . .
· 3-45
CPU Management . . . . . . .
· 3-45
Resource Monitor (VS2.03.807)
· 3-45
6-12. Storage Management (IRARMSTM) . . . . .
· 3-46
6-12. Main Storage Occupancy Analysis (IRARMMS2)
· 3-52
6-14. I/O Management (IRARMIOM) . . . :...... .
· 3-54
6-15. I/O Load Balancing Swap Analysis (IRARMIL2)
· 3-56
6-16. I/O Load Balancing User I/O Monitoring (IRARMILO)
· 3-58
6-17. CPU Management (IRARMCPM) . . . . . . . . . .
· 3-62
6-18. CPU Load Balancing Swap Analysis (IRARMCL2)
....
· 3-66
6-18. Resource Monitor Periodic Monitoring (IRARMRM 1) (VS2.03.807)
· 3-66
6-18A. Resource Monitor MPL Adjustment Processing (IRARMRM2)
(VS2.03.807). . . . . . . . . . . . . . . . . . . .
· 3-68
Workload Management . . . . . . . . . . . . . . . . .
· 3-69
Workload Management(IRARMWLM) (VS2.03.807)
· 3-69
6-19. Swappable User Evaluation (IRARMWM2) (VS2.03.807)
· 3-70
6-20. Individual User Evaluation (IRARMWM3) (VS2.03.807)
3-73.0
6-21. User Ready Processing (IRARMHIT) (VS2.03.807)
3-73.2
6-22. Initialize for MF /1 (IRARMWR 1) (VS2.03.807) . .
3-73.6
6-23. Collect Data for MF/l (IRARMWR2) (VS2.03.807) . .
3-73.8
System Activity Measurement Facility (MF/1) . . . . . . . . . .
· 3-75
Method-of-Operation Diagrams . . . . . . . . . . . . . . .
· 3-80
7-1. Measurement Facility Control (MFC) Mainline (IRBMFMFC)
· 3:-80
7-2. Input Merge Control (IRBMFINP)
· 3-82
7-3. Syntax Analyzer (IRBMFANL) . . .
· 3-84
7-4. List Option Subroutine (MFLISTOP) . . . . . . . . . . .
· 3-86
7-5. MFSTART Mainline (IGXOOOI3) . . . . . . . . . . . . .
· 3-88
7-6. Initialization Mainline (MFIMAINL) . . . . . . . . . . .
3-90
7-7. CPU Activity Initialization (IRBMFICP) or Paging Activity Initialization
(IRBMFIPP) . . . . . . . . . .
3-96
7-8. Workload Initialization (IRBMFIWK)
3-98
7-9. Channel Initialization (IRBMFIHA) . .
3-100
7-10. Device Initialization (IRBMFIDV) . .
3-104
7-11. Data Control (IRBMFDT A)
3-106
7-12. Termination Processor (IRBMFTMA)
3-110
7-13. MF/l Message Processor (IRBMFMPR)
3-112
7-14. MFDATA SVC Mainline (IGXOOOI4)
3-114
7-15. Interval MG Routine for CPU (IRBMFDCP)
3-118
Contents 5
VS2.03.807
7-16.
7-17.
7-18.
7-19.
7-20.
7-21.
7-22.
7-23.
7-24.
7-25.
Interval MG Routine for Paging (IRBMFDPP)
3-122
Interval Routine for Workload (IRBMFDWP)
3-126
3-130
Interval MG Routine for Channels (IRBMFDHP)
3-134
Interval MG Routine for Devices (IRBMFDDP)
MFROUTER SVC Processor (IRBMFEVT) . . .
3-138
Channel Sampling Module (IRBMFECH)
3-140
3-142
Second CPU Test Channel Sampling Module (IRBMFTCH)
3-144
Device Sampling Module (IRBMFEDV) . . . . . . . . .
........
3-146
Report Generator Control (IRBMFRGM)
Report Generators for CPU, Paging, Workload, Channels, and Devices
(IRBMFRCR, IRBMFRPR, IRBMFRWR, IRBMFRHR, and IRBMFRDR)
3-150
Job Scheduling Overview
3-153
Subsystem Interface . . . . . .
3-159
3-164
Method of Operation Diagram
8-1. Subsystem Interface .
3-164
Master Subsystem . . . . . . . .
3-169
Method-of-Operation Diagrams
3-172
3-172
9-1. Common Request Router (IEFJRASP)
9-2. Subsystem Determination (IEFJSDTN)
3-174
3-176
9-3. Subsystem Initiation (IEFJJOBS) . . .
9-4. Converter/Interpreter Interface (IEFJCNTL)
3-178
9-5. Pseudo Access Method (IEFJACTL)
3-182
3-186
9-6. Subsystem Initiation Message Writer (IEFJWTOM)
9-7. Data Set Name Assignment (IEFDSNA)
3-188
3-190
9-8. Subsystem Job Termination (IEFJJTRM)
Initiator/Terminator
......
3-193
Method-of-Operation Diagrams
3-196
3-196
10-1. Initiator: Job Initiation
10-2. Initiator: Step Initiation
3-200
10-3. Initiator: Step and Job Deletion
3-208
10-4. Initiator: Recovery Processing .
3-212
3-215
SWA Create Interface . . . . . . . . . .
Method-of-Operation Diagram
3-216
3-216
11-1. SW A Create Interface (IEFIB600)
Converter/Interpreter . . . . . . . . . . .
3-223
Method-of-Operation Diagrams . . . . .
3-223
3-224
12-1. Converter: Initialization (IEFVH 1)
12-2. Converter: Identifying Verbs on JCL Statements
3-226
3-230
12-3. Converter: Processing Commands in the Input Stream (IEFVHM)
12-4. Converter: Processing In-Stream and Cataloged Procedures
3-232
(IEFVINA) . . . . . . . . . . . . . . . . . . . . . . .
12-5. Converter: Processing Symbolic Parameters (IEFVFA, IEFVFB)
3-234
3-236
12-6. Converter: Converting Statements to Internal Text (IEFVFA)
3-240
12-7. Converter: Entering Defaults into Internal Text (IEFVFA)
3-242
12-8. Converter: Termination (IEFVHF) . . . . . . . . .
12-9. Interpreter: Initialization (IEFNB903) . . . . . . .
3-246
.....
3-248
12-10. Interpreter: Analyzing Parameter Values
3-252
12-11. Interpreter: Creating and Chaining Tables (IEFVGT)
12-11. Interpreter: Writing Tables into SWA (IEFVHH)
3-256
3-258
12-13. Interpreter: Termination (IEFVHN)
SWA Manager . . . . . . . . . . . . . . . . .
3-261
Method-of-Operation Diagrams . . . . . . . .
3-264
3-264
13-1. SWA Manager: Move Mode (IEFQB550)
13-2. SWA Manager: Locate Mode (IEFQB555)
3-266
Allocation/Unallocation . . . . . . . . .
3-269
3-271
Introduction to Allocation/Unallocation
Batch Initialization and Control
3-271
Dynamic Initialization and Control .
3-271
JFCB Housekeeping . . ... . . . .
3-271
Common Allocation Control . . . .
3-271
Data Set Requests and Unit Requests
3-271
Order of Processing Requests
3-271
Generic Allocation Control
3-272
Recovery Allocation
3-273
The Retry Situation
3-273
Processing Tape Requests
3-273
Common Un allocation Control .
3-275
3-275
Volume Mount- & Verify (VM&V) Control
3-275
AllocatioIi/Unallocation Module Name Conventions
Organization of Allocation/Unallocation Method-of-Operation Diagrams
3-275
6
OS/VS2 System Logic Library Volume 3 (VS2.03.807)
VS2.03.807
Selected Terms Used in Allocation/Unallocation
Method-of-Operation Diagrams . . . . . . . .
14-1. Common Allocation Control (IEFAB42l)
14-2. Fixed Device Control (IEFAB430) . . .
14-3. Specific Volume Allocation Control (IEFAB433)
14-4. Allocate Request to Unit (IEFAB434) . . . . .
14-5. Nonspecific Volume Allocation Control (IEFAB436)
'.
14-6. JFCB Housekeeping Control (lEFAB45t)
14-7. DD Function Control (IEFAB454) . . .
14-8. JLOCATE (IEFAB469) . . . . . . . .
14-9. Generic Allocation Control (IEFAB471)
14-10. Allocation Via Algorithm (IEFAB476)
14-11. Demand Allocation (IEFAB479)
14-12. Recovery Allocation (IEFAB485) . . .
14-13. Offline/Allocated Device Allocation (IEFAB486)
14-14. Common Allocation Cleanup (IEF AB490) . . .
14-15. Allocation/Volume Mount & Verify (VM&V) Interface (IEFAB492)
14-16. Volume Mount & Verify (VM&V) Control (IEFAB493)
14-17. Initiator/Allocation Interface (lEFBB40t) .
14-18. Initiator/Unallocation Interface (IEFBB4I0)
14-19. Job Unallocation (IEFBB416)
.... .
14-20. SVC 99 Control (IEFDB400) . . . . . . .
14-21. Dynamic Allocation Control (IEFDB41O)
14-22. Dynamic Unallocation Control (IEFDB4AO)
14-23. Dynamic Concatenation (IEFDB450) . . .
14-24. Dynamic Deconcatenation (IEFDB460) . .
14-25. Dynamic Information Retrieval (IEFDB470)
14-26. Remove In-Use Attribute (IEFDB480)
14-27. Ddname Allocation (IEFDB490) . . . . .
14-28. Common Unallocation Control (IEFAB4AO)
14-29. Disposition Processing (IEFAB4A2)
14-30. Unit Unallocation (IEFAB4A4) . . . . . .
System Mangement Facilities (SMF) . . . . . . . . .
Method-of-Operation Diagrams . . . . . . . . . .
15- 1. Writing SMF Records (IEEMB829, IEEMB830)
15-2. Switching SMF Data Sets (IEEMB829) . . . .
15-3. ST AE Exit Processing for SMF (IEEMB825)
15-4. SMF Cross-Memory POST Error Exit (IEEMB827)
System Log
................ .
Method-of-Operation Diagrams . . . . . . . . .
16-1. System Log Initialization (IEEMB803) .
16-2. Terminating the System Log (IEEMB803)
16-3. Switching Log Data Sets (IEEMB803)
16-4. Log Writer Processing (IEEMB803)
16-5. Processing Log Task Abnormal Termination (IEEMB806)
16-6. Writing Data on the System Log (IEEMB804)
Checkpoint/Restart .
DSDR Processing
The Job Journal .
Journal Routines .
Method-of-Operation Diagrams
17-1. Processing Data Set Descriptor Records (IEFXB609)
17-2. Job Journal to SW A Merging (IEFXB601)
17-3. Step Continue Processing (IEFXB60l)
17-4. System Restart Processing (IEFXB60 t) . .
17-5. Automatic Checkpoint Restart (IEFXB60t)
17-6. Automatic Step Restart (IEFXB60t) . . .
17-7. Merge Cleanup (IEFXB60t) . . . . . . .
17-8. Updating the Virtual Addresses in SW A (IEFXB601)
17-9. Journal Merge Reading (IEFXB60t) . . . . . . . .
17-10. Journal Merge Error Processing (IEFXB60I) . . . .
17-11. Restart Interface Processing (IEFXB602)
.. .. .
17-12. Building a Step Header Record for Job Journal (IEFXB604)
17-13. Preparing Abended Job Step for Restart (IEFRPREP)
17-14. Writing Blocks to the Job Journal (IEFXB500)
17-15. Journal for Restarted Jobs (IEFXB500)
Index
3-276
3-280
3-280
3-294
3-298
3-302
3-308
3-314
3-322
3-334
3-338
3-348
3-354
3-358
3-366
3-378
3-386
3-390
3-396
3-402
3-410
3-412
3-414
3-416
3-418
3-420
3-422
3-424
3-428
3430
3-440
3-444
3-447
3-450
3-450
3-454
3-458
3-460
3-463
3-466
3-466
3-470
3-472
3-474
3-476
3-480
3-483
3-483
3-483
3-483
3-486
3-486
3-492
3-494
3-496
3-498
3-500
3-502
3-504
3-506
3-508
3-510
3-512
3-516
3-520
3-525
1-1
Contents 7
VS2.03.807
System Resources Manager (SRM) Visual Contents . . . . .
. 3-4
SRM Module/Entry Point Cross Reference (VS2.03.807)
3-3.2
Processing Algorithms and Actions in IRARMCTL (VS2.03.807)
3-23.2
RMEP Algorithm and Acti()n Invocation Flags (VS2.03.807)
3-23.3
System Activity Measurement Facility (MF/t) Visual Contents
. 3-79
Job Scheduling: Initiation of the Master Scheduler . .
3-164
Job Scheduling: Initiation of the Job Entry Subsystem
3-165
Job Scheduling: START/LOGON/MOUNT Initiation
3-166
Job Scheduling: Normal Job Entry and Initiation
3-167
SiJbsystem Interface Summary . . .
3-171
Master Subsystem Visual Contents .
3-179
Initiator/Terminator Visual Contents
3-203
Converter Visual Contents
3-223
Interpreter Visual Contents
3-245
General Format of a SW A Control Block and an Example of the JFCB
as it Appears in SW A . . . . . . . . . . . . . . . . . . . . 3-262
2-19 SW A Manager Visual Contents . . . . . . . . . . . . . . . 3-263
2-20 Relationship of the Six Major Functions of Allocation/Unallocation . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-267
2-21 Allocation/Unallocation Functions and Related Method-of-Operation
Diagrams . . . . . . . . . . . . . . . . . . . . . .
3-270
2-22 The Division of Generic Device Types into Device Groups.
3-272
2-23 Tape Device Types and Supported Densities . . . . . . .
3-274
2-24 Tape Device Eligibility . . . . . . . . . . . . . . . . .
3-274
2-25 Batch and Dynamic Allocation/Unallocation Visual Contents
3-277
2-26 Common Allocation Visual Contents . . . . . . . .
3-279
2-27 Function Map of Common Allocation Parameter List
3-293
2-28 Function Map of JFCB Housekeeping Parameter List
3-321
2-29 System Management Facilities (SMF) Recording: Visual Contents 3-449
2-30 System Log Visual Contents . . . . . . . . . .. .
3-465
2-31 Job Scheduler Checkpoint/Restart: Visual Contents . . . . . . 3-485
Figure
2-9
Figure 2-9A
Figure 2-9B
Figure 2-9C
Figure 2-10
Figure 2-11
Figure 2-12
Figure 2-13
Figure 2-14
Figure 2-15
Figure 2-16
Figure 2-17
Figure 2-17 A
Figure 2-17B
Figure 2-18
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
8
OS/VS2 System Logic Ubrary Volume 3 (VSl.03.807)
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. The 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
START/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.
SWA Manager.
- Allocation/Unallocation.
- System Management Facilities (SMF).
- System Log.
- Checkpoint/Restart.
• Timer Supervision.
• Supervisor Control.
• Task Management.
• 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
3-1
. . . Primary pr......!ng -Indl ..... malor functional flow .
. . . ._~ Secondary processing - indicates functional flow within a diagram.
'--_--.>
-
-~
Data movement, modification, or use.
Data reference -
indicates the testing or 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.
- ....t~'---..... Indirect pointer - indicates intermediate pointers have been omitted.
--D
Connector - indicates that a diagram is continued on the next page.
Figure .2-1. Key to Symbols Used in
3-2
Method~f-operation
Diaarams
OS/VS2 System Logic Libruy Volume 3 (VS2 Release 3.7)
VS2.03.807
System Resources Manager (SRM)
1
/
In MVS, address spaces may be swapped into or
out of real storage. When an address space is
swapped out, its entire working storage is moved to
auxiliary storage, and the real page frames it
formerly occupied may be used for paging activity
or to swap in a previously swapped-out address
space. The system resources manager (SRM) is the
system's swap decision maker. By swapping, the
SRM attempts to manage the system to
predetermined multiprogramming levels (MPLS)
within domains of work as indicated in the IPS.
Domains provides a mechanism of controlling
how many of a group of users are swapped in at
one time. That is, a domain associates a
multi-programming level (MPL with aggregate or
group users. The total MPL is the number of
swappable memories in real storage at a given time.
When the SRM's resource monitor determines that
the total MPL may increase, the MPL of one domain
will be incremented by one. Similarly, the MPL of
one domain is decremented when the total MPL
should be lowered. The domain descriptions in the
IPS indicate ranges for the MPL of each domain and
a weighting factor for each domain which indicates
to the SRM which domain to increment or
decrement should a change in the system MPL be
required.
Also, SRM monitors the system resources of
CPU, I/O, and storage. It keeps statistics and uses
them. to make swap decisions that can prevent
either a depletion or an under-utilization of these
resources.
Specifically:
• SRM maintains data concerning real and
auxiliary storage. It uses the real storage
manager (RSM) and the auxiliary storage
manager (ASM) to keep track of frame (RSM)
and slot (ASM) usage. Using this data SRM is
able to detect shortages and use swapping to
correct them..
• SRM monitors the I/O resource and makes
decisions concerning the allocation of devices
based on I/O load balancing considerations.
• SRM monitors and controls CPU utilization
through its ability to balance the CPU load
through swapping and by its ability to
maintain the automatic priority group (APG).
The SRM's structure consists of five functional
groupings:
• The interface function is the means through •
which other system components communicate
•
with the SRM, and through which the SRM
requests the services of other system
components.
• The SYSEVENT processor analyzes
communications to the SRM and translates
them into requests for specific SRM services.
It also formulates responses as required by
the SYSEVENTs.
• The control function performs swapping
analyses, obtains swap recommendations from
other SRM components, and translates these
recommendations into specific swapping
decisions. It also requests that previously
deferred SRM functions be performed when it
is possible to do so.
• The resource use algorithms consist of CPU,
I/O, and storage management functions,
which monitor the utilization of these
resources, and make swapping
recommendations that affect their future use.
Also, as a result of this monitoring,
recommendations to raise or lower individual
domain multiprogramming levels (MPLS) are
made and adjustments to the MPLs occur
within the constraints of the IPS.
• The workload manager function attempts to
maintain each address space's usage of system
resources (their service) as specified for
different user classes in the IPS (Installation
Performance Specification). It exercises this
control by influencing the Control function's
swapping decisions. Additionally, the
workload manager interfaces with MF/l so
that reports concerning the rates of system
resources usage can be easily obtained.
The primary way in which the installation may
affect the functioning of the SRM is by changing
the tuning parameters and the IPS parameters.
These are explained in more detail in the OS/VS2
MVS Initialization and Tuning Guide. The SRM's
principal control block is the resources manager
control table (RMCT). All SRM routines and
subroutines have access to this table and can access
most other SRM blocks via pointers in the RMCT or
by displacements from the origin of the RMCT. The
origin of the RMCT is the entry point of
Section 2: Method of Operation 3-3
VS1.03.807
IRARMCNS t the SRM constants module .. This
module contains all the control tables t constants
and parameters of execution of the SRM as well as
pointers to all the key SRM routines.
The SRM maintains a control block (OUCB)
associated with each active address space. OUCBs
are maintained on one of three queues, depending
on the status of the associated address space:
"IN" queue
- consists of address spaces
currently in real storage.
"OUT" queue - consists of address spaces
currently swapped out of real
storage and awaiting SRM
analysis for swap-in.
3-3.0
OS/VSl System Logic Ubnry Volume 3 (VSl.03.807)
"WAIT" queue
• consists of address spaces
currently swapped out of real
storage and in "long wait"
status.
SRM is packaged as several modules, but each
module does not directly correspond to a unique
SRM function. Specifically, each function in SRM. is
identified by an entry point in one of the modules
that comprise the SRM component. Figure 2·9A
summarizes all SRM entry points and shows in what
module the entry point exists. A description of
each entry point is included at the end of the
section in which its containing module is
diagrammed.
Section 2: Method of Operation
3-3.1
VS2.03.807
~
MODULES
~
no
U
~
0:
«
SRM
ENTRY POINTS
!:!:
CHAP
CPLRVSWF
CPUTLCK
CPUWAIT
IGC095
IRAPRCSR
IRARMAP1
IRARMASM
IRARMCAP
IRARMCEO
IRARMCEL
IRARMCEN
IRARMCET
IRARMCLO
IRARMCL1
,IRARMCL3
IRARMCPI
IRARMCPO
IRARMCOT
IRARMCRO
IRARMCRL
IRARMCRN
IRARMCRT
IRARMCRY
IRARMCSI
IRARMCSO
IRARMCVL
IRARMOEL
IRARME01
IRARMHIT
IRARMIOO
IRARMI01
IRARMI02
IRARMI03
IRARMI04
IRARMI05
IRARMI06
IRARMI07
IRARMI09
IRARMI10
IRARMI48
IRARMILO
IRARMIL1
IRARMIL3
IRARMIL4
IRARMIPS
IRARMMS2
IRARMMS6
IRARMNOP
IRARMPR1
X
X
X
X
..J
0:
w
>
w
t-
U
Z
Q
0:
0:
0:
0:
!:!:
!:!:
!:!:
!:!:
t-
~
0:
«
!:!:
o:
~
«
l-
~
«
~
«
~
~
«
0:
>
~
0:
0:
(I)
(I)
~
0:
0:
~
~
«
!:!:
OS/VS2 System Logic Library Volume 3 (VS2.03.807)
~
«
!:!:
t-
~
«
~
..J
~
~
0:
0:
!:!:
!:!:
«
«
~
0:
«
!:!:
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Figure 2-9A. SRM Module/Entry Point Cross Reference (Part 1 of 2)
,3-3.2
0:
X
X
X
X
VS2.03.807
~
MODULES
SRM
ENTRY POINTS
"
I
/
IRARMPR5
IRARMRM1
IRARMRM2
IRARMRPS
IRARMRR1
IRAAMRR2
IRARMSOA
IRARMTRC
IRARMUXB
IRARMWM1
IRARMWM2
IRARMWM3
IRARMWM4
IRARMWM5
IRARMWM7
IRARMWMI
IRARMWMJ
IRARMWMK
IRARMWMN
IRARMWMO
IRARMWMO
IRARMWMR
IRARMWMY
IRARMWR1
IRARMWR2
IRARMWR3
IRARMWR4
IRARMWR5
IRARMWR6
IRARMWR7
IRARMWR8
IRARMXPS
IRARMXTL
LCHUSE
NEWDP
RMRR1CKO
RMRR2GST
RMRR21NT
RMRR2PER
RMRR2REO
RMRR2RTY
RMRR2SPR
RMRR2VFB
RMRR2VLD
STEAL
I-
0:
0:
l-
:!
:!
:!
:!
«
«
«
«
:!
Q.
(,)
0:
~
..J
(,)
0:
~
w
0:
~
>
w
0:
~
0:
«
:!
:!
:!
:!
«
«
«
:!
>
0:
:!
Q
:!
:!
:!
:!
«
«
«
«
I-
z
0:
~
:!
0:
~
0:
0:
~
en
0:
~
I-
en
0:
~
0:
3:
0:
~
..J
3:
0:
~
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Figure 2-9A. SRM Module/Entry Point Cross Reference (Part 2 of 2)
Section 2: Method of Operation
3-3.3
VS2.03.807
I
6-1
SRM
Interface
(IRARMINT)
I
I
6-2
SYSEVENT
Processor
(lRARMEVT)
I--
I
---t--I
I
--,
6-3
I
I
I
SRM
Control
I
I
(lRARMCTL)
LE~"!!!OL
r--~
I
I
I
I
l
I
I
I
I
I
6-6
Algorithm
Processor
(IRARMCEL)
I
I
I
6-5
I
Deferred
Action
Processor
I
I
(lRARMCEN)
I
I
l
6-9
Swap
Analysis
I
6-7
Periodic
Entry Point
Scheduling
(lRARMCAP)
(lRARMCET)
l
I
6-10
Control
Swap-In
(lRARMCSI)
I 6-11A
Select User
For Swap-In
(lRARMCPI)
I 6-11
Control
Swap-Out
(lRARMCSO)
l 6-118
Select User
For Swap-Out
(lRARMCPO)
I 6-11C
User
Evaluation
(lRARMCVL)
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
- - __________ J
Figure 2-9. System Resources Manager (SRM) Visual Contents (Part 1 of 3)
3-4
OS/VS2 System Logic Library Volume 3 (VS2.03.807)
VS2.03.807
WORKLOAD MANAGER
SERVICE
r-------l
I
I
I
I
I 6-1A
SRM Service
Routine
(lRARMSRV)
I
I
I 6-18
I
I
I
I
Obtain/Free
SOA Storage
(lRARMI04)
II
I
I
Requeue
SRM TOE
I
(lRARMI05)
I
L
6-1C
I
I
I
I
I
I
I
I
I
I
II
I
I
I
_______ ..J
r--------,
l
NO
I
I
6-12
SRM Resource
Monitor
SRM Storage
Management
(lRARMRMR)
(lRARMSTM)
I
I
l
I
NO
SRM
Workload
Manager
(lRARMWLM)
I
6-18
I
6-19
Resource
Monitor
Periodic
Monitoring
Swappable
User
Evaluation
(lRARMRM1)
(lRARMWM2)
I
I
I
I
I
I
I
I
I
I
I
16-18A
6-20
Individual
User
Evaluation
Resource
Monitor
MPL
Adjustment
Processing
(lRARMWM3)
(lRARMRM2)
I
6-21
User Ready
Processing
I
(lRARMHIT)
I
I
I
I
I
I
I
I
I
I
L _______ J
Figure 2-9. System Resources Manager (SRM) Visual Contents (Part 2 of 3)
Section 2: Method of Operation
3-4.1
VS2.03.807
I/O MANAGEMENT
r-------l
MFI1INTERFACE
r-------l
I NO
I
I
6·17
Supply SRM
Data to MF/1
SRM CPU
Management
O(IRARMWAR)
(lRARMCPM)
I
I
I
I 6·14
SRM I/O
Management
(lRARMIOM)
I
I 6·22
Initialize
For MF/1
I
I
I
(lRARMWR1)
I
I
I
6·23
(IRARMWR3)
L _ _ _ _ _ _ -.J
Figure 2-9. System Resources Manager (SRM) Visual Contents (Part 3 of 3)
OS/VS2 System Logic Library Volume 3 (VS2.03.807)
SRM I/O Load
Balancing User
I/O Monitoring
(lRARMILO)
L _ _ _ _ _ _ -.J
Collect Data
ForMF/1
3-4.2
I 6·16
VS2.03.807
SRM Interface
Other system components communicate with the
SRM by means of the SYSEVENT macro instruction.
SYSEVENTs fall into three classes:
• Address space SYSEVENTS are issued to notify
the SRM of a change in status for a particular
address space.
• System status SYSEVENTs are issued to notify
the SRM of a change in status applicable to
the system as a whole.
• SRM services SYSEVENTs are issued to request
particular SRM support functions.
The SRM interface receives control as a result of
the execution of a SYSEVENT macro instruction.
The 'SYSEVENT macro serves as an extended
routing function based on the SYSEVENT code
generated by the SYSEVENT macro from the
specified mnemonic name operand. Each individual
SYSEVENT code represents a logically distinct
interface to the system resources manager, with its
own circumstances, its own input and output
conventions, and its own resultant system resources
manager actions. The use of the SYSEVENT macro
is restricted to those components/modules which
have reached prior agreement with system
resources manager module owners. The SYSEVENT
macro instruction generates either a branch or svc
entry (SVC 95) into the SRM. Branch entry callers
must be in supervisor state, key 0-7, and associated
data areas must be fixed. Disabled page faults that
occur when user data areas are referenced will
cause the SYSEVENT issuer to be abnormally
terminated (ABEND code '15P'). Branch entry
callers must also pass, in register 13, the address of
a 72-byte save area, which can be stored into by
using the caller's key. The SYSEVENT issuer is
responsible for serializing the use of this save area
(via disablement, global or local lock).
SYSEVENT 38 requires no authorization.
SYSEVENTs 41 and 42 either require APF
authorization or must be issued from a program
that the initiator recognizes as "DONTSWAP"
authorized (ASCBNSWP='I' at initiator attach
time). All other SYSEVENT issuers using the SVc
entry facility must be APF authorized, and
associated data areas must be fixed. Unauthorized
use of the svc entry, or page faults occurring while
referencing user data areas, will cause the
SYSEVENT issuer to be abnormally terminated
(ABEND code ' 15P').
The SRM interface passes control to the
SYSEVENT processor for processing related to the
particular SYSEVENT; depending upon the
SYSEVENT, the SRM may then perform further
processing not necessarily related to the invoking
SYSEVENT. Thus many SYSEVENTs serve not only
as status change notifiers or service requestors, but
also as occasions for performing a wide-range of
SRM processing.
The SRM interface also processes requests from
internal SRM routines servicing system components.
These include such services as cross memory post,
obtaining SQA storage and issuing a
Write-to-Operator (WTO) message. The interface
function is used to provide a common point of
invocation and simplified access for internal SRM
routines. The service interface routines are
packaged together in the IRARMSR V module, each
routine having its own entry and exit point. See the
M.O. Diagrams for more detail.
SRM Error Recovery
One functional recovery routine (FRR) provides
recovery for all of the SRM routines. The address
of this routine is identified to the recovery
termination manager (RTM) at the beginning of
SRM processing, when obtaining the SRM lock for
non-globally locked entries and upon entry for
globally locked .entries. The FRR (address) is
cancelled upon exit from SRM processing. The only
section of the SRM component not covered by the
functional recovery routine is the (non-globally
locked) code preceding the obtaining of the SRM
lock; such code is restricted from performing any
updating of system data.
The functional recovery routine recovers SRM
from a percolated error, from machine checks, from
the restart key, and from program checks. The
routine requests that error recording/storage
dumping be performed, supplying additional
information about the error.
The processing performed by SRM's FRR
depends upon the nature of the error. The actions
taken for different errors are described below.
1. If the ABEND macro was issued by SRM, or
if the restart key was depressed recursively,
the error is percolated.
2. If the error occurred in the SRM workload
activity recording routine, the MFI task is
abended. If SRM was running in the same
address space as the MFI task, the error is
percolated.
3. If a translation or protection exception
occurred in SYSEVENT processing, the
abend code is changed to X'ISF'. The FRR
Section 2: Method of Operation
3·~
VS1.03.807
validates queues and status data maintained
by SRM and percolates the error.
4. For other errors occurring within SRM, the
FRR validates queues and status data
maintained by SRM and performs a retry of
the SRM routine that failed. If the error is
repeated, and if the error is associated with
an action or algorithm, another retry is
attempted bypassing the routine in error.
Otherwise, the error is percolated.
The SRM interface also processes requests from
internal SRM routines, servicing other system
components. The SRM interface M.O. diagram
illustrates the functioning of. this sUbcomponent.
The issuing of most SYSEVENTs prior to SRM
NIP processing (performed by lEAVNPlO) will result
in a direct return to the issuer without any SRM
processing. An exception is SYSEVENT RSMCNSTS
(22), for which normal processing will be
performed.
Locking Considerations
All issuers of enabled, branch entry SYSEVENTs
must hold the local lock when the SYSEVENT is
issued.
The SRM lock will be obtained by the SRM on
all SYSEVENT entries to the SRM except the
following SYSEVENTs:
3-5.0
OS/VSl System LogIc Ubrary Volume 3 (VS1.03.807)
USERRDY (4)
SWOUTCMP (15)
SWPINST (16)
RSMCNSTS (22)
AVQLOW (23)
AVQOK (24)
SQALOW (25)
SQAOK (26)
SYQSCST (35)
SYQSCCMP (36)
It is required that issuers of the above
SYSEVENTs be disabled on issuing the SYSEVENT,
because the SRM uses cPu-related save areas while
processing these SYSEVENTs. Issuers of other
SYSEVENTs (those not listed above) must not hold
any global locks higher in the system locking
hierarchy than the· SRM lock when they issue the
SYSEVENT. These issuers must not hold the SRM
lock. SRM must be able to obtain the SRM lock
when entered via any of these SYSEVENTS.
The method-of-operation diagrams that follow
describe the specific functions performed by the
SRM interface. The functions are:
• SRM Interface (IRARMINT).
• SRM Service Routine (IRARMSRV).
/
Section 2: Method of Operation
3-5.1
~
Diagram 6-1. SRM Interface (IRARMINT)
i
Input
~
~
(part 1 of 4)
From
SYSEVENT Issuer
.
...
Process
~
SRM Interface
i
i
azt"'I
~
i
w
~
~
Q
w
-
Output
r'------------------------------------------~
1
Verify that the SRM invocation is valid.
2
Obtain SRM lock. if required.
3
Establish an error recovery environment.
IRASECHT
SYSEVENT
Characteristics
Table
D
Functional Recovery
Routine Stack
SRM FRR
Address
VlI-------~
ASCB
I
ASCBOUCB
00
S
Time of
Century
Clock
Register 0
Register 1
I
IJ
From SYSEVENT
Processor or
SRM Control
(tRARMCTL)
RMCT
4
Perfor":, initialization for SYSEVENT
processIng.
5
Process the SYSEVENT.
i/I
To SYSEVENT
Processor
(tRARMEVT)
(See
SYSEVENT
Processor M.O.)
,GTF Data Set
6
Trace the SYSEVENT via GTF
(generalized trace facility)
7
Release the SRM error environment.
Register 15
'"
~
/"
'- _efT
Diagram 6-1. SRM Interface (IRARMINT) (Part 2 of 4)
Extended Description
Module
The SRM Interface receives control when a SYSEVENT
macro instruction is issued, or when the SRM requests
the services of another system component. When the
interface receives a SYSEVENT, it performs the locking
necessary to ensure that SRM functions which must be
serialized are not performed simultaneously on more than
one CPU. SRM requests the SRM lock unconditionally
before passing control to the SYSEVENT processor. If
the lock is held by another CPU, the lock manager will
spin waiting for the lock to be released. Otherwise, SRM
will acquire the lock and continue processing. In either
case the SRM lock serializes SRM processing in a
multi-CPU environment.
IRARMINT
1
IRARMINT IGC095
For all SYSEVENTs that generate supervisor call
entries to the SRM (SVC 95), except for SYSEVENT
REQSERVC (38), the issuer must be authorized. For
SYSEVENTS 41 and 42, "DON'T SWAP" authorization
is valid. For all other SYSEVENTs, the user is
considered authorized only if he is executing in supervisor
state or protection keys 0-7, or is authorized by APF
(authorized program facility).
ForSYSEVENTs that generate a branch entry to the
SRM, the issuer must be executing in protection key 0-7,
and must be in supervisor state.
2
CI.l
(D
(')
g.
=
~
s::
(D
s-o
t:\.
o....
o
't:I
o·~
=
loW
..:...
Label
IRARMSRV
Module
4
Before passing control to the SYSEVENT processor, a pointer is obtained to the SRM user
control block (OUCB) corresponding to the input
ASID (address space identifier); for SYSEVENT
MEMCREAT, there will not yet be an OUCB (an
OUCB is obtained by IRARMEVT if no Resource
shortages exist). The current time-of-day is obtained
and formatted for SRM use. The time-of-day clock
value is stored and shifted 22 bits to the right, and
the rightmost 32 bits of the resulting value are used
by the SRM. Therefore, SRM constants representing
time are in units of 1024 microseconds
(approximately 1 millisecond).
IRARMINT IRARM001
5
IRARMEVT
The interface invokes the SYSEVENT processor
to initiate the appropriate processing (see
SYSEVENT PROCESSOR table).
6
"IRARMIOO
IRARMINT IRARMOOO
3
IRARMINT RMINT005
Label
<:
CI.l
N
o
loW
A GTF trace record is produced (via the HOOK
macro) if GTF is active. This record includes:
• Register 0 (as input, except that the ASID is placed
here even when it was not included as input).
The SYSEVENT characteristics table indicates, for
each SYSEVENT entry, whether or not the SRM
lock must be obtained for SRM serialization purposes.
The SRM is protected from unexpected errors via
a functional recovery routine (FRR). The processing
will be performed for an error situation depends upon
whether or not the SRM lock was held (see ERROR
PROCESSING, below)'
Extended Description
IRARMINT
• Register 1 (as input, with the addition of possible
return indicators which may overlay input data).
• Register 15 (containing any necessary return code
in byte 3).
7
The address of the SRM FRR is removed from the
system FRR stack.
IRARMINT IRARMI01
00
o
-...J
'of
co
I Diagram 64. SRM Interface (IRARMINT) (part 3 of 4)
~
~
N
fIl
Ib'
~.
8
Release the SRM lock if it was obtained
in step 2.
9
Return the service data if this entrywas
due to SYSEVENT REQSERVC.
Register 1
t
t"'"
a:
!<
~
a
(D
Register 4
Register 5
Register 6
y'"
.....~ User Data
Area
VI
c..I
'<
fIl
N
Q
c..I
00
~
~ Retumto
.
SYSEVENT.
Issuer
1
I
<
fIl
N
Q
c..I
00
~
""'~
~_
J
Diagram 6-1. SRM Interface (IRARMINT) (Part 4 of 4)
Extended Description
Module
8
The SRM lock will have been obtained if the invoking routine did not already hold a lock higher in the
locking hierarchy than the SRM lock (except for
SYSEVENTS SYQSCST and SYQSCCMP).
9
To prevent disabled page faults and an invalid SRM
invocation, and to insure system integrity, the
service data is stored while not holding the SRM lock, and
in the user's protection key.
Error Processing
The issuer of a SYSEVENT will be abnormally terminated
(ABEND code '15F'X) if:
• an invalid ASID or SYSEVENT code was supplied
(reason code 4).
• the program was not authorized to issue the SYSEVENT
(reason code 8).
• a page fault occurred in referencing a data area assumed
to be fixed (reason code 12).
• the program did not have the correct storage key for
storing into a parameter data area (reason code 16).
• the SRM lock was held on entry to the SRM (reason
code 20).
c;n
(p
()
....
g.
N
is::
(p
SO
~
o.....
o
'0
~o·
::l
~
~
A SYSEVENT issuer will be terminated (ABEND code
'25F') if the SRM determines that a system failure has
resulted in the loss of data used by the SRM in controlling an address space. Similarly, the System Activity
Measurement Facility (MFI1) task, and the Set IPS task
will be terminated (ABEND code '25F') when the SRM
receives an error occurring during SRM processing relating
to a Set to New IPS command or to the collection of
workload activity data for MF/1.
IRARMINT
Label
Extended Description
Module
RMINT010
A functional recovery routine (FRR) provides the error
recovery environment for SRM processing. When an error
occurs during SRM processing (or when an error occurring in
a routine invoked by the SRM has been passed back (percolated) to the SRM), the recoveryltermination manager
gives control to the SRM FRR. If the SRM was operating
without holding the SRM lock when the error occurred, error
processing will consist of making one attempt at retrying
the failing routine; a second failure will result in the error
being passed to the previous routine in the FRR stack. If
the SRM was operating under the SRM lock when the
error occurred, the FRR will perform queue validation
before making an attempt at retrying the failing
IRARMERR
routine; queue validation consists of verifying that the
three OUCB queues are properly chained (re-chaining where
necessary), and that OUCBs, OUXBs (user control block
extensions), and OUSBs (user swappable blocks) exist and
are valid, where they are required. Likewise, the pointers
between the ASCBs and OUCBs is checked. Where it is
necessary to create a new OUCB or OUXB, a bit is set in
the OUCB to indicate that the data reflected in these
newly created blocks may not be valid.
On errors occurring during SRM locked processing, retry
action depends upon whether the error occurred during
SYSEVENT related or non-SYSEVENT related processing. For SYSEVENT-related processing, 1 retry will be
attempted. Subsequent failure will result in the error
being passed to the previous routine !n the FRR stack.
For non-SYSEVENT-related processing (i.e., processing
which SRM control was driving), 1 retry of the failing
routine will be attempted. A second error will case an
attempt to bypass the twice failing routine. Subsequent
errors will result in the error being passed to the previous
routine in the FRR stack.
Label
IRARMRR1
IRARMRR2
<:
c;n
N
RMRR2VLD
o
~
00
o
-...J
VS2.03.807
IRARMINT Module Entry Point
Summary
IGC095 - SVC entry
IRARMIOO - Branch
point to SRM.
entry point to SRM.
Handle all external SYSEVENTs.
IRARMI48 - Branch entry point to SRM.
Handle the internal SYSEVENT. (48).
IRARMIOI - Entry point from RARMEVT or
RARMCTL.
Return to the SYSEVENT issuer.
IRARMIIO - Entry point to SRM.
Abend a user of SRM.
3-9.0
OS/VS2 System Logic Library Volume 3 (VS2.03.807)
/
Section 2: Method of Operation
3-9.1
w
~
Diagram 6-1A. SRM Service Routine (IRARMSRV) (part
10(6)
~
From I RARMCPM,
IRARMCTL or IRARMEVT
oCIl
"<
CIl
~
Input
Process
Output
CIl
'<
~
;9
r-'
o
Register 1
Dispatching Queue
'G.
(")
r-'
s:
IRARMI02.
Invoke ASCBCHAP to reorder the
listed ASCBs on the dispatching
queue.
~
~c
9(II
ASCBCHAP
'
I"
Return to
Caller
(JRARMCPM,
IRARMCTL, or
IRARMEVT)
w
--'"
Register 1
IRARMI03.
Call real page frame replacement.
Return to
Storage
Management
(JRARMSTM)
~
;;j
~
o
w
00
S
"._/
~.3!1""
.,
Diagram 6-1A. SRM Service Routine (IRARMSRV) (Part 2 o(6)
fI'l
(D
n
g.
::t
~
f
[
o....
o
1a
g.
~
~
CN
Extended Description
Module
Label
(or Segment)
This module is a collection of several independent routines
which act as interfaces between SRM and various system
services.
IRARMSRV
IRARMSRV
IRARMI02
Reposition the listed ASCBs in the ASCB dispatching
queue to reflect their new dispatching priorities.
IRARMSRV
IEAVEACO
IRARMI02
IRARMI03
Update UICs in pages belonging to all users listed.
Steal pages from users which then have UICs that
meet the steal criterion.
IRARMSRV
IEAVRFR
IRARMI03
<:
fI'l
N
b
CN
00
Q
......
~
\C
I Diagram 6-1A. SRM Service Routine (IRARMSRV)
(part 3 of 6)
:..
FromSRM
Routines
~
"<
1;12
Output
Input
~
1;12
'<
i
9
r-
ei.n
Register 1
or Free Address
r-
§=
~
<
~
9(II
Obtain free storage in SOA.
GETCELL
or
Register 0
~
~
Register 1
Request Size
Q
!,N
14 Storage
!,N
<
or
Q
IEAVGMOO
1;12
~
00
S
Return Code
!,N
00
GETMAIN/.
FREEMAIN
S
/
Return to
Caller
From Periodic Entry
Point Scheduler (I RARMCET)
Register 1
I Timer Value
I· I
IRARMI05.
~ Update the SRM TOE and queue
it on the system timer queue.
ENOTOE
Routine
TOE
[TQEVAL
Return to
Caller
(lRARMCET)
I
Diagram 6-1A. SRM Service Routine (IRARMSRV)
(part 4 of6)
Label
(or Segment)
Extended Description
Module
IRARMI04
Obtain free SQA storage either from a cell in
'RM1' cellpool or from other available SQA.
(See Obtain/Free Storage (lRARMI04) M.O.)
IRARMSRV IRARMI04
IEAVGTCL or
IEAVFRCL or
IEAVGMOO
IEAVBLDP
IRARMI05
Store a new timer value in the SRM TQE and queue
the TQE on the system timer queue. (See Requeue
SRM TQE (lRARMI05) M.O.)
IRARMSRV
IEAVRTIO
IEAVRTIO
IRARMI05
IEAQTDOO
IEAQTEOO
<:
fI)
~
b
~
Co
Q
.......
fI)
~
i
~
~
i
o
o""
}.
~
i.A
~
I Diagram 6-1A. SRM Service Routine (IRARMSRV) (put 5 of6)
\0
~
orI'.l
~
~
From SRM
Routine
Output
Input
rI'.l
i
t"'"
Register 1
~.
[1-
f')
t"'"
0:
~
Register 5
[+
~
a
IRARMI06.
Post an ECB in another memory.
ECB
ASCB
Il
ECB
Cross
Memory Post
: >I
~
<
rI'.l
Return to
Caller
N
o
(D
W
(.oN
00
~
o
.....
From Control
Swap-In (lRARMCSI)
~
(:,
(.oN
00
Q
.....
Register 5
[TUASCB
-
•
IRARMI07.
"
Schedule an SRB to initiate a
swap in.
From Storage
Management (lRARMSTM)
Register 1
•
I
List Form of
WTO Message
IRARMI09.
Invoke record facility to issue a
WTO to the system operator.
Return to
Storage
Management
(lRARMSTM)
ESC1
Return Code
D
>7
~
Diagram 6-1A. SRM Service Routine (IRARMSRV)
?
(part 6 of 6)
Extended Description
Module
Label
(or Segment)
IRARMI06
This entry point is used by the swap-out routine to
post the region control task (for example).
If an error is encountered during the cross memory
post, the error routine (lRARMXPE) gets control
and attempts cleanup while running under an FRR.
IRARMSRV
IRARMI06
IEAOPT01
IRARMSRV
IEAOPT01
IRARMXPE
IRARMI07
Initiates a swap-in, gets an SR8 and schedules it to
run the RSM swap in routine (lEAVSWIN) in the
master memory.
IRARMSRV
IEAVGTCL
IEAVESCO
IRARMI07
IEAVGTCL
IEAVESC1
IRARMI09
The record facility is invoked to issue a WTO to the
system operator console because the requesting
SRM routines hold the lock and cannot therefore
issue a WTO.
IRARMSRV
IRARMI09
IEAVTRER
IEAVTRER
<
c:I:l
N
(:,
w
00
c:I:l
~
::t.
g
~
==
(D
[
o....
o
'tS
g.~
w
~
:....
0
-..l
l.f
I
Diagram 6-18. Obtain/Free SQA Sto~ge (IRARMI04) (Part 1 of 2)
\C)
00
~
1--._--
Go to step 1.
4
Return Code
Do GETMAIN or
FREEMAIN.
GETMAINI
FREEMAIN
Return to
Caller
->
,,_ f
~
"~-'
Diagram 6-1B. Obtain/Free SQA Storage (IRARMI04) (Part 2 of 2)
Extended Description
Module
Label
(or Segment)
This routine is used by the SRM for obtaining and freeing
control blocks in key 0, subpool 245 storage (SQA).
IRARMSRV
IRARMI04
IEAVGTCL
IEAVFRCL
IEAVGTCL
Request processingfollow5 the same procedure for both
obtaining and freeing storage. If register 0 contains zero,
the request is a get.
1
If the request length matches the cellsize for the
IRARMRM1 cellpool, call GETCELL or FREECELL.
Otherwise, go to step 4.
<
en
~
Q
2
If the GETCELL or FREECELL fails, call GETMAIN
or FREEMAIN, for a 2048-byte block. Otherwise,
return to caller of IRARMI04 and the GETMAINI
FREEMAIN return code becomes the IRARMI04 return
CoN
IEAVGMOO
00
C
'-01
code.
3
If a GETMAIN was done and was successful,
issue BLDCPOOL to segment the returned storage
into cells. If BLDCPOOL succeeds, go to step 1.
Otherwise, return to the caUer.
IEAVBLDP
IEAVBLDP
4
IRARMSRV
IEAVELK
IEAVGMOO
GETSTOR or
FREESTOP
Get the SALLOC lock and perform a GETMAIN
or FREEMAIN for the or1ginal request size. Then
release the SALLOC lock. The GETMAIN/FREEMAIN
return code becomes the IRARMI04 return code.
fIl
i
~
I
~
o
1
i
:::a
w
~
\0
..
w
\0
Diagram 6-le. Requeue SRM TQE (1RAItMIOS) tput 1 of 2)
o
~
~
N
From Periodic ,Entry
Point Scheduler (JRARMCET)
..
t
C'Il
'<
~
Register 1
~.
I
b
roe
J
Timer Value
I
RMCT
~
g
RMCTTOC
w
RMCTTSS
II
Outout
Process
Registers 6, 7
">
r
1
>B
Convert timer value to
64 bit format.
I
<:
I
C'Il
N
Q
w
00
Q
~N
.....
S
00
,§
TOE
I
TOEOFF.O
I
IEAOTDOO
t.>
r
2
If currently on system
timer queue, dequeue TOE.
Otherwise go to step 3.
II.
...
...
r
TOE Dequeue
Routine
TOE
Registers 6# 7
I
Enqueue the TOE with
..> 3. the
new converted timer.
to.
1
value.
..,'. .-
IEAOTEOO
TOE Enqueue
Routine
(lRARMCET)
I
>
TOEVALI
~
Diagram6;.lC. Requeue SRM'TQE (lRARMIOS)
(part 2 of 2)
Extended Description
Module
Label
(or Segment)
This routine updates the SRM timer queue element with
a new timer value and enqueues the element on the system
timer queue..
IRARMSRV
IRARMI05
1
Convert timer value to hexidecimal format.
IRARMSRV
IRARMI05
2
Dequeue·timer queue element (TQE) if currently
queued. This is done under the. dispatcher lock.'
IEAVRTIO
IEAQTDOO
3
Enqueue the TQE. This is done while holding
the dispatcher lock;
IEAVRTIO
IEAQTEOO
<
fI)
N
o
W
00
S
fI)
i·
:s
~
iC
CD
~
2-
o
I
w
~
;..
3-9.12
OS/VS2 Sy.temLopc Libruy Volume 3 (VS2.03.807)
VS2.03.807
IRARMSRV Module Entry Point
Summary
IRARMI02 - ASCB CHAP entry point.
IRARMI03 - Real Page Frame Repla
IRARMI04
IRARMI05
IRARMI06
IRARMI07
IRARMI09
-
7ement entry
point.
Obtain or Free SQA Storage.
Requeue SRM TQE Routine;
Cross-Memory Post entry point.
Swap SRB SCHEDULE Routine.
RECORD entry point.
IRARMERR Module Entry Point
Summary
Functional Recovery for Globally
Locked Entries (entries to SRM in
which the SRM lock could not be
obtained).
Retry the failing SRM routine when
possible. Otherwise percolate the error.
RARMRR2 - Functional Recovery for Non-Globally
Locked Entries (entries to SRM in
which the SRM lock was obtained).
Validate queues and cleanup. Retry the
failing routine if possible; otherwise,
percolate the error.
RMRR2RTY - Return to RTM indicating retry.
RMRR2PER - Return to RTM indicating percolation.
RMRR2INT - FRR initialization.
RMRR2VLD - Validate control blocks.
RMRR2GST - Release the dispatcher lock in order
to call IRARMI04.
RMRR2CKQ - Verify the location of an OUCB.
RMRRIVFB - Verity addresses.
RMRR2REQ - OUCB enqueue routine entry point.
RMRR2SPR - Return with the return code in register
15.
IRARMRR 1 -
I!>;.\
v
)
Section 2: Method of Operation
3-9.13
3-10 OS/VS2 System Logic Library Volume 3 (VS2.03.807)
VS2.03.807
SYSEVENT Processor
The SYSEVENT processor function (IRARMEVT)
receives control from the interface function to
perform processing related to the SYSEVENT, and,
in most cases, to request the services of other
internal SRM routines. In a multiprocessing
environment the system may not be able to
perform some of these routines immediately
because of concurrent SRM processing on another
cpu. In these cases, execution of the requested
routines is deferred until a later SRM invocation.
Listed are all SYSEVENTs in alphabetical order
along with their associated codes.
The next diagram lists the SYSEVENTs
(numerically by code), the situation occasioning
their issuance, information passed to and returned
from them, internal SRM routines that they may
explicitly invoke, the functions of these routines,
and any exceptional notes about the SRM action
taken as a result of a SYSEVENT. Also, this
diagram indicates for each SYSEVENT whether the
SRM lock is obtained by the SRM interface routine
and where control passes after the SYSEVENT is
processed. All SYSEVENTs receive the associated
SYSEVENT code (listed below the SYSEVENT name)
as input information (in byte 3 of register 0),
although this information is not explicitly
mentioned in the figure. Where an ASID is listed as
input, it is passed in register 0, bytes and 1.
Note that some SYSEVENTs do not hold the SRM
lock. These SYSEVENTs return directly to the SRM
interface for return to the issuer. Most other
SYSEVENTs exit to the SRM control function, which
may then invoke algorithm processing. Thus, for a
given SYSEVENT entry to the SRM, processing may
be performed that is unrelated to the purpose of
the original SRM entry.
°
ALTCPREC (33)
AVQOK (24)
AVQLOW (23)
BRINGIN (44)
CONFIGCH (29)
COPYDMDT (40)
DEV ALLOC (28)
DONTSWAP (41)
ENQHOLD (20)
ENORLSE (21)
INIT ATT (to)
INITDET (11)
JOBSELCT (8)
JOBTERM (9)
MEMCREAT (6)
MEMDEL (7)
NEWIPS (32)
NIOWAIT (3)
OKSWAP (42)
QSCEFL (18)
QSCEMCP (13)
QSCEST (12)
RSMCNSTS (22)
REQPGDA T (39)
REQSERVC (38)
REQSVDAT (49)
REQSW AP (43)
RESETPG (31)
RSTORCMP (19)
SETDMN (37)
SQALOW (25)
SQAOK (26)
.sWINFL (17)
SWOUTCMP (15)
SWPINST (16)
SYQSCCMP (36)
SYQSCST (35)
TERMW AIT (2)
TGETTPUT (34)
TIMEREXP (1)
USERRDY (4)
VERIFYPG (30)
WKLDCOLL (46)
WKLDINIT (45)
WKLDTERM (47)
(48)
Section 2: Method of Operation 3-11
cr
t
~
fI)
w
fI)
I
I Diagram
6-2. SYSEVENT Processor (part 1 of 16)
Information
SVSEVENT
Routines Invoked
When Issued
Returned
Passed
TIMEREXP
(1)
SRM timer interval
has expired.
r"'"
o
Indication whether
TOD clock
initialization (01)
or not (00).
(register 1, byte 3).
None
~.
Periodic Entry Point
Scheduling
(IRARMCET).
8
TERMWAIT
(2)
(D
1M
Issued by TGET or
TPUT when a user
enters terminal
wait.
'<
til
W
Q
1M
00
S
Resets the "time due"
fields of the time
driven queue according to the current
time, for TOD
initialization.
~------ ~-
r"'"
c;:
~a
Periodic Entry
Point Initialization
(lRARMWMY).
Function of Invoked
Routine
NIOWAIT
(3)
Issued by WAIT
macro processing
when some task in
an address space
enters long wait.
USERRDY
(4)
An SRB has been
scheduled for an
address space for
which QUI ESCE is
running, or for a
swapped out
address space.
MEMCREAT
(6)
MEMDEL
(7)
• ASID.
• Input (00) or
output (SO)
indication.
(register 1,
byte 0).
None
• ASID.
None
Control Swapout
(lRARMCSO)'
SRM Action
This SYSEVENT
provides the exclusive
means for invoking the
majority of the SRM
algorithms.
SRM Lock
Held
Exit To
Yes
SRM
Control
(lRARMCTL)
Yes
SRM
Control
(lRARMCTL)
---- ---
See Periodic Entry
Point Scheduling
M.O.
See Control Swapout
M.O. called for
swappable users.
<:
til
W
Q
1M
00
S
. Control Swapout
(lRARMCSO).
See Control Swapout
M.O. called for
swappable users.
Yes
SRM
Control
(lRARMCTL)
I
!
• ASID.
None
User Ready
Processing
(IRARMHIT).
The ready user is
placed on the "OUT"
queue.
An ASID has been
associated with a
new address space
and space has been
obtained for an
ASCB and OUSB.
.ASID.
• START(01)/
LOGON(02)/
MOUNT(03)
indication.
(register 1,
byte 0).
Indication whether
or not memory
creation should not
proceed because of
a resource shortage.
(OO-proceed
SO-do not
proceed).
(register 1, byte 0)_
Storage Request
(lRARMI04)'
Obtain storage for an
OUCB and OUXB if
no resource shortages
exist.
Storage associated
with an ASCB is
about to be freed,
and an ASID
disassociated with
an address space.
• ASID.
Indication that
memory delete may
not proceed and
must wait.
-04 (register 1 ,
byte 3).
User-ready processi ng
is performed through
the action request
routine.
No
Invoker Via
IRARMI01
Yes
SRM
Control
(lRARMCTL)
Yes
SRM
Control
(IRARMCTL)
-- ---- --- ------- -User-Control
-- Place
Block
user on "in"
User Control Block
Repositioning
(IRARMRPS).
queue.
OUCB and OUXB
delete
(lRARMDEL).
Free storage associated OUCB and OUXB
with an OUCB and an
delete is pe.rformed
OUXB, and indicate
indi rectly, through
that memory delete
action request routine.
processing may proceed
by issuing XMPOST to
the Master Memory.
Repositioning is
performed through the
action request routine.
··_~7
Diagram 6-2. SYSEVENT Processor (part 2 of 16)
Information
SYSEVENT
When Issued
Returned
Passed
JOBSELCT
(8)
JOBTERM
(9)
til
(D
()
g.
=
~
INITATT
(10)
An address space
has begun using
system services, on
behalf of a new job,
START or MOUNT
command, or a
TSO session.
• ASIO.
None
Routines Invoked
Control Swapout
(lRARMCSO).
• Address of jobname or user-id.
• Performance
Group number
(register 0,
byte 2).
An address space
has completed
using system
resources on behalf
of a job, START or
MOUNT command,
or a TSO session.
• ASIO.
Whenever an
initiator attaches
a task.
• ASIO.
• Performance
Group number.
(register 1,
byte 2).
Transaction Stop
Routine
(IRARMWMO).
;
g.
=
'of
w
SRM
Control
(lRARMCTL)
~
N
o
W
00
Q
-...I
This SYSEVENT
revokes authorization
for starting new
transactions.
Yes
SRM
Control
(lRARMCTL)
None
Transaction
Resume Processing
(lRARMWMR).
Resumes a suspended
transaction, if the
performance group
number for a new nonTSO job step is the
same as for the
previous step; otherwise starts a new
transaction.
SRM validates the
performance group
number indicated for
the address space. I f it
is not valid, a default
value is assigned. If
the input dispatching
priority is in the APG,
the SRM will follow
the IPS specification
for this user.
Yes
SRM
Control
(JRARMCTL)
8-
~
Yes
Exit To
Updates the accumulated time and service
for a transaction. Also
indicates that the
current transaction has
ended. If workload
activity reporting is
active, invokes
IRARMWR4to
accumulate report
information.
~
1 - - - - - - - - - f-- - - - - - - -
• Dispatching
Priority.
(register 1,
byte 3).
This SYSEVENT
authorizes the
accumulation of service
for the job. SRM
validates the performance group number
indicated for the
address space. I f it is
not valid, a default
value is assigned.
SRM Lock
Held
Transaction Stop
Routine
(JRARMWMO).
(D
~
Updates the accumulated time and service
for a job. Also
indicates that the
current transaction has
ended or been suspended. If workload
activity reporting is
active, invokes
IRARMWR4 to
accumulate report
information.
SRM Action
None
• Address of jobname or user-ide
o
Called to swapout an
address space if a
second level auxiliary
page shortage exists or
an excess of fixed
frames exists.
f - - - - - - - - - ~-------
:r
o
Function of Invoked
Routine
Change Dispatching
Priority
(JRARMI02).
Move ASCB to correct
position on dispatcher
queue.
~
.,..
~
<
f'-I
~
f'-I
~
;-
a
I Diagram 6-2. SYSEVENT Processor (part 3 of 16)
Information
SVSEVENT
Routines Invoked
When Issued
Returned
Passed
INITATT
(10)
(continued)
• Nonswap
Authorization
(ASCBNSWP bit
of ASCB).
t"'"
Start New
Transaction
(lRARMWMN).
I ndicate the start of
a new transaction. If
workload activity
reporting is active,
calls IRARMWR6 to
indicate that a
transaction has ended.
Transaction Stop
Routine
(lRARMWMO).
Updates the accumulated time and service
for a transaction. Also
indicates that the
current transaction has
ended or been suspended. If workload
activity reporting is
active, invokes
IRARMWR4 to
accumulate report
information.
~.
t"'"
;:
~
<
~
INITDET
(11)
Whenever an
initiator detaches
a task.
a
(D
• ASID.
• Dispatching
Priority.
(register 1,
byte 3).
None
Function of Invoked
Routine
eN
~
~
b
eN
00
o
.::!
t - - - - - - - - - ~--------
110 Load
Balancing IMCB
Deletion
(lRARMIL4)'
1---- - - -
Change Dispatching
Priority
(lRARMI02).
QSCEST
(12)
-
-
Issued during
quiesce processing
when the status of
all associated tasks
has been deterdetermined.
• ASID.
• Long wait
indication.
(OO-not in long
wait
SO-in long wait).
(register 1,
byte 0).
• Conti nue with
(00) or terminate
(08) quiesce
processing.
(register 1,
byte 3).
110 Load Balancing
User 110 Monitoring (lRARMILO).
Frees 110 measurements control block
(which has been
created if the user is
a heavy 110 user).
SRM Action
SRM Lock
Held
Exit To
Yes
SRM
Control
(lRARMCTL)
~
~
b
eN
00
o
.....
--- ----.IMCB deletion is
performed through
action request.
~------- ~-------
Move ASCB to correct
pOSition on dispat~her
queue.
An 110 measurement
control block is
created for heavy 110
users. The IMCB is
updated with channel
useage data from the
Timing Control Table
1/0 Table (TCTIOT).
(See 110 Management
M.O. (lRARMIOM)
and I/O Load
Balancing User I/O
Monitoring M.D.
(I RAR MILO.)
Note: After this
SYSEVENT, no further
quiesce processing is
performed for:
• non-swappable users,
and
• users being swapped
because of a long
wait, and who are
no longer in a long
wait status.
Yes
SRM
Control
(lRARMCTL)
~
~
Diagram 6-2. SYSEVENT Processor (part 4
of 16)
Information
SVSEVENT
Routines Invoked
When Issued
Passed
QSCECMP
(13)
CI:l
(D
(")
g.
N
==
(D
So
8-
o
.....
o
'1:1
(D
~
o·
=
-
"f
. For level 4,
swap out user
acquiring fixed frames
at the fastest rate.
Notify system
operator and inhibit
creating memories.
Repeat swap outs
until shortage is
relieved.
I nform System
operator of the SOA
shortage (see Storage
Management M.O.!.
SRM Action
SRM Lock
Held
Exit To
None
No
Invoker Via
IRARMI01
Because it is important that the Main
Storage Occupancy
Analysis algorithm be
run as soon as possible,
an SRB is scheduled
after requesting the
algorithm; the SRB
will issue SYSEVENT
48 when it is dispatched, which will result in
the CONTROL function being invoked.
This algorithm will
then be executed.
No
Invoker Via
IRARMI01
SRM ceases its special
efforts to free up real
storage.
No
Invoker Via
IRARMI01
The Message Writer
algorithm is scheduled
for execution the next
pass thru the CONTROL function.
SRM does not permit
the creation of new
address spaces when
an SOA shortage exists.
No
Invoker via
IRARMI01
-<
til
N
o
Y-l
00
o
-I
--
~
Diagram 6-2. SYSEVENT Processor (part 8 of 16)
Information
SYSEVENT
When Issued
Routines Invoked
Passed
Returned
SQAOK
(26)
An SQA page
shortage has been
relieved.
Code indicating the
level of the relieved
shortage {register
1, byte 3):
above level 1 (01)
above level 2 (02)
None
SQA Shortage
Message Writer
(IRARMSOA).
DEVALLOC
(28)
A device allocation
choice must be
made from two or
more candidates.
e ASID.
e Pointer to a three
word list
(register 1)
containing:
- address of a list
of candidate
UCB addresses.
(word 1).
- address of a list
of UCB
addresses
already
allocated to
requestor.
(word 2).
- address of a
two word
return area.
(word 3L
e Pointer to same
three word list
as on entry
(register 1),
with return area
conta.ning:
- address of the
candidate list
entry that was
selected
(word 1).
e Successful (00)
or unsuccessful
(08) indication.
(Register 15,
byte 3).
None
Function of Invoked
Routine
I nform system operator of the fact that an
SOA shortage has been
relieved (see Storage
Management M.O.).
~
SRM Lock
Held
SRM Action
Exit To
Issue a message if all
SOA shortages are
relieved (i.e. level 1).
No
Invoke Via
IRARMI01
The UCB is selected by
applying the following
selection principles in
the order indicated:
e Avoid contention
(reallocating same
UCB to same user)
for Direct Access.
e Avoid allocation on
units with pre mounted volumes.
e Give preference to
less heavily utilized
logical channels,
assuming that each
previous allocation
for this user has
know projected
constant impact on
utilization.
e For direct access
devices, pick the one
with the lowest
allocated user count.
e Choose randomly,
if more than one
candidate remains.
Yes
SRM
Control
(IRARMCTL)
<:
en
N
o
W
00
o
......
i
(1)
n
C'.
o
=
CONFIGCH
(29)
A VARY
command has been
issued for a
channel or CPU.
eASID.
e SMF record
describing the
change. (pointed
to by register 1).
None
None
Update SRM control
information for logical
channel utilization
monitoring.
Yes
SRM
Control
(IRARMCTL).
VERIFYPG
(30)
An interpreter has
received a performance group
number which
needs verification.
e Performance
group number.
(register 1,
byte 3).
• Valid (00)/
Invalid (01non-TSO user;
02-TSO user
ASI D) indication.
(register 1,
byte 2).
None
The IPS is checked for
performance group
number validity. If
the number is invalid,
a default is provided.
Yes
SRM
Control
(lRARMCTL)
~
s::
(1)
;.
8-
o.....
o
'e
(1)
;3
i'
'of
IC
- -
L-_ _ _ _ _ _ _ _ _ _ _
- -
--
- - -
I.f
N
I Diagram 6-2. SYSEVENT Processor (part 9 of 16)
-
Q
o
f'-)
"<
Information
SVSEVENT
Routines Invoked
When Issued
Passed
Returned
eASID.
e New performance
group number.
(register 1,
byte 3).
Return code
indicating
- request honored
(00)
or
-performance
group number
invalid (04)
or
-ASID oot
currently
assigned (08),
(register 1,
byte 2).
Start New
Transaction
(lRARMWMN).
• ASID.
• Pointer to WMST
describing new
IPS. (register 1).
• Old IPS description.
• Indication
whether SET
command may
proceed Ondicated by posting an
ECB).
Set to New IPS
(tRARMSET).
• CPU address.
(register 1).
None
None
Function of Invoked
Routine
SRM Action
SRM Lock
Held
Exit To
f'-)
N
f'-)
'<
;
RESETPG
(31)
b
~.
The system
operator has
entered a RESET
command for a
particular address
space.
5
~
~
2'
a
(D
w
'<
f'-)
N
<=>
W
NEWIPS
(32)
00
9
ALTCPREC
(33)
The system
operator has
~ntered a SET
command with the
IPS keyword.
As a result of an
error some CPU
has had to be
configured out of
the system.
For users in real
storage, a new transaction is started. For
swapped out users a
new transaction will be
started upon swapin.
If workload reporting
is active, IRARMWR6
is called to indicate
that a transaction has
ended.
Starting a new trans·
action results in the
user being associated
with the performance
objective and domain
corresponding to the
first period of the
performance group
definition.
Yes
SRM
Control
(tRARMCTL)
I
I
I
~
N
<=>
t.J
00
If Workload Activity
reporting is active for
MF/1, the reporting is
terminated (it will
later be re-established
by MF/1L The performance group
number of all active
transactions are
examined. If the
corresponding performance group has
changed in the new
IPS, a new transaction
is begun; if it is the
same, the old transaction continues; if the
performance group
number is not defined
in the new IPS, a
default performance
group number is
substituted.
The IRARMSET
routine is called by
IRARMIPS, which is
performed indirectly,
through the action
request routine.
Yes
SRM
Control
(IRARMCTL)
UpdatesSRM control
information for logical
channel utilization
imbalances.
Yes
SRM
Control
(lRARMCTL)
Q
-..I
'\ .
J
~
.,
Diagram 6-2. SYSEVENT Processor (part 10 of 16)
Information
SYSEVENT
When Issued
Routines Invoked
Returned
Passed
TGETTPUT
(34)
C"Il
C'Il
~
=
~
a::
C'Il
g
Q.
o
o"'"
1g.
w
N
A TGET or TPUT
instruction has
completed some
1/0 to a terminal.
SYSQSCT
(35)
The system startl
stop routine has
been entered to
stop the system.
SYQSCCMP
(3S)
The system startl
stop routine is
about to restart
the system.
SETDMN
(37)
The operator
entered a SETDMN
command to
change constraint
values for a
domain.
None
• ASID.
• TGET (0) or
TPUT (1)
indication.
(register 1, byte
0, bit 0).
• (for TGET) entire
message tra nsferred indicator.
(O-all transferred;
1-at least one
more TGET
required);
(register 1, byte
0, bit 0).
None
None
Start New Transaction
(lRARMWMN).
None
None
Data area address
(register 1).
Byte 0Domain number
Byte 1Flags
Bit O-New
minimum passed
Bit 1-New
maximum passed
Bit 2-New
weight passed.
Byte 2- New
minimum
Byte 3-New
maximum
Byte 4-New
weight.
Return code
(register 15)
0: Successful
4: Invalid
domain
8: Minimum
exceeds
maximum
None
Function of Invoked
Routine
For TG ET, indicates
the start of a new
TSO transaction. If
workload reporting
is active, IRARMWRS
is called to indicate
that a transaction has
ended. If the
TGETTPUT
SYSEVENTwas preceeded by a TERMWAIT condition the
IRARMWMN routine
was instead called at
the time the address
space was swapped in.
SRM Action
Starting a transaction
results in the user being
associated with the
first period of his
performance group.
SRM Lock
Held
Yes
Exit To
SRM
Control
(lRARMCTL)
I
I
i
~.
N
<:>
w
00
~
The SRM saves the
time at which the
system was stopped.
No
Invoker Via
IRARMI01
Steps forward transaction starting times
by the duration of the
system stoppage.
No
Invoker Via
IRARMI01
Update the domain
control table with the
new ranges or weights.
Yes
Invoker Via
IRARMI01
I
w
~
Diagram 6-2. SYSEVENT Processor (part
11 of 16)
~
o
Ie
<:
f'-)
~
f'-)
'<
~
;:3
t""
~
n·
t""
8:
~:3
c
w
'<
f'-)
~
Q
w
00
Q
~
Information
SVSEVENT
Routines Invoked
Function of Invoked
Routine
SRM Action
Service Calculation
• ASID.
• Return area for
Routine
a TSO user:
• Address of 4-word
(lRARMWM1).
- Total service
return area.
(word 1).
( registe r 1).
- Total transaction active
time for all
transactions
(word 2).
- Last performance group
number (word
3, bytes 0 & 1).
- Total number
of transactions
(word 3, bytes
2& 3).
• Return'area for a
non-TSO user:
- Total service
(word 1).
- Total transaction active
time (word 2).
- Last performance group
number (word
3, bytes 0 & 1).
• Indication
whether data was
successfully
returned (00) or
not (04).
(register 15,
byte 3).
Calculates the service
accumulated during
the current "in real
storage" interval. This
is added to previous
accumulated service
to obtain total service.
Accumulated service
information is stored
in the user's area
(while not holding the
SRM lock) and under
the user's protect key.
When Issued
Passed
REQSERVC
(38)
Issued by the TSO
TIME command, to
obtain user related
service data.
Returned
SRM Lock
Held
Yes
Exit To
Invoker Via
IRARMI01
<:
f'-)
~
Q
w
00
S
'~Y'
"
Diagram 6-2. SYSEVENT Processor (part 12 of 16)
Information
SYSEVENT
Routines Invoked
When Issued
Passed
REQPGDAT
(39)
Issued by SMF
during step
termination, to
obtain user paging
data.
Note: This
SYSEVENT is
intended for use
only by SMF. It
should not be
issued by callers
others than SM F ,
because the related
data fields in the
OUSB and the
OUXB are reset to
zero on readout. If
requested by
another caller, the
data would be lost
to SMF.
c:I.l
(1)
()
f
t-..
a::
(1)
~
8o
~
o
"C:I
g.~
~
~
~
-
• ASID.
• Address of 14word return area.
(register 1).
Returned
• Return area:
- Non via pageins (word 1).
- Non via pageouts (word 2).
-Non via
reclaims
(word 3).
- VIO page-ins
(word 4).
- via page-outs
(word 5).
- via reclaims
(word 6).
- Pages swapped
in (word 7).
- Pages swapped
out (word 8).
-Swapouts
(word 9),
- Common area
page-ins
(word 10).
- Common area
reclaims
(word 11).
- Pages stolen
(word 12).
-CPU pageseconds
(words 13,14).
• Indication
whether data was
successfully
returned (00) or
not{Q4).
(register 15,
byte 3).
Function of Invoked
Routine
SRM Action
The SRM obtains
paging data from SRM
control blocks and
resets related fields in
these blocks to zero.
None
SRM Lock
Held
Yes
Exit To
SRM
Control
(IRARMCTL)
<:
c:I.l
t-..
o
~
00
o
.......
-
- -
~
N
N
Diagram 6-2. SYSEVENT Processor (part 13 of 16)
~
~
"<
f:I'l
N
f:I'l
Information
SYSEVENT
Passed
Issued when a
"DISPLAY"
command with the
keyword "DMN"
has been entered.
Pointer to a fixed
area of 2584 bytes.
(register 1).
Pointer to same
area. (register 1)
Byte 0 and 1 Count of Domains.
Byte 2 and 3Reserved.
Byte 42583 contain copy
of Domain Table.
None
DONTSWAP
(41)
Issued to notify
SRM that the
issuing address
space must not be
swapped out until
either a 0 KSWAP
(42) or INITDET
(11) SYSEVENT.
• ASID.
• Indication
whether request
was honored
(00), was dishonored because
it was not for the
current address
space (04). or
was dishonored
because it was
not authorized
(08). (register 1,
byte 3).
Swap Status
Change Request
(lRARMWMK).
Issued to notify
SRM that issuing
address space,
which had
previously issued a
DONTSWAP
SYSEVENT, may
again be considered
for swappi ng.
• ASID.
• Indication
whether request
was honored (00)
was not for the
current address
space (04). or
was not authorized (08L
(register 1,
byte 3).
Swap Status
Change Request
(lRARMWMK).
Cl9.
n
r0-
~
c:
Returned
COPYDMDT
(40)
Ib
t
Routines Invoked
When Issued
:3
('II
~
'<
S
f:I'l
N
00
o....,
OKSWAP
(42)
Function of Invoked
Routine
SRM Action
SRM Lock
Held
Exit To
Yes
Invoker Via
IRARMI01
Determine SRM
algorithms applicable
to user, and reposition
user on SRM swap
queue.
Yes
SRM
Control
(lRARMCTL)
Same as for
DONTSWAP (41).
Yes
Duplicate Domain
Information
-<
f:I'l
N
Q
~
00
~
SRM
Control
(IRARMC.TL)
" ,
~
,~,
Diagram 6-2. SYSEVENT Processor (part 14 of 16)
SYSEVENT
Information
When Issued
Routines Invoked
Passed
REQSWAP
(43)
CIl
~
g
~
a::
(D
[
o
o"'"
'C
~
IIa
g'
w
N
~
tH
Returned
Function of Invoked
Routine
Issued when a
VARY storage
command
has been issued, to
swapoutthe
address space that
occupies the
storage to be taken
offline.
Issued also at job
step initiation of a
non-swappable
user, so that, when
swapped back in,
the user may be
allocated particular
page frames to
enhance recovery
from real storage
errors.
• ASID.
-. Address of ECB
to be posted (if
dependency
exists on
requested swap).
(register 1).
BRINGIN
(44)
Issued when the
system operator
has issued a
CANCEL command for a
particular job.
.ASID.
• Indication
whether request
was honored (00),
or was not honored because the
add ress space
was in the
process of being
swapped (08).
(register 1,
byte 3).
Simulate User
Ready Notification
(IRARMHIT).
Invokes IRARMWMU
to make the memory
eligible for swap-in.
WKLDINIT
(45)
Issued by MF/1 to
request that SRM
begin collecting
workload activity
data.
• ASID.
• Data collection
buffer address.
(register 1).
• Indication
whether request
was honored
(00), was not
honored because of incorrect buffer
size (08), or data
collection is
already active
(20).
(register 15,
byte 3).
Workload Activity
Recording
Initialization
(IRARMWR1).
Constructs and
initializes the workload activity
measurement table
(WAMT).
• Indication
whether request
was honored
(00), was
ignored because
the address space
is non-swappable
(04), or was
ignored because
the address space
is in the process
of swapout (08),
(register 1,
byte 3).
Control Swapout
(IRARMCSO).
Initiates the swapout
of the address space
(see CONTROL
SWAPOUT M.O.).
SRM Action
Quiesce is posted to
begin the swapout. If
swap completion
notification is requested (by providing
an ECB), the ECB will
be posted when the
address space is next
swapped in.
SRM Lock
Held
Yes
Exit To
SRM
Control
(lRARMCTL)
-<
o
w
CIl
~
00
~
Expedite the swap-in
of a memory that is
swapped-out.
Yes
SRM
Control
(IRARMCTL)
Yes
SRM
Control
(lRARMCTL)
\,0.1
~
Diagram 6-2. SYSEVENT Processor
(part 15 of 16)
~
;,;.
oC'-l
~
~
C'-l
~
Information
SYSEVENT
Routines Invoked
When Issued
Passed
WKLDCOLL
(46)
;3
f"'"
o
Issued by MF/1 at
the end of a
reporting interval,
to collect workload activity data.
.ASID.
• Data Buffer
address.
(register 1).
• Indication
whether request
was honored
(00), whether an
IPS change has
occurred (04), or
data buffer had
not yet been
established (40).
(register 15,
byte 3).
Issued by MF/1 to
terminate workload activity data
recording, at
MF/1 termination
or when an IPS
change has
occurred .
• ASID.
• Address of the
buffer no longer
used by SRM.
(register 11.
• Indication
whether the
request was
honored (00) or
the data collection buffer had
not yet been
established (40).
(register 15,
byte 3).
Issued by the SRM
when the control
function must be
invoked immediateIy (i.e., without
waiting for the next
SYSEVENT issued
by another
component) .
• ASID.
• Address of
issuing SRB.
(register 1).
Cf:9.
(')
f"'"
0:
~
~
3(D
WKLDTERM
(47)
\,0.1
'<
C'-l
~
Q
\,0.1
00
o
.::::!
(48)
Returned
-
None
Workload Activity
Recording Data
Collection
(lRARMWR3L
SRM Control
(lRARMCTLL
Function of Invoked
Routine
SRM Action
Exit To
Yes
SRM
Control
(lRARMCTLl
The SRM indicates
that workload activity
data collection no
longer be performed.
Yes
SRM
Control
(lRARMCTLl
Frees up SRM
SR B for reuse.
Yes
Moves the contents of
the WAMT into a
collection buffer.
Performs control
mainline processing,
in the course of which
a scheduled critical
function will be
performed (see SRM
Control M.O.).
SRM Lock
Held
<:
C'-l
~
Q
\,0.1
00
o
"
SRM
Control
(lRARMCTLl
Diagram 6-2. SYSEVENT Processor (Part 16 of 16)
SYSEVENT
Information
When Issued
Routines Invoked
Passed
REQSVDAT
(49)
til
(D
n
~
N
r==
(D
~
8-
o.....
o
't:I
;
g'
IN
N
N
~
Issued by SMF
during job session
termination to
obtain .user related
service data.
.ASID.
• Address of 4word return area.
(register 1).
Returned
• Return area for
a TSO user:
- Total service
(word 1).
- Total transaction active
time for all
transactions
(word 3).
- Last performance group
number (word
3, bytes 0& 1).
- Total number
of transactions
(word 3, bytes
2& 3).
-Session
Residency
time (word 4).
• Return area for
a non-TSO user:
- Total service
(word 1).
- Total transaction active
time (word 2).
- Last performance group
number (word
3, bytes 0& 1).
-Session
Residency
time (word 4).
• Indication
whether data was
successfully
returned (00) or
not (04).
(register 15,
byte 3) .
Service Calculation
Routine
(IRARMWM1).
Function of
Invoked Routine
Calculates the service
accumulated during
the current "in real
storage" interval. This
is added to previous
accumulated service
to obtain total service.
SRM Action
Accumulated service
information is stored
in the caller's area
under the caller's
protect key.
SRM
Lock
Held
Yes
Exit To
Invoker Via
IRARMI01
<
til
N
Q
IN
00
o~
I
VS1.03.807
lRARMEYT Module Entry Point
Summary
processor.
Begin to process the indicated
IRARMEVT - SYSEVENT
SYSEVENT.
IRARMXVT - SYSEVENT retry.
Prepare a retry of a sysevent that had
incurred a system ~rror.
3-22.6 OS/VSl System Logic Ubrary Volume 3 (VS1.03.807)
Synchronize memory delete
processing.
IRARMIPS - Set new IPS.
Invoke IRARMSET to establish a new
IRARMDEL -
IPS.
IRARMUXB -
Synchronize OUXB deletion at
swapout completion time.
VS2.03.807
SRM Control
\
SRM Control is the dispatcher of SRM. It is
packaged in the module IRARMCTL along with the
swap analysis algorithm and various other SRM
routines (see volume table of contents, figure 2-9).
Most SYSEVENTS which execute holding the SRM
lock exit to SRM Control to perform the following
functions.
• SRM Control executes deferred actions
(routines which execute on behalf of a single
user memory). Examples of actions are:
• moving a user control block from one SRM
queue to another.
• memory delete processing.
• SRM Control executes deferred algorithms
(routines which execute on behalf of the
entire operating system). Examples of
algorithms are:
• Real Page Shortage Prevention.
• Real Page Shortage Page Replacement.
• Following the TIMEREXP SYSEVENT, SRM
Control schedules timed algorithms. Examples of
timed algorithms are:
• assigning swapp able users their current
workload level (Swappable User Evaluation
Algorithm).
• Keeping the multiprogramming level (MPL)
at its target level in each domain by
performing user swaps (Swap Analysis
Algorithm).
Action/Algorithm Scheduling
Actions and algorithms can be requested/scheduled
by any of the components of SRM. These requests
are processed by request handling subroutines
within IRARMCTL. Requests for actions are
processed in one of the following ways:
.
• The action is called inline if the SRM lock IS
held and if the action was not requested by
another action.
• Otherwise, the action. is deferred. A flag is set
in the OUCB to indicate that the action was
requested.
Requests for algorithms are always deferred. A
flag is set in the RMCT to indicate that the
algorithm was requested. If an action or algorithm
which has been deferred is critical, the request
handling subroutine schedules an SRB to another
entry point, IRARMCED, within IRARMCTL.
IRARMCED executes SYSEVENT 48. SYSEVENT 48
exits to SRM Control where the deferred action or
algorithm is executed.
Non-critical actions and algorithms which have
been requested but deferred are executed the next
pass through SRM Control. This execution will
normally occur after processing the next SYSEVENT
while holding the SRM lock.
SRM Control identifies which actions and
algorithms to execute by bit strings in the OUCB
(for actions) and the resource manager control
table (RMCT) (for algorithms). "On" bits in the
OUCB (OUCBACN field) and in the RMCT
(RMCTALA and RMCTALR fields) identify deferred
action and algorithm requests, respectively. The
actual addresses of the individual routines that
process actions and algorithms are located in
resource manager entry point elements (RMEPS)
which are chained together. One RMEP chain exists
for actions and another for algorithms. SRM
Control compares the "on" bits in the bit string
(the OUCB or RMCT) against each RMEP in the
action/ algorithm RMEP chain. When a match is
found, the entry point address in the isolated RMEP
identifies the action or algorithm routine that will
get control. As a part of routing to the identified
routine, SRM Control turns off the bit in the OUCB
or RMCT used in finding the proper RMEP. When
all bits in the OUCB and RMCT bit strings are "off"
SRM Control has processed all deferred actions and
algorithms and exits to a return point in the SRM
interface module IRARMINT. Figures 2-9B and
2-9C show in more detail the routines and bit
settings used in processing algorithms and actions.
Swap Analysis
The swap analysis algorithm is concerned with
maintaining the multiprogramming level at the
target value in each domain defined to the system.
A domain is a group of user memories defined in
the installation performance specification (IPS)
which have common execution characteristics (for
example, all TSO users might be assigned to one
domain). The multiprogramming level (MPL) in a
domain is the number of users in that domain
which are in real storage. The target
multiprogramming level is the number of users in
real storage which the SRM resource monitor has
determined is optimal for this domain.
SRM recognizes user memories, (i.e. address
spaces) as being in one of three states. Each state
corresponds in concept to a queue on which OUCBs
that describe address spaces are placed. The three
..
possible states of an address space are:
IN - The working set of an address space III thIS
state occupies real storage.
Section 2: Method of Operation 3-23
VS2.03.807
WAIT - The working set of an address space in this
state does not occupy real storage (that is,
has been swapped out), and the address
space is incapable of being placed into
execution.
OUT - The working set of an address space in this
state does not occupy real storage,
however, the address space is capable of
executing, and may be considered for
swap-in.
The decision to swap address spaces is made
based on a number of input factors supplied by
other SRM functions. The workload manager
provides workload levels for each user. The
resource-use algorithms tell which users are
significant users of system resources (via individual
recommendation values). Swap analysis combines
the individual recommendations of the workload
manager and resource managers into a· composite
recommendation value. The steps of the swap
analysis algorithm are defined below in the order of
execution. In steps one and three all domains are
considered in numerical order. The algorithm is
terminated at the end of any step which has
resulted in at least one swap.
1. Unilateral Swap-Out. In each domain the
required number of user memories are
swapped out to lower the MPL to its target
value. Users which have the smallest
recommendation values (RVS) in each domain
are selected for swap out.
2. Express Swap-In. If there is a user out of real
storage which is enqueued on a resource
requested by another user, the enqueued user
is swapped in if this can be done without
exceeding the target MPL in that domain. If
the MPL would be exceeded, the user with the
smallest RV in that domain is swapped out to
lower the MPL. The enqueued user will be
swapped in on the next invocation of swap
analysis. If no user is swappable, the
3-23.0 OS/VS2 System Logic Library Volume 3 (VS2.03.807)
enqueued user is swapped in. This raises the
MPL in thai domain above its target
temporarily.
3. Unilateral Swap-In. In each domain, the
required number of user memories are
swapped in to raise the MPL to its target
value. Users which have the largest RVs in
each domain are selected for swap in.
4. Exchange Swap. For a domain having its MPL
at the target, an in-real-storage user memory
and an out-of-real-storage memory are
selected for an exchange. The user in real
storage with the smallest recommendation
value are selected. The difference in their
recommendation values must exceed a limit
(RMPTXCHT) to proceed with the exchange.
If an exchange is justified, the swap out of
the in-real-storage user is initiated, and the
swap in of the out-of-real-storage user
memory is deferred until a subsequent
invocation of swap analysis.
The following M.O.s describe SRM Control
processing and other important routines within
IRARMCTL:
• Swap analysis (IRARMCAP), which analyzes
users and, if it determines a swap desirable,
requests it.
• Control swap-out (IRARMCSO), which
initiates requested user swap-outs.
• Control swap-in (IRARMCSI), which initiates
requested user swap-ins.
• Select user for swap-in (IRARMCPI), which
finds the user with the highest
recommendation value in its domain.
• Select user for swap-out (IRARMCPO), which
finds the user with the lowest
recommendation value in its domain.
• User evaluation (IRARMCVL), which
calculates a recommendation value for a
specific user.
Section 2: Method of Operation
3-23.1
VS2.03.807
SRM Lock
Held
Scheduling
Routine
RMEP
Chain
Bit
String
SRM Lock
Held
Executing
Routines
RMEP
Chain
ACTIONS
NO
YES*
IRARMCRN
EPDT
OUCBACN**
YES
(JRARMCEN,
IRARMCRT)
EPDT
ALGORITHMS
NO
YES
IRARMCRL
IRARMCRL
EPAT
EPAT
RMCTALA
RMCTALR
YES
(JRARMCEL,
IRARMCRT)
EPATf
TIMED ALGORITHMS
YES
IRARMCET
IRACTMQE
RMCTALR
YES
(lRARMCEL,
IRARMCRT)
EPAT
*If SRM lock is held when an action is requested, it is not deferred (except where an action
invokes another action). Control passes to IRARMCRY (if the action is IRARMCSI or
IRARMCSO) or to IRARMCRN (for all other actions) and then directly to the action.
**During execution this field is inspected only in OUCBs which have been queued on the
action queue by the action-scheduling routine (JRARMCRN).
Figure 2-9B. Processing of Algorithms and Actions in IRARMCTL
3-23.2 OS/VS2 System Logic Library Volume 3 (VS2.03.807)
~
VS2.03.807
Attributes
RMEP Algorithm Invocation Flags
11.,
RMEPFLG
*IRARMIL 1
*IRARMCL1
IRARMSOA
I-~~~--~~
=ill
I~--~~~--I~~~~~---I----~~I
~=ill
===-.J
~
Critical
Timed
=
0 (algorithm)
*IRARMAP1
*IRARMPR1
*IRARME01
*IRARMASM
*IRARMMS6
IRARMPR5
IRARMMS2
*IRARMRM1
*IRARMRM2
*IRARMWM2
*IRARMCAP
*indicates Timed Algorithm
Attributes
\.
RMEP Action Invocation Flags
RMEPFLG
IRARMDEL
Critical
IRARMUXB
Timed (algorithms
IRARMIL4
= 1 (action)
~=lli
only~ ~
IRARMIPS
IRARMHIT
IRARMRPS
Figure 2-9C. RMEP Algorithm and Action Invocation Flags
Section .2: Method of Operation
3-23.3
'of
~
I Diagram 6-3. SRM Control (IRARMCTL)
(part I of 2)
~
oCIl
From SYSEVENT
Processor
(/RARMEVT)
<
CIl
~
CIl
'<
Input
i
a
t"""
Q
~.
1
t"""
J
~
a=
From SYSEVENT
Processor when
SYSEVENT
Timerpop (1) is
Received
(I)
~
'<
CIl
~
o
~
2
3
00
§
Process all actions that have been deferred
and can now be performed.
(See Deferred Action Processor M.O').
Route control to all algorithms that were
previously requested. and can now be performed.
(See Algorithm Request M.O.).
Request the invocation of time-driven
algorithms.
(See Periodic Entry Point Scheduling M.O.).
To
IRARMINT
Return Point
(/RARMI01)
I
I
Step 1
Register 0
Address of SR B
4
Issue SYSEVENT 48 to perform control
mainline processing (steps 1 and 2),
To
IRARMINT
Entry Point
(lRARMI48)
Control
Mainline
Processing
<:
CIl
~
o
~
00
S
,7
Diagram 6-3. SRM Control (IRARMCTL)
fIl
f
~
iC
(D
[
e.
o
"0
Iw
~
til
,:~
-:"!I'
(Part 2 of 2)
Extended Description
Module
SRM Control routes control to actions and algorithms
which have been requested and also to timed algorithms
which have come due.
IRARMCTL
1
Route control to actions which have been requested
but deferred. Actions are SRM functions performed
on behalf of a single user.
IRARMCTL IRARMCEN
2
Route control to algorithms which have been
requested. Algorithms are SRM functions performed
on behalf of the system.
IRARMCTL IRARMCEL
3
Request the invocation of time-driven algorithms
which are now due. The queue of time-driven
algorithms is scanned, and all algorithms whi~h are due
are requested by turning on representative bits in
RMCT ALR. SRM Control now branches to step 1 above.
Continuing with step 2, SRM Control will route control
to those time-driven algorithms which were requested.
IRARMCTL IRARMCET
4
IRARMCTL IRARMCED
This SRM Control entry point receives control under
an SRB which was scheduled by another component
of SRM. The SRB was scheduled on behalf of routines
not holding the SRM lock to execute critical actions and
algorithms. Upon receiving control under the SRB, SRM
Control makes a branch entry into the interface module,
IRARMINT, to execute SYSEVENT 48. The SYSEVENT
processor will in turn branch to SRM Control at step 1.
Control will then be routed to the critical actions and
algorithms which were requested.
g
,
Label
<
{J:l
~
o
w
00
Q
-...J
VS2.03.807
This blank leaf represents pages 3-26 - 3-27 which were deleted by Supervisor Performance #2.
3-26 thru 3-27
OS/VS2 System Logic library Volume 3 (VS2.03.807)
\,
/
Section 2: Method of Operation
3-27
~
I
Diagram 6-5. Deferred Action Processor (IRARMCEN) (part 1 of 2)
00
~
<:
r.fJ
N
Sequential Flow in
SRM Control
(lRARMCTL)
Input
Output
r.fJ
'<
i
a
RMCT
Deferred Action Processor (I RARMCEN)
ro
~.
r-
so
~
~
~
w
<:
RMCTAOHD
1
(
Verify that more users remain on the
deferred action queue.
No QUCSs Remaining
r.fJ
N
o
QUCSs
W
00
o
......
-
Deferred
A ct.i on
Queue
QUCSACN
RMCT
AMCTEPDT
.1
2
Remove the next OUCS from t h e :
deferred action queue.
3
Route control to the action routines
requested for this user.
<:
r.fJ
N
o
W
Continue SRM
Control Mainline
Processing
00
S
QUCSs
r---
:
:>I
Shortened
Deferred
Action
Queue
_f
~
'_:#'
Diagram 6-5. Deferred Action Processor (IRARMCEN) (part 2 of 2)
Extended Description
Module
The Deferred Action Processor routes control to each
requested routine for all OUCBs on the deferred action
queue. The entry point descriptors for all possible
action routines are contained in RMCTEPDT.
IRARMCTL IRARMCEN
1
If the action queue header is pointing to the dummy
pre-assembled OUCB (that is, RMCTAQHD=
RMCTOUCB), then the action queue is empty.
IRARMCTL IRARMCEN
2
The top OUCB is dequeued via compare-and-doubleswap, to prevent multi-processing interaction
problems. OUCBACT is set to zero.
IRARMCTL IRARMCEN
3
IRARMCTL IRARMCRT
IRARMCRT scans the EPDT entry point table
looking for entry point blocks (RMEPs) whose invocation flags match "one" bits in the input bit pattern.
For each successful match, the corresponding entry point
is invoked. The invocation bit of each routine invoked
is set to zero in the input bit pattern. It is possible for
an action routine to call another action routine. In this
case, the new routine request is inserted into the
OUCBACN field, to be picked up during the processing
of this OUCB.
io·
=
~
;c
~
[
....
o
o
'Ea
o·
=
IN
N
'"
Label
~
~
o
IN
00
o
.......
~
=
~
<
fI)
N
fI)
'<
~
a
r-
ei.
(")
I
Diagram 6-6. Algorithm Processor (IRARMCEL) (put 1 of 2)
-
Sequential Flow in
SRM Control
Mainline
(IRARMCTL)
Input
RMCT
r-
RMCTALA
8
RMCTALR
es:
Output
L-...J
1
Verify that some algorithms have
been requested.
No Algorithms Requested
~
Continue SRM
Control Processi.ng
~
I-.J
i
C
IN
IN
~
2
Combine deferred and immediate
algorithm requests.
3
Route control to the necessary
algorithms.
N
00
=
....,
S
00
-s
RMCT
RMCTEPAT
Continue SRM
Control Processing
"
~7
Diagram 6-6. Algorithm Processor (IRARMCEL)
Module
Algorithm request routes control to all algorithms that
have been requested and can now be executed. The entry
point descriptors for all possible algorithm routines are
contained in RMCTEPAT.
IRARMCTL IRARMCEL
1
Some algorithms have been requested if RMCT ALA
and RMCTALR are not both zero. Algorithm requests are stored in RMCTALR by SRM locked routines,
and in RMCTALA by SRM unlocked routines.
I RARMCTL I RARMCEL
2
IRAHMCTL RMCELL 1
3
IRARMCRT scans the EPAT entry point table
looking for entry point blocks (RMEPs) whose
invocation flags match "one" bits in the input bit pattern.
For each successful match, the corresponding entry
point is invoked. For each algorithm called, the invocation bit is set to "zero" in the request bit pattern.
Input parameters:
• reg. 1 - address of first entry point block (RMEP)
in the EPAT chained table
• reg, 6 - address of input bit pattern (RMCTALR)
c;f.)
(D
~
0'
=
~
;s::
(D
[
o
....
o
"0
~
a-
0'
=
w
W
'-~
(part 2 of 2)
Extended Description
Compare and swap logic is used to insure that all
current requests are obtained for a multiprocessing
environment.
./
Label
<:
c;f.)
~
(:)
w
IRARMCTL IRARMCRT
00
<:)
.......
~
Diagram 6-7, Periodic Entry Point Scheduling (IRARMCET) (part 1 of 2)
N
From SYSEVENT
Processor as a Result
of SYSEVENT 1
~
~
N
til
Input
--
'S
;-
RMCT
a
~
o
RMCTTMQE
11:9,
n
Process
t
Outl
Periodic Entry Point Scheduling (lRARMCET)
1
Pick up the first algorithm entry point
block from the timed algorithm queue.
2
Verify that this algorithm is due.
~
a:
~
"
RMCTTOD
g:
=
a
~
<:
en
CD
N
RMPT
w
Q
w
~
RMPTTOM
Q
RMPTTOL
N
w
•
00
o
......
I
'1
00
~
RMCT
, IRACTMQE
+ FWD
V
RMEP
L
1
'") 3
RMEPFLG
L
RMEPFWD
4
RMEPTME
RMEPINT
RMEP
II
I\.
"
5
k
Set a request for executing this
algorithm.
'"
'
If more algorithms are due, step to the
next one.
Reset the timer expiration.
RMCTALR
y
,
.'1IIlr'4C1I\tva\'_
-'"
IRARMSRV
~
2
.L
...
~
IRARMI05
~
'--~
Diagram 6-7. Periodic Entry Point Scheduling (IRARMCET) (part 2 of 2)
Extended Description
Module
Periodic Entry Point Scheduling is invoked following an
SRM TOE timer expiration. It sets up requests for all
SRM periodically scheduled algorithms which are then
due. It also requests the resetting of the SRM TOE to
cause an interruption when next required.
IRARMCTL IRARMCET
1
The timer algorithm queue is ordered by the
RMEPTME value of the RMEP blocks on the
queue.
IRARMCTL IRARMCET
2
An algorithm on the time-driven queue is "due"
if the RMEPTME value is less than the current time
(RMCTTOD) + an allowable tolerance (RMPTTOL).
IRARMCTL IRARMCET
3
The algorithm request field is set up for later action
by algorithm control routing (JRARMCEL).
IRARMCTL IRARMCET
4
The next RM EP block is obtained from the queue.
IRARMCTL IRARMCET
5
A new timer interruption is requested for the greater
of: the minimum scheduling period (RMPTTOM),
and the smallest time due of a scheduled routine (see
SRM Interface M.O.!.
C"'-l
(D
ae·
;:I
~
a::
(D
[
o
000)
o
't.S
Q
~
o·
;:I
~
~
~
Label
IRARMSRV IRARMI05
VS2.03.807
This blank leaf represents pages 3-34 - 3-35 which were deleted by Supervisor Performance #2.
3-34 thru 3·35
OS/VS2 System Logic Library Volume 3 (VS2.03.807)
",
I
,JI
'""',
i
/
Section 2: Method of Operation
3-35
~
I Diagram 6-9'. Swap Analysis (IRARMCAP)
(Part I of 2)
~
0'\
~
<
c:Il
N
c:Il
'<
S
::3
I'"'"
-
From Algorithm
Request (IRARMCEL)
Input
Output
Process
Swap Analysis (IRARMCAP)
Register 2
Domain
Descri ptor Table
DMDT
CUCB
"IN"
o
~.
1
Reinitialize domain descriptor
table.
2
Perform UNILATERAL SWAP-OUT. ,,.,._--------....--.
Swap-out users in domains having
multi-programming level (MPL)
greater than target.
I'"'"
;:
~
<:
o
=-::3
~
~
I
'<
If any swaps
Q
~
00
§
Queue
Header
3
Perform EXPRESS SWAP-IN.
Swap-in oldest user who is
enqueued on a ;ritical resource.
Return to
Algorithm
Request
(lRARMCEL)
If swap
Domain Descriptor Table
DMDT
4
Perform UNILATERAL SWAP-IN.
Swap-in users in domains having
MPL less than target.
If any swaps
5
Ail!
\lib
Perform EXCHANGE SWAP.
Swap-out user with lowest
recommendation value (RV) in
each domain whose highest user
RV exceeds the lowest by a
threshold.
Return to
Algorithm
Request
(IRARMCEL)
Return to
Algorithm
Request
(lRARMCEL)
~
N
Q
~
00
<:>
......
Return to
Algorithm
Request
(lRARMCEL)
c:Il
N
II
~
",-_7
Diagram 6-9. Swap Analysis (IRARMCAP) (Part 2 of 2)
Label (or
Segment)
Extended Description
Module
Swap Analysis is pe'rformed on a time-driven basis, It is an
algorithm activated by IRARMCET, It is also activated by
the processing of two SYSEVENTS: USERRDY (4) and
SWOUTCMP (15).
IRARMCTL IRARMCAP
1
The Domain Descriptor Table has one entry for each
domain defined by the IPS. Each OUCB on the IN
and OUT queues is examined. Swappable, valid users on
the IN queue which are not in the process of being swapped
out or moving from one SRM queue to another are
counted in the current multiprogramming level (MPL)
for a domain, as well as users on the OUT queue which
are going in or moving from one SRM queue to another.
Fields in each domain descriptor table entry are
reinitialized with the above MPL count information.
IRARMCTL IRARMCAP
2
IRARMCTL IRARMCPO
IRARMCSO
Search the domain descriptor table entries for a
domain with an MPL higher than the target value
and swap out the user with lowest recommendation
value (RV). Repeat until the MPL reaches the target
value in every domain.
3
fI)
g
f
~
s:
(D
i....o
o
I
w
....W
If there is a user on the OUT queue enqueued on
a critical resource, attempt to swap the user in. If
MPL in that domain is less than the target, swap that
user in. Otherwise, make room for it by a swap out of
the user with the lowest RV. Repeated calls to swap
analysis may be necessary to reduce MPL below target
value to allow the enqueued user to be swapped in. If
there is no enqueued user, continue to step 4. Otherwise
swap analysis ends here.
Module
4
Search the domain descriptor table entries for a
domain with an MPL less than target and swap in
user with highest RV. Repeat until the MPL (plus users
in the process of being swapped out) reaches the target
in each domain. If at least one swap is done in this step,
swap analysis ends here.
IRARMCTL IRARMCPI
IRARMCSI
5
IRARMCTL IRARMCPO
IRARMCPI
IRARMCSO
Search the domain descriptor table entries for a
MPL that equals the target for that domain. I n each
of these domains, find the out-of-storage user with the
largest RV to come in, and the in-storage user with the
smallest RV to remain in. If the difference of their RVs
exceeds a threshold (RMPTXCHT). swap out the user
with the lower RV.
Error Processing:
IRARMERR handles all unexpected errors.
Any non-zero return" codes from called routines
causes Swap Analysis (I RARMCAP) to end without
finishing its processing.
If at least one swap is performed in this step, swap
analysis ends here. Otherwise, continue at step 3.
IRARMCTL IRARMCSI
IRARMCTL IRARMCPO
IRARMCSO
Label (or
Segment)
Extended Description
<:
fI)
N
Q
w
00
Q
....
VS2.03.807
This blank leaf represents pages 3-38 - 3-39 which were deleted by Supervisor Performance #2.
3-38 thru 3-39
OS/VS2 System Logic Ubrary Volume 3 (VS2.03.807)
Section 2: Method of Operation
3-39
~
~
I Diagram 6-10. Control Swap-In (IRARMCSI)
(Part 1 of 2)
<:>
otil
~
til
N
til
'<
r4
(I>
F rom Swap Status Change
Request (lRARMCRY)
Input
Register 4
OUCB
3
r-'
o
Output
OUCBOUT
Return Code
1
w
'til:2
Obtain user control block
extension (OUXB) for the
user being swapped in.
Q
Return to
Swap Status
Change
Request
(lRARMCRY)
~
N
IRARMI04 entry point
(obtain storage)
N
b
Return Code
8
If unable to obtain OUXB.
w
00
b
w
00
Return to
Swap Status
Change
Request
(IRARMCRY)
<:>
~
IRARMSRV
IRARMI07 entry point
(swap-in request)
3
o
Initiate swaR~in.
If successful, return.
Return Code
Return to
Swap Status
Change
Request
(lRARMCRY)
Otherwise, free OUXB
storage.
Return Code
#=0
IRARMSRV
IRARMI04 entry point
(tree storage)
Return to
Swap Status
Change
Request
(IRARMCRY)
<:>
.......
--,---,
Diagram 6-10. Control Swap-In (IRARMCSI) (Part 2 of 2)
Extended Description
Module
Label (or
Segment)
Control Swap-I n accepts a request that an address space
be swapped in. If the address space is already swapped
in, this is indicated by a return code; if not, control
swap-in initiates a swap-in of the address space.
IRARMCTL
IRARMCSI
1
Control swap-in returns to the calling routine
with a return code of 8 if the user for which
a swap-in has been requested has already been
swapped-in. Otherwise, control goes to step 2.
IRARMCTL
IRARMCSI
2
IRARMSRV
IRARMI04
<:
The user control block extension (OUXB) is
obtained. It remains in existence as long as
the user is swapped in and is released at swap-out.
I;Il
N
(:,
~
00
0
-..I
3
If the swap-in is successfully initiated
(return code from IRARMI07 equals 0),
the OUXB is cleared, the address of the OUXB is
placed into the ASCB (ASCBOUXB), and the
OUCS going-in bit is set (OUCBGOIl.
IRARMSRV
IRARMI07
Otherwise, the storage for the OUXB is freed.
IRARMSRV
IRARMI04
IRARMCTL
IRARMCSI
Error Processing:
If an attempt to obtain storage for an OUXB fails
(step 2), or an attempt to initiate a user swap-in
fails (step 3), the user remains on the OUT queue,
and Control Swap-in returns to the caller with an
error return code.
I;Il
(p
~
O·
::s
N
~
(p
;.
o
~
....o
o
"0
...
(p
~
O·
::s
~
.i:.
~
Diagram 6-11. Control Swap-Out (IRARMCSO) (part 1 of 2)
~
o
rIl
From Swap Status
Change Request
~
~
~
i
~
~.
r""
a:
~
e:=
51
(\)
Input
(lRARMCRY)
Register 4
140UCB
1
~
.p.ro.ceisis•••••••••••••••1
Output
Control Swap-Out (lRARMCSO)
Return
Code
OUCB
1
OUCBQFL
OUCBASCB
Check to see if the user is a l r e a d Y .
swapped out.
~
•
v1..._ __
Return to Swap
Status Change
Request
(IRARMCRY)
<:
rIl
t-J
(:,
c...J
c...J
'<
00
C>
rIl
o..J
~
(:,
c...J
ASCB
00
C>
.::!
ASCBECB
2
3
Initiate a swap-out of the
current user, by posting
the Region Control Task
Cross Memory
Post
If swap-out is successfully initiated,
place user at top of dispatching
queue and
Return
Code
pass back "successful" return code; _____.,_----.----------,
Return to Swap
Status Change
Request
(lRARMCRY)
Otherwise, return unsuccessful.
Return to
Swap Status
Change
Request
(IRARMCRY)
J
Diagram 6-11. Control Swap-Out (IRARMCSO)
(part 2 of 2)
Label
Extended Description
Module
(or Segment)
Control Swap-Out accepts a request that an address space
be swapped out. If the address space is already swappedout, this is indicated by a return code; if not, control
swap-out initiates the swap-out of the address space.
IRARMCTL
IRARMCSO
1
Control swap-out returns to the calling routine
if the user for which a swap-out has been requested
has already been swappe~ out. Otherwise, control goes
to step 2.
IRARMCTL
IRARMCSO
2
The supervisor service request routine requests the
initiation of quiesce processing for the user to be
swapped out. This request results in the posting of an
ECe for the indicated address space, so that the RCT
will begin quiesce processing.
IRARMSRV
IRARMI06
3
IRARMSRV
To expedite quiesce processing, request that
the user's ASCe be moved.
A successful return indicates that the post of quiesce
processing has been scheduled for the address
space. The progress of quiesce processing will be
indicated to the SRM by future SYSEVENTs
(typically, quiesce started, followed by quiesce
completed, followed by swap-out complete).
til
(D
n
go
:=
N
~
(D
[
o....
o
'g
t·
w
J:.
w
<:
til
N
<=>
W
Co
0
......
IRARMI02
~
~
I Diagram 6-11A. Select User for Swap-In (IRARMCPI)
(Part 1 of 2)
w
<:>
o
CI)
<
From Swap
Analysis (IRARMCAP)
Input
Output
CI)
~
CI)
'<
go
;-
3
o
'5.
n
Register 11
Domain Table Entry
r'"'
RMCT
r'"'
;:
~
<:
RMCTOTQE
VUI
OUCBs
_____- - - - - _......./ 1
-
-
o
=
3
Compute composite recommendation
value (RV) for each user (in domain)
on OUT queue, which is not already
scheduled for swap-in.
(II
CI)
~
Register 4
w
'<
<:
CI)
2
Select user with highest RV.
~
<:>
w
00
Q
.:::!
Return to Swap
Analysis (IRARMCAP)
It
<:>
w
00
S
OUCB
Diagram 6-11 A. Select User for Swap-In (IRARMCPI)
Extended Description
Module
This routine choos!'!s the user with the highest RV in a
particular domain on the OUT queue. If one of the users
represented by an OUCB in this domain is assigned toa
different domain, for example, because of a period
change, return a code of zero indicating no user found.
In this case, swap analysis (lRARMCAP) is rescheduled
to ensure that the domain descriptor table is initialized
to reflect this domain change. The following two steps
are performed in a loop until all OUCBs on the OUT
queue have been evaluated.
IRARMCTL IRARMCPI
1
Examine each OUCB on the OUT queue for users
in the specified domain. Use the user evaluation
subroutine to compute the composite RV for each user.
IRARMCTL IRARMCPI
~
IRARMCTL IRARMCVL
Q
c...I
00
2
IRARMCTL IRARMCPI
Gompare the computed RV to that of the highest
RV found up till now. Save this OUCB as the best
candidate for a swap-in if its RV is greater. Otherwise,
continue until all OUCSs on the OUT queue in this
domain have been evaluated.
CIl
(D
()
g'
~
~
(D
~
8o....
o
't:S
S
g
c...I
~
~
(Part 2 of 2)
Label
~
9
~
w
I Diagram 6-11B. Select User for Swap-Out (IRARMCPO)
N
&1
~
w
f'-)
I
r~.
f')
~
8<
(part 1 of 2)
From Swap
Analysis (tRARMCAP)
Input
Output
Register 11
I
Domain Table Entry
RMCT
I
RMCTINQE
l-
-
-
'" 1
--.
~
--.
a
Compute composite recommendation
value (RV) for each user (in domain)
on I N queue which is not already
scheduled for swap-out.
(D
w
~w
;;3
w
Q
w
Register 4
...
l-
2
Select user with lowest RV.
i-
Q
w
00
-9
Return to Swap
Analysis (tRARMCAP)
It
OUeB
00
9
#
~=-y
Diagram 6-11B. Select User for Swap-Out (IRARMCPO)
"
"
(part 2 of 2)
Extended Description
Module
This routine chooses the user with the lowest RV in a
particular domain on the IN queue. If one of the users
represented by an OUCS in the domain is assigned to a
different domain, for example, because of a period change,
return a code of zero indicating no user found. In this
case swap analysis (lRARMCAP) is rescheduled to ensure
that the domain descriptor table is initialized to reflect
this domain change.
IRARMCTL IRARMCPO
Label
The foUowing two steps are performed in a loop until all
OUCS's on the IN queue have been evaluated.
1
Examine each OUCS on the I N queue for users
in the specified domain. Use the user evaluation
subroutine to compute the composite RV for each user.
<
IRARMCTL IRARMCPO
IRARMCTL IRARMCVL
f.f)
t-J
0
c.I
00
0
......
2
Compare the computed RV to that of the lowest
RV up till now. Save this OUCS as the best
candidate for a swap-out if its RV is lower.
Otherwise, continue until all OUCSs in this domain on
IN queue have been evaluated.
f.f)
~
g'
t-J
i'
~
;.
&.
Q
....
o
"1:1
tc.I
J:..
c.I
~
IRARMCTL IRARMCPO
~
~
I Diagram 6-11C. User Evaluation (IRARMCVL)
(Part 1 of 2)
I.H
~
..
From Select User for Swap-In (lRARMCPI) or
Select User for Swap-Out (lRARMCPO)
&S
"<
tI)
~
tI)
'<
RRPA
""
;3
-.
I
RRPATOD
S
I
~
"')
--
Check to see if a workload manager
recommendation value has been
computed within a time less than a
threshold.
or
OUCBTMA
~
E'
3
If the computation is recent
(D
«'
I.H
...
.
~
~
(:)
Go to Step 3
OUCB
o
'<
.......
tI)
WPGD
o
I.H
o
,:;;!
....
tI)
-<
~
00
~
00
I.H
00
"1:1
Ilo'
~
o
Performance
Group
Descriptor
OUCB
WPGLDUR
Calculate the new workload
manager recommendation value.-
...
)
v
OUCBWMR
..')
OUCBIRV
OUCBWMS
RRPA
RRPATOD
2
v
OUCBTMP
WPGLlSV
1
")
6
.......
OUXB
OUXBPRS
·1
,
OUXBTRS
WMST
Workload
Manager
Specification
Table
I
ASCB
I
Performance
Objective
II
I
OUXB
II
I
") 3
v
If RTB=1 (OUCBRMA) then
calculate the composite RV,
based on I/O and CPU usage.
"
OUCBCRV
OUCBCMRV
OUCB
OUCBWMR
OUCBRMA
Return to Caller
Select User for Swap-In (lRARMCPI) or
Select User for Swap-Out (I RARMCPO)
-
< II
6
~
-y
"'~
Diagram 6-11C. User Evaluation (IRARMCVL) (Part 2 of 2)
Extended Description
Module
Label
User evaluation computes a recommendation value (RV)
for one user based on its workload manager
recommendation value and its I/O and CPU recommendation values.
IRARMCTL
IRARMCVL
1
A new value is calculated for the workload manager
RV only if sufficient time has elapsed since its
previous calculation. This time is called threshold 2.
(Swap Analysis evaluating threshold RMPTSAET).
IRARMCTL
IRARMCVL
2
Compute the workload manager recommendation
value (the normalized workload level) representing
the desirability of a swap of this user. This value is based
on the rate at which he has recently been receiving
service and on the IPS.
IRARMWLM
IRARMWM3
3
IRARMIOM
IRARMIL3
IRARMCPM
IRARMCL3
If the applicable RTB is 1, add to the workload level
an I/O manager recommendation value (for
significant users of I/O) and add a CPU manager
recommendation value (for significant users of the CPU
resource). A positive RV favors the swap-in of a user
to correct a CPU or I/O imbalance and a negative RV
favors the swap-out of a user.
en
(!)
~
cS-
=
~
~
~
Q.
o
....
o
"CI
(!)
o·e.
=
~
J:,.
~
u.
<:
~
N
o
~
00
o
....,
VS2.03.807
IRARMCTL Module Entry Point
Summary
IRARMCTL - Mainline Control Processing.
Transfers to deferred user action
processing (IRARMCEN) and then to
the algorithm request routine
(IRARMCEL).
IRARMCEN - Deferred User Action Processing.
Examines the OUCBACN field of the
OVCB to determine the users on the
action queue and routes control to all
routines whose request bits have been
set in the OUCBACN field. Dequeues
each OUCB after its indicated actions
have been performed.
IRARMCEL - Algorithm Request Routine.
Examines the RMCT ALR and
RMCT ALA fields in the RMCT and
routes control (via IRARMCRT) to
each algorithm whose request bit has
been set in either of the two fields.
Resets the individual request bit after
each algorithm completes.
IRARMCET - Periodic Entry Point Scheduler.
Accepts timer interrupts, schedules
the algorithm currently due for
execution and requeues the SRM timer
element to permit interrupts again
when the next algorithm is due for
execution.
IRARMCED - SRB Dispatched Original Entry
Processor.
Receives control under an SRB
scheduled by the dispatcher and sets
up an entry to the maihline of
SRM(IRARMCEN) by issuing
SYSEVENT 48.
IRARMCQT - Periodically-Invoked Entry Point
Rescheduler.
Accepts a request to reschedule the
execution of a periodically invoked
algorithm and requeues the
corresponding RMEP block on the
timed entry queue.
IRARMCRD - SRB Scheduling Routine.
Accepts a request to schedule the
SRM SRB which if available is
scheduled to obtain the SRM lock.
IRARMCRL - Algorithm Scheduling Routine.
Accepts requests for an algorithm to
be run. Turns on the bit associated
with the algorithm in the RMCTALA
or RMCTALR.
3-43.6 OS/VS2 System Logic Library Volume 3 (VS2.03.807)
IRARMCRN - Action Request Routine.
Accepts requests for an action which
must run under the SRM lock. If the
SRM lock is held, control passes
immediately to the action via a
routing routine. If the SRM lock is not
held, the bit is set in the OUCBACN
field of the OUCB associated with the
requesting user that identifies that the
action requested is deferred.
IRARMCRT - Entry Point Table Scanner.
Accepts an invocation bit pattern and
an entry point table address.
Compares the bit pattern to
invocation flags in the entry point
table entries. Invokes the routine
identified by the entry point when a
match is found between the bit
pattern and the invocation flags.
IRARMCRY - User Swap Request Receiving
Routine.
Accepts a request for a user swap
and checks to see if such a swap is
already in progress. Routes control to
IRARMCSO or IRARMCSI if a swap is
not in progress and the SRM lock is
held.
IRARMCSI - User Swap-In Request.
Accepts a swap-in request, allocates
an OUXB for the user and initiates the
swap-in.
IRARMCSO - User Swap-out Request.
Accepts a swap-out request and posts
the region control task's quiesce
routine to initiate the swap-out.
IRARMRPS - OVCB Repositioning Routine.
Dequeues an OUCB and requeues it at
the end of the queue specified in its
OUCBQFL field~
IRARMWMY - Periodic Entry Point Requeuing
Routine.
Requeues all of the members on the
Timed Algorithm Queue and adjusts
all the time-due fields.
IRARMCAP - Swap Analysis Algorithm.
Attempts to keep the
multiprogramming level (MPL) at its
target level in each domain by
performing user swaps.
IRARMCPI - Select Swap-In Candidate Subroutine.
Scans the OUT queue for the user in
a particular domain with the highest
recommendation value.
VS2.03.S07
Select Swap-Out Candidate
Subroutine.
Scans the IN queue for the user in a
particular domain with the lowest
recommendation value.
IRARMCVL - User Swap Evaluation Routine.
Computes a numerical value
representing the recommendation of a
IRARMCPO -
user to be swapped in. This
recommendation value is the sum of
the user's workload level and the
recommendations of the I/O and CPU
resource managers.
Section 2: Method of Operation 3·43.7
3·44
OS/VS2 System Logic Library Volume 3 (VS2.03.807)
VS2.03.807
Resource Use Algorithms
The resource management algorithms are concerned
with improving overall system resource utilization.
These include:
Storage Management
• Page Replacement - This function maintains
an up-to-date indication of which frames have
gone unreferenced for the longest period of
real time and the age of the oldest
unreferenced frame in the system. This is
accomplished by invoking the real storage
manager's (RSM) routine lEA VRFR, real frame
replacement (RFR), at periodic real time
intervals so that RFR may increment the
unreferenced interval count (UIC) for those
unreferenced since the last RFR invocation. If
RFR finds that an allocated frame was
referenced in the last interval it resets the UIC
to zero. When the page replacement algorithm
completes updating the UIC's for all allocated
frames it then saves the highest UIC in the
system for use by the real page shortage
prevention algorithm and the resource
monitor algorithm.
• Real Page Shortage Prevention - This
function is invoked by SRM when the
available frame queue falls below the
available frame queue LOW threshold
(PVTAFCLO) so that SRM can take action to
remedy the existing real page shortage. When
the real page shortage prevention algorithm is
notified of a real page shortage it will steal
frames from all users and the system pageable
area (SPA). It steals the oldest unreferenced
allocated frames in the system starting with
the highest UIC as saved by the page
replacement algorithm until the count of
available frames plus the count of the pages
stolen exceeds the available frame queue OK
threshold. (PVTAFCOK).
• Auxiliary Slot Shortage Prevention - This
function is invoked at periodic intervals to
check for two levels of auxiliary slot
shortages. Reaching the first level threshold
causes the creation of memories to be
prevented, the swap-out of the batch user
who is acquiring auxiliary storage slots at the
greatest rate, the delay of newly initiated
jobs, and the setting of all domains to their
minimal MPL. Messages are written to the
operator indicating the occurrence of either of
the shortages and the jobnames of the users
swapped out because of the shortage.
Additionally, when this function determines
that the auxiliary slot shortage is relieved a
message is wriften to the operator indicating
the alleviation of the slot shortage. Creation
of memories is again allowed and those
memories that were swapped out are again
made eligible for swap-in.
• SQA Shortage Prevention - This function is
invoked by the virtual storage manager (VSM)
when a shortage of system queue area (SQA)
space is detected. This function will then
prohibit the creation of memories for the
duration of the SQA shortage and notifies the
operator of the existence and severity of the
shortage. Also, a message is written to the
operator when VSM informs this function that
the SQA shortage has been relieved and the
creation of memories is again permitted.
• Page able Real Storage Shortage Prevention This function is invoked by the real storage
manager (RSM) when the percentage of fixed
frames to total frames exceeds a predefined
limit. This function will then prohibit the
creation of memories, initiate a swap-out for
the swapp able user who has allocated the
greatest number of fixed frames, deiay newly
initiated jobs, and set all domains to their
minimal MPL. The operator is notified of the
existence and severity of the pageable storage
shortage and of the identity of the swapped
users. Additionally, when this function
determines that the shortage has been
relieved, a message is written to the operator
indicating the alleviation of the shortage.
Creation of memories is again allowed, and
those memories that were swapped-out are
again made eligible for swap-in.
110 Management
• Device Allocation - This function makes
device allocation decisions, based on I/O load
balancing considerations when a choice must
be made from more than one device
candidate. The device allocation decis~on· is
made by applying the following rules to the
list of candidates (in the order indicated):
1. If the request is for tape, eliminate all
candidates on ready devices (eliminate
premounted tape drives) and on devices
that contain passed volumes.
Section 2: Method of Operation 3-45
VS1.03.807
2. Choose the candidates on the logical
channel with the lowest utilization. The
utilization takes into account any datasets
previously allocated to the logical channel.
3. Choose the direct access candidates with
the lowest allocated user counts.
4. From a list of equal candidates, choose one
at random.
5. Insure that the selected candidate device
has not been previously allocated to the
same user.
I/O Load Balancer Swap Analysis - Consists of a
set of routines that monitor I/O logical channel
usage of certain users. Users are recommended for
swapping based on the extent to which the swap-in
or swap-out of a user would correct a detected I/O
system imbalan.)
~OUCB
v
"In Queue"
Q
lJl
eN
00
9
PRI RMEP
MCT
I
Initial
Value
I
i
From Algorithm
Processor as a
Result of a
Request by
Algorithm Request
(lRARMCRL)
..
Steal as many pages as required to
relieve the real page shortage. The
decision to steal is made at
IRARMMS2 (see step 5).
...
.
~
...
Return.
I
PVTAFCOK
PVTAFC
~
00
..
9
OUXBSTCT
IRARMSRV
IRARMI03
R F R Interface
To Algorithm Processor
(lRARMCEU
PRIREMP
") 5
v
.
Reset I RARMPR 1 .invocation
interval.
...
..
PVT
MCT
MCTAVQI
RMEPINT
4
.. OUXB
RMEPINT
MCT
...
..)
If AVQLOW level 1, 2 or 3
calculate number of pages needed
to be stolen and schedule
IRARMPR5 (step 4) to be executed.
....
MCTFRCNT
"
RMCTALA
I
Return. . . To Algorithm Processor
(lRARMCEU
I
]
~
Diagram 6-12. Storage Management (IRARMSTM)
(part 4 of 8)
Extended Description
Module
Label
4
The Real Page Shortage force steal routine is a
co-operative effort between the SRM and RSM.
SRM calls the RSM routine, IEAVRFR, passing a
parameter list identifying an in storage user, the number of
pages needed and a steal criteria number, MCVST~RI.
All pages associated with this user that have a U IC
greater than the steal criteria are no longer considered
part of the user's working set and are stolen. If not
enough pages were stolen, another user is identified
and IEAVRFR will steal all pages associated with this
user that have a UIC greater than the steal criteria.
If, after all eligible users have been stolen from at
this criteria, pages are still required, the steal criteria
will be decremented by one and the process repeated
until no further pages are required. The result of this
procedure is that the oldest unreferenced system wide
pages are stolen first. Pages in the common system
area and link pack area are not associated with any
specific user. RSM examines these pages when SRM
page replacement calls it with an ASCB address of zero.
IRARMSTM
IRARMPR5
STEAL
IRARMI03
5
IRARMSTM
IRARMMS2
IRARMCTL
IRARMCRL
The SRM will have received an AVOLOW
SYSEVENT if there is a shortage of real page
frames. Reset the IRARMPR1 interval back to its
original value. If the invocation is due to A VOLOW
level 1,2 or 3 (real page shortage) calculate the
number of pages needed to get the available frame
queue back to the OK threshold and invoke the
forced steal algorithm via the algorithm request
mechanism.
tI.I
(D
n
g'
~
a::
(D
~
8.
e.
o
"CI
i
w
J;,.
\Q
IRARMSRV
,
./
;;j
~
Q
w
00
Q
.....,
~
I
Diagram 6-12. Storage Management (IRARMSTM)
(part 5 of 8)
<:>
~
~
,
"In Queue"
Header
OUCB
"In Queue"
ldJ
ASCB
I:
Control
Swap Out
Set the domain targets to the
minimum and request the swap-out
of selected users.
From Algorithm
Processor
(lRARMCEL) as
a Result of a
Request by
Periodic Entry
Point
Scheduling
(lRARMCET)
DMDT
~
v ...._ _ _ _ _- ;
Return.
•
To Algorithm
Processor
(lRARMCEL)
...
: >7
_10..
...
Request the swapping of users
determined to be in a wait state
for a sufficient period of time.
L
...
IRAR
IRARMCSO
Control
Swap Out
OUXBs
~----II
~
v
l
I~
Base
Values
-r:;::
Return.
To Algorithm Processor
(lRARMCEL)
Base
Values
Q
~
00
S
'- ,,-
~
Diagram 6-12. Storage Management (IRARMSTM)
(Part 6 of 8)
Extended Description
Module
Label
6
IRARMSTM
IRARMMS2
IRARMSRV
IRARMI09
Pageable Real Frame Shortage, indicated by
AVQLOW Level 4, checks for two levels of
shortages. A first level shortage causes the prevention
of further memory creates, the setting of domain targets
to minimums, the delay of newly-initiated jobs and
the swap out of the user which has the greatest number
of fixed frames. When the second level is reached,
another swappable user with the greatest number of
fixed frames is also swapped-out. Messages indicating
the occurrence of both levels and a message identifying
the users swapped are written to the console. A
message is also written indicating the alleviation of the
shortage.
'cf
-<
en
N
o
<.oJ
7
Users who issue a long wait macro instruction will
be detected by the SRM when the wait macro
processor issues the NIOWAIT SYSEVENT. Users who
do not issue a long wait macro instruction to notify
the SRM that they will be in the wait state for a "long"
time will be detected when they have gone without
executing for a sufficient period. At this time, swappable
users will be swapped-out.
en
g
g
N
a::
(I>
;.
8-
o
-.
o
"0
(I>
i
<.oJ
V.
00
IRARMSTM
I RARMMS6
o
.....,
~
tit
I Diagram 6-12. Storage Management (IRARMSTM)
Q
From Algorithm processor (J RARMCEU as a request
by Periodic Entry Point Scheduling (J RARMCEn
~
"<
C"Il
IV
(Part 7 0(8)
Output
Input
~.
~
1
I
I
I
Output,
v
--1\
Compute logical channel utilization values.
-V
~ /0
Management
Control Table
RLCTRORT
RLCTRVUF
ICT
3
(D
CJ
lOS Logical
Channel Table
Process
c
I
~
00
Q
tI)
'-l
~
o
~
00
Q
~
<:
tI)
t.)
OUXB
(Extension block
for users in real
storage)
-'"
) 2
...
From OSCEST (12)
in Sysevent Processor
I/O Usage
I riformation
ICVLCBPT
...
I
IMCB
(I/O measurements
control block)
I
RLCT
I
Return to
Sysevent
Processor
(lRARMEVT)
IIRARME_
ICT
[
Initiate the updating of user I/O profiles for
heavy I/O users who have not recently been
monitored (swapped).
I
I
F rom User Swap
Evaluation
(lRARMCVLl
During Partial Swap
Analysis
(lRARMCAP)
3
Update user I/O profiles.
OUCB
--...
...
...
...
4
Compute a value representing the
desirability of the swap-in or swap-out
of a user.
.I.
""
--,.I'
Return to Swap
Evaluation
(IRARMCVLl
Recommendation
Value
(OUCBIRV)
Time of
Recommendation
(OUCBTIO)
'c~
Diagram 6-14. I/O Management (IRARMIOM)
(part 2 of 2)
Extended Description
Module
I/O Management consists of a set of routines that monitor
the I/O logical channel usage of certain users. They recommend users for swapping based upon the extent to which
the swap-in or swap-out of a user would correct a detected
IRARMIOM
Label
2
I/O system imbalance. One I/O management function is
described elsewhere:
• I/O load balancing IMCB (I/O measurement control
block) deletion is performed due to execution of the
INITDET(11) SYSEVENT and is described in the
SYSEVENT Processor M.O.
IRARMIOM IRARMIL4
1
IRARMIOM IRARMI L 1
For each logical I/O channel in the system, the following are calculated:
Extended Description
I/O management generates a request that the heavy
I/O user, who has not recently been monitored, be
swapped out (via Control Swap-Out IRARMCSO), solely
for !he purpose of 'obtaining addressability to the user's
TCTIOT % timing control table). When the quiesce
started SYSEVENT is received by the SRM, the measurements will be obtained, and quiesce processing will be told
to "turn the user around" (i.e., do not continue with quiesce
processing). See SYSEVENT Processor M.D., SYSEVENT
QSCEST.
3
See I/O load balancing user I/O monitoring M.O.
4
• Logical channel utilization (the percentage of recent I/O
requests for the channel that encountered a busy
condition.
LCHUSE
• Logical channel request rate (rate of recent I/O requests
per second) .
LCHUSE
• Logical channel utilization factor (difference between a
threshold utilization and actual utilization, squared, with
a sign indicating whether the logical channel is overutilized or under-utilized; for logical channels with a
balanced I/O utilization, the factor equals zero).
LCHUSE
The I/O swap recommendation value for a user varies
with the extent to which the user makes use of out-ofbalance logical channels and the degree to which the channels are out of balance. The maximum for this recommendation value is one-fifth of the largest work load level. The
I/O resource factor coefficient (RMPTIOC) is factored in
to produce the final user swap recommendation value.
.,
CI.l
~
g.
o·
=
~
ac
~
~
8-
o
000)
o
"0
~
Co)
g.
=
~
&.
VI
$
Module
Label
IRARMILl
IRARMEVT IRARME12
IRARMIOM IRARMILO
IRARMIOM IRARMIL3
IRARMCTL IRARMCVL
<
CI.l
N
<=>
~
00
o
.......
VS2.03.807
This blank leaf represents pages 3-56 - 3-57 which were deleted by Supervisor Performance #2.
3-56 tluu 3-57
OS/VS2 System Logic Ubrary Volume 3 (VS2.03.807)
~
.•
/
Section 2: Method of Operation
3-57
~
Diagram 6-16. I/O Load Balancing User I/O Monitoring (IRARMlLO) (part
10(4)
00
~
~
N
til
From QSCEST
SYSEVENT (12)
in IRARMEVT
Input
Process
Output
'<
=-
a
b
~.
t:
2'
~
~
OUCB
~
IMCB
u
1
Obtain and initialize IMCB
if not already available.
r
~
CD
CN
~
RLCT
ASCB
N
b
CN
ASCBASXB
00
C
-...J
ASXB
ASXBLCTB
LowestTCB
Job Step TCB
TCBTCT
TCTIOTBL
2
Access total cumulative EXCP
counts for all devices of all DO
statements by logical channel.
RLCTUMWA
'~~_7
Diagram 6-16. I/O Load Balancing User I/O Monitoring (IRARMlLO) (part 2 of 4)
Extended Description
Module
I/O load balancing user I/O monitoring maintains detailed
information on logical channel (LCH) utilization for heavy
I/O users. This LCH information is used by other I/O load
balancing functions to influence swapping decisions when
heavy users are using out-of-balance logical channels
(over-utilized or under-utilized).
IRARMIOM IRARMILO
This monitoring is done at the time of the quiesce-started
SYSEVENT (SYSEVENT 12). At this time, the I/O Timing
Control Table (TCTIOT), which contains monitoring
source data, is addressable. Entry through the quiescestarted SYSEVENT may be forced for a user who has not
been monitored recently (see I/O Management (lRARMIOM)
M.O.).
1
If I/O load balancing is active and the user does not
have an IMCB, obtain an IMCB if the user's total I/O
request rate is high enough (that is, higher than ICCMNIOR).
2
Access TCTIOT, looking at all user data set
declarations, and access all devices allocated to each
data set. Through the UCB, associate the device to a logical
channel, and sum the user's EXCPs by logical channel using
RLCTUMWA as a working variable for the summation.
fIJ
G
Sl.
8'
=s
N
ac
G
[
~
o
1~
8'
=s
eN
u-
\Q
Label
~
Diagram 6-16. I/O Load Balancing User I/O Monitoring (IRARMILO) (part 3 of 4)
c
o
en
~
N
en
~
~
~
«2
OUCB
~
~i ")
n'
~
J<
Q
ea
OUCBIMCB
v
(Mca
3
Create or update user lCH usage
entry for each logical channel
on which user has made requests,
j
" b,
....
IMCB
IMCBlBGN
IMCBlEND
IMCBSlCB
(II
1M
;~
'
~
00
o
.::!
RMCTlNQE
~
-
Execution
Time
T
"IN"
Queue
Header
~Queue
Same as
IRARMI02
Change
Dispatching
Priority
CCT
~
RMPT
Logical Configuration
Communication Area (one per CPU)
~
LCCAWTIM
CPU Management
Control Table
CCT
I I
I
..
- ....
ICCVENQCTI I RMPTERV I
CSDA
0
Return.
IRARMSRV
OUCB "IN"
CCT
II
a_
_
OUCBDP
"
2
y
II
..") 3
Y
CCVENQCT
Monitor users previously given permission
to accumulate extra CPU service because,
of their use of a serially reuseable (ENQ)
resource in demand by other users.
"
OUCB
..
Revoke a user's permission to accumulate
extra CPU service, if he has accumulated
a threshold amount of extra ~ervice.
.
Return.
ab'"
OUCBENQ
"
A
CCT
Same as
."
..
)4
Return to
Algorithm Processor
(lRARMCEU
Compute CPU utilization variables.
II
6
..
"
CPU Utilization
(CCVUTlLP)
System Wait
Factor
(CCVRVSWF)
~
t..a
<=>
~
00
o-...l
'''"'--'
Diagram 6-17. CPU Management (IRARMCPM) (part 2 of 4)
rI'.l
(D
t')
g.
=
~
~
(D
:;
8-
o....
o
"0
(D
;1
g.
=
w
0w
Label
(or Segment)
Extended Description
Module
CPU Management consists of a set of routines thaf monitor
the system-wide CPU load. They recommend users for
swapping when the system is under or over-utilized. One
CPU management function is described elsewhere:
IRARMCPM
• CPU load balancing system profile adjustment is performed
when the SRM receives a QSCECMP SYSEVENT (13); it
is described in the SYSEVENT Processor table.
IRARMCPM
IRARMClO
1
IRARMCPM
IRARMAP1
An optional parameter of the period definition in
the IPS has the following format: APG=I where I is
an integer between 0 and 15, this parameter applies only
to those transactions whose beginning dispatching priority
(from the job or step JCLl lies within the APG range
defined in I EASYSxx. It is ignored for those transactions
which lie outside the range. The effect of this parameter
is that the initial dispatching priority (at transaction
start and initiator attach) is set to the I value plus the
lowest APG dispatching priority. If the parameter is not
coded, it defaults to the highest mean time to wait
priority in the APG: 6. If the value I is 6 or less, subsequent
dispatching priorities will be calculated based on the
address space's mean time to wait; that is, the average time
he was in execution before entering the wait state. The
lower his mean time to wait, the higher will be a user's
priority within the APG. This computation is performed
for all APG users in main storage who have executed for
greater than a threshold of time (CCCAPMET) since their
last computation. If the value I is 11 the address space
will enter a rotate group. At a timed interval, SRM will
examine all address spaces in the rotate group. If there
is more than one, SRM will move the first dispatchable
address space in the group to become the last address
space of the group on the dispatching queue.
If the value I is any other valid integer, the dispatching
priority will be unchanged until the APG parameter is
changed on the IPS period specification. Since it is also
possible for a user's dispatching priority to be recalculated
while he is being swapped out (See SYSEVENT
QSCECMP (13) - profile adjustment, in SYSEVENT
Processor table), periodically both "IN" and "OUT" users
are checked to see if their order must be changed on the
dispatching queue. This function re-sets its time of next
Module
Label
(or Segment)
2
A user is given permission to accumulate extra CPU
service when an ENQHOlD SYSEVENT (20) is
received by the SRM, indicating that he holds a resource
in demand by other system users. The mechanism for
giving him this extra service is the prevention of his swap
out by the SRM because of service rate considerations.
IRARMCPM
IRARMEQ1
3
IRARMCPM
IRARMEQ1
Extended Description
invocation, based upon the percentage of APG users that
had their dispatching priorities changed.
The Enqueue Residence Value (ERV), an OPT
parameter, specifies the length of the privileged
"spurt" of service for a user for whom an ENQHOLD
SYSEVENT (20) has been issued (see 21. When this
time is exceeded, the user is made eligible for swap-out,
and his OUCB is so flagged. The individual user
evaluation routine is called to assign a current workload
manager recommendation value to this user.
4
The CPU utilization is the average percentage of
time any CPU in the system was not in the wait
state. It is computed by the following formula:
NEWDP
~
0
w
00
0
........
IRARMWLM
IRARMWM3
IRARMCPM
IRARMCL1
r:(sum of wait routines on each CPU) *100
]
utilization = 100 -L:
(elapsed time since last entry) *(number of CPUs)
CPU utilization is artifically set to 101% if actual
utilization is 100% and one Or more users have not
been dispatched. This allows the CPU to be considered
over-utilized even if the CPU threshold is 100%. The
system wait factor is calculated for use in determining
the swap recommendation value for a user (see CPU
Management M.D., step 5); it is a multiple of the square
of the difference between a threshold value and the
utilization, with the sign indicating the direction of the
imbalance (over- or under-utilized). If the CPU
utilization falls between the high and low thresholds,
the factor equals zero.
<:
rI'.l
CPUWAIT
CPLRVSWF
eM
~
Diagram 6-17. CPU Management (IRARMCPM)
(Part 3 of 4)
.a:.
o
CIl
"<
CIl
t-J
CIl
'<
during Swap
Analysis
i
9
URARM_
f"'"
Q
'19.
f')
f"'"
I
J
CCVRVSWF r
&
~
I
J
<
Q
2'
9(D
eM
!~
OUCS
CCT
OUCS
) 5
Compute a value representing the
desirability of the swap-in or swap-out
of a user, based on the user's effect on
system CPU utilization.
r
Recommendation
Value
(OUCSCRV)
Time of
Evaluation
(OUCSTCP)
OUCSCRV
<
CIl
t-J
beM
00
<:)
.....
. . , . . Return to User
Evaluation
(lRARMCVL)
~~~
Diagram 6-17. CPU Management (IRARMCPM)
(Part 4 of4)
Extended Description
Module
Label
(or Segment)
5
The CPU swap recommendation value for a
significant CPU user varies with the degree to which
the CPU load is out of balance. The recommendation
value can not be greater than one-fifth the highest workload level. For insignificant CPU users, the
recommendation value is zero.
IRARMCPM
IRARMCL3
The time of this evaluation and the swap recommendation are saved in the OUCS. The user swap evaluation
routine, IRARMCVL, then multiplies the
recommendation value by the CPU resource factor
coefficient (RMPTCPU) to produce the final CPM
swap recommendation value.
I RARMCTL
I RARMCVL
<
CIl
N
o
W
00
c:
-..J
CIl
(1)
(")
g.
=
~
s::
(1)
;;
8.
....o
o
'e
...
(1)
ac)"
=
w
0-.
VI
VS2.03.807
IRARMCPM Module Entry Point
Summary
IRARMAPl - Automatic Priority Group Reorder
Processing.
Recompute dispatching priorities for
all APG users in main storage. Invoke
ASCBCHAP for each user whose
dispatching priority has changed.
IRARMEQl - ENQ/DEQ Algorithm ENQ Time
Monitoring.
Stop giving extra CPU service to users
with ENQHOLD SYSEVENTs
outstanding who have already
received their quaranteed CPU service.
IRARMCLO - CPU Load Balancing User Swap
Processing.
Compute user CPU usage profile at
QSCECMP SYSEVENT.
IRARMCLl - CPU Utilization Monitoring.
Compute CPU utilization variables for
CPU load balancing and resource
management algorithms.
IRARMCL3 - CPU Load Balancing User Swap
Evaluation.
Produce a numerical recommendation
value which reflects the desire ability
of swapping a user based on its CPU
utilization.
3·65.0
OS/VS2 System Logic Library Volume 3 (VS2.03.807)
CHAP - IRARMCPM Internal Chapping Subroutine.
Search queue for APG users with
changed dispatching priorities, put
them in a list and call ASCBCHAP.
CPLRVSWF - IRARMCPM Internal Wait Factor
Computation Subroutine.
Compute system wait factor for CPU
load balancing recommendation value
computation.
CPUWAIT - IRARMCPM Internal Wait Time and
CPU Utilization Compute. Subroutine
Compute accumulated system wait
time total for all CPUs and compute
recent CPU utilization.
CPUTLCK - IRARMCPM Internal CPU Utilization
Checking Routine.
Insure that the computed CPU
utilization percentage falls between 0
and 100 percent. If 100 percent and
lowest priority user has not been
dispatched, set it to 101 percent.
NEWDP - IRARMCPM Internal APG Computation
Routine.
Compute mean time to wait and a
new dispatching priority for the APG
user.
Section 2: Method of Operation
3-65.1
~
'"
o
Diagram 6-18. Resource Monitor Periodic Monitoring (IRARMRM1)
0'1
C"I'J
"<
C"I'J
..
From Algorithm
Request (lRARMCEU
Input
~
C"I'J
~:I
~
~.
(')
~
0:
~
<
S2.
c
:I
~
~
(part 1 of 2)
Output
Process
RCT
RCVUICC
MCT
I
MCVSTCRI
I
CCT
I
CCVLGUTL
I
II.
I
') 1
...
I
Sample system and domain
resource contention
indicators.
'"...)
RCVASMO
RCVCTMC
~
~
o
ASMVT
<
~
00
o
.....
ASMIOROC
Return to Algorithm
Request (lRARMCEU
DMDT
I-~
DMDTCMPL
DMDTOUTU
I
I
)
...
ASMIOROR
~
o
~
DMDT
...
C"I'J
RCVCPUC
II
DMDTRUC
I
00
tb
o
.....
'- j'
~
,~--;
Diagram 6-18. Resource Monitor Periodic Monitoring (IRARMRMI) (part 2 of 2)
Extended Description
Module
Label
1
IRARMRMR
IRARMRM1
This routine is invoked at one second intervals and
accumulates the highest system unreferenced frame
interval count (MCVSTCRI), the current CPU utilization
(CCVLGUTL), and the number of un·completed ASM
requests (ASM requests minus ASM completed requests).
Additionally the number of ready users (the number of
users on the IN queue plus the number of users on the
OUT queue) for each domain is accumulated.
<:
til
N
o
~
00
<:>
....a
~
til
n
~.
N
a:
til
[
So
o
'C
~
~
g'
CN
~
....a
I.f
~
I Diagram 6-18A. Resource Monitor MPL Adjustment Processing (IRARMRM2) (Part 1 of 2)
,
....
00
~
<
From Algorithm
Request (lRARMCEU
Input
til
N
til
~
S-
a
o
ce.
RCT
MCT
I
~
(')
RCVUICC
~
s:
~
<:
o
RCVCPUC
PVT
c
a
RCVASMQ
w
RCVCTMC
(1)
MCVAVQC
Process
Output
"-
"-:1"
~
~
RCT
II
">1
v
DMDT
~
Compute the system contention
and average the ready users by
domain.
"
RCVUICA
I, ~MDTRUA tn
RCVCPUA
Pit:
RCVAVQC
<:
til
N
RCVAVQP
PVTNPIN
(:,
W
00
o
......
RCVASMQA
PVTNPREC
~
RCVPTR
til
N
(:,
DMDT
W
I
00
o
.:::!
I
DMDTRUC
I
'N
~
, .."..
DMDT
. .) 2
-'"
v
Compute the domain contention.
"
DMDTRUA
DMDTMPLT
Minimum Contention Domain
I
It
Maximum Contention Domain ,
':;t,
~
~,
3
DMDTRUA
DMDTWT
It
I
Adjust the domain
mu Iti programmi ng
levels (MPLs)
A
<
: II
<
~
- raise the MPL.
- lower the MPL.
I
~.
.
v
or
DMDT
I
I
- equalize the MPL.
DMDTMPLT
I
~
I
I
ii
ITJ
q
... -_......--7
Diagram 6-18A. Resource Monitor MPL Adjustment Processing (IRARMRM2) (Part 2 of 2)
Extended Description
Module
Label
Extended Description
This routine is invoked at 30 second intervals and
processes the data accumulated by IRARMRM1 to
compute the average unreferenced frame interval count
(RCVUICA), the number of "AVQ Lows" over the last
RM2 interval (for tracking only), the average ASM queue
length (RCVASMQA), the system page fault rate per
second (RCVPTR), and the average number of ready
users for each domain (DMDTRUA). IRARMRM2 also
computes the system-wide logical channel utilization.
If the average logical channel utilization is above a
threshold value or if an individual logical channel has
a high utilization and request rate above threshold values,
a contention indicator, RCVIOUSE, is set. The above
system and domain contention factors are used to
adjust the domain target MPLs as follows:
IRARMRMR
IRARMRM2
• If any domain is unused (average number of ready
users less than target minus one) that domain's
MPL is decreased by one if the decrease does not
drop it below the minimum MPL or one.
2
• If the system MPL should be decreased, the Resource
Monitor will pick the domain with the lowest
contention index which has not yet reached its minimum
MPL and decrease this domain's MPL by one.
Each used domain contention index is computed
by the formula:
max (current target MPL or one)
3
The Resource Monitor will then determine if the
system MPL should be raised or lowered by
comparing the system contention indicators against predefined limits. All positive conditions must be met to
increase and only one condition need be met to force a
decrease in the MPL.
o·
=
LIMITS
INCREASE
MPL
N
~
('II
;.
8o
....
o
~
('II
'"t
I»
g'
UIC*
CPU utilization
PAGE FAULTS
ASMQ
Average logical channel utilization
Logical channel utilization
GT
LT
LT
LT
LT
LT
95%
30/sec
10 requests
20%
30%
Logical channel request rate
LT
50 requests
t..I
0.-
~
*unreferenced internal count
<
en
N
o
~
Oc
C
-....J
• If the system MPL should not be increased or decreased,
the Resource Monitor will attempt to equalize the
domain's contention index; such that if the highest
domain contention index is greater than the lowest,
the Resource Monitor will increase the MPL for the
high contention domain and decrease the MPL for the
lowest contention domain.
This yields a measure of contention for this domain
weighted by the user specified importance factor
(weight) for the domain.
~
Label
• If the system MPL should be raised, the Resource Monitor
will pick the domain that has the highest contention
index and has not yet reached its maximum MPL and
increase this domain's MPL by one.
average ready users x weight
en
('II
Module
DECREASE
MPL
LT
GT
GT
GT
GT
CT
GT
99%
40/sec
20 requests
20%
)
and 30%
50 requests
VS2.03.807
IRARMRMR Module Entry Point
Summary
IRARMRM 1 -
IRARMRM2 -
3-68.2
Resource Monitor Periodic
Monitoring.
Accumulate several system resource
contention indicators and the number
of ready users for each domain at
periodic sample intervals.
Resource Monitor MPL Adjustment
Processing.
Compute the average system resource
utilization and determine if the
system MPL should be raised or
lowered.
OS/VS2 System Logic Library Volume 3 (VS2.03.807)
VS2.03.807
Workload Management
~,
The workload manager is a collection of
subroutines which perform three main functions:
• Monitoring the rate at which system resources
are being provided to individual address
spaces.
• Providing swapping recommendations (based
on installation specifications and resource
usage) requested by SRM Control
(IRARMCTL).
• Collecting data for MF/l workload activity
reporting.
Subroutines that support the first two functions
above are packaged in the workload manager
module (IRARMWLM), and the data collecting
subroutines are in the workload activity recording
module (IRARMWAR).
Nonswappable address spaces and certain
privileged system control program functions are not
under the control of the workload manager.
In providing swapping recommendations to SRM
Control, the workload manager affects the relative
rates at which processing resources are provided to
active address spaces. By comparing an address
space's resource usage (service rate) against the
installation performance specifications, the
workload manager computes the address space's
workload level (also called workload manager
recommendation value) which is used by SRM
Control as a swapping recommendation.
The workload activity recording facility
(IRARMWAR) collects data for MF/l when MF/l
workload activity reports have been requested. This
facility is invoked periodically by the workload
manager and the SYSEVENT processor to collect
data, that is placed in the workload activity
measurement table (w AMT). The workload activity
reports may be analyzed by an installation and
used to determine the appropriate installation
performance specification parameters to meet their
needs.
(See the MF/l and SRM sections of the OS/VS2
(MVS) Initialization and Tuning Guide on using
workload activity reports).
Several workload management functions are of a
housekeeping nature, and are triggered by the
receipt of certain SYSEVENTS. These are described
in the SYSEVENT Processor M.O., and include:
• Service calculation routine - invoked by
SYSEVENTS WKLDINIT(45) and REQSERVC
(38).
Module
Label
IRARMWLM
IRARMEVT
IRARMWMI
IRARME45,
E38
• Workload level calculation - invoked by
SYSEVENT WKLDCOLL(46).
Module
Label
IRARMWM4
IRARMWLM
IRARMEVT
IRARME46
• Start new transaction - invoked by
SYSEVENTS RESETPG(31), TGETTPUT(34)
and INITATT(10), and module IRARMSET
after a NEWIPS(32) SYSEVENT is received.
Module
Label
IRARMWLM
IRARMEVT
IRARMWMN
IRARME31,
E34,ElO
IRARMSET
IRARME32
IRARMEVT
• Swap status change request - invoked by
SYSEVENTs DONTSW AP( 41) and
OKSWAP(42).
Module
Label
IRARMWMK
IRARME41,
E42
• Stop old transaction - invoked by SYSEVENTS
JOBTERM(9), INITDET(1l) and
JOBSELECT(8).
IRARMWLM
IRARMEVT
Module
Label
IRARMWMO
IRARME09,
Ell,E8
• Restore completed processing - invoked by
SYSEVENTs RSTORCMP(19) and INITATT(10).
IRARMWLM
IRARMEVT
Module
Label
IRARMWLM
IRARMWMR
Section 2: Method of Operation
3-69
VS2.03.807
IRARMEVT
IRARMEI9,
EIO
• Quiescecompleted processing - invoked by
SYSEVENT QSCECMP(13).
Module
Label
IRARMWLM
IRARMWMQ
IRARMEVT
IRARME 13
The following workload manager M.O.s describe
3 major functions performed by the IRARMWLM
module:
• Swappable user evaluation.
• Scanning the IN queue and OUT queue,
evaluating each non-privileged, swappable
user, and assigning a current workload level.
• Individual user evaluation - evaluating a (one)
non-privileged, swappable user, and assigning
a current workload level.
3-69.0
OS/VS2 System Logic Library Volume 3 (VS2.03.807)
• User ready processing - initializing user
control blocks and repositioning the user from
the WAIT queue to the OUT queue so the user
is eligible for swap-in.
The following workload activity recording M.O.s
describe 2 major functions performed by the
IRARMW AR module:
• WAMT initialization
• updating the workload activity
measurement table (w AMT) with
information from the workload' manager
specification table (WMST).
• WAMT reinitialization
• copying the WAMT data to a temporary
buffer and then updating service values and
workload levels.
Section 2: Method of Operation
3-69.1
~
I
Diagram 6-19. Swappable User Evaluation (IRARMWM2) (part I
c
oCIl
~
CIl
N
CIl
'<
a=r-
~.
C":
r-
i
..
From Algorithm
Routine (lRARMCRT)
Input
RMCT
"IN" "'t-:::..
Queue
Header
?
RMCTINQE
RMCTOTQE
~
"OUT",
Queue
Header
<
2:3
c
r-:..
OUCB
"IN"
Queue
n
Process
to.
)
--v
1
Output
Pick user from queue for
evaluation.
OUCB
"OUT"
Queue
(II
CoN
I
<
of 4)
n
<
CIl
N
Q
CoN
00
CIl
C
N
Q
CoN
00
C
-..I
Workload Manager
Specification T able ~..:::"
B
...
...)
2
WMST
Obtain user service
(IRARMWM1).
..)
OUCBWMS
OUCBIOC
OUCBMSO
OUCBCPU
OUCB
I
OUCBPSS
I
-..I
OUCB
OUXB
OUXBPSS
OUXBMSS
OUXBIOS
ASCB
ASCBEJST
ASCBIOSM
OUXB
Performance
Group
Descriptor
OUCB
WPGD
"""-"""
"
I
..
WPGLDUR
WPGPAPGV
WPGPDMN
"
3
Check for Performance
Group Period change
(IRARMWM5).
OUXB
OUCBWMS
OUCBTMP
OUCBDMN
OUCBAPG
OUXBPRS
I
I.
..
r1
I
OUXBPRS
OUCB
OUCBPGP
OUCBDMN
OUCBDMO
OUCBNDP
OUCBTMP
I
~~
Diagram 6-19. Swappable User Evaluation (IRARMWM2) (Part 2 of 4)
Extended Description
Module
Label
IRARMWLM
IRARMWM2
The WM2 routine is invoked by I RARMCET
approximately every second to evaluate all users that
have not been evaluated during the past second and
whose period duration is specified in real time. If no
periods have real time specified anywhere in the IPS,
IRARMWM2 will not be invoked. This ensures that
users with period durations specified in real time
units are evaluated for period change even though
they may be in an inactive domain.
1
Both the IN and OUT queues are scanned,
evaluating non-privileged swappable users.
2
til
g
g.
=
t.J
==
~
:;.
&.
....o
o
"0
l=
w
~
o
W
WM1 is invoked to calculate the service
accumulated during the "in real storage
interval" for users currently in storage.
IRARMWLM
3
IRARMWLM
IRARMWM5
I RARMWAR
I RARMWR4
IRARMCTL
IRARMRPS
Depending on the units code in the IPS (service
units or time units), the transaction's accumulated
service or time units are checked to determine whether
a period has ended. If a period has ended, the current
period indication is updated. If workload reporting is
also active, IRARMWR4 is invoked to communicate
the period change. If in switching periods, the user
also changes domains, he will be repositioned at the
end of the appropriate queue. The user dispatching
priority is also updated, if applicable.
<
til
t.J
IRARMWM1
00
<:>
-....J
~
I
Diagram 6-19. Swappable User Evaluation (IRARMWM2) (Part 3 of 4)
N
~
~
N
fIl
Ii=:
~.
Performance
Group
Descriptor
r-
f
~
a
CD
Output
Process
Input
WPGD
WPGLlSV
,.~------~.r~J
OUCB
4
Performance
Objective
Determine the workload
level at which this user is
receiving service
(lRARMWM7L
OUCBWMR
OUCBTMA
OUCBWMS
OUCBTMW
<:
fIl
N
~
~N
Q
~
00
5
Obtain the next user for
evaluation.
Go to
Step 1
~
Return to Algorithm
Routine (lRARMCRT)
Q
~
00
S
~
'-~#
Diagram 6-19. Swappable User Evaluation (IRARMWM2) (Part 4 of 4)
Extended Description
Module
Label
4
IRARMWLM
IRARMWM7
The workload level is a means of comparing users
to other users in the same domain. If a user has
not yet received enough service to be controlled by the
workload manager (that is, his service is less than his
interval service value-ISV) or if the user is between job
steps, a workload level corresponding to a zero service
rate is returned. In calculating his recent service rate,
a user's accumulated service is reset to zero when he is
swapped-in; his accumulated time is reset to zero when
he is swapped-out.
5
Processing continues until all users on the IN and
OUT queues are evaluated.
<:
rI'.l
N
(:,
IN
00
S
rI'.l
~
t':l
g.
::s
N
a::
~
~
8-
o-.
o
...
"d
~
~
g'
IN
..!J
IN
.!.f
......
IN
Q
~
~
t-J
t:I:l
~
S-
a
S
Diagram 6-20. Individual User Evaluation (IRARMWM3)
..
From User
Evaluation (IRARMCVL)
Input
. . . Process
Workload
Manager
Specification
Table
EJ
WMST
~.
;:
,
OUCB
I
OUCBPSS
ASCS
t"'"
~
(part 1 of 2)
;
i>
1
I
Output
OUCB
"...
Obtain User Service
(lRARMWM1).
ASCBEJST
OUXB
-<
~
a
OUXBPSS
IN
OUXBIOS
ASCBIOSM
-<
t:I:l
t-J
OUXBMSS
~
OUXB
~t-J
(-OUXBPRS
Q
IN
00
o
......
OUCBCPU
OUCBIOC
OUCBMSO
OUCBWMS
Performance
Group Description
WPGD
WPGLDUR
WPGPAPGV
WPGPDMN
OUCB
OUCB
OUCBWMS
OUCBTMP
OUCBDMN
OUCBAPG
.....
_
".} 2
Check for Performance Group
Period change (lRARMWM5).
'")
"
OUCBPGP
OUCBDMN
OUCBDMO
OUCBNDP
OUCBTMP
OUXB
OUXBPRS
Performance
Group Description
WPGD
U
OUCB
OUCBWMS
OUCBTMW
OUCB
:
: >3
Determine the workload level at
which this user is receiving service
(lRARMWM7).
Performance
Objective
Return to User
Evaluation (lRARMCVL)
'"")
OUCBWMR
OUCBTMA
<=>
IN
00
~
'IIE'-.3I"'"
Diagram 6-20. Individual User Evaluation (IRARMWM3)
(part 2 of 2)
Module
Label
1
WM1 is invoked to calculate the service
accumulated during the "in real storage interval"
for users currently in storage.
IRARMWLM
IRARMWM1
2
IRARMWLM
IRARMWM5
Extended Description
The IRARMWM3 routine is invoked by the user evaluation
routine (lRARMCVL) during analysis of users in a
particular domain. The major output of the routine is
the workload level (recommendation value) of the user
being evaluated. Non-swappable and privileged users
are not evaluated.
Depending on the units code in the IPS (service
units or time units), the transaction's
accumulated service or time units is checked to
determine whether a period has ended. If a period has
ended, the current period indication is updated. If
workload reporting is also active, IRARMWR4 is
invoked to communicate the period change. If in
switching periods, the user also changes domains, he
will be repositioned at the end of the appropriate
queue. The user dispatching priority is also updated,
if applicable.
3
r/}
(11
(")
g'
~
i:
~
8-Q
....
o
"C
S
go
::I
~
~
~
-
The workload level is a means of comparing
users to other users in the same domain. If a
user has not yet received enough service to be
controlled by the workload manager (that is, his
service is less than his interval service value-ISV)
or if the user is between job steps, a workload level
corresponding to a zero service rate is returned.
In calculating his recent service rate, a user's
accumulated service is reset to zero when he is
swapped-in; his accumulated time is reset to zero
when he is swapped-out.
~
N
(:,
~
00
S
IRARMWAR
IRARMWR4
IRARMCTL
IRARMPRS
IRARMWLM
IRARMWM7
....~
I Diagram 6-21. User Ready Processing (IRARMHIT)
(part 1 of 2)
~
N
o
~
~
..
From Control Routing Routine
(lRARMCRT, IRARMC~Nt or IRARMCRY)
Input
~
~
Ib
«19.
n
t'""
J
~
c
a
WPGD
Performance
Group
Descriptor
WPGLDUR
WPGPAPGV
WPGPDMN
OUXBPRS
OUXB
...
) 1
OUXB
I
Output
""
I
1
OUCB
OUCBWMS
OUCBTMP
OUCBDMN
OUCBAPG
Process
v
I
I
OUCB
"-
Check for Performance Group
Period change (I RARMWMS).
OUXBPRS
v
OUCBPGP
OUCBDMN
OUCBDMO
OUCBNDP
OUCBTMP
1
~
N
<:>
~
00
o
-.J
(D
~
'<
rI)
~
<:>
~
00
§
OUCB
OUCB
...
OUCBPVL
OUCBENQ
OUCBINC
OUCBATR
OUCBTRM
OUCBCIM
OUCBINC
.? . 2
OUCBOFF
OUCBSTR
OUCBNTR
OUCBPGP
OUCBDMN
OUCBDMO
OUCBTMP
OUCBTMS
OUCBTMW
OUCBWMR
OUCBTMA
....
)
Reset Transaction Indicators.
--y
"
!;
RMCT
RMCffl?
...
v'>
"Wait"
Queue
Header
)
~ OUCB
Ready User
on
3
Make user eligible for swap-in.
..
RMCT
I RMCTOUTQ
-y
Header
4
~ OUCB'on
Ready User
Request SRM Analysis to
Expedite Swap-In (IRARMCAP).
"OUT" Queue
"Wait" Queue
l
"OUT"
Queue
Return to Control Routine
(lRARMCRT,IRARMCRN,
or IRARMCRY)
ta;i
W
'TIi£tUi,_k1[0;W!fitJIIttili.
~
D
...
""'----:-"
~
,~
Diagram 6-21. User Ready Processing (IRARMHIT) (part 2 of 2)
Extended Description
Module
Label
IRARMWLM
IRARMWM5
IRARMWAR
IRARMWR4
IRARMHIT is requested by IRARMEVT when it receives
a user ready SYSEVENT(4) from the dispatcher. The
major function of this routine is to make users eligible
for swap-in by repositioning them from the WAIT,
queue to the OUT queue.
1
Depending on the units code in the IPS (service
units or time units), the transaction's accumulated
service or time units are checked to determine whether
a period has ended. If a period has ended, the current
period indication is updated. If workload reporting is
also active, IRARMWR4 is invoked to communicate
the period change. If in SWitching periods, the user
also changes domains, he will be repositioned at the
end of the appropriate queue. The user dispatching
priority is also updated, if applicable.
o
~
IRARMCTL
IRARMRPS
IRARMWLM
IRARMWM4
2
The transaction indicators are reset based on the
type of user and the user's transaction status
when swapped-out. That is:
a) OUCBs for users between job steps remain
effectively unchanged.
b) OUCBs for Terminal wait users are updated to
reflect transaction. Indicators are set to the first
period characteristics.
A workload level is assigned which is equal to the
first period objective "zero point".
cl OUCBs for users which have suspended transactions
~
(may be due to issuing "long wait") are updated so
that they look as if the swap-out had just ended.
a'0'
=
~
3
The "ready" user OUCB is repositioned from the
WAIT queue to the end of the OUT queue.
IRARMCTL
IRARMRPS
4
The SRM analysis function is requested in order
to have the user swapped in as soon as possible.
IRARMCTL
IRARMCAP
a=
~
So
8-
....o
o
"d
i.=
~
.!..
~
W
<:
c;f.J
N
00
o
-...J
VS2.03.807
lRARMWLM Module Entry Point
Summary
IRARMWM 1 -
Workload Manager Service
Calculator Routine.
The IRARMWM 1 routine calculates the
amount of service provided to an user
since the beginning of the current
workload manager reasurement
interval for that user. Service is
calculated using the following
equation:
Service = (MP)/K)+(CT)/K)+EI WHERE:
T = The job step time elapsed in the current
interval.
K = The time required to execute 10,000
instructions. (Dependent on the CPU Model)
M = The MSO service coefficient scaled by 1/50.
P = The number of Page-Seconds used by the
user.
C = The CPU service coefficient.
E = The EXCP count for this interval.
= The I/O service coefficient.
This routine calculates each of the three service
factors and the total service for the user for the
interval.
IRARMWM2 - Swappable User Evaluation Routine.
The IRARMWM2 routine scans the
in-storage queue and the
out-of-storage-but-ready queue, and
evaluates each swapp able user
assigning each his current workload
level.
IRARMWM3 - Individual User Evaluation Routine.
The IRARMWM3 routine evaluates
swappable users on the IN and OUT
queue, assigning each a current
workload level.
IRARMWM4 - Workload Manager Workload Level
Calculator Subroutine.
The IRARMWM4 routine accepts a
service rate and a performance
objective, and calculates the
corresponding workload level.
IRARMWM5 - Workload Manager Update
Performance Group Period
Subroutine.
The IRARMWM5 subroutine tests
whether an user has accumulated
enough service/time to be assigned to
a new performance group period. If
so, IRARMWM5 adjusts the pointers
which indicate the performance group
period, performance objective and
3-1l.4 OS/VS2 System Logic Library Volume 3 (VS2.03.807)
domain applicable to the transaction
current for the user. Note that the
frequency (resolution) at which the
test for period end is made depends
on how often IRARMWM5 is called for
any given user.
IRARMWM7 - WLM Recommendation Calculation
Routine.
The IRARMWM7 routine calculates a
workload manager recommendation
value for a user based on the service
which was received and on the
performance objective currently
associated with the user. Users which
have not yet received an amount of
service equal to their interval service
value (Isv) specification while in core
are given a recommendation value
boost. The boost gives preferential
treatment to users in their ISV as
compared to users not in their ISV
and users between job steps.
IRARMHIT - Workload manager User Ready SYSEVENT
Swap-In Scheduling Routine.
The IRARMHIT routine receives
control as the result of a decision to
apply swapin processing to a now
ready user. It repositions the now
ready user from the WAIT queue to
the OUT queue.
IRARMWMI - Workload Manager In Storage
Interval Change Subroutine.
The IRARMWMI subroutine updates
the transaction accumulators with the
service and the time received by the
user during the preceding in-storage
interval.
IRARMWMJ - Routine To Determine The Scope of
Applicability of Analysis Processing
to a User.
The IRARMWMJ routine examines the
current swap status and the
performance specification for a user.
It indicates if the resource manager
algorithms are applicable to this user.
IRARMWMK - WLM Dontswap/Okswap User
Analysis Routine.
The IRARMWMK routine calculates
the current service and ensures that
the user is in the correct performance
group period. Applicable algorithm
indicators are set based on the new
swap status of the user.
VS2.03.807
Workload Manager Transaction Start
Routine.
The IRARMWMN routine receives
control as the result of a SYSEVENT
that has been defined by the
workload manager to signify that a
new transaction should be started for
that user. If the user is not in storage,
a flag is set to cause the IRARMWMN
routine to be reentered during the
swap-in of the user. Otherwise, any
existing transaction is stopped by
calling IRARMWMO, and the user
transaction fields are reset to reflect
the new transaction being started.
- Workload Manager Transaction Stop
Routine.
The IRARMWMO routine receives
control as the result of a SYSEVENT
that has been specified by the
workload manager as defining the end
of any current user transaction. If a
new transaction is to be created for
the user, IRARMWMO indicates the
end of the current transaction. If the
next user event is not known,
IRARMWMO leaves the transaction
accumulated values for later
resumption of the transaction. In any
case, IRARMWMO causes the
IRARMWMO -
IRARMWMO
IRARMWMQ
IRARMWMR
preceding time and service to be
properly recorded for the current
transaction.
- Workload Manager Quiesce
Completed SYSEVENT Processing
Routine.
The IRARMWMQ routine receives
control when a user has stopped
executing, and is being swapped out,
so that the workload manager may
record the service given that user
while he was in storage. The
workload manager determines if a
user event caused the swap-out, and
flags the user to indicate whether
such previous service is to be
considered when the user is next
swapped-in.
- Workload Manager Restore
Completed SYSEVENT Processing
Routine.
The IRARMWMR routine receives
control when a user has been
swapped in, and is ready to begin
executing, so that the workload
manager can set up the fields used to
calculate the service rate received by
the user during the forthcoming
in-storage residency period.
Section 2: Method of Operation 3-73.5
~
......
I Diagram 6-22. Initialize for MF /1 (IRARMWRI)
(Part 1 of 2)
~
~
oCI.l
"<
CI.l
From SYSEVENT Processor
(lRARMEVT) (SYSEVENT 45)
Input
Output
Process
N
CI.l
'<
~
Register 6
Initialize The WAMT
(lRARMWR1)
.3
r-
Register 6
Ǥ.
(')
r-
a:
~
<::
a
WAMT
WAMT
..) 1
..
=
Update header.
J..
<::
Header
"
CI.l
~
o
3(D
~
00
~
o
......
'<
CI.l
N
o
WMST
~
00
o
~
Workload
Manager
Specification
Table
JI.
"
2
Build index structure and
initialize buffer
(call IRARMWR2).
Index
Table
~;:
r..
:;:
..
WAMPDMN
")
WAMPOBJ
"
WAMPSRV
-.,
Performante
Group Period
Entries
(WAMPs)
WAMPDMN
3
Update period service values
(call IRARMWM1).
J-.
"
WAMPOBJ
WAMPSRV
t
•
•
•
Register 15
....)I
.. I
Return Code
r.
'- ->
':~
Diagram 6-22. Initialize for MF/I (IRARMWRI) (Part 2 of 2)
Extended Description
Module
Label
IRARMWR1 constructs and initializes the workload
activity measurement table (WAMT) in the buffer
(Storage from SQA) obtained by MF/1 anq input
with Sysevent 45.
IRARMWAR
IRARMWR1
IRARMWAR
IRARMWR2
1
2
The index is used to locate the period entries in
WAMT which correspond to a particular
performance group. The period entries are updated
with their respective domain and performance
objective numbers. All other period entry values are
zeroed.
3
Service values in the period entries are initialized
such that service already received by active user
transactions will not be included in the MF/1 interval
service totals.
R~turn
Codes in Register 15 byte 3
X'OO' - Data area accepted and initialized.
X'08' - Length of data area incorrect.
'"
~
(')
S·
=
s:
N
~
~
8o
~
o
"0
...
~
~
o·
=
I.IJ
~
I.IJ
~
<:
'"o
N
I.IJ
00
o
-...J
tN
..!..a
Diagram 6-23. Collect Data for MF/l (IRARMWR3)
(part 1 of 2)
tN
00
"<
C"Il
~
'<
go,
C"Il
Register 6
S-
l
a
ro
..
Froin SYSEVENT Processor IRARMEVT
~
~.
,
I
o
p
I
")
1
...
Register 6
l
<
o
2'
tN
'1
Copy WAMT to provide area.
J
(D
Buffer Are.
\.WAMT
r-
a
Cl--
RRPAINP
Collect Data Recorded In
WAMT (lRARMWR3)
RRPAINP
I
~.
J
WAMT
~
'"f.;
~
Buffer
Area
<=>
tN
00
I
\
~
II.J
Header
...
) 2
..
...
) 3
I'
Reinitialize the WAMT
(call IRARMWR2L
Index
Table
...
WAMPSRV
...
WAMPSRV
S
:~
)
") ;~
v
Update period service values
(call IRARMWM1).
••
•
WAMPSRV
l
RRPf-IND
J
~
>-
Performance
Group
Period
Entries
(WAMPs)
,...
Buffer Area
~
v
A
v
4
Calculate the workload level
for each period
(call I RARMWR5)_
...
SRV+ WLL
v
SRV+WLL
)
-c
[SRV+WLL
Register 15
")I Return Code
II'
J
f
J
> Period
Entries
_7
~7
Diagram 6-23. Collect Data for ~F/1 (IRARMWR3) (Part 2 of 2)
Extended Description
Module
Label
IRARMWR3 copies the contents of the WAMT into a
collection buffer. The buffer is obtained by MF/1
from LSQA and is fixed in core.
IRARMWAR
IRARMWR3
IRARMWAR
IRARMWR2
1
The WAMT is copied into the buffer.
2
If a set to new IPS occurred, workload collection
was terminated and the WAMT was updated
to reflect the statistics at that point in time. I f the
IPS has not been changed, the WAMT is updated for
a new collection interval.
<:
tI.)
~
3
Both the WAMT and the collection buffer are
updated to reflect the actual service (SRV)
received within each resp. interval.
4
The Workload Levels (WLL) are updated in the
collection buffer for MF/1.
Return codes in Register 15 byte 3
X'OO' - Successful Data collection
X'04' - Successful Data collection, but an IPS
change occurred terminating workload
collection
X'40' - Data collection not active, or data buffer
non-existent or copy buffer incorrect size.
tI.)
(D
n
g
~
~
(D
[
o
o"'"
.~
i
~
.....
c..J
\0
IRARMWLM
IRARMWM1
o
c..J
00
o
.....
VS2.03.807
IRARMWAR Module Entry Point
Summary
Workload Activity Recording
Initialization Subroutine.
Constructs and initializes the
Workload Activity Measurement
Table (w AMT) in the buffer (storage
from SQA obtained by MF/l and
input with SYSEVENT 45).
IRARMWR2 - Workload Activity Recording WAMT
Initialization Subroutine.
Builds the W AMT in a format suitable
for updating by the SRM.
IRARMWR3 - SRM Workload Activity Recording
Data Collection Subroutine.
Moves the contents of the W AMT
into a collection buffer capable of
containing the data. Note: The buffer"
is obtained by MF/l from LSQA,
storage key 0, and must be fixed in
storage.
If the IPS has not been changed, then
add to the collected data the
transaction data for the current
in-storage interval for each in-storage
memory with an active transaction
re-initialize the data collection buffer
for the next collection interval, and
calculate the workload level for each
performance group period that
contains transaction data.
IRARMWR4 - SRM Workload Activity Recording
Transaction Data Update Subroutine.
Adds the service and transaction
active time to the appropriate W AMT
performance group period
accumulator in the data collection
buffer.
IRARMWR 1 -
3-73.10 OS/VS2 System Logic Library Volume 3 (VS2.03.807)
Workload Activity Recording
Workload Level Calculation
Subroutine.
Calculates the workload level for
each W AMT performance group
period entry in which transaction data
has been accumulated during the last
data collection interval.
Note: For those W AMT entries in
which the service rate calculated can
be associated with multiple workload
levels or is zero even though at least
one transaction has been active
during the data collection interval, the
negative value of the workload level
will be calculated to indicate to MF / I
an estimated value.
IRARMWR6 - SRM Workload Activity Recording
Transaction End Update Subroutine.
Adds to the appropriate W AMT
performance group period
accumulator the transaction elapsed
time and counts the number of
transactions that terminated during
the current data collection interval.
IRARMWR7 - SRM Workload Activity Recording
W AMT Entry Determination
Subroutine.
Obtains addressability to the W AMT
performance group period entry in
which to accumulate user transaction
information.
IRARMWR8 - SRM Workload Activity Recording.
Terminates workload activity data
collection whenever an IPS change
occurs.
IRARMWR5 - SRM
~\
I
"
Section 2: Method of Operation
3-73.11
3-74
OS/VS2 System Logic Library Volume 3 (VS2.03.807)
System Activities Measurement Facility (MF /1)
t,
I
System Activities Measurement Facility (MF /1)
collects information about system activity in order
to produce System Management Facilities (SMF)
data records or printed reports or both. MF /1 can
monitor the following five classes of system
activity:
1. CPU
2. Paging
3. Workload
4. Channel
5. Input/Output Device
il.
1
MF /1 information collection can be initiated by
the issuing of a START command and can be
terminated either by the expiration of a specified
collection period or by an operator STOP command.
MF /1 is always generated with the system, but its
execution is completely optional. When it is not
operating, it causes little or no performance or
storage overhead. When it is executing, storage and
performance overhead depends on the set of
control options under which it is running.
Options are available to specify the reporting of
any of the five classes of system activity. In
addition, the time interval for gathering and
reporting measurements is an option. Channel and
device data are sampled more frequently than once
per measurement gathering interval, and the
frequency of this sampling rate is an input option.
Printed reports and/or SMF records can be
obtained once per gathering interval or at the end
of the period of MF /1 operation.
MF/l has three major components:
1. Measurement Facility Control (MFC), which
controls the collection, recording, and
reporting of system activity measurements, in
compliance with specified options.
2. System Activity Measurement Gathering
(SAMG), which obtains measurements of
system activity, by collecting data at timer
interruptions and. remote-pending IPC
(interprocessor communication) interruptions,
and which records measurements on the SMF
data set.
3. System Activity Report Generation (SARG),
which produces formatted, printed reports
from system activity measurements.
Figure 3-11 in the Program Organization section
illustrates the flow of control among the major
components and main modules of MF /1.
The operator's START command causes MFC
Mainline, the system task controlling MF /1
execution, to receive control. MFC Mainline
establishes the operating parameters for MF /1
execution from specified options and loads the MG
(measurement gathering) routines required by these
parameters; it then enables the routing of control
to these routines.
MFC Mainline passes control to interval-driven
MG routines to gather measurements at a
parameter-specified time interval. These routines
move collected data into SMF-record-formatted
areas and optionally record the data on the SMF
data set.
System components outside MF /1 maintain data
that is obtained by SAMG at measurement
gathering intervals. These include:
1. System Measurement Facility (SMF), which
maintains CPU wait time.
2. Real Storage Management (RSM), which
maintains VIO paging statistics.
3. Auxiliary Storage Manager (ASM), which
maintains auxiliary page statistics.
4. System Resources Manager (SRM), which
maintains workload activity data.
5. Input/Output Supervisor (Ios), which
maintains I/O activity statistics.
•
The SARG function is given control at reporting
intervals to produce summary reports of the
measurements obtained by SAMG and routed to it
by MFC. These reports are routed to a SYSOUT
data set, which is made available for printing at a
parameter-specified time (either immediately or
after MF /1 termination).
MFC allows the operator to use the STOP
command to terminate MF /1, overriding any
parameter-specified duration of execution.
Otherwise, MFC terminates measurement gathering,
recording, and reporting at the end of the specified
duration.
Operational Considerations
MF /1 operation is controlled by input parameters.
These parameters are obtained from four sources
during MF /1 initialization:
1. START command PARM field.
2. EXEC statement PARM field (MF /1 cataloged
procedure) .
3. Partitioned data set number (the partitioned
data set is specified in the cataloged
Section 2: Method of Operation
3-75
procedure - normally it will be
SYS1.PARMLIB); the member name is of the
form IRBMF1nn, where nn is an input
parameter.
4. Program default values.
The parameters can be grouped into three
classes:
1. Parameters affecting the initial parameter
merge.
2. Parameters causing the loading of MG
(measurement gathering) routines.
3. Parameters affecting the mechanics of MF/1
operation.
Class 1 consists of the following merge control
keywords:
MEMBER (nn) - the value to be appended to
IRBMFl to name the member of the partitioned
data set from which parameters are to be obtained
during the input merge. (The default is 00,
indicating member IRBMF100.
OPTIONS/NOOPTIONS - specifies whether or not
the results of the input merge will be printed on
the operator's console, to permit changes to be
made. The default value is OPTIONS.
Class 2 consists of the following measurement
gathering keywords. (Program default values are
underlined. )
CPU/NOCPU
PAGING/NOPAGING
CHAN/NOCHAN
WKLD(PERIOD/GROUP/SYSTEM)/NOWKLD
DEVICE (devicereportlist)/NODEVICE
where the device report list may consist of the
following elements:
UNITR/NOUNITR
TAPE/NOTAPE
DASD/NODASD
COMM/NOCOMM
GRAPH/NOGRAPH
CHRDR/NOCHRDR
Specification of the first of any of the above sets
of two measurement gathering keywords (CPu,
PAGING, and so on.) causes the loading, during
MF /1 initialization, of the interval MG routine
associated with the keyword, so that reports
and/ or record copies are produced for that
measurement type. If the second of any of the
above sets of two is chosen (NOCPU, NOPAGING,
and so on.), then no MG routines are loaded for
this measurement type, and little or no
performance or storage overhead is caused by these
routines.
3-76
OS!VS2 System Logic Library Volume 3 (VS2 Release 3.7)
Class 3 consists of the remaining MF /1
keywords: (Program default values are underlined.)
REPORT (REALTIME/DEFER) /NOREPORT specifies whether formatted reports are to be
written to SYSOUT, and, if they are, whether they
are to be printed when available, or at MF /1
termination.
SYSOUT (class) - specifies the SYSOUT class for
all printed reports. The default is class A.
RECORD/NORECORD - specifies whether or not
data records are to be written to the SMF data set
at specified intervals.
INTERVAL (value/valueM) - specifies the length
of time in minutes between gathering measurements
and (optionally) preparing records and printing
reports.
CYCLE (value) - specifies the frequency in
milliseconds with which channel and device
statistics are to be obtained within the specified
interval.
STOP (value/valueM/valueH)/NOSTOP specifies a length of time after which MF /1 will
automatically terminate or, alternatively, that MF /1
can only be terminated by an operator's STOP
command. The default value is 15M.
Measurement Facility Control (MFC)
MFC is the system task controlling MF /1 operation.
It performs the input merge to establish the
parameters controlling MF /1, initializes for MF /1
data collection by loading the appropriate MG
routines, issues SVC MF DATA A at reporting
intervals to initiate data collection for active report
printing, and controls MF /1 termination.
See the following method-of-operation diagrams:
Measurement Facility Control (MFC) Mainline
(IRBMFMFC)
MFSTART Mainline (IGXOOO13»)
Input Merge Control (IRBMFINP)
Syntax Analyzer (IRBMFANL)
List Option Module (MFLISTOP)
Initialization Mainline (MFIMAINL)
CPU Activity Initialization (IRBMFICP) or Paging
Activity Initialization (IRBMFIPG)
Workload Initialization (IRBMFIWK)
Channel Initialization (IRBMFIHA)
Device Initialization (IRBMFIDV)
Data Control (IRBMFDTA)
Termination Processor (IRBMFTMA)
MF/l Message Processor (IRBMFMPR)
System Activity Measurement
Gathering (SAMG)
SAMG consists of a set of measurement gathering
(MG) routines whose function is to collect data
from the various system components for eventual
reporting through SARG, and to copy the
information to the SMF data set if so required by
the RECORD/NORECORD option. There are two
classes of MG routines-interval MG routines and
cycle MG routines. There is one interval MG
routine associated with each active reporting class;
it is activated at reporting intervals (as determined
by the INTER v AL keyword to collect interval
measurements and, optionally, copy the SMF
record. Cycle MG routines are associated with the
device and channel reporting classes. If active, they
are entered at periods determined by the CYCLE
keyword to sample queue lengths and maintain
other intermediate device and channel-related data
that the related interval MG routines collect at
reporting intervals.
See the following method-of-operation diagrams:
MFDATA SVC Mainline (IGXOOO14)
Interval
Interval
Interval
Interval
Interval
MG Routine for CPU (IRBMFDCP)
MG Routine for Paging (IRBMFDPP)
Routine for Workload (IRBMFDWP)
MG Routine for Channels (IRBMFDHP)
MG Routine for Devices (IRBMFDDP)
MFROUTER SVC Processor (IRBMFEVT)
Channel Sampling Module (IRBMFECH)
Second CPU Test Channel Sampling Module
(IRBMFTCH)
Device Sampling Module (IRBMFEDV)
System Activity Report Generating
(SARG)
SARG produces all the formatted reports about the
activities being monitored. These reports are made
available for printing at a time specified in the
REPORT parameter.
See the following method-of-operation diagrams:
Report Generator Control (IRBMFRGM)
Report Generators for CPU, Paging, Workload,
Channels, and Devices (IRBMFRCR, IRBMFRPR,
IRBMFR WR, IRBMFRHR, and IRBMFRDR)
Section 2: Method of Operation
3-77
3·78
OS/VS2 System Logic Library Volume 3 (VS2 Release 3.7)
'~-?
System Activity
Measurement Facility
(MF/1) (no diagram)
---±
r
l
I
I
I
I
I
I
CI'.l
(D
~
o·
=
~
a::
(D
So
8o
~
o
1~
I
=
L
o·
w
~
-
MFe jSAMG-
7-1
I
7-4
I
Initialization
Mainline
(MFIMAINL)
CPU (lRBMFICP)
or Paging
(lRBMFIPG)
Initialization
Figure
I
I
1 7-12
7-11
Data Control
(lRBMFDTA)
Termination
Processor
(lRBMFTMA)
I
I
I
I
I
L
J
Second CPU Test
Channel Sampling
Module
(lRBMFTCH)
Channel
Sampling Module
(lRBMFECH)
I
L __
7-8
Workload
Initialization
(lRBMFIWK)
7-9
Channel
Initialization
(lRBMFIHA)
I
J
7-10
Devicc
Initialization
(lRBMFIDV)
>System Activity Measurement Facility (MF/I) Visual Contents
I
7-20
MFROUTER SVC
Processor
(lRBMFEVT)
7-22
7-21
7-25
Report Generators
(lRBMFRCR
IRBMFRPR
IRBMFRWR
IRBMFRHR
IRBMFRDR)
I
I
I
I
I
I
I
7-23
Device Sampling
Module
(lRBMFEDV)
7-15
Interval MG
Routine for CPU
(lRBMFDCP)
~
L _____
J
1
I
7-16
Interval MG
Routine for
Paging
(lRBMFDPP)
1
I
J
I
I
J
I
2~lO.
7-24
I
7-14
MFDATASVC
Mainline Processor
(lGXOO014)
I
I
7-7
I
I
I
7-13
Message
Processor
(lRBMFMPR)
List Options
Subroutine
(MFLISTOP)
I
-
Report Generator
Control
(lRBMFRGM)
r-.J
I
7-6
I
1
7-5
MFSTART
Mainline
(lGXOO013)
I
I
I
I
I
7-3
Syntax
Analyzer
(lRBMFANL)
~A~
Measurement
Gathering (SAMG)
(no diagram)
I
I
7-2
Input Merge
Control
(lRBMFINP)
I
-
I
I
I
t- -
-
I
Measurement Facility
Control (MFC)
Mainline
(lRBMFMFC)
I
I
I
I
I
1
7-17
---
-
~
I
I
I
-J
I
J
I
L
7-19
Interval MG
Routine for
Devices
(lRBMFDDP)
__
........
I
I
7-18
Interval MG
Routine for
Channels
(lRBMFDHP)
Interval MG
Routine for
Workload
(lRBMFDWP)
I
I
I
I
J
:.J
w
~
o
se
;;3
Diagram 7-1. Measurement Facility Control (MFC) Mainline (IRBMFMFC) (part 1 of 2)
From Dispatcher
After Recognition
of START Command
Input
N
:
til
'<
~
a
i
MFENQAPL
II
!
n
t::
..
Output
Process
Measurement Facility Control (MFC)
Mainline (lRBMFMFC)
Return to caller
if MF/1 already
running
-11.
-l) 1 Ensure that only one MFC task runs at
v
anyone time by checking that another
MFC task is not already running.
y
~
~
~
=
a
MFEXECPA
EXEC Parameters
2
I
L
(1)
MFPCT
Enable the MFC task to be stopped
by an operator-entered stop
command.
c--
w
!
~N
;
::c
t
~
w
~
IRBMF1xx Member
of PAR¥LlB
Jo.
v
3
Command
Input Block (CIB)
Combine input options fr~m all ~ources
and prepare conSOlidated list of mput
options. (See MO diagram Input
Merge Control (lRBMFINP).)
~
Y'L
r
.....
,
~
Permanent Common
Option Area
I
Input Merge Control
"... """
4
.
.....
,
Allocate storage for message Sysout
data set and open the Sysout
data set.
~
IRBMFALL
Dynamic Allocation
".
;:
l
1'-.
iF v
L
J
,
g ./"'#.
, '::
.•
~r·::.'.,,;" .',
.<
5
6
Initialize to begin measurement
gathering (MG) and to begin report
generation, both according to
consolidated input options.
~
f:
.....
,
~
IGXOOO13
MFST ART Mainline
.....
Wait for completion of reports.
Then close out each report subtask
as it completes.
.,•. :O,.:./:C.i,. .,........ , ....·;·;:.·r·:·«·:S·.·.·.>;:;.;;:;::.:> . L
Diagram 7-1. Measurement Facility Control (MFC) Mainline (IRBMFMFC) (part 2 of 2)
Extended Description
Module
The Measurement Facility Control (MFC) Mainline module
(lRBMFMFC) is the first MF/1 module to receive control as
a result of the operator starting MF/1. Its main functions are
to initialize MF/1 option control blocks, to issue an SVC to
cause monitoring of system variables by MF/1, and to assist
in terminating MF/1.
IRBMFMFC
1
IRBMFMFC
The return from an enqueue on a global name indicates
whether another MFC Mainline task is dispatched, even
if it has been dispatched in another virtual area. If so, this
MFC Mainline task issues an operator message and then
terminates.
MFC Mainline obtains an ECB address so Data Control
(lRBMFDTA) can later accept a stop command from
the operator.
MFC Mainline loads and calls Input Merge (lRBMFINP)
to merge input options, analyze the syntax of these
options, and indicates the option values specified in the
PMAand COA.
til
(D
~
5·
=
~
a:
....
6'
(D
~
e.
o
~
Q
a5·
=
w
00
Extended Description
IRBMFINP
Module
4
MFC Mainline calls the Dynamic Allocation module
(lRBMFALL) to allocate storage for the Sysout data
set and then opens the data set.
IHBMFALL
5
Issue SVC MFST ART to initialize the monitoring,
reporting and recording of system measurements by
MF/1. Control will not return to this point until MF/1 is
ready to terminate (when the specified duration is reached,
or MF 11 is stopped by the operator).
IGX00013
6
Detach each SARG subtask, and free all associated control blocks.
IRBMFTMA
Issue CLOSE to close the message SYSOUT data set,
and issue DEQ to indicate that MF/1 is not active. Call
the message processor (I R BM FMPR) to indicate termination
to the system operator.
IRBMFMFC
7
2
3
Label
Label
~
Diagram 7-2. Input Merge Control (IRBMFINP) (put 1 of 2)
~
Input
~
w
..9
..
From MFC Mainline
(lRBMFMFC) via CALL
,j
!t
i
t:
r
START parameters
;
I
~
r
EXEC parameters
....
i
~
~
....
}
v
:\
"i
;;:
;j2
ie,,:
...
I:
y
"
MFCOA
Permanent
Common
Option
Area
:'
"
,
;
d. Default options.
MFMVT
~;
~ ?
".
I
-:'
,
s"
<,
I
~~
,.;"
~
Common
Option Area
,:,
:,"
F=;>
i
w
MFCOA
y
c. Specified or default data set.
Member of
SYSt.PARMLIB
Measurement
Vector Table
~\
Permanent
Measurement
Vector
Table
;"
b. Parametersin
the EXEC statement.
v
IRBMF1XX
....
)
MFEXECPA
I
,,:
PMA
,
w
~w
Process input options in the following
order:
1"
MFMVT
"
a. Parameters in the START command.
...
~
''},
Input Merge Control (lRBMFINP)
..>
I
Output
ili
1
Command
Input Block (CIB)
n
Process
_
f';
..
...
IRBMFANL
',;
Syntax Analyzer
.'
"
:Zf,
,;,
....
y
2
:,:
Perform validity checks of all
merged input options.
""...
r;'
SYSOUT
Data
Set,
;
,
\',
:
'f
;;
>;
:':'
::
'"
3
List the options in effect in a
SYSOUT data set and, if the
operator so requested, list them
on the master-console.
:':
:'
)I
II
Return to MFC Mainline
(lRBMFMFC)
~~
...
B
Operator's Console
;::~
j
Diagram 7-2. Input Merge Control (IRBMFINP) (part 2 of 2)
Extended Description
Module
The Input Merge Control module (lRBMFINP) receives con·
trol from MFC Mainline (lRBMFMFC) early in the execu·
tion of IRBMFMFC. IRBMFINP controls the preparation of
tables that represent consolidated input parameters and con·
trois the printing of this set of input parameters if required
either by an input request or because of invalid or conflict·
ing inputs. Inputs to IRBMFINP are from Start command
parameters, EXEC statement parameters, input-specified
data set parameters, or from default options. IRBMFINP
controls the interpretation of inputs, the merging of these
inputs into a set of control blocks that indicate the reo
quested options, and the communication with the console
operator to obtain approval or correction of the list of
options prepared in response to inputs. The four input
sources have the following priority, from highest to lowest:
START command, EXEC statement, member data set, and
default.
IRBMFINP
Label
Extended Description
Module
1
The processing of input options from each input source
is essentially similar: for each source, the input data is
separated into recognized fields and initialized in temporary
control blocks, and then these fields are merged into perma·
nent control blocks that represent input options combined
from all sources of input. Routines check for invalid values
in input data, for mutually exclusive options, and for syntax
errors. Such errors are reported to the operator, who may
request new options or instruct the program to ignore the
inputs (if ignore is requested, lower priority inputs or
defaults are used).
IRBMFINP
2
IRBMFINP
MFVALCHK
IRBMFINP
MFLISTOP
Routine MFVALCHK performs the following validity
checks between different option types:
Label
MFMERGE
MFSRCPRO
IRBMFMPR
a) The report option must not be set to DEFER if NOSTOP
is requested.
b) Options NOREPORT and NORECORD must not both be
set.
c) The STOP value must be such that the time in operation
is not less than the INTERVAL value.
3
The set of options is written to a SYSOUT data set and
if so requested is printed on the console. Subroutine
MFLISTOP writes to SYSOUT, and to the console if
required. (See List Option Subroutine (MFLISTOP)
diagram.)
if
()
g.
1:1
~
ar::
«t
l...
o
o
'Ia
!'
1:1
~
~
t
Diagram 7·3. Syntax Analyzer (IRBMF ANL) (put 1 of 2)
o
From Input Merge Control
(lRBMFINP) via CALL
fIj
~
N
Input
Process
¥
fIj
1
I
t
i-
t
t""
SZ
!
,
~
e-
El
(D
w
'<
fIj
N
~
t
I
w
Output
'~A
me
~
Scan Control
Block (SCB)
t
\/
,
Item Entry
~
SCB
Recursive
Work Area
~
Current
BCB
, Current
Text
No. of Bytes
Left in Buffer
,
.v
~
~
1
Length of
Buffer
t
Obtain next recursive work
area element from pushdown
stack.
Input Character String
I MFSNTAB
-~
I
">2
'if
r
~1
If the input item is from a
terminal, call the appropriate
terminal recognizer. If not,
proceed to step 3.
~'///////////
SYITEMnn
•
~
Structure
L
L
4 Recursive Alternatives
",//,,.,///
Item List
_
4 Initialization Routine
C__ / / / / / / / / / / / /
0
....
..
"
;'
..r ) 3
)
If the input is a structure,
recursively call1RBMFANL
again to examine each
alternative of the structure.
...
..
....
i
~
;;
1st Item Entry
~
{
Last Item
Entry
5
}:
~.
Recognizer Routine
s
Parameter List
i:
For identified alternatives,
call an initialization routine,
if one exists, to make
appropriate entries in tables
of input options.
10.
..
....
%
If structure is recursive,
indicate use of alternatives
of recursive structure and
return to step 2.
IRBMFINP
MFOPINIT
"
'f
fJi;'
;
~,;
::
I
INMVT
~
C:~ l
I
PMA
;~;{
~;
~
I
".'
>.
;
6
"
IRBMFANL
," i;', i,,' "i":':," ,L '.C., ::x ;':+>:. ",•./. ;iit<<;
",I~
Operator's
"
I..:"
V"I
:~.:
<;
.<
);'
INREPBUF
Operator's Reply
I
.<
..
<.
;.,
~.~
::
.......•
(D
C.H
1
~
i":
~
I
i
L~
:.'
~
Output
List Option Subroutine (MFLISTOP)
..
MFCOOPI
-
Process
~;"
I,;
""
".
'"
")
v
2
:.
~
If option list is not to be printed
for the operator, or if printed for
the operator and he replies GO,
allocate a data set, open it, and
list the options in the data set.
. "
...
~:)
Return to caller.
C.H
:...a
&"
:~.:
i
;:
)
...
.,
::'
:.:
\.....
";\
v
3
If the operator reply contained more
options, merge these options with the
previous input options and validity
check the merged set of options.
Return to step 1.
i:
t·;
(:
..•.
". ···.t
. ' < " . ".'
....
."
'.,
•..•• "'•. 'S.
·•• ·pv".• ·
2:
~~
Return to
Caller
(lRBMFINP) i:s
MFCOA
~i
-".
v
)I
Permanent Common
Option Area
MFMVT
(
.
',,'
IRBMFALL
"
:;
.
".
:>
,t
;;
."
Dynamic
Allocation
t:c
!:
Console
-"
~i
[''''
I;;
f'
ft;
~;.
v
MFPMAs
~
""-J'
Diagram 7-4. Ust Option Subroutine (MFLISTOP) (Part 2 of 2)
Extended Description
Module
Label
The List Option module (MFLISTOP) lists options, as requested by the input source or in response to errors in
specifying the MF/1 options.
IRBMFINP
MFLISTOP
1
If the OPTN option (list input options on the console)
is set on, either by direct operator request as an input
option or as a result of an error in input options, the list is
printed.
IRBMFINP MFLISTOP
IRBMFMPR
2
Routine IRBMFALL is used to allocate space for
listing the SYSOUT data set. If the opening of the data
set is successful, the final list of options in effect is written
to the data set.
IRBMFALL
3
IRBMFINP MFSRCPRO
IRBMFANL MFVALCHK
If the operator replied with more options in response
to REPLY WITH MORE OPTIONS OR GO, his reply
is scanned for errors and control blocks (permanent) are
initialized. This cycle of actions continues until he replies
GO to the message, then a final list of options is written to
the SYSOUT data set.
ff
g.
l:I
~
a:CII
Io....
f
o
l:I
w
~
'of
Diagram 7-5. MFSTART Mainline (IGXOOO13) (part 1 of 2)
00
00
~
~
From MFC Mainline
(lRBMFMFC) via SVC
..
Input
~
fIl
'<
f4.
a
b
Process
Output
MFSTART Mainline (lGXOOO13)
~.
1
Set up for recovery routine to
handle errors in M FST ART.
2
Set up for measurement gathering.
t"'"
e:
!
~
=
a
...II.
~
F
...
CALL
,
MFIMAINL
r
""-
Initialization
Mainline
,
(D
w
'<
fIl
~
f
""0'" '" .",
Input Parameters
I
L
addr: MFMVT
--1\.
I
J
y
)
3
w
~
r
L
addr: MFCOA
Set interval time for requested
interval and perform
measurement gathering when
there is an interval timer
interruption.
SYNCH
;:
....
.
-'".
Data Control
.,
4
Delete MG routines and resources
for both interval and cycle MG
activities.
CALL
....
.;'e,
"0,
.0:
",
"
y
•..We.iiL
IRBMFDTA
,
J
"
.'··,·.'\it
...
.
...
0.·
•• ; ; '
IRBMFTMA
Termination
Mainline
;'1
.
5
Cancel recovery setup of Step 1.
,,",,'"
Return to MFC Mainline
(lRBMFMFC)
;"
)U.hFTx!;1/.';C A; ".i
~
Diagram 7-5. MFSTART Mainline (IGXOOO13) (part 2 of 2)
Extended Description
Module
The MFSTART Mainline OGX00013) processor controls the
initialization and termination of routines that perform MF/1
functions.
IGX00013
1
IGX00013
IRBMFSDE
Issue an EST AE macro instruction to provide entry to
routine IRBMFSDE, which receives control in event of
MF /1 errors.
2
Call the Initialization routine (MFIMAINL), which, in
turn, calls other initialization routines (see the first
paragraph in the MFC Mainline (lRBMFMFC) M.O. diagram).
3
Use SYNCH macro instruction to change to problem
state and to transfer control to the Data Control routine OR BMFDT A), which sets the interval timer and initiates measurement gathering after each interval.
4
5
fI:l
(D
sa.
o·
::I
!'!
at
So
(D
8-
o
101)
o
"0
~
o·=-::I
w
do
\.Q
MFIMAINL
IRBMFDTA
.A: fter the
last interval, Data Control returns control to
MFSTART Majnline, which calls Termination Mainline
(lRBMFTMAI.
MFSTART Mainline cancels.the ESTAE routine entry.
Label
IRBMFTMA
't'
!
2
~
N
Diagram 7-6. Initialization Mainline (MFIMAINL)
(put 1 of 6)
..
From
MFSTART Mainline
(lGXOOO13) via CALL
Input
...
~
fIJ
i
l"'"
IMGSTSRG
i
j
I
~
[
Process
•
""-,
< •
Initialization Mainline
(MFIMAINL)
.,,>
L
L
Output
w;·
1
IMMMVSRG
1
'V
>
Control
Blocks
>
Control
Blocks
...
..
Obtain local pagable storage needed
by MF 11 control programs.
'V
I
3
w
%/i"
I-
STSCT
~
'"
"
Control
Blocks
J
2
-
>
~
I
~
N
-
Global Storage
MFROUTER
Vector
Table
(MMV)
"
Obtain global fixed storage needed
by MG routines that operate at
intervals.
Iw
f
:...
...
STGST .
~
STMVT
~
l
Initialize control blocks STGST
and STMMV and set up controls
for MG routines that run at cycles
(specified in input options).
STCOA
I
STSMA
I
STRVT
.'.
4
Initialize more tables.
..
,.
v
I
1
.·.C.'
MFCOA
I
..>
1
•
I
Input Option
CYCLE
'
.... "'.
-y
~N
<,
5
--
STSCT
~
f-
STMVT
I
STSMA
l
STRVT
I
STCOA
"?....... .
AC'.·0."",..•"...·· ...........
.
STGSCYC
Validate the minimum cycle time
and make it available for global
reference.
")I
;
.,. L
~
Cycle Time
..J
~--
Diagram 7-6. Initialization Mainline (MFIMAINL)
(I.)
(D
sa.
0·
::I
~
a:
(D
[
o
.....
o
"tI
I0·
::I
eN
~
(part 2 0(6)
Extended Description
Module
Label
The Initialization MainJine (MFIMAINL) procedure controls
the allocation of space for and the initialization of control
blocks. It also calls routines whose purposes are to initialize
different functions essential to measurement gathering
(MGL Finally, it issues the MFDATA SVC to collect initial
values of requested measurements.
IGXOOO13
MFIMAINL
·1
MFIMAINL uses the GETMAIN macro instruction to
obtain storage for the Global Storage Table (STGST)
and for the MFROUTER (control routine for sample collecting routines) Vector Table (STMMV).
IGX00013
MFIMAINL
2
MFIMAINL uses the GETMAIN macro instruction to
obtain storage for the Supervisor Control Table
(STSCT), Measurement Vector Table (STMVT), the Common Option Area (STCOA), Supervisor Measurement Area
(STSMA), and the Resource Vector Table (STRVT).
IGX00013
3
MFIMAINL places initial values into the control blocks
for which space was obtained in step 1.
IGX00013
4
MFIMAINL places initial values into the control blocks
for which space was obtained in step 2.
IGX00013
5
The time specified by the cycle input option must not
be less than 50 milliseconds.
IGX00013
:bN
i
~N
Diagram 7-6. Initialization Mainline (MFIMAINL)
Process
Input
1
i
j
~
_9
Output
MFPMA
~---~-~
/'1 MFPMAOPT
~
-.I
MFMVT
J
MFMVPAG
w
MFMVWRK
~N
MFMVCHl
~
MFMVDEV
......
MFPMAOPT
MFMVCPU
r--
MFPMA
FMFPMAOPT~
(I
i
(put 3 of 6)
......
r-
[
......
r--
R
w
:...a
MFPMAOPT
r--
L...-........,
....
STSMACPU
~---
----
--.
~
STSMINIT
'STMVT
Fr
',¥:~~
~<;::
,\;
",
~"\
:
6
Initialize for interval-driven
measurement gathering
(MG) routines as specified by
input options.
•
......
r--
Initialize MG
Routine
(lRBMFICP)
CPU Meas.
~
(lRBMFIPG)
Paging Meas.
I;'
t~
I--
(lRBMFIWK)
I--Workload Meas.
STMVPAG
,
STMVCHl
STMVDEV
~
(lRBMFIHA)
Channel Meas.
~'
STMVWRK
"
~IT
-Fin
STSMA Devices
~
--
I--
(IRBMF IDV)
Device Meas.
~
Diagram 7-6. Initialization Mainline (MFIMAINL) (part 4 of 6)
Extended Description
Module'
6
IRBMFICP
IRBMFIPG
IRBMFIWK
IRBMFIHA
IRBMFIDV
MFIMAINL calls the routines that initialize the MG
routines. Only those MG routines required for the requested kinds of reports are called. For example,
if CPU is the only requested report, then
IRBMFICP is the only MG routine called.
til
(D
Sl.
e'
::s
~
a:
(D
[
Q
"""
o
1a
e'
::s
w
~
w
Label
~
Diagram 7-6. Initialization Mainline (MFIMAINL) (part 5 of 6)
~
Input
'i
ofI1
~
i
r-
~.
r-
IMCYCTOD
Cycle Value (TOO)
7
Enable sample MG routines
(event-driven), if required, and
establish time for the sample
period, if required.
8
Enable for I/O data collection,
if required.
IRBMFIOI
9
Obtain initial values of
measurements for the
requested measurements.
IGXOO(l14
J
f
CD
~
~
~
~
II"
5
~
~
CINITDAT
First Call
Flag for
MFDATA
Return to M FST ART
Mainline (lGXOO013)
MFDATA SVC
Processor
Diagram 7-6. Initialization Mainline (MFIMAINL) (part 6 of 6)
Extended Description
Module
7
If channel or device reports are requested, MFIMAINL
sets a flag in the Communications Vector Table (CVT)
in CVT item CVTMFACT. MFIMAINL also puts the time of
the next sample into MF/l's Timer Ouene Element (TOE).
Before calling Routine IEAOTEOO to enqueue the TOE on
the timer queue, MFIMAINL obtains the dispatcher lock and
establishes a Functional Recovery Routine (FRR) exit; after
setting the TOE, these actions are reversed.
IGX00013
8
MFIMAINL calls routine IRBMFIOI to change instructions in the system 105 functions so that channel and
device measurements are collected as 105 operates.
IRBMFIOI
9
IGX00014
MFIMAINL issues the MFDATA SVC (SVC 109, code
14) to collect data as requested by input options. This
first call to each, however, is indicated as the initial call and
results in taking initial values against which later values are
compared.
CIl
(1)
e·~:::s
~
~
(1)
[
Q
~
o
1~
e·:::s
w
~
IEAOTEOO
Label
~
Diagram 7-7. CPU Activity Initialization (IRBMFICP) or Paging Activity Initialization (IRBMFIPG)
(part 1 of 2)
\.Q
Q\
From Initialization
Mainline (MF IMAINL)
via BAL
o
I:Il
~
N
Input
I:Il
'<
~
STSMA
B
b
~.
STSMOPT
f
CPU Activity Initialization
(I RBMFICP) or Paging Activity
Initialization (lRBMFIPG)
1
Verify the request for the option.
""I
II
Program
Resource Table
~
~
2
;:
a
Obtain storage for tables.
(I)
~
STPRNAME
<
STPRADDR
I:Il
N
~
t
~
~
=...
3
Load required interval MG routine
and place name in resource list. ____-"""""L' _ _ _ _ _----''''''"-_ _ _ _ _ _----1
4
Calculate storage for interval data area.
CVT
CPU
Only
CVTMAXMP
' .
'"
"'It---------t
Return to Initialization
Mainline (MFIMAINL)
-,<
~
~
Diagram 7-7. CPU Activity Initialization (IRBMFICP) or Paging Activity Initialization (IRBMFIPG)
Extended Description
Module
The CPU Initialization (lRBMFICP) and the Paging Initiali·
zation (lRBMFIPG) both have very similar functions, inputs,
and Oljtputs. Therefore, one M.O. diagram is used to
describe the functions of both. IRBMFICP and IRBMFIPG
allocate storage space for control blocks, ensure that copies
of the required interval MG routine are in the virtual storage
space, and calculate the length of the required data area.
IRBMFICP
or
IRBMFIPG
1
The CPU or Paging Initialization routine ensures that
the input option has been specified by checking the
STSMSTA bit in the STSMOPT word of the Supervisor
Measurement Area (STSMA).
IRBMFJCP
or
IRBMFIPG
2
The CPU or Paging Initialization routine uses the
GETMAIN macro instruction to obtain the necessary
storage.
IRBMFJCP
or
IRBMF IPG
3
IRBMFJCP
or
IRBMFIPG
After adding the entry to the Program Resource Table
(STPRT), the initialization routine indicates in the
Resource Vector Table (STRVT) the next available entry in
the STPRT. The entry point address is placed in the System
Measurement Area (STSMA) for use by the MFDATA SVC
Processor (lGX00014).
4
The storage length for CPU data is:
4 + length of (SMFRCD70) + length of (SMF70A) +
(CVTMAXMP + 1) times length of (SMF70B).
The storage length for paging data is:
4 + length of (SMFRCD71) + length of (SMF71A) + length
of (SMF71 B).
CIl
(D
~
e·
=
N
ac
(D
~o
1"0)
o
"tI
~
ae·
=
~
~
......
Label
~
(part 2 of 2)
-_.7'
~
00
~
N
C'Il
Diagram 7-8. Workload Initialization (IRBMFIWK) (put lof 2)
-
-
-.-
--
}7-''''''''''''''-'
· ..
·x·."
-- -
-
1
;
STSMA (workload)
i
---
n
t""
C;Z
!
..
From Initialization
Mainline (MFIMAINL)
STSMOPT
-
"v) 1
-
Verify the request for a workload
option.
'"
...
P'
f
2
w
~N
~
Error
return to
Initialization
Mainline
(MFIMAINL)
Workload Initialization (lRBMFIWK)
Allocate storage for tables; load into
virtual storage and page-fix the
System Resource Manager (SRM)
routine IRARMWAR, and place
addresses in the necessary tables.
STPRT
STPRNAME
..."
}
r
STPRADD
;
~
II
STPRLGTH
w
~
3
WMST
Load into virtual storage the intervaldriven MG workload routine
IRBMFDWP, and place its name and
address in required tables.
-
"
--
,
--
STSGT
to
WMSTPGHI
v
-.II.
WMSTPGPC
I
."
>
4
Initiate workload activity data
collection and obtain space for
interval data area.
~J}
@JIlffIi.1IM!
•--
Return to Initialization
Mainline (MFIMAINL)
)I
Storage Resource
Table
DWWIN
.
- -
~
...
SWWIWAML
y
-
't~?
'=-__ .7
Diagram 7-8. Workload Initialization (IRBMFIWK) (part 2 of 2)
Extended Description
Module
The Workload Initialization (lRBMFIWK) routine allocates
storage for control blocks, ensures that a copy of the
Interval MG routine for Workload (lRBMFDWP) is in storage, and calculates the length of the data area.
IRBMFIWK
1
IRBMFIWK ensures that the workload option has been
selected as an input option by checking the STSMSTA
bit of the STSMOPT of the Supervisor Measurements Area
(STSMA).
IRBMFIWK
2
IRBMFIWK uses the GETMAIN macro instruction to
obtain the required storage. IRBMFIWK also uses the
PGFIX macro instruction to fix IRARMWAR. Then,
IRBMFIWK issues a WAIT macro instruction for page fix
completion. The name and address of IRARMWAR are
placed in the Program Resource Table (PRT) and the
Resource Vector Table (RVT) is marked to indicate the
next entry in the PRT.
IRBMFIWK
3
IRBMFIWK
The name of the Interval MG Routine for Workload
(lRBMFDWP) is placed into the STPRT, and its
address into STSMINTP of the System Measurement Area
(STSMA).
ir
g.:s
~
a::
a
[
2o
'I!!t
8"
:s
~
Label
Label
Extended Description
Module
4
IRBMFIWK MFIIPSWA
IRBMFIWK calls routine MFIIPSWA, which uses a
GETMAIN macro instruction to obtain storage for the
interval workload data area. The length of this area is:
length (WAMT) + (highest performance group number times
(length (WAMTNDX entry» + (total number of performance
group periods) times (length of WAMP). (A performance
group is a term of the System Resources Manager (SRM).)
The length and address of the area are inserted into Storage
Resource Table (STSGT). The address of IRARMWAR is
inserted into the gotten area, and IRBMFIWK issues a
SYSEVENT WKLDINIT macro instruction to initiate SRM
workload data collection. Return code 00 from the
SYSEVENT is the good return. Return code 08 indicates
that the installation performance specification (IPS) was
changing when the SYSEVENT macro instruction was
issued; another SYSEVENT is therefore issued. Return code
20 from the SYSEVENT indicates that MF/1 data collection
is already active; therefore a bad return is made to
IRBMFIWK.
....~
8
~
Diagram 7-9. Channel Initialization (IRBMFDlA) (part 1 of 4)
Input
"'
tw
fI.)
1
9
-
i.
--
I,
STSMA (Channel)
n
r-
f
..
From
Initialization Mainline
(MFIMAINU via BAL
I
I
L
I
..J
I
STSMOPT
-
-
Output
Process
~
11.>
.,,"
1
Verify the request for this option.
STPRT
STPRNAME
2
~.
~
JI..
Allocate space for tables STPRT
and STSGT. Load and page-fix
the event-driven MG routines.
~A
I'
E"
Iw
3
~tw
::c
f
CVT
I CVTMAXMP
w
Store address of MFROUTER
service routine into CVT.
'--
I
4
..J
~
,
Load into virtual storage intervaldriven channel routine IRBMFOHP,
and place its name and address
in required tables.
- -
PCCA i
t
t
t
,J-
PCCA 1 orO
'-1
L
PCCA2 or 0
•••
PCCA 16 or 0
lJ\
CSOCHAO
I"
~
5
Allocate storage for Channel
Event Data Table (ECCEO),
and initialize it and related
tables.
~
PCCACAT
.I
-
~4\~_
';
--
,to.
"
I
"
STSMINTP
;
ECCEO
STSMEOAO
-
--1,
ECCECPEa
-
......
•
:9
ECCPE
ECCPE (1)
ECCPE (2)
----a
•••
I
V
'._- .
....-
~
"
1
I
I
~
CVTMFRTR
STSMA (Channel)
"
,----"-
CVT
11\
CSO
l
STPRLGTH
I
;
~-,
~
"
STPRAOOR
rv
I
,
ECCPE (n)
~ ECCOB
ECCOS (1)
ECCOS (2)
•••
ECCOS (n)
...
~
Diagram 7-9. Channel Initialization (IRBMFIHA) (part 2 of 4)
Extended Description
Module
The Channel Initialization (lRBMFIHA) performs the initialization functions required to cause MF/1 to begin collecting channel data. These functions include initializing
both event-driven and interval-driven MG routines.
IRBMFIHA
1
IRBMFIHA checks bit STSMSTA of SYSMOPT in the
System Measurement Area (STSMA) to ensure that
channel data has been specified as an input option.
IRBMFIHA
2
IRBMFIHA
IRBMFIHA activates modules IRBMFEVT (to respond
to MFROUTER requests), IRBMFECH (to collect
event-driven sample data on the channels of the CPU that
executes the instructions when IRBMFEVT receives control), and IRBMFTCH (to collect event-driven sampled data
on the channels of any CPU not executing the instructions
when IRBMFEVT assumes control). The activation consists
of adding the modules to the Program Resource Table
(STPRT) and adding IRBMFECH and IRBMFTCH to
IRBMFEVT routing table entries, STMMMGRL 1 and
STMMMGRL2.
r:Il
a
~.
=
~
ac:
a
8:
So
o
"'CI
i
~.
::I
:r::
Q
-
Label
IHLOADM1
IHPAGFX1
IHLOADM2
IHPAGFX2
IHLOADM3
IHPAGFX3
Extended Description
Module
3
Set the MF/1 MFROUTER pointer (CVTMFRTR)
in the Communication Vector Table (CVT) to point
to IRBMFEVT.
IRBMFIHA
4
The name IRBMFDHP is placed into the STPRT and
the STRVNPRT is updated to show the addition of
IRBMFDHP. The address of IRBMFDHP is placed into
STSMINTP of the STSMA for use by IRBMFEVT.
IRBMFIHA
IHLOADM4
5
IRBMFIHA
IHGETMN3
A CPU element (ECCPE) is allocated and initialized
for each possible CPU (MAXMP + 1), and then for each
ECCPE, channel Data Block (ECCDB) entries are formed
for each possible channel (CSDCHAD + 1). These CDBs are
used to store data collected at each sampling event.
Label
~
Diagram 7-9. Channel Initialization (IRBMFIHA) (part 3 of 4)
S
o
~
~
N
til
Output
Process
'<
=9
STMMV
b
STMMEVTL1
~.
l"'"
~
6
~
Store the address of the ECCED into
required tables.
./\
c.....
STMMMGRL1
STMMMEVTL2
~
[
<-.
(I)
'<
til
N
STSGFREE
~
~
!..I
7
Calculate the storage required for the
interval data areas.
8
Request start of lOS data collection,
request that the MFROUTER be
enabled, and indicate that sampling
is required.
Return to Initialization
Mainline (MFIMAINL)
~
)
STMMMGRL2
~
"i
)
STSMIGMC
-?
~
Diagram 7-9. Channel Initialization (IRBMFIHA). (Part 4 of 4)
Extended Description
Module
6
IRBMFIHA
The address of the Channel Event Data Table (ECCED)
is stored in STMMMGRL1 and STMMMGRL2 of the
MFROUTER Measurement Vector Table (STMMV) for use
by the MFROUTER Processor (lRBMFEVT). The ECCED
address is also stored into the Storage Resource Table
(STSGT) and the System Measurement Area (STSMA).
7
The storage length for interval data is:
4 + length of (SMFRCD73) + length of (SMF73A)
+ (CVTMAXMP + 1) times (CSDCHAD + 1) times length
of (SMF73B).
8
The return code from IRBMFIHA is set to indicate
that lOS data collection should be requested, that the
MFROUTER should be enabled, and that sampling of
channel data is required.
til
(D
(')
g.
:s
~
i:
!1
[
o
"""
o
I
~.
:s
~
c:>
~
IRBMFIHA
Label
"'----'
~
Diagram 7-10. Device Initialization (IRBMFIDV)
2
(part I of 2)
..
From Initialization
Mainline (MFIMAINL)
ofIl
--
~
N
STSMA (Device)
--
fIl
'i
a
STSMOPT
-
S'
OQ
ti"
r~
- -
Device Initialization (lRBMF IDV)
".,
--
~
o<
1
Verify the request for this option.
2
Allocate space for STPRT and STSGT
tables; load into virtual storage
and page-fix device event-
;, *=J~;Wt'i• • •&1.0!Br?ljYf3ii.-jj_,§!t~.
2
Permanent Common
Option Area
MFCOA
-
IRBMFMPR
r'
Message
Processor
""
....
MFCOINTV
...
Issue message to operator:
MF/1 ACTIVE.
,
-
-
~
w
1
"
r'
~
i
Error
Linkage
Only
,1 ...
~
(II
Output
Process
v
)
MFPCT
3
r:::::--
Convert the interval (input option
data) to time-of-day form.
L..--
-"')I
~
-
v~_
!..I
MFPCT
~
-
- -
-
1
--
J
MFPCMINT
I
I
MFCOA
r---
-
-I
MFCOSTPV
r....
I
-
I,
1
I
I
-
-
--J
~--
...
..> 4
J\
Unless the input option indicates
NOSTOP, calculate the number
of intervals to the stop time.
.,
MFPCT
MFPCNINT
-
MFPCT
.-I
~
--""I
MFPCMINT
...)
v
-
,~
"
0'0"
5
Reduce the interval count by one.
When the count is zero, cancel
the ESTAE and return.
_~
Returnto
MFSTART
(lGXQOO13)
MFPCNINT
---
-- -
Diagram 7-11. Data Control (IRBMFDTA)
rn
(I)
~
e'
1:1
~
a::
[
a.
o
"0
~5'
1:1
I.f
S
(part 2 of 4)
Extended Description
Module
Data Control (lRBMFDTA) is executed in problem state
in response to a SYNCH macro instruction issued by the
MFSTART module. This change from supervisor state in
MFSTART represents the entry into the main measurement
gathering operations, which are controlled from the Data
Control Module. Control includes establishing the interval
of measurement gathering, as specified by an input option,
and the queueing of report generation subtasks if real time
reporting was requested. In addition, Data Control performs
a number of event control block and storage control functions.
IRBMFDTA
1
Establish ESTAE routines.
IRBMFDEA
2
This message is the first normal operation message to
the operator. It is issued after he indicates GO.
IRBMFMPR
3
Interval time is entered in minutes. This time is converted to microseconds and placed in a doubleword
such that a one in bit 51 equals one microsecond.
IRBMFDTA
4
A stop time (input option) is specified or NOSTOP
is specified. If NOSTOP is specified, the stop command
is used to stop MF/1 operation. If a stop value is given, the
amount of time from the current time until the stop time
is divided by the interval length to obtain the number of
intervals.
IRBMFDTA
5
IRBMFDTA
Data Control reduces the number of such intervals
each time through this code. When this interval count
is zero, MF/1 measurements are ended.
Label
...~
Diagram 7·11. Data Control (IRBMFDTA) (part 3 of 4)
i
i
~
N
'"h<
fIl
1
6
Set interval timer to alert Data Control
when the end of the current interval
is reached.
MFPCT
i-
~-
az
MFPCELADI=O
n
r-
IV
--
!<
2.
I
§
(D
eN
~N
Operator STOP Command
7
If a previous list of event control blocks
exists, free that storage, set up storage
for a new ECB list, and set ECB
addresses into new ECB list.
8
Wait for the posting of one of the
following events (9, 10, or 11) in
an event control block (ECB).
9
If the ECB for an operator-entered
STOP command is posted,
cause measurement gathering
for this interval. If reports are
to be printed, attach report
'"
generation subtasks in accord
with input options. Cancel
the ESTAE, and end
-,
measurement gathering by
returning.
-'
1\
\.... STOP Command ECB
I
f
....
rJ>
eN
~
~ARG Subtask' Ended
MFSEL
--J
-
-
STIMER Time Ended
~STIMERECB
DTSTIECB
SVC 109
I
I
IGXOOO14
Start measurement
gathering routines
~
to.
IRBMFRGM
~
...
Report Generator
Return to MFSTART
UGXOOO13)
n;)
10
If the ECB for the end of a report
generator subtask is posted, indicate
its completion and free its main
storage.
11
If the ECB for the end of the
current interval is posted, cause
measurement gathering for this
interval and, if reports are to be
printed, attach report generation
subtasks in accord with input
options.
...I
1
I
to.
...
1
....
MFSESECB
f
f
,! ...
"')
II'
..
(SVC 109)
.
r'
Start MG Routines
-,
..
(ATTACH)
...
"'='>
"
p
<~<
- -- -
IRBMFRGM
Report Generator
-,
!ill'
IGXOOO14
"".
:
'
)7
" __ 7
Diagram 7-11. Data Control (IRBMFDTA) (part 4 of 4)
Extended Description
Module
6
The routine sets the STIMER macro instruction for
the length of the current interval and compensates for
any stop during the interval.
IRBMFDTA
7
It uses one FREEMAIN macro instruction to free
storage of any existing event control blocks (ECBs).
Then the routine uses GETMAIN to obtain storage for
pointers to ECBs: one ECB for the STOP command, one
for the STIMER alert, and one for each report generation
(SARG) subtask.
IRBMFDTA
8
IRBMFDTA
One of three conditions has occurred when an ECB is
posted:
a) The operator has issued a stop command. If so, create
short interval data, and end measurements. Return to
caller of Data Control.
b) A report generator subtask has ended. If so, detach the
subtask, and dequeue its subtask element (SEL) from the
subtask queue (SQU).
c) The STIMER interval has been reached (the current
interval has ended). If so, issue an MFDATA SVC to cause
measurement gathering for this interval and attach a
report generation subtask unless no report of these
measurements was requested. Build a (SARG) subtask
queue element (MFSQU) for the subtask.
1;1)
(D
::a.
c)"
::I
~
ac
sa.
5'
Q.
~
o
1as·::I
~
$
Label
Extended Description
Module
9
IRBMFDTA
An EXTRACT macro instruction is used to obtain the
command input buffer (CIB) address of the STOP.
A short interval results when the STOP command is issued.
The MFDATA SVC controls the collection of requested
measurement data. Report generation subtasks are called
by attaching the Report Generator control (JRBMFRGM).
IRBMFRGM
10
Data Control issues a DETACH macro instruction to
remove a completed subtask and then shortens the
subtask queue. The subtask's main storage (its element subpool space) is freed by means of a FREEMAIN macro instruction.
IRBMFDTA
11
IGX00014
The MFDATA SVC controls the collection of
requested measurement data. Report generation
subtasks are called by attaching the Report Generator control (lRBMFRGM).
IGXOOO14
IRBMFRGM
Label
~
Diagram 7-12. Termination Processor (IRBMFI'MA) (part 1 of 2)
o
o
rIl
~
W
From MFSTART
Input
Process
. .1•..•
r".ITil*
-=
el'rli;;,I'dil~I~ltilol~lpl'rl:lce!;
::1
Issl·~I';W-I(I';RIi.IBI:I·FI~IIM·lil~)lIil,
•..
Output
SVC via CALL
US: . .
: . . • ZBJ1iiiG
rIl
Is
ESTAE PAR AM
~.
:
:>
1
I~
Esta?lish connection to recovery
routme.
Error
Linkage
Iq
aI
ESTAE Routine
~
~
~
i
(D
CVT
,........--
;,,-
CVTMFRTH
-y
-
CN
~
w
~
rit
2
Disconnect event driven (MFROUTER)
routines.
3
Stop workload MG activity.
4
Stop 105, device, and channel MG
activity.
CN
....
~
...
~
...
t1
...
!.J
5
Dequeue the MF1 timer queue
element (TOE).
...
IRBMFIOI
Terminate 105 MG
Activities
IEAOTDOO
Dequeue TOE
STSCT
Supervisor Control
Table
·r',:.
..')
STGST
7
Free event-driven (MFROUTER) MG
vector table, local, pageable storage,
and global, fixed storage.
8
Set termination variables.
9
Cancel connection to recovery
routine and then return.
,'"
~:
Free resources obtained for MG
routines.
""f
:;,:,;.:.'
~
Global Supervisor
Table
6
Return to MFST ART
Mainline Processor
OGXOOO13)
IRBMFTRM
Terminate I'y'IG
Routine Resources
Diagram 7-12. Termination Processor (IRBMFTMA) (part 2 of 2)
Extended Description
Module
The Termination Processor (lRBMFTMA) disconnects
MFI1 from the resident nucleus. The Termination Processor dequeues the Timer Oueue Element (TOE), disconnects the event driven (cycle) MG routines, disables workload activity data collection, releases global storage, and
restores the changes made in the system I/O processor (lOS)
to enable channel and device data collection.
IRBMFTMA
1
IRBMFTMA
The Termination Processor provides ESTAE parameters
to provide for retrying while releasing resources.
2
IRBMFTMA
3
IRBMFTMA
IRARMWLM
4
The Termination Processor calls the lOS Initiation/
Termination Module (lRBMFIOI) to restore the
changes it made to lOS.
ell
a
~.
=
N
==
~
io
"'o"
'0
;
g.
=
~
Extended Description
Module
5
IRBMFTMA
The Termination Processor dequeues the MF/1 timer
queue element (TOE) by disabling (using the
SETLOCK macro instruction); providing a functional
recovery routine (FRR) link (because of having disabled);
and using the TOE Dequeue routine (lEAOTDOO) to
dequeue the TOE. The Termination Processor then cancels
the FRR link, and enables by means of the SETLOCK
macro instruction.
6
The linkage to the MFROUTER service routine
(lRBMFEVT) is changed so that if an attempt is made
to transfer control to IRBMFEVT, immediate return will
be made by a BR 14. The Termination Processor also
ensures that no CPU is currently executing event-driven MG
code when this code is disconnected.
The Termination Processor causes the workload manager to stop workload activity data collection.
Label
The Termination Processor calls routine I BBMFTRM
to release the resources of each MG routine.
7
IRBMFIOI
IEAOTDOO
IRBMFTRM
The Termination Processor uses the FREEMAIN macro
instruction to release the measurement Vector Table
(STMMV), the MF/1 local storage, and MF/1 global storage.
IRBMFTMA
8
The Termination Processor dequeues the MF/1
enqueue resource by use of the DEO macro instruction.
IRBMFTMA
9
The EST AE connection is canceled by use of the
ESTAE macro instruction.
IRBMFTMA
Label
"f
Diagram 7-13. MF/l Message Processor (IRBMFMPR)
w
~
(part 1 of 2)
From Caller of
Message Processor
Input
Process
~
w
rn
'<
fQ.
a
MF /1 Message Processor
(lRBMFMPR)
MPLIST
MPMDL
~
~.
r-
I
MPMSGBUF
<
~
a
1
Assemble the parts of the message
and fill the output buffer with the
assembled message text for one
line.
2
Output the buffer (one line of the
message) to:
Message
Text Module
IRBMFLMP
(D
w
'
J.',
a. Operator's console.
}::j
'. VI
~
b. Data set.
~
or
MP1STLIN
First Line
Indicator
c. System Message (WTP
messages) area.
''TJ
,~;
-C;;"
;.'~ 3
SYSOUT
or
If another buffer load (message
line) is required, return to Step 1.
Otherwise, return.
;;;
'1
r;~
System
Message
Area
Data
Set
~
Diagram 7-13. MF/l Message Processor (IRBMFMPR) (part 2 of 2)
Extended Description
Module
The Message Processor (lRBMFMPR) is called from several
places in the MF/1 program to print output messages.
(These are: IRBMFDTA, IRBMFINP, IRBMFRGM,
IRBMFMFC, and IRBMFMLN.) The Message Processor
assembles the required message from parts in the Message
Text module (lRBMFLMP), moves the parts into an output
buffer, one message line at a time, and writes the message
lines to the required output device or data set.
IRBMFMPR
1
Input parameters define the message in terms of fi?
MG Routines
Call each measurement gathering
(MG) routines three times
(for prolog, move, and epilog),
disabling before move and
enabling afterword. All prologs
are called before any move,
and a II moves before any
epilog.
-
addr: Channel
I
MG routine
addr: Channel
move or epilog
~
Device SMA
~
addr: Device MG
routine
addr: Device
move or epilog
~
II.~,
I
........m
...Jjr---.
Return to Data Control
(lRBMFDTA) or
MFSTART UGXOO013)
~
Diagram 7-14. MFDATA SVC Mainline Processor (IGXOOOI4) (part 4 of 4)
Extended Description
Module
3
IRBMFDCP
IRBMFDPP
IRBMFDWP
IRBMFDHP
IRBMFDDP
Each MG routine has a prolog, a move part, and an
epilog. The prologs for all the required (by input
option) MG routines are called first in the order listed in the
first paragraph of this explanation. When the prologs have
been called, the required move parts are called, and then the
epilogs are called. The effect on each MG routine, however,
is as though it executed from start to end without interruption. This arrangement is used to allow the move parts
of these routines and IGX00014 to execute disabled. Before
the move parts of the MG routines, which contain the code
to move measurement data into record formats, are executed, interruptions are disabled by obtaining and releasing
the dispatcher lock. When the SETLOCK is released, it is
released disabled. The reverse technique is used to enable,
after all the move parts of the MG routines have been
executed.
4
til
a
~.
::I
t-.,)
iC
a
8'
Q.
o""l
o
"0
~
a~)"
::I
~
-
...,
Upon return to the caller, IGXOO014 save the Measurement Vector Table (DTMVT) address in register 1.
IGX00014
Label
~
Diagram 7-1 S. Interval MG Routine for CPU (IRBMFDCP) (part I of 4)
00
&$
From MFOATA SVC Mainline
Processor (lGXOO014)
Input
~
N
".,.,', ....:."/ .."
Process
Interval MG Routine for CPU
(lRBMFDCP)
f.I.)
1
,
s
,;
~
~.
Co
~
~
~
~
STSMA (CPU)
..
:
;,
0-
--
Prolog
....
)
...
(I STSMIGMC
,'.
':'
;,;
Output
"",
(
1
.''''''"
:
i
STSMA
;
~
::
~;
1>.
Obtain storage area for new data.
STSMIADD
...
STSGT
--
L.. __
Parameter List
+STSMA
2
Initialize and fix (in real storage) the
new data area and fix IRBMFDCP.
3
Save entry point for Move routine
(see the MFOATA SVC Mainline
Processor (lGXOOO14) diagram).
~
\;,"
Storage
Resource
Table
';:
(II
~
~N
SMF Header
---
~
~
i
~
From
MFDATA
SVC
(tGXOOO14)
..
STSMA (CPU)
~
!..!
STSMEOAD
-
Move
4
~
~-
-
....
"
A
Return to
MFOATA
Processor
Update tables for CPU activity status
and change in status since last interval.
~
....
.....
,~;.
CSDCPUAL
LCCAi
LCCAWTIM
~
,.--
J
J
f
-
'"
.....
J
-----
.}~.·0."%"",:.·
5
Move all CPU waiting times into
new data area.
I
y
6
Save entry point for Epilog routine
(see the MFOATA SVC Mainline
Processor (tGXOO014) diagram).
PCCAPCID
.,.
-- -
,/'+
.,
<;';""
~.,.,
....~
... L
- -
....
PCCA i
....)
I
I
~
STSLCOM
...
CSO
::I
STSMENTR
Return to
MFOATASVC
Mainline
Processor
'"
',·c,;
-- -;;2"
New Data Area
"c
~
,..•.
I
~
Diagram 7-1S. Interval MG Routine for CPU (IRBMFDCP) (part 2 of 4)
Extended Description
Module
The Interval MG Routine for CPU (lRBMFDCP) receives
control from the MFDATA SVC Processor at the end of
each interval if CPU activity reports are required .
.IRBMFDCP copies CPU wait times for all CPUs into a contiguous storage area and builds an internal image of the
MF/1 CPU activity record (SMFRCD70) for the SMF data
set. IRBMFDCP calculates wait time for each CPU by subtracting the wait time read at the end of the current interval
from that read at the end of the previous interval, after
adjusting for the possibility of wrap-around readings.
IRBI'ylFDCP
Label
Prolog
1
Use the GETMAIN macro instruction to obtain the
required storage in key zero.
IRBMFDCP DCGETMN1
2
Store the subpool and length of the storage obtained
into the first word of the area. Use the PGFIX macro
instruction to fix the data and IRBMFDCP.
3
Save the entry point, as described in the M.D. diagram
MFDATA SVC Mainline Processor OGXOOO14), for
use in returning to the Move part of IRBMFDCP.
IRBMFDCP
Move
4
If a CPU is now online whose flag is not set in
STSMEDAD of the Supervisor Measurement Area
(STSMA), set its flag to indicate that it has been online.
IRBMFDCP DCMOVE
5
IRBMFDCP
~
Partially initialize the SMF record image, set online
status flags for all valid CPUs, and move in wraparound wait time measurement counters for those CPUs.
::s
!'!
6
IRBMFDCP DCEPILOG
I:I'J
(D
~.
a::
sa.
[
So
o
"C:S
~
a
~.
::s
~
\C
See Step 3.
~
~
o
Diagram 7-15. Interval MG Routine for CPU (IRBMFOCP) (part 3 of 4)
From MFDATA SVC
Mainline Processor
(JGXOOO14)
(I)
"<
(I)
Process
Input
Output
N
(I)
'<
~
9
i
(Ii)"
Parameter List
Initial Call Flag
Epilog
7
If this is the initializing call of this
routine, return to MFDATA SVC
processor; otherwise, proceed to
next step.
8
Complete the SMF record image by
calculating CPU data for this interval
and moving it into the area that
contained previous interval data.
9
If RECORD is requested, write the
SMF record. Otherwise, proceed
to the next step.
10
Obtain storage in TCB key
(also called user's key), move
calculated data into it, and return
the data address to MFDATA SVC
caller.
r-
a0:
'<
<
o
~
(D
w
'<
(I)
N
~
(D
i'
Y6
w
Record Flag
~
VI
SMF Data Set
DCSMFLEN
11
Free area obtained for the last
interval's new data.
Return toMFDATA SVC
Mainline Processor
(JGX00014)
Output Data
Address
'--_
~
Diagram 7-1 S. Interval MG Routine for CPU (IRBMFDCP) (part 4 of 4)
Extended Description
Module
Epilog
7
On the first call to the MFDATA SVC, the MFDATA
SVC Processor calls the interval MG routines to obtain
a first set of wrap-around measurements for later calculations (subtraction).
IRBMFDCP
8
Move through all possible CPU entries in old and new
data areas, and calculate CPU wait times for CPUs
active throughout the interval. Allow for wrap-around
values when subtracting current from previous values.
IRBMFDCP
9
IRBMFDCP
Use the SMFWTM macro instruction to write the image
of the SMFRCD70 record to the SMF data set.
10
r
~.
:=
~
tiC
ia
o
I
~.
:=
-Cf
t-J
Use the GETMAIN macro instruction to obtain the
required storage in user key; use the MODESET
macro instruction to change to the TCB key.
IRBMFDCP
11
IRBMFDCP
Release the storage of the internal SMF image using
a FREEMAIN macro instruction.
Label
.1'
"'-.-Y
::;:
Diagram 7-16. Interval MG Routine for Paging (IRBMFDPP) (part 1 of 4)
t1
~
From MFDATA SVC
Mainline Processor
(lGXOOO14) via CALL
Input
w
STSMA (Paging)
Interval MG Routine for Paging
(lRBMFDPP)
STSMIGMC
Prolog
1 Obtain storage area for new data.
{'IJ
IS-
List
• STSMA
~.
Process
Output
STSMA
STSMIADD
STSGT
i
~
~
2
Initialize and fix (in real storage) the new
data area and fix IRBMFDPP.
3
Save entry point for Move routine
(see the MFDATA SVC Mainline
Processor (IGXOOO14) diagram).
J
(D
w
'<
ASMVT
{'IJ
w
is
-
ASM Vector
Table
From
IGXOOO14
via CALL
Move
w
4
:....
,
SMF Header
Move header data and PVT and ASMVT
data into new data area.
STSMENTR
Return to
MFDATA
Processor
New Data Area
PVT
I
Paging
Vector Table
From
IGXOOO14
via CALL
STSMA
5
Save next entry point.
Epilog
Initial Call
Flag
6
Free previously fixed areas.
7
If this is the first time through this routine,
return to MFDATA SVC Mainline
Processor UGXOOO14); otherwise, proceed
to next step.
Return to
MFDATA
Processor
Diagram 7-16. Interval MG Routine for Paging (IRBMFDPP)
Extended Description
Module
The Interval MG Routine for Paging URBMFDPP) builds an
internal image of an SMF-71 paging record and, optionally,
copies this image to the SMF data set. IRBMFDPP uses, for
the internal image, data collected by the paging supervisor
and the auxiliary storage manager. As described in the M.O.
for the MFDATA SVC Processor, IRBMFDPP executes in
three parts, PROLOG, MOVE, and EPILOG, but no break
in execution is apparent except for the need to save entry
points for the MOVE and EPILOG parts.
IRBMFDPP
1
The GETMAIN macro instruction is used to obtain
storage in key zero. The data for this interval is to be
moved into this storage.
IRBMFDPP
2
IRBMFDPP
3
Use macro instruction PGFIX to inhibit paging of
both the data area and routine IRBMFDPP.
The entry point is to be used to enter the Move
part of IRBMFDPP. Between the PROLOG and Move
a mechanism is used that avoids freeing data that would be
freed in a normal return.
til
$t
e'
=
~
at::
sa.
8'
Q.
SO
"0
~5·
=
~
N
tN
(part 2 of 4)
Label
Extended Description
Module
4
IRBMFDPP moves a standard SMF record header and
MF/1 control section and then fills in data fields in the
internal record image (SMFRCD71 ).
IRBMFDPP DPRTOO17
5
IRBMFDPP provides entry to its EPILOG.
IRBMFDPP
6
IRBMFDPP uses the PGFREE macro instruction to
allow paging in previously fixed area.
IRBMFDPP DPRTOOO18
IRBMFDPP DPPAGFX4
7
IRBMFDPP
IRBMFDPP DPMOVE
On being called as part of initialization via the
Initialization Mainline (MFMAINL) and MFDATA
SVC Processor (lGXOOO14), IRBMFDPP returns to
IGXOO014, leaving initial-value data in an SMF record to be
used at the end of the interval.
IRBMFDPP
Label
DPEPILOG
~
Diagram 7-16. Interval MG Routine for Paging (IRBMFDPP)
(part 3 of 4)
~
i
~
N
fIl
.~.
,
~.
1
~
cin'
f
I'rI
1'01
8
Record Flag
Complete the SMF record by
calculating paging data for this interval
and moving it into the area that
contained previous interval data.
"
..
Previous Interval
Data Area
..
..)I
SMF Data Set
~
~
r
CD
...
w
~N
~
f
>
9
Previous
Internal
Data Area
..> 10
w
~
...
DCSMFLEN
I
I
If RECORD is requested, write
the SM F record. Otherwise
proceed to next step.
!"
o/:!v
I
Obtain storage in TCB key
(also called user's key), move
calculated data into it, and return
the address to MFDAT A SVC
caller.
DCRETDTA
"I Address of Data
I
~
II
II
11.)1
...
4
t'
Invoke the workload activity data
collection facility of the System
Resources Manager (SRM).
--
"
"
TMFDATA
Return to
5
Save the next entry pOint.
(Local) WAMT
Processor
(lGXOOO14)
Workload
Activity
Measurement
Table
~
Diagram 7-17. Interval MG Routine for Workload (IRBMFDWP) (part 2 of 4)
Extended Description
Module
The Interval Routine for Workload (lRBMFDWP) builds the
internal image of SMF-72 records from data collected by
the Workload manager of the System Resources Manager
(SRM). If required by input option selection, IRBMFDWP
also copies the SM F record image to the SM F output
data set.
IRBMFDWP
Prolog
1
The Interval Routine for Workload (lRBMFDWP)
uses the GETMAIN macro instruction to obtain
storage in supervisor key for the Workload Activity
Measurement Table (WAMT).
IRBMFDWP
2
IRBMFDWP
IRBMFDWP uses the PGFIX macro instructions to
page-fi x the data area and instructions of I R BM F DWP .
Item STRVNSGT is updated to indicate the next available
slot in the Storage Resource Table (STSGT).
til
(D
$l
eS"
:s
N
ac
i....
o
o
1g.
:s
"f
N
......
Label
Extended Description
Module
3
IRBMFDWP DWMOVE
The entry point of the Move part of IRBMFDWP is
saved in the Supervisor Measurement Area (STSMA)
to implement a special return sequence, which does not
free storage and does not invalidate addressing. The purpose
of this return sequence is to separate each interval MG
routine into three parts: Prolog, Move, and Epilog. The
Prologs of all MG routines are all executed before any Move,
and all the Move parts before any Epilog. Because of the
special return sequences used, however, each interval MG
routine appears to be executed without any break, from
start of Prolog through end of Epilog.
Label
Move
4
Issue a SYSEVENT WKLDCOLL, which generates a
branch entry to the SRM. SRM copies workload data
from the global WAMT to the local WAMT.
IRARMINT
5
IRBMFDWP DWEPILOG
Save entry point in STSMA for epilog segment.
~
Diagram 7-17. Interval MG Routine for Workload (IRBMFDWP)
(part
3 of 4)
N
00
o
~
~
N
t-rom
IGXOOO14
via CALL
..
~
~
rJi
n'
r-
'..;.:-,
,..;.:-
.«
-»~,
!
6
Free previously fixed areas except the
address of the local WAMT in the
STSGT.
7
If the return from invoking the
SRM in step 4 indicated that
the Installation Performance
Specification was changed
since the last check, stop
collecting worklOad data and
reinitialize.
'c
(II
CN
~N
..
..
~
Resource Release
....
..
.
")
Initial Call Flag
rd
r
~
8
If this is the initializing call of
this routine, free local WAMT and
return. Otherwise, proceed.
9
Obtain storage fo, SMF "co'lls.
l!
IRBMFIWK
P'
Input Parameters
CN
IRBMFTRM
~
Workload
Initialization
~
i
»>:
Epilog
eT
~
a
'O!'
~,
Return to
MFDATA
Processor
UGXOOO14)
--u
i'
")I
SMF -72 Records
)f
SMF Data Set
r
II
-~~
"Ji!
" 10
.,>
SMF Header
~
Record Option Flag
Format an SM F record for each valid
performance group. Write the data
if RECORD option is requested in
input options.
1""""-"--"""- - - - " -
11
~
~~
..
Free local WAMT and return.
-y
~ MFDATA
Retumto
"
Processor
OGXOOO14)
"<_::'
'--"
~
Diagram 7-17 ° Interval MG Routine for Workload (IRBMFDWP)
Extended Description
(part 4 of 4)
Module
Label
Extended Description
Module
Label
Epilog
6
Remove the address of the storage, from the Storage
Resource Table (STSGT). (The address of the local
WAMT in the STSGT is not removed until its storage is
freed in step 8 or 9J
IRBMFDWP'
7
IRARMINT
IRBMFTRM
IRBMFIWK
If the IPS changes; issue a SYSEVENT WKLDTERM
to terminate the recording of workload data. Call
General Resource Release to free the global WAMT and
10
Start Length
highest perf group number
WAMTNDX 1
WAMTNDX 2
MF/1 workload measurement resources. Then call workload
initialization to re-initialize workload activity data collection
for the new IPS.
8
9
IRBMFDWP issues a FREEMAIN macro instruction
to release storage for the local WAMT.
The amount of storage obtained in user's key (the
key in the TCB) is determined as follows:
No. of bytes required = 8 + (highest performance group
noJ times (length of WAMTNDX) + (total number of performance groups) times (length of SMF72B) + (total no.
of valid performance group numbers) times (length of
SMFRCD72 + length of SMF72A)
Following is the SMF records area
format:
...
WAMTNDX highest perf group number
SMFRCD72,
IRBMFDWP MFFREWAM
SMF72A 1
SMF72B1 t
IRBMFDWP
SMF72B1 2
SMFRCD72 2
. ..
Where WAMTNDX is the ith index to the SMF72 record
associated with PGi (or zero if PGi is not a valid performance
group).
IRBMFDWP issues an SMFWTM macro instruction to copy
each record to the SMF data set if RECORD was requested.
11
~
a
eo
=
~
~
[
o
o"'"
"g
&teo
=
~
~
\C
See step 8.
IRBMFDWP MFFREWAN
...
~
Diagram 7-18. Interval MG Routine for Channels (IRBMFDHP)
~
i
~N
From MFDATA SVC
Mainline Processor
UGXOOO14) via CALL
Input
en
'<
I
STSMA (Channel)
~
i
r1
ro-
er
~
~
STSMIGMC
-
~
Parameter List
,+
~
--
I ti
-.
Process
Output
Interval MG Routine for Channels
(lRBMFDHP)
Prolog
i;> 1
to.
2
STSMA
(part 1 of 4)
Obtain storage tor new data area.
Initialize and fix (in real storage) the new
data area and fix IRBMFDHP.
11
If
«$
=-;
+1
Y1
Jo..
W,
1
STSGT
STSMIADD
Storage
Resource
Table
E'
51
(D
w
~N
t
s
w
:..,
L
3
SMF Header
Save the entry point for Move (see MO
diagram for MFDATA SVC Processor).
STSMENTR
From
IGXOO014
ECCED
~
I
:
ECCESAMP
ECCPE Queue
ECCPE
ECCDB Queue
1
ECCDB 1
2
ECCDB 2
ECCPE
Return to
MFDATA
Processor
UGXOOO14)
Move
~ ECCECPEQ
:" >
4
Check the Channel Data Blocks
(ECCDBs) of all CPUs, and move
valid channel data into the new
data area.
5
Save the next entry point. _ _ _ _ _ _..,...".._,/\
;
;
~
....
to.
•••
Return to
MFDATA Processor
(lG XOOO 14)
,
New~taA~
~<-'
Diagram 7-18. Interval MG Routine for Channels (IRBMFDHP) (part 2 of 4)
Extended Description
Module
The Interval MG Routine for Channels (lRBMFDHP)
receives control from the MFDATA SVC Main'lne
Processor at the end of each interval if channel
activity reports are required. IRBMFDHP obtains
and formats (sample) cycle data collected by the
event-driven channel routines IRBMFECH and
IRBMFTCH. IRBMFDHP records the data on the
SMF data set (via the SMFWTM macro instruction)
if RECORD is specified as an input option.
IRBMFDHP
Label
Prolog
1
Use the GETMAIN macro instruction to obtain the
required storage in key zero.
IRBMFDHP
2
Store the subpool number and the length of the storage
area obtained into the first word of the area. Use the
PGFIX macro instruction to fix the data area and
IRBMFDHP.
3
Save the entry point, as described in the M.O.
diagram, MFDATA SVC Mainline Processor
(lGXOOO14), for use in returning to the Move part
of IRBMFDHP.
IRBMFDHP DHMOVE
Move
4
C"Il
(II
sa.
Partially initialize the SMF record image in storage.
Then check through the channel Data Blocks
(ECCDBs) associated with each CPU. (There is a CPU
Element (ECCPE) entry for each CPU; each CPE entry
points to one or more ECCDB entries') Move data from
each ECCDB to an associated part of the new data area.
IRBMFDHP
5
IRBMFDHP DHEPILOG
~.
=
~
a::
a
[
e.
o
a
'C
5'
=
-~
w
Save the entry point for returning to the Epilog
segment.
";:.~
...w"fI
Diagram 7-18. Interval MG Routine for Channels (IRBMFDHP)
(put 3 of 4)
N
..
~
~
N
1
i
r-
- - --
Parameter List
---
:~
Epilog
Ji..
>
Initial Call Flag
II"
ea
6
If this is the initializing call of
this routine, return to MFDATA SVC
Processor; otherwise, proceed
to the next step.
7
Complete the SMF record image by
calculating data for this interval
from previous interval data.
8
If record is required, copy the
calculated data; otherwise, proceed
to the next step.
!
f
w
~N
,
~
Return to
MFDATA
Processor
(JGXOOO14)
r
w
,:,
f ..
Record Flag
>
!I"
DCSMFLEN
....)I1
l
I"
SMF Data Set
J
f
,to.
I
I
,..> 9
10
Obtain storage in TCB key, move
SMF record image into it, and
return the data address to
MFDATA SVC caller.
DCRETDTA
~cl Output Data Addr.
1"1
Free storage area that contains
previous interval data.
'~~&ih·
'-5\
W'~~lr1%1i'M1'iiltEiihiiii0L
Return to MFDATA
Processor (JGXOOO14)
J
Diagram 7-18. Interval MG Routine for Channels (IRBMFDHP) (part 4 of 4)
Extended Description
Module
Epilog
6
On the initializing call to the MFDATA SVC,
the MFDATA SVC Processor calls the interval MG
routine to obtain initial values of measurement data, which
IRBMFDHP
are required at the end of the measurement interval to calculate data for that interval. Processing ends here on that
call.
7
There is an SMF73B entry for each channel whether
or not it was detected online during the interval. At
this point, entries for chann~ls not online during the'interval are eliminated from the record image and remaining
entries are compressed together.
IRBMFDHP
8
The internal image of the SMF record is copied to the
SMF data set by use of the SMFWTM macro
instruction.
IRBMFDHP
9
IRBMFDHP
Use the GETMAIN macro instruction to obtain the
required storage in user key. Use the MODESET
macro instruction to switch to the user's (TeB) key.
10
Release the storage used for the internal image of
the SMF record, using a FREEMAIN macro
instruction.
fIl
ite·
::I
!':»
s:
t
fe·
2-
::I
~
CoN
CoN
Label
~
Diagram 7-19. Interval MG Routine for Devices (IRBMFDDP)
~
From MFDATA SVC
Mainline Processor
UGXOOO14) via CALL
o
~
Input
~
fI.)
'<
lQ.
STSMA (Devices)
;
~
i
~
Parameter List
+
r-'
J
..
i~
1
Process
Output
>~ol~
Interval MG Routine for Devices
(lRBMFDDP)
...
i~;
i~
J
1
Obtain storage area for new data.
2
Initialize and fix (in real storage) the --~.,------,.,i/I
new da'ta area and fix IRBMFDDP.
3
Save the entry point for the Move
routine (see the MO diagram for
MFDAT A SVC Processor).
~~MIA~
STSMA
STSMA
~
E'
(part 1 of 4)
SMF Header
a
(D
~
w
~
~
~
..
EDDED
r
From
IGXOO014
~
!
w
:..a
EDDESAMP
-
L1DDECDT
't:
-D
I
,
EDDCD
EDDCD
Move
~SMFRCD741
4 ~heck all device classes and move data
EDDDB
EDOCD
1
,r---
2
~
----zt.-------..,.....-- r--------..11 STSMENTR
t-----.......
4SMFRCD742
mto new data area.
• •
•
SMFRCD74 1
1
Device
Data
Block
SMFRCD742
1
I-.
•••
~
5
l
~
L7~z4
It
--
'v"
Save next entry point.
Returnto
~~~~~:{ocessor
--
',,-~
Diagram 7-19. Interval MG Routine for Devices (IRBMFDDP) (Part 2 of 4)
Extended Description
Module
Label
The Interval Routine for Devices (lRBMFDDP) receives con- IRBMFDDP
trol from the MFDATA SVC Mainline Processor OGXOOO14)
at the end of each interval if any device reports are required.
IRBMFDDP builds the internal image of one or more
device data SMF records (SMFRCD74; one record for each
class of device report requested) from data collected in
event control blocks by the device data event-driven sampling routine (lRBMFEDV). If requested in the input options,
IRBMFDDP copies the internal record images to the SMF
data set (via the SMFWTM macro instruction).
Prolog
1
Use the GETMAIN macro instruction to obtain the
required storage in key zero.
IRBMFDDP
2
Store the subpool and length of the storage obtained
into the first word of the area. Use the PGFIX macro
instruction to fix the data area and IRBMFDDP.
IRBMFDDP
3
IRBMFDDP DDMOVE
Save the entry point, as described in the M.O. diagram,
MFDATA SVC Mainline Processor (lGXOO014), for
use in returning to the Move part of IRBMFDDP.
Move
4
rn
!e'
::s
~
rc
a
5'
Co
2.
o
1
!
o
::s
~
~
Initialize the images of the SMF records. Check all
device classes (one class is associated with each
EDDCD), and move data from the Device Data Block
(EDDDB) entries and the Device Event Data Table (EDDED)
into the SMF74 record image corresponding to that device
class. If no devices exist for a class or if no measurements
are required for a class, the pointer for the SMF74
record image is set to zero.
IRBMFDDP
5
IRBMFDDP
Save entry for returning to Epilog segment.
!of
Diagram 7-19. Interval MG Routine for Devices (IRBMFDDP)
(part 3 of 4)
CN
0\
~
~
From
Input
IGX00014
II
~
rI'J
'<
~
~
oir)"
t""
Output
Process
~ ~~~~~~~~~~~~~~~
Parameter List
Initial Call Flag
Epilog
6
If this is the first time through this
routine, return to MFDATA SVC
Processor; otherwise, proceed to the
next step.
7
Complete the SMF record images
(one for each valid device class) for
this interval and move it into the
area that contained previous interval
data.
8
If RECORD is requested, write
the SMF record. Otherwise,
proceed directly to the next s t e p . )
J
~
~
('D
CN
'<
rI'J
~
~
i
~
CN
:...
Record F l a g " ' )
"'.:.,'
~ ~
·:.·;. ·. ,.1
.·
,";"~'
9
Obtain storage in TCB key (also
called user's key), move the data
images into it, and return the data
addresses to the caller
MFDATA SVC.
10
o f ; ,;.;
Free area containing the key zero
copy of the SMF record just moved.
Return to MFDATA
Processor UGXOOO14)
,;
1
SMF Data Set
,.9
I.:.:·, .· .·
.
'.:.'
I~
"
">':,
,.'
~<:.:t;
:/
Output Data
Addresses
~,_T
Diagram 7-19. Interval MG Routine for Devices (IRBMFDDP)
Extended Description
(part 4 of 4)
Module
Label
Epilog
6
On the initializing call to the MFDATA SVC, it calls
interval-driven MG routines to obtain a first set of
wrap-around measurements for use at the end of the first
interval in calculating values for that interval. Processing
ends here on that call.
IRBMFDDP DDEPILOG
7
IRBMFDDP
For each device class for which a device exists and for
which measurements are required, place the data for
the interval just ended in the record for previous interval,
overlaying previous data where necessary. For each SMF74B
record, which exists for a device whether or not it appears
at all online during the interval, the determination is made
of whether or not to keep it.
If no device measurements are associated with the SMF74B
record, the record is eliminated and the other records compressed. All the SMF74 records retained are sorted into
order of ascending device address.
8
Use the SMFWTM macro instruction to copy the internal images to the SMF data set.
9
Use the GETMAIN macro instruction to obtain the
required storage in user key. Use the MODESET
macro instruction to change to user key.
IRBMFDDP
10
IRBMFDDP
Use the FREEMAIN macro instruction to release
the storage obtained for the internal images of SMF
records.
rI'.l
CD
a
~.
=
~
a::
a
[
sa.
o
"0
!5·
=
~
~
-.J
IRBMFDDP
Cf
w
Diagram 7-20. MFROUTER SVC Processor (IRBMFEVT) (part 1 of 2)
00
o
~
From external Interrupt
Handler (lEAVEXS)
;i;~:~;~~~;·~~;~~~0~~~~~.:~L~~~'~'0~~~·!~'0.m~j~2~~!r>~<~t,~05A.~?r:~~·i~~~!i~b~~~·f*o/%1(~.j~!!m&¥~;*~4t
III
Process
~ ii:~:r~~~~~~~~~~~!1~~~~~~~~
Output
MFROUTER Processor
(lRBMFEVT)
N
fIl
i
i
f)
1
Obtain list of MG routines to be called
for this cycle.
2
Collect measurement samples as
required by input options.
3
Utilize exit routines:
t:
2"
~
~
[
(D
STMMMGRL
w
IRBMFEDV
IRBMFECH
IRBMFTCH
~
N
i
I
w
~
a. To cause timer interruption for
next cycle time to be reset and
return to caller,
MF/1 Global Supervisor
Table
'"
and/or
b. To return to caller.
Return to External
Interrupt Handler
(lEAVEXS)
~
Diagram 7-20. MFROUTER SVC Processor (IRBMFEVT) (part 2 of 2)
Extended Description
Module
The MFROUTER Processor (lRBMFEVT) calls the
event-driven MG routines and a routine to reset the MF/1
Timer Queue Element (TQE) after the time expires in the
TQE. The routines called are:
IRBMFEVT
•
•
•
•
Channel Event MG (lRBMFECH)
Second CPU Channel Event MG (lRBMFTCH)
Device Event MG (lRBMFEDV)
Timer Enqueue (I EAQTEOO)
1
Events are timer interruptions or remote pending
interruptions on CPU-to-CPU communications. Timer
interruptions are at the rate of sample time periods for
device and/or channel sampling. CPU-to-CPU communication interruptions are at the same rate, but are only caused
by one CPU requesting another to sample channel data.
fIl
(D
~
!'
1:1
~
a::
sa.
8'
Q.
SO
'0
i!'
1:1
Cf
~
\C
Label
Extended Description
Module
2
IRBMFECH
IRBMFTCH
IRBMFEDV
The MFROUTER Processor branches to the MG
routines in the order set up by their entry addresses
in the MFROUTER Vector Table (STMMV), which was
set according to entry options by MFSTART and modules
connected with MFSTART.
Label
3a
IRBMFEVT
If IRBMFEVT was entered in response to a timer
interruption, it branches last to a subroutine
(lRBMFEVE) to reset the timer (enque the TQE onto the
timer queue). The address of the subroutine is placed in
the MG routine loop (MFROUTER Vector Table) by the
MFSTART SVC Processor (lGXOO013).
3b
If IRBMFEVT was entered in response to a CPU-toCPU interruption, it branches last to a subroutine
(lRBMFEVL) to restore status and return to the caller of
IRBMFEVT.
IRBMFEVE
IGXOOO13
IRBMFEVT IRBMFE
...
Diagram 7·21. Channel Sampling Module (IRBMFECH)
~
Input
~
~
From
MFROUTER SVC
Processor (lRBMFEVT) via BAL
(part 1 of 2)
Process
,
w
Ii
PCCA
i
r-c
IJ
i
-- -
PSA
~
1
-
~
~
-
ECCDB i
...
iw
>
2
'<
-
a.
I
PSATOLD
.-
For all channels of all CPUs, sample
the number of start I/O instructions,
and either:
Remote Pendhlg IRBMFEVT
IPC Interruptio~ MFROUTER
a. If the CPU is not the one
VC
executing these instructions,
Processor
signal the CPU to collect channelbusy and CPU-waiting-for-channel
indications on all its channels.
JII
-
ECCPE List
.-
ECCPE1
ECCPE2
•••
ECCPE n
,.
-
b. If the CPU is the one executing
these instructions, check for
channel-busyand CPU-waiting,
Update appropriate counters.
~ ------
r-
-
-
-
.-.
"
..
--
""'"
ECCDB i
...
...
~
ECCDSIOS
)I
.
II
w
~
...
.
fIj
~
ECCESAMP
~
¥
w
...
..
Add one tQ the number samples taken .
~
-
.-
ECCED
,,--...
ii~
PSACPUPA
2'
Channel Sampling Module
(lRBMFECH)
.-
PCCACAT
1;'
Output
-
-
ECCDBUSY
-
-
...
ECCDOLAP
-,.
;
ECCDB List,
~
ECCDB1
)-
...
~
ECCDB
¥
2
3
If this is time for a configuration check,
make the check and post results.
ECCDB n
\
ECCDB Lis~
-
.....
ECCDB 1
ECCDB
2
•••
ECCDB n
L-
-
ECCDB Flags
i
-
-
:¥tl
-
r--
..
.....
•••
~
....
--
Return to
MFROUTER SVC
Processor (lRBMFEVT)
". J
~~
Diagram 7-21. Channel Sampling Module (IRBMFECH)
~
~
~
e'
=
~
~
~
8:
So
o
"0
~
a
o·
=
-~
~
(part 2 of 2)
Extended Description
Module
The Channel Sampling Module (lRBMFECH) receives control from MFROUTER SVC Processor at each cycle sample
time. IRBMFECH collects the channel measurement samples
lOS provides and monitors channel status with regard to the
channels being online or offline.
IRBMFECH
1
The Channel Sampling Module increases counter
ECCESAMP in the Channel Event Data Table
(ECCED).
IRBMFECH
2
IRBMFECH
IRBMFECH checks channels through CPU Entry
Tables (ECCFE), which contain a pointer to a Channel
Data Block (ECCDB) list for each CPU. If item ECCDVAlD
in the CDB is on, that CPU was online at one or more configuration checks, and therefore, IRBMFECH obtains the
count of Start I/O (SIO) instructions issued to the channel.
This count of SIOsis obtained from the Physical Configuration Communication Area (PCCAI.
..
label
Extended Description
2a
IRBMFECH signals the other CPU with the RPSGNl
macro instruction, with the PCCA address in register 1.
Module
IRBMFECH
2b
IRBMFECH uses entries from the Channel Availability Table (CAT) to increase the count of Start
I/O (SIO) instructions since the last sample. If this channel
is not offline and is not a byte multiplexor, IRBMFECH
issues a TCH instruction to test whether the channel is now
busy. If the channel is busy, the routine adds one to the
count of busy samples. If the CPU was waiting when
MF/1 was given control, IRBMFECH adds one to the
count of CPU waiting and channel busy (ECCDOLAPI.
IRBMFECH
3
IRBMFECH
The Channel's Configuration is checked if the number
of samples taken is multiple of the configuration
check field. If the CPU is online, set appropriate flags
in the ECCED. If a change in configuration has occurred
since the last check, the routine sets appropriate flags.
label
'7
-•
'of
Diagram 7-22. Second CPU Test Channel Sampling Module (IRBMFTCH) (part 1 of 2)
~
o
~
From MFROUTER
SVC Processor via
..
- t
~
..
!f
ECCPE
oi;.
j
~
-
----
-
.51
,
a
..
1
Obtain a pointer to a Channel Data
Block (ECCDB) for a channel of the
CPU.
~
...")
2
If the channel is valid, was online at
the last cycle, and is not a byte
multiplex channel, test whether the
channel is busy. If it is not to be
tested, return to step 1.
..
.
ECCDFLGS
fD
~
.....
,
v
-
",.
~
ifI'"
-
I
ECCDB
E"
w
Second CPU Test Channel Sampling
Module (lRBMFTCH)
"
,
~
p
.
;
TCWRKRG1
...
w
3
-
-
If the channel is busy, add one to the
busy count for this channel.
If it is not busy, return to step 1.
,
';,,·"/:·:;:l;'i:l:
'<.
:...,
PSA
:
Result of
test channel
instruction
y
"
ECCDB
.....
.
ECCDBUSY
y
~
PSATOLD
-
~
CVT
-
--
CVTWTCB
--
~
.....
")
y
:
"v
EDDDB flags
.....
-
.....
.,..
"'~-~
Diagram 7-23. Device Sampling Module (IRBMFEDV) (part 2 of 2)
Extended Description
Module
The Device Sampling Module (lRBMFEDV) receives control
from the MFROUTER SVC Processor (lRBMFEVT) at each
cycle sample time. IRBMFEDV gathers sample data on the
use of 1/0 devices, as maintained by 105.
IRBMFEDV
1
IRBMFEDV
The Device Sampling Module increases counter
EDDESAMP in the Device Event Data Table (EDDED).
2
The Device Sampling Module checks the Device Class
Data Table (EDDCD) entry for devices that exist in
that class. Nonzero entries in the EDDCD point to one or
more Device Data Blocks (EDDDB) for that class. Each
EDDDB entry points to a Unit Control Block (UCB), which
contains data with which to add to the following wraparound counts in the EDDDB:
IRBMFEDV
a. EDDDSIOS, which is the current number of SIOs for that
device in this interval.
b. EDDDBUSY, which is the current number of samples,
in which the device was busy.
c. EDDDNENQ, which il the current number of SRBs
enqueued on this device.
3
ie'
::I
~
a::
!.
[
Sa
o
1a.
e'
::I
~
".
7 Indicate that this is the last subtask
to complete processing .
~
I
CPU Interval Data
~
Last Subtask
~
.
"
I
II.
I
Workload
Interval Data
II
I
Data
I
Devices Interval
Data
"..
1'1
Paging Interval
Data
~ Channels Interval
...:~I
MFPCALST
..
I
I
I
""> 8
' r
Free interval data storage areas
and interval data measurement
vector table area .
I
(Measurement
Vector T
MFCOA
r-MFCOREP
~
;
-
1
;,
>
(Common OPt~
,
,..> 9 If report option is REALTIME,
!r
send message to operator that
report is ready to print.
RGREALTM
Realtime Flag
"
..,.,
"'
I
I
I
10
Delete the established recovery
routine.
Return to MFDATA SVC
Mainli ne Processor
OGXOO014)
...
.~:;;;
Message
Processor
(lRBMFMPR)
-
Diagram 7-24. Report Generator Control (IRBMFRGM) (part 4 of 4)
Extended Description
Module
7
IRBMFRGM
The identity of the last subtask to terminate is updated
to establish serialization of reports on the printer.
8
The main storage for this interval's data is not needed
after the required reports are written on the SYSOUT
data set.
IRBMFRGM
9
The operator message is MF1 REPORT AVAILABLE
FOR PRINTING.
IRBMFMPR
Cancel the previously established ESTAE routine.
IRBMFSAR
10
ERROR PROCESSING: If an error occurs while a report
is being written, another attempt is made to write all reports. A second error, or an error occurring prior to report
writing, will cause an ABEND,
C"'-l
a
5'
=
I-.j
~
sa.
[
S-
o
'tS
~
i
5'
=
'of
~
I.Q
Label
~
~
Diagram 7-25. Report Generators for CPU, Paging, Workload, Channels, and Devices
(IRBMFRCR, IRBMFRPR, IRBMFRWR, IRBMFRHR, and IRBMFRDR) (part 1 of 2)
o
CIl
~
~
From Report
Generator Control
(lRBMFRGM) via CALL
..
Input
CIl
~
e
~
~.
lt
~
~
Input
Parameter
~
2"
(D
w
'
,
fData
_
.~
PMAOPT
.y
'<
SMF
Record
~I
1
.") 2
~
3
:;"
t
r-DDDVJ:"
,.
Device
report
only
Insert page header and data column
headings into internal page image.
DDDVT
Device
Vector
Table
~
MFHDRISR
Insert
Header
...
Convert binary data from SMF
records to BCD in character
strings, compute entry values, and
insert into internal page image,
along with any required line
headings.
.,.
.
,
,,""',*'*',,'"-,
IRBMFCNV
Convert
Binary to
BCD
...
'-l\
:l 3
!
;K<"",;'
Write formatted internal page
image to Sysout data set and
then blank the internal page.
~'
~
...
IRBMFRGM
Set of pages
represents one
report
MFISRTXT
Insert Text
...
• STWVT
IRBMFRGM
~
"
,y
CIl
w
---.
J-.
L
...
~
i
Output
Report Generators for CPU, Paging,
Workload, Channels, and Devices
URBMFRCR, IRBMFRPR, IRBMFRWR.
IRBMFRHR, and IRBMFRDR)
IRBMFRWR
Only
t"'"
a
Process
....
~;
~
+STWVT
Workload
report
only
b
Workload
Vector
Table
--..
except
'C
IRBMFRGM
~
...
MFWRTPAG
Write Page
...
Typical Inputs; See "Explanation" for
differences for workload report, and
device report.
;
~::;i+;','<
,-""
i.M"',_",_,
-'i',
",'
~[\~
v
!i'
!
Return to Report
Generator Control
(lRBMFRGM)
device data
which has:
One set of
' pages for a
..... , report of
{::
"
-
.'i'IJ{.","
''&~i,
~
-
~moo~
type
-
Diagram 7-25. Report Generators for CPU, Paging, Workload, Channels, and Devices
(IRBMFRCR, IRBMFRPR, IRBMFRWR, IRBMFRHR, and IRBMFRDR) (part 2 of 2)
Extended Description
Module
Label
This M.O. diagram covers the five report generator modules:
• CPU Activity (lRBMFRCR)
IRBMFRCR
• Paging Activity (lRBMFRPR)
IRBMFRPR
• Workload (lRBMFRWR)
IRBMFRWR
• Channel Activity (lRBMFRHR)
IRBMFRHR
• Device Activity (lRBMFRDR)
IRBMFRDR
Each report generator formats interval data for its report
type and writes it to a SYSOUT data set for either REALTIME or deferred printing.
IRBMFRGM MFHDRISR
2
After the page and column headers are written, the
report generator extracts data from the SMF record
image, manipulates it, and writes entries into the internal
image of the report page. Parameter MFPMAOPT is used
only for the workload report to determine the depth of
workload reporting.
The report generator routine calls routine IRBMFCNV to
convert a signed binary number into its equivalent as a character string. The resulting string is supplied as a fixed length
string parameter. The following are provided as input parameters (starting address in register 1) to IRBMFCNV:
til
('D
~
e'
::s
~
a:
~
5
Q.
e.
o
"'CI
~
e'
::s
~
~
a) the input signed binary value.
b) the signed decimal scaling factor for the input value.
c) the address of the output string.
d) the length of the output string.
e) the no. of digits to the right of the decimal pt.
f) commas or no commas.
g) floating point or no floating point.
If commas in the output could cause loss of significant
digits, they are not inserted. If the output string is shorter
than necessary, commas are removed first. If the output
string still cannot accept the entire value, least significant
digits to the right of decimal point are next removed, up
to and including the decimal point itself. If this action is
sufficient, the return code is 4; otherwise the entire field is
filled with asterisks and the return code is 8. If the output
string is larger than necessary, it is right justified. The insert
text routine is used to put data into the RGM internal page
image.
3
1
Each report generator subtask calls procedure
MFHDRISR whenever a header is to be written on a
new page (see note after step 3).
Extended Description
Subroutine MFWRTPAG writes the internal page
image, line by line, to the SYSOUT data set using a
OSAM PUT. Blank lines are consolidated, and a single
record is written with carriage control characters indicating
the number of lines to skip.
Module
IRBMFRGM MFISRTXT
IRBMFRGM MFWRTPAG
Note: Input data formats differ among the five report
generators:
IRBMFRGM MFISRTXT
IRBMFCNV
Label
• CPU, paging, and channel report generators each receive
a single SMF record image and each produce a single
report.
IRBMFRCR
IRBMFRPR
IRBMFRHR
The device report generator receives a fixed length list of
SMF record images and produces a report for each one.
There is input data for each defined device type unless the
corresponding Device Vector Table (DDDVT) entry is zero.
IRBMFRDR
The workload report generator receives a variable length
list of SMF record images, preceded by a count, and produces a single report. There is input data for each performance group number (PGN) unless the corresponding
Workload Vector Table (STWVT) entry is zero.
IRBMFRWR
3-152 OS/VS2 System Logic Library Volume 3 (VS2 Release 3.7)
Job Scheduling Overview
The following four figures illustrate the relationship
among some of the job scheduling subcomponents
(Details of module-to-module flow within a
subcomponent are in 'Section 3: Program
Organization. '):
• Figure 2-11 shows the first use of job
scheduling code: master scheduler
initialization attaches the initiator to start the
master scheduler. The initiator attaches
IEEMB860, which continues the initialization
process and finally passes control to the
master scheduler wait module. Starting the
master scheduler in this manner allows several·
system and TSO data sets to be allocated
normally. These data sets are then available
during the last portion of master scheduler
initialization. Note that the master subsystem,
rather than a job entry subsystem, converts
and interprets the master scheduler's JCL. For
more information on master scheduler
initialization, refer to OS / VS2 System
Initialization Logic, SY28-0623.
• Figure 2-12 shows the second use of job
scheduling code: the START command for a
job entry subsystem is processed. This START
command was in the master scheduler JCL
that was interpreted during the initiation of
the master scheduler. Note that the master
subsystem, rather than a job entry subsystem,
converts and interprets the job entry
subsystem's JCL. The master subsystem starts
job entry subsystems and also starts
subsystems defined by the installation. For
more information on the master subsystem,
see 'Master Subsystem' in this section.
• Figure 2-13 depicts general
START /LOGON/MOUNT processing. This
processing begins with a START, LOGON, or
MOUNT command and culminates in the
attach of an initiator, a terminal monitor
program (TMP), the MOUNT processor, or a:
started system task (TCAM, for example). A
new address space is created for each START,
LOGON, or MOUNT command. The value of
the new address space ID (ASID) is at least
four (master scheduler's ASID is one; auxiliary
storage manager's ASID is two; and the
primary job entry subsystem's ASID is three). •
• Figure 2-14 shows how a normal job enters
I •
the system and is attached as a problem
I
program by the initiator. A new address space
is not created for each job entering the
system; a job executes in the address space of
the initiator that attached it. When the job
entry subsystem first receives a job's JCL, it
stores it on the spool data set. It then passes
the JCL through the converter and puts the
resultant internal text in another data set.
When initiator requests the selection of a job
(via the subsystem interface), the job entry
subsystem chooses a job and passes the
already-existing internal text through the
interpreter, creating SW A control blocks. The
initiator can now continue with the initiation
of the job.
Section 2: Method of Operation
3-153
7
LINK from IEAVNIPX
IEEVIPL
Master
Scheduler
Base
Initialization
~ ___ {For detail, refer to System
. Initialization Logic, SY28-0623.
SYS1.LINKLIB
!ATTACH
IEFSDI60
~
",-
Subsystem
Interface
Data Areas
r-----------
~
IEFSD161
'-
A
IEFJSUBI
-
"""""
~
~
~
..../
I-
,-MSTR JCL~
,.
I
I
Master
....,/
Subsystem
(Job entry
~----------------------~I~~ JCLS
subsystem not:
, "'--~-.--available.)
Initiator
IEFVH1
- -
ATTACH
A
I
""
I
...
ViaSVC34
Converter
r
CSCB for Starti ng
Job Entry
Subsystem
IEFIB600
-
LINK
...
-
SWA Create
Interface
Internal
Text
J LINK
IEFNB903
IEFW21SD
......-IE-F-S-D-1-62-~ ,.BALR...
----~-
-
......
Interpreter
Device Allocation for:
...
...
SWA
Control
Blocks
I
L _________ ..J
A
r-
ATTACH
I EEMB860
Malter
Scheduler
Region
Initialization
For detail, refer to
~
- - -
System Initialization
Logic, SY28-0623.
-U
XCTL
IEAVEMCR
IEEVWAIT
-
Master
Scheduler
Wait
Note: Refer to the index for the page numbers of function diagrams
(hipos) that describe the functions of particular modules.
Figure 2-11. Job-Scheduling: Initiation of the Master Scheduler
3-154
r
I
internal readers
(TSOINRDR and
STCINRDR)
SYS1.PROCLIB
SYS1.PARMLIB
SYS1.UADS
SYS1.BRODCAST
SYS1.MANX
SYS1.MANY
IEFSD263
!
I
OS/VS2 System Logic Library Volume 3 (VS2 Release 3.7)
--
"" ATTACH
...
Start the
job entry
subsystem
r- ___rFor detail,
~ee Figure 2-12
Y
XCTL from IEEMB860
IEEVWAIT
Master
Scheduler
Wait
+
ATTACH
IEAVEMCR
Address
S~~
Creation
t------
{ The region control task is the first
task dispatched in the newly -created
address space. (The ASID for the job
entry subsystem is 3.)
IEAVAROO
Region
Control
Task
~ ATTACH
IEEPRWI2
Started
Task
Control
IEFJSDTN
..
IEESB605
...
Subsystem
Interface
LINK
-.
I
Yes
-
IEFSD160
IEFSD161
Is a subsystem
being
started ?
...
-
IEFJSUBI
Subsystem
Interface
,.
Master
Subsystem
(Job entry
subsystem not
available.!
-.
-
Converter
IEFIB600
--
LINK
Initiator
IEFVH1
ATTACH
,.
--..
SWA Create
Interface
fUNK
IEFW21SD
BALR
IEFSD162
-
..
Device
Allocation
IEFNB903
Interpreter
IEFSD263
~ ATTACH
Job Entry
Subsystem
Figure 2-12. Job Scheduling: Initiation of the Job Entry Subsystem
Section 2: Method of Operation
3-155
. . ._a.aM• ..,:;:
CSCB + POST
Master
Scheduler
Wait
IEEVWAIT
Memory
Create
IEAVEMCR
.- ATTACH
~
- - - -,--
----~--
-- -
ASID
-
-
=1
---
ASID? 4
Region
Control
Task
IEAVAROO
ATTACH
SVC
Dump
Task
IEAVTSDT
...
ATTACH
WAIT
Started
Task
Control
IEEPRWI2
XCTL
(for LOGON)
IKJEFLA
TXCTL
(for STARTI
• MOUNT)
I
LOGON
Scheduling
IKJEFLB
Started Task
Control
IEEVSTARI
IEEVMNT1
XCTL
ATTA~
Started
Task
Control
IEESB605
Subsystem
Interface
~
~----~-~----------~~
~
Primary
Job Entry
Subsystem
_ LINK
Subsystem
_
-Interface
'---~.--.....,r---_J
-----'
LINK
Converter
IEFVH1
_
po
SWA Create
IEF IB600
~
IEFSD160
Initiatorl
Terminator
IEFSD263
____________________________________..J
~
~ BALR
ATTACH
•
•
•
•
For START INIT:
For LOGON:
For MOUNT:
For other STARTs:
Allocation
IEFW21SD
Initiator (lEFSD160at IEFIIC).
Terminal Monitor Program (lKJEFT011.
MOUNT Processor (lEEVMNT2).
Started system task.
Figure 2-13., Job Scheduling: START/LOGON/MOUNT Initiation
3-156
LINK
~
OS/VS2 System Logic Library Volume 3 (VS2 Release 3.7)
,
Interpreter
IEFNB903
User
Program
Job Entry
Subsystem
Converter
IEFVHI
~\
!
/
Subsystem
Interface
Initiator
(For START
INIT
processing,
see Figure
2-13.)
LINK
Job Entry
Subsystem
LINK
SWA Create
IEFIB600
LINK
LINK
Allocation
IEFW21SD
Interpreter
IEFNB903
ATTACH
Problem
Program
JOB
Figure 2-14. Job Scheduling: Normal Job Entry and Initiation
Section 2: Method of Operation
3-157
3-158
OS/VS2 System Logic Library Volume 3 (VS2 Release 3.7)
Subsystem Interface
The subsystem interface is the means by which
OS/VS2 system routines request services of either
the master subsystem or a job entry subsystem. To
request subsystem services, a system routine issues
the IEFSSREQ macro instruction after placing the
correct function code in the SSOB and placing the
name of the desired subsystem in the SSIB. The
macro instruction causes control to pass to the
subsystem interface routine, IEFJSREQ. The
specified function code and subsystem name tell
the interface routine which subsystem routine gets
control. Figure 2-15 lists all existing function
codes, their meanings, and the subsystem modules
that get control.
A job entry subsystem performs functions
related to entering jobs into the system. For
example, it handles SYSIN and SYSOUT data sets; it
also passes a job's JCL through the converter and
interpreter, thus creating SWA control blocks for
the job. See 'Job Scheduling' in this section.
On the other hand, the master subsystem does
not handle normal jobs. It is used by the system to
start the master scheduler and subsystems. A
subsystem can be a job entry subsystem (JES2, for
example) or another subsystem defined by the
installation. Once a job entry subsystem is initiated
and ready to accept jobs, the master subsystem is
no longer needed for initiation processing.
However, if an installation wishes to replace the
active job entry subsystem with another version (or
to start another subsystem), the master subsystem
must be used to start this new version (or the new
subsystem) .
In addition to starting subsystems, the master
subsystem broadcasts requests to all active
subsystems. (See note at bottom of Figure 2-15.)
For a detailed description of the master subsystem,
refer to 'Master Subsystem' in this section. JES2, a
job entry subsystem, is described in OS / VS2
JES2 Logic, SY28-0622.
•
Section 2: Method of Operation
3-159
"f
01
Q
Function
Code
SSOB
Subsystem Function
Extension 10
Subsystem
Module Name
Module Label
Pri mary Caller
SO
Process SYSOUT data sets.
JES2
JES3
HASPSSSM
IATSIOP
HOSSOUT
IATSIOP
TSO OUTPUT
TSO OUTPUT
2
CS
Cancel a job.
JES2
JES3
HASPSSSM
IATSICN
HOSCANC
IATSICN
TSO CANCEL
TSO CANCEL
~
3
CS
Find the status of a job.
i
JES2
JES3
HASPSSSM
IATSIST
HOSSTAT
IATSIST
TSO STATUS
TSOSTATUS
4
ET
Notify the subsystem of end-of-task.
Master
IEFJRASP*
JES2
JES3
HASPSSSM
IATSIJS
HOSEOT
EOT
Subsystem job selection. (Provides a job that has a
complete SWA.)
Master
JES2
JES3
IEFJJOBS
HASPSSSM
IATSIJS
HOSJBSL
IATSIJS
IEFSD161
IEFSD161
IEFSD161
Allocation of SYSI N/SYSOUT data sets (and internal
readers')
Master
JES2
JES3
IEFJDSNA
HASPSSSM
IATSIDM
HOSALLOC
IATSIDMA
Allocation
Allocation
Allocation
Unallocation of SYSI N/SYSOUT data sets (and internal
readers.)
Master
JES2
JES3
IEFJDSNA
HASPSSSM
IATSIDM
HOSUNAL
IATSIDMU
Unallocation
Unallocation
Unallocation
Notify subsystem of end-of-address space.
Master
IEFJRASP*
JES2
JES3
HASPSSSM
IATSIJS
HOSEOM
EOM
Master
JES2
JES3
IEFJRASP*
HASPSSSM
IATSIWO
HOSWTO
IATSIWO
Master
JES2
JES3
IEFJRASP*
HASPSSSM
IATSI34
HOSCMND
IATSI34
0
~
<
('I)
N
('I)
'<
=l""'
;:
...
~
<
0
C
9
(D
5
JS
1M
<
('I)
N
6
AL
i'"
~
1M
7
AL
~
8
9
10
EN
WT
CM
Notify subsystem of a WTO message.
Notify subsystems of an operator command.
SVC87
Subsystem interface resource
manager
SVC 35
SVC 34
11
US
Request subsystem to validate a remote destination userid.
JES2
JES3
HASPSSSM
IATSIVL
HOSUSER
IATSIVL
TSO LOGON, Unallocation
TSO LOGON, Unallocation
12
JT
Notify the subsystem of job termination.
Master
JES2
JES3
IEFJJTRM
HASPSSSM
IATSIJS
HOSTERM
JOBTERM
IEFSD166
IEFSD166
IEFSD166
* IEFJRASP broadcasts the indicated request to all active subsystems.
Each active subsystem then performs the requested function.
Figure 2-15. Subsystem Interface Summary (part 1 of 3)
--
~~
"'-_7
I"
Function
Code
SSOB
Extension 10
Subsystem Function
Subsystem
Module Name
Module Label
HOSRENO
JOBREO
13
RO
Request subsystem to re-enqueue a job.
JES2
JES3
HASPSSSM
IATSIJS
14
OM
Notify all subsystems of a delete operator message (DOM)
Master
IEFJRASP*
JES3
IATSIDO
Primary Caller
IEFSD166
IEFSD166
Subsystem interface resource
manager
IATSIDO
15
VS
Request master subsystem to verify a subsystem name.
Master
IEFJSDTN
STC
16
DA
Open a subsystem data set.
JES2
JES3
HASPSSSM
IATSIDM
HOSOPEN
IATSIDMO
OPEN
OPEN
17
DA
Close a subsystem data set.
JES2
JES3
HASPSSSM
IATSIDM
HOSCLOS
IATSIDMC
CLOSE
CLOSE
18
DA
Checkpoint a subsystem data set.
JES2
JES3
HASPSSSM
IATSIDM
HOSCKPT
IATSIDMK
Checkpoint
Checkpoint
19
DA
Restart a subsystem data set.
JES2
JES3
HASPSSSM
IATSIDM
HOSREST
IATSIDMR
Restart
Restart
20
RR
Request job id.
JES2
JES3
HASPSSSM
IATSIJS
HOSREOID
REOJBID
System Log
System Log
21
RR
Return job id.
JES2
JES3
HASPSSSM
IATSIJS
HOSRETID
RETJBID
System Log
System Log
22
SI
Notify subsystem of step initiation.
JES3
IATSIBS
IATSIBS
IEFSD162
23
DY
Dynamic allocation.
JES3
IATSICA
IATSIDA
Dynamic allocation
24
CA
Common allocation.
JES3
IATSICA
IATSICA
Allocation
25
CU
Common unallocation.
JES3
IATSICA
IATSICU
U nallocation
26
DO
Change DDNAME.
JES3
IATSICA
IATSIDD
Allocation
()
g.
27
NO
Change ENO use attribute.
JES3
IATSICA
I ATS IDO
Allocation
=
28
DR
DDR device candidate selection.
JES3
IATSIDR
IATSIRC
DDR
a::
29
DR
DDR device candidate verification.
JES3
IATSIDR
IATSIRV
DDR
30
DR
DDR UCB swap notification.
JES3
IATSIDR
IATSIRS
DDR
C"J'.I
(D
~
a
6'
Q
....
Q.
0
'e
(D
IiJ
g.
=
--
* IEFJRASP broadcasts the indicated request to all active subsystems.
Each active subsystem then performs the requested function.
tf
0\
Figure 2-15. Subsystem Interface Summary (part 2 of 3)
~
0\
W
~
~
w
~
Function
Code
SSOB
Extension 10
Subsystem Function
Subsystem
Module Name
Module Label
Primary Caller
31
DR
ooR swap completion.
JES3
IATSIDR
IATSIRE
ooR
32
CF
Failing START command.
Master
JES3
IEFJRASPIATSISF
IATSISF
SVC 34
=-B
33
WT
Notify subsystem of console switch. --
JES3
IATSIWO
IATSIWO
IEAVSWCH
i-
34
WT
Notify subsystem of WTL message. --
JES3
IATSIWO
IATSIWO
SVC36
f
E'
-IEFJRASP broadcasts the indicated request to all active subsystems.
Each active subsystem then performs the requested function.
--Functions 14, 33, and 34 are not supported by JES2.
~w
Figure 2·15. Subsystem Interface Summary (Part 3 of 3)
<
o
iw
f
w
~
)
Section 2: Method of Operation
3-163
~
Diagram 8-1. Subsystem Interface (IEFJSREQ)
(part 1 of 4)
~
~
ofIl
~N
.~
From a system
routine requesting a
t
p
OutDut
subystem se.
rv;....
. .m
fIl
'<
:l
Subsystem Interface
R1
fa
11
b'
~.
f
_
+SSIB
E'
a
(11
w
~
iC
w
:....
•
Valid SSOB pointe, ?
CVTTCBP
_--....~TCB
0
1 JSCB
~
I
SSIB
Y
I
1~----SSIB
V
~+---........
•
·
Valid SSIB pointer in
SSOB or in JSCB ?
Valid length and format for
SSOB and SSIB ?
"
.
.
.
r:==;.> 2
i
c'SS name'
job 10
\
i~:.
No
'S
No
.
R 15
r-:-"';;"-20----'1
~
::::,n to
Not found
CVTJESCT
R15
..... , . . . - - - - - - -
12
Find the subsystem CVT (SSCVT)
for the requested subsystem.
no SSCVT
-1.
\
...
invalid request -
CVT
' - ___
I
R15
,...---1-6----1
:~
;~
'-------' ')
CVT
. ••
t
k~
Check validity of request.
function code
~
i
1
( SSOB
~
~N
~
r
Y
No
....
-
~
r""""
return to
caller
w
JESCT
1
~
-. SSCVT chain
~
c'SSname'
~~ I--.II___--.J
~
~~-----~
I I
~
I
1
,,~
Diagram 8-1. Subsystem Interface (IEFJSREQ) (part 2 of 4)
F~tended
Description
Module
The subsystem interface handles requests for services to be
IEFJSREQ
performed by a job entry subsystem or the master subsystem. When a system routine issues the macro instruction
IEFSSREQ, the subsystem interface gets control. It determines which subsystem is requested and which function
routine in that subsystem is to be executed. The initialization
of the subsystem interface is described in OS/VS2 System
Initialization Logic, SY28-0623.
1
The requestor creates an SSIB and SSOB before
invoking the subsystem interface: the SSIB identifies
the subsystem requested, and the SSOB identifies the subsystem function routine that is to be executed. The subsystem interface ensures that the requestor made no errors
in its request. If the SSOB has a zero SSIB pointer, the subsystem interface uses the SSIB pointer in the current JSCB.
IEFJSREQ
2
There is one SSCVT for each subsystem defined at
system generation time. The four-character subsystem name in each SSCVT is compared to the subsystem
name in the SSIB. If a match is found, the subsystem name
in the SSIB is valid.
rI'J
a
e'
=
~
a::
i
~
f
e'
=
~
~
IEFJSREQ
Label
~
Diagram 8-1. Subsystem Interface (IEFJSREQ) (Part 3 of 4)
0'1
0'1
~
~
~
f'-)
Input
'<
~
a
i
SSOB
R15
no SSVT found
ction code I
"ql
()
3
t""
i
Obtain address of the subsystem
routine which performs the
function requested.
",i
8
h
R15
16
~
~
w
<
f'-)
~
~
R15
4
pointers to
function
routines
request cannot be processed
i
~
RO
w
~
return to
caller
4
Give control to the function
routine.
t
SSCVT
R1
1+
SSOB
R15
To the req uested
subsystem function
routine
If
function
ro~
I
'~
Diagram 8-1. Subsystem Interface (IEFJSREQ) (pad 4 of 4)
Extended Description
Module
3
If the SSVT pointer in the SSCVT (the SSCVT
located during Step 2 above) is zero, the subsystem
has not been initialized yet and therefore is inactive. If
the SSVT exists, it is used to find the address of the subsystem function routine.
IEFJSREQ
In the SSOB is the function code, a number between 1 and
256, which refers to a single byte in the SSVT's function
matrix. The number 1 refers to the 1st byte in the matrix,
2 refers to the 2nd byte. and so on. The matrix byte contains a value that is an index into the list of entry point
addresses for the subsystem function routines. A value of 1
refers to the 1st address. a value of two refers to the 2nd
address. and so on. A value of 0 in the matrix byte indicates
that the function is not supported by this subsystem~
4
Finally. the subsystem interface passes control to the
subsystem routine at the address obtained in Step 3
above. When the subsystem routine completes its processing. it returns directly to the system routine that requested
the service.
f:I)
g
g.
=
.....
iC
('II
[
e.
o
."
i<5.
=
~
0\
-...I
IEFJSREQ
Label
3-168 OS/VSl System Logic Library Volume 3 (VSl Release 3.7)
Master Subsystem
The master subsystem is a collection of routines
that perform functions required to initiate certain
system tasks. Job scheduling normally initiates a
task or a user job using the services of a job entry
subsystem to obtain and interpret the job's JCL.
But, certain system tasks are initiated when a job
entry subsystem is not available. These tasks
include the master scheduler, which is the first
initiated task in the system, and job entry
subsystems. In fact, any subsystem defined as such
at SYSGEN time is initiated via the master
subsystem rather than via a job entry subsystem.
The converter and interpreter, when invoked by
the master subsystem to interpret the JCL for a
task, do not use the normal access method (VSAM)
to read and write the JCLS and internal text chains;
rather, they use the pseudo access method. The
pseudo access method manipulates data located in
real storage, whereas VSAM manipulates data
located in external storage. Since the pseudo access
method uses the standard RPL/ ACB interface, the
converter and interpreter can use the pseudo access
method as if it were VSAM.
The master subsystem performs additional
functions related to initiating subsystems:
subsystem determination, common request routing,
data set name assignment, and subsystem
termination. These functions, as well as subsystem
initiation itself, are invoked via the subsystem
interface.
•
Section 2: Method of Operation
3-169
3-170 OS/VS2 System Losic Library Volume 3 (VS2 Release 3.7)
.~
Master Subsystem
(no diagram)
I
I
~
Common Request
Router
(lEFJRASP)
~
I
~
~
Data Set Name
Assignment
(lEFJDSNA)
Subsystem
Initiation
(lEFJJOBS)
Subsystem
Determi nation
(lEFJSDTN)
~
Converter Interpreter
Interface
(lEFJCNTL)
r---------,
I
I
Converter /I nterpreter
interface to SWA
create
(no diagram)
I
I
IL ________ ...JI
fIl
(D
g.
Pseudo Access
Method
(lEFJACTL)
:=
~
~
[
e.
o
~
I-
:=
-~
....
Figure 2-16. Master Subsystem Visual Contents
Subsystem Initiation
Message Writer
(lEFJWTOM)
I
L§
Subsystem Job
Termination
(lEFJJTRM)
~
.N....
o
~
Diagram 9-1. Common Request Router (IEFJRASP) (part 1 of 2)
From a system routine
Input
via the subsystem
. . . . .~_)I.i•••tSii~·~stttiliEit.Q\~tr!f11 interface
~~
t'rocessing
I!t:" '~r~<~ vt",~ ,~,~.% ~ .j;! !:·i;W! l&:.i"'~ ~:~j:~;~X:;'· ;."!'; : ."'l',!\I!"!'·/~#%: \! ?L!" \.:!" ·E"'F.0"'~\0"«~Z!'!:·:;·>"'~5"':'Z~.·~\..!";:":"'f)!"".iL"'!.:jl!l!}#~'P«¥:!!;-~o"'+"'f.7~"!!;;;I!l!:?:"'~!II!~~:j
:
UEFJSREQ)
N
fIl
'<
f!'4.
Common Request Router
;
SO
~.
SSOB
t:
I
SSOBFUNC
~
;:
~
w
SSIB
1
Route the specified request
(SSOBFUNC) to all active
subsystems, one at a time,
via the subsystem interface.
SSOBSSIB
SSOBFUNC
~N
i
SSIBSSNM
~
w
:..,
Repeat call for
each active
subsystem
Name of
subsystem
being invoked
SSOB
ISSOBRETN
from
interface
2 •
•
Save the lowest return code
from the subsystem interface.
, ,
Save the corresponding
subsystem return code.
Return to the
system routine
I
from subsystem
~=-
Diagram 9-1. Common Request Router (IEFJRASP) (part 2 of 2)
Extended Description
Module
The common request router, a function of the master subsystem, routes a single request to all the active subsystems
except the master subsystem. This request may be for command processing, for notification of address space or task
termination, for WTOs, and for DOMs.
IEFJRASP
1
The common request router obtains the numerical
code of the requested function from the SSOB and
notifies each active subsystem to perform the requested
function. To accomplish this, the router first places the
name of an active subsystem in the SSIB and the function
code in the SSOB. Then, the router invokes the subsystem
interface which passes control to the routine that performs
the function. The router invokes the interface once for
each active subsystem, changing the subsystem name in the
SSIB each time.
IEFJRASP
2
IEFJRASP
Following each invocation of the subsystem interface,
the router analyzes the return codes from the subsystem interface and from the subsystem. The router saves
the lowest code returned by the interface. It also saves the
highest subsystem return code that was passed back with
the lowest interface code.
CI.I
itg.
~
~
t
Q.
Q
"""
o
'1:1
e:
!a-
IS·
=
~
....,j
w
Label
-....
Diagram 9-2. Subsystem Determination (IEFJSDTN) (Part 1 of 2)
oC"Il
Input
~
~
"<
C"Il
From STC (lEESB605) via the
~ubsystem
Processing
, . 21Ii• • (~~e;j~~EQ) •••••;1I!ltlllI• • •m••••
2
Output
~
C"Il
'<
Subsystem Determination
~
a
i
task name
f)
1
r""
i
Determine if the task being started
is a subsystem.
CVT
~
[
(D
S50B
~
'<
C"Il
~
~
•
t
The task is a subsystem.
Pt.
to ......... 550BRETN
=0
~
~
~
subsystem
names
SSOB
JE5CT
iE5PJE5N
I
::;
•
The task is not a subsystem.~
lZi' .......
primary job entry
subsystem name
551B
S51BJBID
551BPJE5
'~~
Diagram9-2. Subsystem Determination (IEFJSDTN)
Extended Description
Module
The master subsystem provides a subsystem determination
function. Subsystem determination is used by the initiator
during the processing of a START command to determine
if a subsystem is being started. A subsystem must be
started using the master subsystem, whereas other tasks are
started using the primary job entry subsystem.
IEFJSDTN
1
IEFJSDTN
Subsystem determination compares the task name in
the job 10 field of the 551 S to the subsystem name in
each of the subsystem CVTs. If a match is found, the task
being started is a subsystem. In this case, the name of the
master subsystem is left in the SSIS. If no match is found,
the task is not a subsystem. In this case, the name of the
primary job entry subsystem is placed in the SSIS.
C"'-l
a
~r
=
~
~
a
go
Q.
e.
o
"0
;
g.
=
I.f
~
(part 2 of 2)
Label
~
Diagram 9-3. Subsystem Initiation (IEFJJOBS) (Part I of 2)
~
otil
~
N
From the initiator (IEFSD161) via
the sub-
In
til
Subsystem Initiation
'<
~
§
i
1
Obtain the access method work
area.
2
For master scheduler initiation only:
• Obtain the master JCL from
SYS1.LlNKLIB.
• Convert the master JCL to a
JCLS c h a i n . " , .
(:).
~
~
~
=
a
"J
'/
..........
common area
ftj
w
'xflY€<&ii:;hft<:tt"'~:!.'?fJ;K<;:ff'?14!)i!f;;I1~'i¥f1:+£5M\\$,C')ZtlsY:d"'k:'/:'
Converter/Interpreter Interface
1
in'
Prepare to convert JCLS:
• Obtain anl~ initialize initiator
entrance 1st.
' < '
:~"Y:~I
t-
J
~
c
a
(D
w
•
Obtain, initialize, and chain;'!!)
ACBs.
•
For initiating a subsystem,
obtain, initialize, and chain
a DCB forSYS1.PROCLlB.
.
.
~'x ~ t_~~:~~lst
,,:J!
I I
1-.>.".
.,
1(0,
V I .. _- .... - .. --_.-
'<
fIl
N
f
w
~
2
For initiating a subsystem, open
SYS1.PROCLIB.
3
Convert JCLS chain to internal text
via the converter.
return code
7111
continued
'i'"
~
'e:=-~
Diagram 9-4. Converter/Interpreter Interface (IEFJCNTL) (part 2 of 4)
a
e'
=
~
a:
i2.
o
1=.
e'
=
~
~
\C
Extended Description
Module
The converter/interpreter interface, a master subsystem
routine, controls the conversion of a JCLS chain to SWA
control blocks. The JCLS chain, passed from subsystem
initiation (lEFJJOBS), defines the resources needed by the
started task (that is, by the master scheduler, a job entry
subsystem, or any other defined subsystem).
IEFJCNTL
1
The converter/interpreter interface creates the environment for the converter to operate. It builds the NEL as
an interface with the converter. It also builds the ACBs to
allow the converter to interface with the pseudo access
method as if it were the normal access method (VSAML
Refer to the diagram, Pseudo Access Method.
IEFJCNTL
2
When starting a subsystem, started task control
(STC) builds a JCLS chain which the initiator passes
to the master subsystem. This JCLS defines a step that
executes a JCL procedure located in SYS1.PROCLIB. The
converter/interpreter interface opens SYS1.PROCLIB so
that the converter can obtain the procedure and convert it
to internal text.
IEFJCNTL
3
IEFVH1
The address of the NEL (interpreter entrance list) is
passed to the converter which then proceeds to convert the JCLS chain to internal text. The converter uses the
pseudo access method to read the JCLS chain record-byrecord and then to write a chain of internal text. The subsystem initiation message writer handles the error messages
normally issued by the converter/interpreter. The messages
are sent to hardcopy according to the MSGLEVEL specification in the JCL. All the error messages,.and card images,
in addition to having their usual message 10, will be pre·fixed by the master subsystem message 10 (c'IEF1961'L
Refer to the diagram, Subsystem Initiation Message Writer.
Label
~
Diagram 9-4. Converter/Interpreter Interface (IEFJCNTL)
(Part 3 of 4)
!
~
"V' ..- I U\ia;»IIIH
III.,UL
'<
=-
SSOB
I
9
ABEND code
in'
I
r~
~
I
~
......
"
)l,
or
return code
~,
4
Set error flags.
5
When Initiating a subsystem only,
close SYS1.PROClIB.
V
.....1
I
',,"
i
I
fI)
N
is
bypass=0
'
interpreter
~-----flag
(BYPINTER)
t
I,
eM
:...,
"
~l-~
I
I
Ie.
Prepare to- interpret the internal text:
Reset text entry to read internal
text.
Initialize ACB pointers in SSOB
extension.
•
•
I
I'
.......
SSJSTACB
I
I
SSJSJMR
AMWA
~
I
R15
•L
+0
D
I
interpreter error:
no SWA created
,
'
error message ACB
~
internal
text ACB
text entry
L
L
7
Create SWA control blocks from
internal text via the interpreter.
"
.....
.....
'
orlr
..........
~
8
Check whether a SWA was created.
If no SWA was created
Save the return code from the interpreter, unless a non-zero converter
return code has already been saved.
..i::
Return code
D
SSOB
(
~
~
stopinitiation
code = 16
(SSOBRETN)
R15 return
code
(SSJSERR)
Return to Subsystem
Initiation (lEFJJOBS)
"",',-
~
I
subpool241 or 237
SWA
control
blocks
t
internal
text
...
~
~
L
~
SSOBERR:# 0
----.......
=0
~
....
Ir
Converter
no SWA createc
SSJSJACB
=0
y
L-..
AMWA
SSJS
SSJSMACB
I
ACB
pointers
I
SSOBINDY
6
I
SSOB
bypassinterpreter
flag
(BYPINTER)
SSOB
I
R1
JCL error
flag
(CONVERR)
X'24' for
ABEND or
converter
return code
(SSJSSERR)
L
AMWA (common area)
(D
'<
",.=.'_"=
"
~
eM
1"-
AMWA
(common area)
j
Converter
attach ECB
fI)
f
$,
~
N
':
>
,
,,;
"'i":,i>,,\
j
',,', """""",.\t"-:;
~
Diagram 9-4. Converter/Interpreter Interface (IEFJCNTL) (part 4 of 4)
Extended Description
Module
4
Depending on the success of the converter, flags are
set that affect subsequent processing. If the converter
abnormally terminated or passed back a return code greater
than four, the bypass-interpreter flag is turned on. In this
case, the interpreter is not invoked. The converter return
code is placed in the SSJSSERR field as a preliminary indication that no SWA control blocks were created.
IEFJCNTL
5
IEFJCNTL
SYS1.PROCLIB is closed since it is no longer needed
by the converter.
6
The SSJS extension of the SSOB is initialized with the
addresses of the ACBs required by the interpreter. The
JMR field is set to zero because SMF records are not being
collected; the journal ACB address is set to zero because
journal records for checkpoint/restart are not being kept.
IEFJCNTL
7
The converter/interpreter interface passes control to
the SWA-create interface (lEFIB600), passing it the
address of an SSOB in register one. The SWA-create interface invokes the interpreter to create SWA control blocks
from the internal text. (The SWA is located in subpool 241
for the master scheduler and subpool 237 for a subsystem.)
The interpreter uses the pseudo access method to read the
internal text and, like the converter in Step 3, uses the
message writer to issue its error messages. (Refer to the
diagrams, Pseudo Access Method and Subsystem Initiation Message Writer.)
rIl
it
e"
=
~
I::
a
[
~
o
"0
~
!
e'
=
~
....
00
....
IEFIB600
IEFNB903
Label
Extended Description
Module
8
IEFJCNTL
If a SWA was not created because a converter error or
an interpreter error occurred, the SSOBRETN field is
set to indicate that the initiation of this task is to be ended.
If there was an interpreter error but no converter error, the
contents of register 15 are placed in the return code field
of the SSOB. If a converter error occurred previously, the
SSOBERR field is not changed thus preserving the converter return code.
Error Processing
If subsystem initiation passes a zero SSOB or AMWA
pointer to the converter/interpreter interface, the interface
issues a OB1 ABEND. The interface issues a OB4 ABEND if
SYS1.PROCLIB was not opened successfully or if the
block size contained in the PROCLIB DCB is not a multiple
of 80. If the attach of the converter is unsuccessful, the
interface issues a OB5 ABEND.
IEFJCNTL
Label
~
Diagram 9-5. Pseudo Access Method (IEFJACTL) (part 1 of 4)
00
~
o
rIl
~
From converter
•••••••••••••
I£1~;~
(lEFVHA) or
liJinterpreter
iflEFVHE)
Processing
1&&
~
Em
~~1
79/
Output
~
rIl
I
in'
t""
c;:
Pseudo Access Method
-,
I
I
!
I
E'
I
I
~
I
iw
I
'<
rIl
N
i
performs one of four different types
of data movement as follows:
I
I
I
1
Read area containing
record text
Perform a direct read.
R
w
~
RPL
2
Write area containing
new record text
Perform a direct write.
continued
"- -'
~
Diagram 9-5. Pseudo Access Method (IEFJACTL) (part 2 of 4)
Extended Description
Module
The pseudo access method provides the master subsystem
with a data ma'1ipulation service at a time when no access
methods services are available via the RPLI ACe interface.
Rather than accessing data that resides on an external
storage device, the pseudo access method manipulates data
located in real storage. The converter and interpreter use
the pseudo access method when a task is being started
via the master subsystem and not by a job entry subsystem.
IEFJACTL
The subsystem initiation function of the master subsystem
sets up the standard RPLI ACe interface for the converter
and interpreter but places the address of the appropriate
pseudo access method routine in the ACes instead of the
address of the VSAM routines. The switch is not detectable
to the converter and interpreter.
IEFJCNTL
Pseudo access method control determines which of four
IEFJACTL
types of data movement is being requested by checking
flags in the RPL and AMWA. Each of the four steps in the
diagram indicate the flag settings required for its
particular processing.
1
The converter uses the di rect read to obtain a
particular internal text record for updating. First, the
control routine must determine that a direct read is being
requested by checking flags in the RPL. The read routine
moves the text record to the specified area. The length of
the move is specified in the header on the text record being
read.
IEFJACTL
IEFJDIRD
2
en
as·
::s
~
a:
[
e.
o
1
=
f
~
00
w
After the converter has updated the internal text
record obtained by a direct read operation, it writes
the new record over the original record by requesting a
direct write operation. First, the control routine must
determine that a direct write is being requested by checking
flags in the RPL. The direct write routine moves the new
record text to the specified area.
IEFJACTL
IEFJDWRT
Label
,~
l.f
Diagram 9-5. Pseudo Access Method (IEFJACTL)
(part 3 of 4)
00
~
continued
o
til
~
Input
Output
~
til
'<
~
a
£
(=j.
t""
~
~
~
c
=
3
(D
I.H
'<
til
~
~
Perform a sequential read from
a chain of records. Save the address
of the next record in the chain or
indicate that the last record has
been read (end of file).
I '-.- - - , . : - ' . - - . . - - - - - - - - - - -
(D
end-of-fi Ie
flag
(AMWDEOF
= 1)
i
~
I.H
~
area containing record text
4
Perform a sequential write:
a) Obtain a write area in
subpool10.
b) Write the record and chain"
it to the previous record,
if there is one.
Address of first record in
the chain
or
Zero if there is no chain yet
(AMWDLAST)
Return to
either the
converter (lEFVHA)
or the interpreter (lEFVHE)
."
~
Diagram 9-5. Pseudo Access Method (IEFJACTL) (Part 4 of 4)
Extended Description
Module
3
The converter and interpreter use the sequential read
to read records from in-storage record chains (the
JCLS chain and the internal text chain, respectively). First,
the control routine must determine that a sequential read is
being requested by checking flags in the RPL. If the bit
AMWDEOF is on, indicating an end-of-file condition, a
return code of 8 is passed back to the caller.
The read is performed by moving a record in the chain to a
specified area. The header in the record just read contains a
pointer to the next record in the chain. This pointer is
saved in preparation for the next sequential read. If the
pointer to the next record is zero, the end-of-file flag is
turned on to prevent another read operation.
4
til
(1)
(")
g.
=
N
:::
(1)
g
Q.
a.
o
"'0
o·~
=
~
QO
U\
IEFJACTL
IEFJREAD
The converter uses the sequential write to write and
chain together internal text records.
a) First, the control routine must determine that
a sequential write is being requested by checking
flags in the RPL.
IEFJACTL
b) The write is performed by first obtaining an area
in subpool 10. The new record is moved to the
area just obtained. If the AMWDLAST field
indicates that a previous record exists in the chain,
that record is chained to the newly-written record.
IEFJWRTE
Label
-
Diagram 9-6 .. Subsystem Initiation Message Writer (IEF JWTOM) (part 1 of 2)
o
In
~
~
~
From the converter (lEFVHEB or IEFVGM); the
interpreter (lEFVGM), or allocation (lEFAB4FD)
Processi
iiii'iiii:tfi_.l~.4J••m..%t.:w;wifii~iI..
1\t:tY;\\i0j;:r;FJ!${#;';1£#leX1j:K'fjiJ\Y£~4[Z,;;j;);:,>#:ii,'1F\;:SiJ.sBt!(JJ.a0.1tj§{;:;,;;j;hsvj
Output
fI)
N
1
i
RPL
Subsystem Initiation Message
Writer
n·
1
r-
c;:
WTO list
max.#of
bytes for
Obtain and initialize the WTO list.
!
~
E'
Input to
Step 3
text
Iw
2
Remove any blanks following the
message text; adj ust
message-length field.
3
Move message text to a buffer until
maximum message length is reached;
issue a WTO to the hardcopy device.
~
N
i
I
w
~
Output
of Step 1
WTO list
max. ff of
bytes for
message
4
5
,«"
7'
Repeat Step 3 until the entire message
has been issued.
Common 10
hardcopy
Delete the WTO list.
Return
to the
requester
Diagram 9-6. Subsystem Initiation Message Writer (IEFJWTOM) (part 2 of 2)
I:I.l
a
~.
::I
~
a:
[
~
o
."
(D
i
~.
::I
Cf
00
.....
Extended Description
Module
The converter, the interpreter, and allocation normally
issue their messages to a SYSOUT data set. The sub·
system initiation message writer issues these messages
to hardcopy instead. This message writer is used for tasks
being started via the master subsystem. These tasks include
the master scheduler, job entry subsystems, and other
defined subsystems.
IEFJWTOM
1
The message writer issues the list form of the WTO
macro instruction. In this way, it obtains the maximum length allowed for a hardcopy record.
IEFJWTOM
2
The message text is scanned backwards starting at the
end in order to eliminate any trailing blanks.
IEFJWTOM
3
The writer issues a WTO macro instruction to write
the message to hardcopy device. The hardcopy device
is defined at system generation time. Each message, in
addition to having its usual identifier, is prefixed by the
common identifier IEF1961 to indicate that the master
subsystem issued this message on behalf of a starting task~
IEFJWTOM
4
If the message is longer than the maximum length
allowed for a single hardcopy record, the message is
split, and the WTO macro instruction is issued repeatedly
until the entire message text has been issued to hardcopy.
IEFJWTOM
5
IEFJWTOM
The writer deletes the WTO list area after the
message is issued.
Label
tf
~
Diagram 9.,7. Data Set Name Assignment (IEFDSNA)
co
.
00
~
~
N
__ -.- _ _
•
Hi!
T
fI}
t:
2'
~
Output
!!'l!!.
Data Set Name Assignment
'i
B
i-
a. .
(part 1 of 2)
From an allocation routine (lEFAB425)
•
via the subsystem
interface
Processmg
UEFJSREQ) .-~I!I!I!-.kl!l!l!fi*'I!I!I!Ji.~.I!I!I!.I!I!I!
....
.•
,.n .
••._m.l!I!I!
. . .•...~ii6n;.:_.. "m
_
.. I!I!I!.I!I!I!.
_
~I!I!I!_"'.-I!I!I!.'
!!'P~!!l!!I
JFCB
JESCT
Primary
JES name
(JESPJESN)
1
Assign a data set name to the
SYSOUT data set.
..
..
~
E"
~
~
~N
~
r
Return to the allocation
routine (lEFAB425)
55IB
R
~
~
Job 10
(SSIBJBID)
DO name
OS name
..........
?
Diagram 9-7. Data Set Name Assignment (IEFDSNA)
(part 2 o(2)
Extended Description
Module
The master subsystem provides a data set name assignment
function. Data set name assignment assigns a data set name
to each SYSOUT data set specified in the master JeL (that
JeL used to start the master scheduler) and in the JeL used
- to start a job entry subsystem.
1
The data set name is constructed according to the
following format:
xxxx.yyyyyyyy.aabbbb.cccccccc
where xxxx = primary job entry subsystem name
yyyyyyyy = job 10 specified in the SSIB
aa= c'MS'
bbbb = c'OOOO'
cccccccc = DO name of the JeL record for
the SYSOUT data set.
ae·rn
::I
~
J:
$l
[
~
1=e·::I
"f
00
\Q
IEFJOSNA
IEFJOSNA
Label
"'!8§11'"
-
If
Diagram 9-8. Subsystem Job Termination (IEFJJTRM)
(part 1 of 2)
From the initiator (IEFSD166)
via the subProcessing
system
interface
(lEFJSREQ)
\Q
C
Input
~
~N
Subsystem Job Termination
(Master Subsystem)
fIl
l
a
in'
SSOB
Ifunction code I
Output
d
.......
1
SSOB
Check whether job termination
is being requested.
R15
RETN
not job
termination
t"'"
J
~
~
o
Return to
requester
:;
2
1
-
-
SSOB
Build the. subsystem identification
block (55IB) and the subsystem
options block (SSOB).
I
From Master
Scheduler
Initialization
(IEEVIPL),
or fromSTC,
1 1 0 . - - '
-
I
::!J
~1§i
/
Ld)
'~31
:
<... 55IB
~..
I
r
v,:ill
]
Current JSCB
w
~
LCT
t
SWA
Subpool
::
~
: >3
.
.\
:::,1
I
"
JI"ItI
~
~
~
I\
* STEPL
SSOB
~[
J
;
1 tl
1
r:>
~~;
5
Build the STAE parameter
list (STEPL),
.A
'::,l1
o~ ''" [;"""'I5'';>j
..
JCT
v----
-
........
Diagram 10-1. Initiator: Job Initiation
(part 2 of 4)
Extended Description
Module
The initiator interface control module (I E F IIC) issues a
MODESET macro instruction to put the initiator task into
supervisor state; it then begins building the control blocks
required to process a jobstep or task.
1
IEFIIC issues a GETMAIN macro for storage to build
the initiator's entrance, options, and exit list (lEU.
2
IEFIIC gets storage to construct the subsystem identification block (SSIB) and the subsystem options block
(SSOBl. It determines the name of the subsystem which will
select jobs for this initiator and places it in the SSIB:
If the subsystem name was specified on a START command,
a command input buffer (CIB) exists for it and the subsystem
name is taken from there.
If no CIB exists, IEFIIC checks for a subsystem name in the
PARM field of the EXEC statement for this step and uses it.
If no subsystem has been specified on an EXEC statement,
the default value (the primary subsystem name found in
the JESCT) is used.
I EF IIC deletes the RACF accessor environment if one
was obtained for the initiator.
IEFIIC sets an initiator indicator in the command scheduling control block (CSCB) and passes control to IEFSD160.
IEFSD160, the initiator subroutine receives control from
I"EFIIC for a normally initiated job or task, from started
task control processing for a started task, or from master
scheduler initialization.
C"n
('D
o
S·
=
N
s::
('D
~
Q.
....
o
o
"'C
('D
~
o·
=
:t
\I)
'-I
Label
Extended Description
Module
3
IEFSD160
I EFSD160 gets storage for the linkage control table
(LCT) from the SWA subpool pointed to by the current job step control block (JSCB); it then moves information from the IE L into the LCT.
IEFIIC
Label
4
After initializing the queue management parameter
area (QMPA) in the LCT, IEFSD160 builds a 16-byte
parameter list for a STAE exit routine, then issues an ESTAE
macro instruction. It places a pointer to this private ST AE
parameter list (STEPU in the LCT. IEFSD160 passes control
to IEFSD161.
5
IEFSD161, the job select routine, checks an indicator
in the LCT to determine if STOP processing is required.
If so, it frees the SSOB, SSIB, and the STEPL pointer if
one exists, and passes control to a termination routine specified in the initiator's exit list.
If STOP processing is not required, IEFSD161 issues the
IEFSSREQ macro instruction, a routine that interfaces with
the subsystem interface routine. When control is returned
to IEFSD161 along with job status information, it checks
the return code in the SSOB or register 15 to determine if
the initiator should stop at this point. If so, it frees the
SSOB, SSIB and the STEPL and passes control to a termination routine specified in the initiator's exit list.
IEFSD161 next checks an indicator in the LCT to determine if the selected job is being warmstarted. If it is, control
passes to the step delete routine, IEFSD164, to delete the
current step.
IEFSD161
-<
en
N
<:>
w
00
o
~
~
Diagram 10-1. Initiator: Job Initiation (part 3 of 4)
IoC
00
o
~
~
N
II
",.
~
""
~
~
~
Scheduler Work
Area Virtual
Address (SVA)
t"'"
~
a
(D
~
~N
/
Build a data set tree structure for
data set integrity processing.
Data Set Address
to.
a.- Tree
"
Address
Starting Step Number
Tree
+ Next Tree or 0
0000
7
Starting Step
Number
~
00
~
r> 6
Data Set
Address
b
-
SVA
Local
Parameter List
.io·
J
Local Parameter List
~
---
Update the tree structure witH' the
new data set name for the current
jobstep.
• First Entry
Address of Last Word in Tree
Scheduler
Work Area
• Current Entry
0000
SV A of Current Data Set
Data Set
ENQUEUE
Table
Associated Step Number
Data Set Attribute (Exclusive or Shared)
Length of Data Set Name
~
8
Data Set Name
,.
Build the ENQUEUE parameter list
from the entries in the tree.
ENQUEUE Parameter List
h-
....
"
~
Major Name
Heading Info
Data Set Flags
• Major Name
• Minor Name # 1
To step initiation (lEFSD101)
I
Data Set Flags
• Major Name
• Minor Name #2
"I
,\
~
~~
Minor Name Data Set # 1
~inor Name Data Set # 2
--rfi
-
-
w
Diagram 10-1. Initiator: Job Initiation
(part 4
of 4)
Extended Description
Module
6
IEFSD161 then checks an indicator in the JCT to
IEFSD161
determine if data set integrity processing is necessary for IEFDSTBL
this job. If it is, IEFSD161 reads each data set name and
passes it in a parameter list to IEFDSTBL. To process data
set integrity (the assignment of the exclusive or shared
attribute to a data set), IEFDSTBL builds a data set tree
structure. The purpose of the tree is to eliminate duplicate
data set names in the ENQUEUE parameter list which will
ultimately be built for a job. The parameter list passed to
IEFDSTBL contains the step number at which the job
started, as well as a data set name and its current associated
step number. The entire procedure ensures that a data set
in use for a job will not be freed until after the last step
needing it has used it.
If this is the first entry into IEFDSTBL for a job, IEFDSTBL
issues a GETMAIN for storage for the tree and initializes it
with control information.
7
IEFDSTBL determines if the job is a restart by comparing the starting step number in the parameter list
with the current step number in the data set entry. If the
current step number is larger, the job is a restart. No further
data set integrity processing is needed since a DSENQ list
already exists for a restarted job. I EFDSTBL simply returns
control to IEFSD161.
For jobs that are not restarts or a first entry, IE F DSTB L
compares the data set name in the parameter list with the
first data set entry in the tree.
I:I'.l
nI
~
e'
=
N
~
a
8:
o.....
o
-g
ic:)"
=
~
IC
IC
If the two data set names match, IEFDSTBL compares the
associated step number in the tree to the current step number. If the current step number is higher, IEFDSTBL
replaces the step number in the tree with the current step
number. It also replaces the associated data set attribute
(exclusive or shared) in the tree if the current attribute is
more restrictive (exclusive).
If the data set names do not match, IEFDSTBL continues
searching through the tree until it does find a match; then,
if necessary, it updates the step number and data set attribute in the tree.
IEFDSTBL
label
Extended Description
Module
If IEFDSTBL reaches the end of the tree without finding a
match, it adds the new data set name, its associated step
number, and its attribute to the end of the tree. It
returns control to IEFSD161.
IEFSD161 looks at the CPU-task affinity indicator in the
program properties table (PPT). When affinity is required,
IEFSD161 calls IEFICPUA to assign CPU-task affinity to
the job. If the return code from IEFCPUA is not zero,
affinity cannot be assigned and IEFSD161 issues an appropriate message via IEFIMASK which converts the CPU
information in the PPT to readable text.
IEFSD161
8
IEFSD161
IEFDSLST
Once the tree structure contains all the data set entries
for a job, IEFSD161 passes control to IEFDSLST to
build the ENQUEUE parameter list. IEFDSLST places the
system data set name (major name) and the individual data
set names (minor names) from the tree into the ENQUEUE
parameter list and frees the tree, since it is no longer needed.
Control returns to IEFSD161.
label
~
Diagram 10-2. Initiator: Step Initiation (part 1 of 8)
8
From job initiation (lEFSD161)
for the first step of a job or
from step deletion (IEFSD164)
for subsequent steps
,0
~
t\oJ
..
Input
~
~
~
i
f;'
r-
Register 1
I
~
r.
'@
Initiator, Step Initiation
~
lo-
~
......
JCT
(D
----
CN
~t\oJ
e
,>." . ".",
~
PPT
(accessed by VCON)
Non -cancelable
Special protect key
Non-swappable
Privileged
r
System task
-
CPU affinity
~
1
Perform SMF processing as
required.
;;,
v> 2
~
Analyze the program properties
for the current jobstep/task.
;
~
.,,-
L
JCT
§
v
"'
"
'.',.>:c<> <. . ':<
""""'::""'~'\'"
... >"
I'
:i
~-cancela~
Non-cancelable
Current TCB
i;:
VL
-";
-,;j
-~
Data Set
Enqueue
(DSENQ) List
...
"
4
-~
6
~~
....-~
":
i
,,><,;~~;!
:
~
""<'
~~
"
Bypass
password
protection
GWT
Enqueue on the data set enqueue
list for this jobstep/task.
:,
JSCB
':0;::'>;:',:;:':::t,,:~i: .';;,;;, '<'·"'i:'/'?:"";<'.i/
LCT
f
Protect Key
'----- -
I'
::~
System task
Non-swappable
CPU-affinity
Build a GETPART work table
(GWT) for the current jobstep.
;:'
i:
P'"' 1 ASCB
....
'7*,:
-
,::::;;0>\
SCT
;.
.,"
{",
L~
3
,'+/', "',
:)
Privileged
Oa .. Set integrity
"
"co,,',
-~CSCB
-
~
,:
~
=...t
....
;
Time and
date
LCT
Data set integrity
CN
,,~
Type 20
SMF Record
...
;:;
...
',wC~"""
ji
,
LCT
f
.$
~
p
,'."
..
".
,./.,;
:;
;
':
"
\;
"
";"<:" .,."",':':/",:, '. ,.'i.;\'
~
Diagram 10-2. Initiator: Step Initiation (part 2 of 8)
Extended Description
Module
1
IEFSD101
IEFSMFIE
I EFSD161 passes control to the PPT scan routine,
IEFSD101, which in turn calls IEFSMFIE for SMF
processing. Once IEFSMFIE has determined that SMF
options are to be performed, it stores the current time
and date in the JCT.
For every step in a job, IEFSMFIE executes a user step
initiation routine, if one is provided. When control returns
to IEFSMFIE, it passes control to IEFSD101 with an indicator in the JCT if either the user's job or step initiation
routine caused job cancellation.
By checking a protect key in the JCT, IEFSD101
determines if the current job step is to run in V=R or
V=V. In either case, it moves the protect key into the current TCB. (When a user has specified V=R for a job step.
his program is allocated a contiguous area of real storage
and of virtual storage, both with identical addresses. His
entire program is loaded into real storage at one time and
cannot be paged.)
Before assigning any other special properties to this program,
IE FSD 101 sets to zeroes the special properties indicators
that were set for a previous step. It then scans the program
properties table (PPT) for the following properties:
Special protect key - If a special protect key is indicated in
the PPT, IEFSD101 moves it into the current TCB.
CI}
(\)
~
o·
=
N
a::
(\)
[
o
1"0)
o
'"d
~
a
o·
=
~
N
I:>
Non-cancelable job - If the non-cancelable property is indicated in the PPT, I EFSD1 01 sets an indicator in the LCT
and marks the CSCB non-cancelable.
Non-swapable - If the program is marked non-swapable in
the PPT, IEFSD101 sets the appropriate indicator in the
ASCB.
Privileged - If the program is marked privileged in the PPT,
IEFSD101 sets an indicator in the LCT. The privileged
property ensures that a program will not be swapped unless
it is in a long wait.
System task that is also a one-step started task - IEFSD101
sets an indicator in the LCT that indicates that the task
need not be timed.
Extended Description
Module
System task that is an initiated task and/or consists of more
than one step - I EFSD101 sets an indicator in the LCT to
assign some of the normal program properties to the task
and to issue an appropriate message.
No data set integrity - For a one step job, I EFSD 101 sets
an indicator in the LCT to assign this property to a program. For a job consisting of more than one step, an indicator is set in the LCT to assign some of the normal program
properties to the program and to issue an appropriate
message.
For the first step of a job, IEFSMFIE, the SMF initialization
exit support routine, constructs a timing control table (TCT).
At this point, if a user job initiation routine is provided, it
is executed. When control returns to IEFSMFIE, it builds a
type 20 SM F record.
2
Label
Bypass password protection - I EFSD101 sets an indicator
in the JSCB.
IEFSD101
CPU task affinity - IEFSD101 checks this property for all
steps in a job other than the first. When affinity is required,
IEFSD101 calls IEFICPUA to assign CPU task affinity to
the step via an indicator in the address space control block
(ASCB). If the return code from IEFCPUA is not zero,
affinity cannot be assigned and IEFSD101 issues an appropriate message by invoking IEFIMASK to convert the CPU
information in the PPT to readable text.
IEFIMASK
3
IEFSD101 builds a GETPART work table (GWT) for
the current job step if the user specified the REGION
parameter or V=R mode or if a region beginning at a specific address is required for a checkpoint restart. A pointer
to the GWT is placed in the LCT and control passes to
IEFSD102.
IEFSD101
4
IEFSD102
If no data set enqueue list exists and the job is successful to this point, IEFSD102 passes control to the
device allocation interface routine, IEFSD162.
IEFICPUA
IEFSD162
If a data set enqueue (DSENQ) list exists, but the job is
unsuccessful, IEFSD102 frees the DSENQ list before it
passes control to IEFSD162.
If a data set enqueue list exists, this is the first step of a job
that requires non-temporary data sets. IEFSD102 marks
the CSCB cancelable and issues an ENQUEUE macro instruction for the DSENQ list.
IEFSD102
If the ENQUEUE is unsuccessful, IEFSD102 issues an error
message; otherwise, IEFSD102 waits for the ENQUEUE
ECB to be posted (indicating that the specified data sets
are now available) or the CANCEL ECB to be posted as a
result of an operator CANCEL. In any case, control passes
to the device allocation interface routine, IEFSD162.
IEFSD102
Label
w
~.
Diagram 10-2. Initiator: Step Initiation
(part 3 of 8)
~
"<"-l
N
"-l
'<
fQ.
;
t""
~.
t""
cr
!<
~
iw
~N
~
i
!
Process
input
I
LCT
I
9
JCT
J
~ 5 ~alculate the time limit for this
Jobstep/task.
J
J
""--'"
:.
,g
VOw
fJ~Tc'
---'
~SCT
~
J
J
J
,/-.J
LCT
~}I
A
-V
6
Set j.obstep/task cancelable if
possible.
~.,.~
.'.'
.ij~
~
YEry;
~
::::::l
c:
\
~
r::::::::=:::t
<'t-:"ik/1'.vu~{Ji~,:Z~0;:E;: ~ ,;~~z,{P,:::::·fNJ{1t. : ·~,x'<~:f~~~·~::)~~9/;t~~~::· ?:.~;<~.'::"! :2' y'r ':j ';;Y ~.:' '.~
.
~7
w
:....
~
8
Call subsystem to notify
:
of step Initialization.
:,,1
.~~
Perfor":, checkpoint/restart
processlng.:;;1
~
Y~,
R1
\
I
550B
I
Parameter List
!/tCT
SSOBINDV (
..
~~~:::SS:O::B:S:I:~
i
~i
y~?
TIOT
~
9
:>10
=> 11
Perform
processing f o r : :
the current Jobstep/task.
all~cation
;,1
~!.
v'l
Update the job journal.
::
>til
J====l
t:=:::::::j
IEFPARAM
ATTACH
Diagram 10-2. Initiator: Step Initiation
(Part 4 of 8)
Extended Description
Module
5
IEFSD162
IEFSD162 first calculates the step time limit using
input from the SCT, JCT and LCT; the resultant time
limit for the current job step is stored in the LCT.
6
Label
If the current jobstep task is a started task (this is
indicated in the CSCB), IEFSD162 sets up fields in
the command scheduling control block (CSCB) so that the
task will have a name that can be specified on a CANCE L
command.
7
IEFSD162 builds the SSOBSI extension in the
LCT work area. Then, using the IEFSSREO
macro, it calls the subsystem to notify it of step
initialization, providing step names and step number.
On return from the interface, if register 15 does not
indicate a "successful call" or "function not
supported by subsystem", issue a X'OBA' ABEND.
IEFSD162
CI)
CD
aa·
::t
!':»
51:
t
c:a.
o....
o
1s·
=
w
N
S
Module
9
IEFSD162 gets storage for both a save area and parameter list for the allocation routines. At this time, if the
current jobstepltask is a system task, I EFSD162 marks the
CSCB cancelable for the duration of allocation processing:
it then branches to the device allocation load module,
IEFW21SD. When IEFSD162 again receives control, if
necessary, it restores the non-cancelable status of the task.
IEFSD162
If allocation was unsuccessful, IEFSD162 sets an indicator
in the initiator exit list (I E U and passes control to
IEFSD164 to delete the jobstepltask.
IEFSD162
10
IEFSD162
IEFXB500
After allocation processing, IEFSD162 updates the
JSCB and JCT and calls IEFXB500 to write the
updated information into the job journal.
11
8
If checkpoint/restart processing is required, IEFSD162
cans IEFXB604 to set appropriate job status bits in
the job step control block (JSCB) and JCT to indicate that
allocation processing is beginning for the current jobstep/
task. IEFX8604 also writes the step's header record in the
job journal before returning control to tEFSD162.
IEFJSREO
Extended Description
IEFXB604
Label
IEFW21SD
IEFSD162
In preparation for ATTACH processing, IEFSD162
issues a GETMAIN for storage for IEFPARAM,
which will serve as the initiator's internal parameter list, and
for an ATTACH parameter list. IEFSD162 places a pointer
to the LCT and to jobstep/task TIOT (created by the allocation routines) in IEFPARAM. It next places a pointer to
IEFPARAM in the STEPL. IEFSD162 then calls SWA manager to write the SCT and JCT into the job journal.
~
N
o
W
00
~
I.f
N
Diagram 10-2. Initiator: Step Initiation (part 5 of 8)
~
otil
~
N
til
~
LCT
9
\ . JSCB
E
n'
...
y
~
~
12
Open the catalogs required by
this jobstep/task.
\
~CB
I
~
~
2"
I
:I
('D
L-
I.N
~
TIOT
"
I
v
1
Data sets
marked "OPEN"
J
~
"-
LCT
N
o
I.N
v
~
00
o
~
13
Open the JOBUB, STEPLlB,
and/or F ETCH LIB as required
by th is jobstep/task.
LCT
DEB
DCB
4
?
r---
"-
-:::::;:7
R1
v
Assign special properties to
programs if possible.
~
ATTACH
Parameter List
~ lEFPARAM
) 14
Is this library
- defined to contain pgms
_ with special _
properties?
-
ATTACH
Para meter List
'"
--y
15
Initialize the ATTACH
parameter list.
"-
v>
(...A""
/
.......
---
~
.......,
.~
~
''II!''!''!!II''
Diagram 10-2. Initiator: Step Initiation (part 6 of 8)
Extended Description
Module
12
Before beginning OPEN processing, IEFSD162
IEFSD162
places a pointer to the jobstep/task TlOT in the
initiator's own TCB. It then checks the jobstep/task JSCB
to see if there are catalogs to be opened. If so, IEFSD162
calls the initiator interface to catalog control, IEFICATL.
This routine scans the DSAB (data set association block)
chain associated with the jobstep/task to identify the
required catalogs. It then invokes IEFAB4F5 to open these
catalogs and update the private catalog control bfocks (PCCBs),
and returns control to IEFSD162. If OPEN processing is
unsuccessful, IEFSD162 branches to IEFSD164 to delete
the jobstepltask.
13
{"I.l
a
e'
=
~
at::
[
~
1a.
e'
=
~
N
~
IEFSD162 issues an OPEN macro instruction for the
JOBUB, if one exists, or for the STEPLIB if a
STEPLI B exists. It issues another OPEN macro instruction
for FETCHUB if it is also required. When OPEN processing has completed successfully, IEFSD102 restores the
TIOT pointer in the initiator's TCB so that it once again
points to the initiator's own TIOT.
IEFSD162
14
IEFSD162
IEFSD162 checks the related data event blocks
(DEBs) to see if the job library or step library just
opened is an authorized library (this is indicated in the
DEB). If the library is authorized, complete the
assignment of special properties. If the library is not
authorized, assign normal properties to the job step
and issue an appropriate message. When this is done,
IEFSD162 branches to IEFSD103 for ATTACH
processing. (Special and normal properties are
discussed in OS/VS2SPL: Job Management.)
Label
Extended Description
Module
15
IEFSD103
IEFSD103, the ATTACH interface routine, places
the following information in the ATTACH parameter list passed to it:
• The entry point of the problem porgram to be attached
in behalf of the jobstep/task.
• The address of the ATTACH ECB.
• The address of the FETCHLIB DCB.
• The address of the STEPLIB or JOBUB DCB.
• The identification of which SWA subpool (236 or 237)
cannot be shared.
If the DPRTY parameter was specified for the jobstep,
IEFSD103 calculates an address space priority for the job.
If DPRTY was not specified, the automatic priorit~ group
(APG) from the CVT is used. In either case, IEFSD103
puts the memory priority, along with the performance
group number, into IEFPARAM. It then branches to
the ATTACH routine, IEFSD263.
Label
;
Diagram 10-2. Initiator: Step Initiation (part 7 of 8)
i
~N
f'-)
,
'om,m,
1
LCT
~
i
f
"y 16
Get a region for the current
j obstep/task.
TCTIOT
~
;:
17
a
j
w
~N
~
r
~
w
~
D
.....
Perform SMF processing.
~
y
R1
1
,I
") 18
~
"
A list of
end-of-task and
cancel ECBs
'" 19
f;!:' "
~
:~
\"
~
"y
Attach the task and wait for it
to complete processing.
TCB
:'
Detach the task when it has
completed processing.
,.
To step deletion
(tEFSD164)
,itt
,l~
CJ
.,
~
. .:- .........;i.
:
j:
.
Diagram 10-2. Initiator: Step Initiation
"
(part 8.of 8)
Module
Extended Description
If the jobstep/task is not swapable, IEFSD263 issues
a SYSEVENT macro instruction, REQSWAP, that
. causes the initiator's own address space to be swapped out.
It also frees the initiator's region.
16
IEFSD263
When no GETPART work table (GWT) exists for a
jobstep/task, IEFSD263 CJbtains a V=V region of default
size.
If there is a GWT, a special type of region is required for
the jobstep/task. IEFSD263 issues a GETMAIN for a region.
If the request cannot be immediately satisfied, IEFSD263
waits for a GETPART or CANCEL ECB to be posted
indicating whether the GETMAIN completed successfully
or failed.
17
;;'.
IEFSD263 calls IEFAB820 to build a TCTIOT
(timing control TIOT), if one is required.
1
J
Label
'
..'~""
Extended D~ription
Module
18
WhehlEFSD263 regains control from IEFAB820,
it moves the jobstep parameter area from subpool
253 to subpool 0, issues an ATTACH for the jobstep/task,
and sets a time limit in the ASCB. It takes the task's ASCB
priority from IEFPARAM, issues the STATUS macro
instruction to make the newly created TCB dispatchable, and
then issues a WAIT macro instruction. It waits for the
end-of-task and for the cancel ECBs associated with the
attached task to be posted.
IEFSD263
19
IEFSD263
If the cancel ECB is posted, IEFSD263 invokes the
abnormal termination routines via SVC 34 and
issues another WAIT macro instruction for abnormal
termination processing to complete.
IEFAB820
When the cancel ECB is posted a second time, or when the
end-of-task ECB is posted once, IEFSD263 begins DETACH
processing.
If the jobstep was timed, IEFSD263 saves the time allowed
for the job and the time used by the job step (both in the
LCT) and calculates the time remaining. It builds a parameter list to be used for step deletion processing, frees the
jobstep/task region and if one exists, the GWT, and finally
branches to the step delete routine. IE FSD164.
til
a5'
=
~
a::
a
6
Q.
o....
o
-=;
g.
=
w
W
c
.....
IEFSD263
Label
CoN
~
otil
"<
Diagram 10-3. Initiator: Step and Job Deletion
From IEFSD263 (the end of step
initiation) orfrom IEFIB621 for
attempted retry
nput
til
N
til
(part 1 of 4)
Process
Output
Register 1
'<
fQ.
Step and Job Deletion
~
J
b
~ I EFPARAM a-+J LCT
~.
t:
2"
~
II
;
;
!J"f$,
>
1
Close F ETCH LIB and .IOBLIB or
STEP LIB If necessary.
LCT
J..
4 FETCHLIB
~
I
[c
r--v
, JOBUBI
STEPLIB
~
CoN
~N
~
i
LCT
~:
~
-
:: :: >2
CoN
:...
v "'"
~
--- ~
JCT
1 k :_ _
'
t
Job Journal
Calc~la.te time elapsed and time
remammg for the current
jobstep/task.
yl
L.J\,
v
f;'~1
ACT
~i211
JCT
....
:;.> 3
• ACT
SCT
Free IEFPARAM and the ATTACH
parameter list •
.~
"----4
Build a dummy TCB to be used by
the unallocation routines.
5
Determine status of the current job.
Q
".
,,£I
....
1/1
~)
ACT
SCT
tACT
~
~
DummyTCB
~
To step initiation to begin another step if
the last step in a job has not been completed.
""---.-?
~
Diagram 10-3. Initiator: Step and Job Deletion
~
nI
~
ci"
=
N
a::
~
S
Q.
o
.....
o
"0
o·~
=
~
~
o
\0
(part 2 of 4)
Extended Description
Module
When the step delete routine IEFSD164 receives control,
it checks indicators in the JCT and LCT to determine if
the jobstep is being deleted for warmstart processing or
because of an error during allocation. If either of these
conditions exists, I EFSD164 begins processing at step 3.
IEFSD164
1
IEFSD164 closes FETCHLIB if it was used by the
jobstepltask and frees the storage its DCB occupied;
it does the same for a JOB LI B or STEP LI B.
IEFSD164
2
IEFSD164 calculates the SRB time for the jobstep and
writes it the SCT. It calculates the execution time for
the jobstep and writes it into the step account table (ACT).
It does the same calculations for the job and writes the
resultant figures in the JCT and the job account table
(ACT) respectively. I EFSD164 then calls SWA manager
to write the updated block into the job journal.
·
r
IEFSD164
3
IEFSD164 frees IEFPARAM, sets to zero the
pointer to it in STEPL, and also frees the ATTACH
parameter list.
IEFSD164
4
IEFSD164 builds a dummy TCB to be used by the
una"ocation routines; the dummy TCB contains the
jobstepltask status and completion codes. When the
dummy TCB is completed, control passes to the unallocation routines to free the data sets and devices used by
the jobstep/task.
IEFSD164
5
IEFSD164
When I EFSD164 regains control from unallocation, it
frees the dummy TCB and checks the return codes.
Label
!of
N
Diagram 10-3. Initiator: Step and Job Deletion
(part 3 of 4)
o
otil
"<
til
'If
N
til
'<
~
(I>
:3
rt2;:;.
r-
a:
-<
;
<
o
=
:3
(I>
~
'<
til
N
b~
00
o
.::!
LCT
1
QMPA
1
I
~
If~b~'
6
Delete the security accessor
environment.
7
Delete, suspend, or re-enqueue
this job.
'") 8
Y
.
.
Free all control blocks associated
with this job in the LSOA, SOA,
and SWA.
<
til
N
b
~
00
o
......
LCT
9
Indicate that this job should stop.
'"
Y
Internal Stop
l/"'--'-
To job initiation to
begin the next job.
-
~
..,.
Diagram 10-3.' Initiator: Step and Job Deletion
"<
"''.':..Y''
;?
(part 4 of 4)
Extended Description
Module
label
6
If RACINIT processing was performed for this job
step/started task by the SWA create routine
(lEFIB600), then delete the RACF environment since the
task has completed.
7
If another step in the job is to be initiated, control
passes to IEFSD101, the step initiation routine.
If tl:le job step just completed was the last step in a job,
control passes to IEFSD166, the job delete routine.
IEFSD101
IEFSD166
If the job associated with the jobstepltask is to be suspended,
control passes to IEFSD166 to do this.
...
<:
rn
If the job ran in V=R mode, IEFSD166 releases the job's
protect key. It gets storage for job delete or job enqueue
N
o
I.N
00
processing. The decision to delete or re-enqueue a job
depends on the function code in a two-word parameter
list pointed to by register one. IEFSD166 sets appropriate
indicators in the SSOB and issues the IEFSSREO macro
instruction requesting the job entry subsystem to delete
or re-enqueue the job.
If no error occurs in job entry subsystem processing,
IEFSD166 puts the return code from the subsystem into
the IEL.
o
...;j
IEFSD166
8
rn
(1)
IE FSD 166 frees all the control blocks associated
with this job in the LSOA and SQA. It passes
control to the SWA management routines requesting
deletion of job related blocks in SWA. It then calls the
auxiliary storage manager routine (I LRJTERM) that
frees any ASM control blocks still existing for VIO data
sets created by the job being terminated.
S·
9
n
is:
If the completed job was a normally initiated task,
IEFSD166 removes the job name from the initiator's
TIOT.
8-
If the completed task was not begun by the initiator,
IEFSDl66 sets an internal stop indicator in the LCT.
=
N
IEFSD166
(1)
~
o...,
o
"0
(1)
~
S·
=
I.N
-~
Control passes to IEFSD161.
IEFSD161
w
oN
Diagram 104. Initiator: Recovery Processing (part 1 of 2)
..
From recovery
termination
management
N
oC"'-l
~
N
C"'-l
'<
Input
Register 1
~
3
i
Co
g-
~
~
~
Initiator Recc very
SDWA
... The initiator task recover " routines receive
" control when:
~
-
(STEPL
~
a) A program check
OCCl
~
rs.
b) An ABEND occurs.
STEPL
OCCl
rs.
e) Percolation occurs.
---
~
N
o
W
........
00
c::>
~
LCT
1
--'
Contribute to system rror recording.
...
y
~
,..-
~
'-
-""
SYS1.LOGREC
Data Set
........
'-..
JCT
2
---"
.........
cl The operator pushes t ,e REST ART key.
d) A machine check
w
C"'-l
Output
~ SDWA
(D
'<
Process
Take a dump.
~
...
,..-
"
"'~
3
Exit to IEFSD164, ei her to delete the
jobstep/task and retry it or to terminate the
entire job.
,
(Ie
16
System
.DUMP
Data Set
"-
""""'
~"
~
Diagram 10-4. Initiator: Recovery Processing (part 2 of 2)
Extended Description
Module
The initiator task recovery routine (lEFIB620) receives
control when:
a·) a program check occurs,
b) an ABEND occurs,
c) the operator pushes the RESTART key,
d) a machine check occurs,
e) percolation occurs.
1
IEFIB620 receives control from recovery/termination
management (RITM). If RITM does not provide a STAE
diagnostic work area (SDWA), IEFIB620 simply sets an
indicator in register 15 to continue termination processing
and returns to RITM.
IEFIB620
Unless the error that occurred was an OPEN failure or unless
the routine received control as a result of percolation,
IEFIB620 records the error in the SDWA.
2
If entry into this routine is not the result of percolation,
recursion, an OPEN failure, or a machine check,
IEFIB620 issues an SDUMP macro instruction.
3
If this is not a recursion or if the LCT does not contain
both a JCT SWA address and an SCT SWA address,
IEFIB620sets a retry indicator in the SDWAand places the
address of the retry routine in the SDWA. It then returns
to its caller, R/TM.
f:IJ
11
e'
=
~
~
[
2-
-i
=.£1
e'
=
~
-
(N
R/TM, in turn, passes control to IEFIB621, the initiator
task recovery retry routine, which will enable the retry and
then pass control to IEFSD164, the initiator step delete
routine to delete the step currently in progress.
IEFIB621
Label
3-214
OS/VS2 System Logic Library Volume 3 (VS2 Release 3.7)
SWA Create Interface
The SW A create interface routines receive control
from either the master subsystem or the job entry
subsystem. Their main function is to. prepare a job
for the interpreter by setting up its job step control
block (JSCB) chain. One of the SW A create
interface routines, IEFIB600, passes control to the
interpreter, and when control returns, it places the
SW A address of the JCT in the JSCB for a job. It is
the interpreter that actually builds the SW A and
many of the control blocks that reside in SW A, for
example, the JCT.
Whenever the current job is not a started task,
the S·w A create interface routines build a command
scheduling control block (CSCB) to represent the
job. (The CSCB for a started task is created by the
started task control routines.)
The sw A create interface routines also
reconstruct SW A for restarted jobs.
Section 2: Method of Operation
3-215
-
Diagram 11-1. SW A Create Interface (IEFIB600) (part 1 of 2)
"<
Input
~
N
01
o
rI:I
{I}
~
rI:I
'<
~
9
I
From the master
subsystem or the job
entry subsystem
II
I:;: I
I -N
1
E
n'
p
SWA Create
"
SSOB
v
1
r-
~
-<
t2'
3(D
Output
~ illolcellssllllllllllll~1I1I1I1I1I1I1I1I1I
i'nterfa~
I
LCT
I,
1·T ~CB 1J
~
Create an EST AE erlvironment in case an
error occurs.
Job Status Flags
• LCT
(
~
JSCB
<:
2
~
Q
~
~
---...
L-...J\.
Initialize the JSCB fpr the starting jobstep
or task.
f
~
_Jo...
Invoke the interpret~r to build required
control blocks.
Initialize RACF acc,ssor environment
if RACF is active.
5
Build a CSCB for th~s task if necessary.
LCT
Is this a
started task?
l---
J\
v
-v
NEL
,,~ Message Text
Register 1
1
+ACB
+OMPA
fudi
CSCB
...Jo..
VII
-
Cancel Status
N
N
T
Register 1
CC:SSO~
~
00
~
?f
0 . . . - -_ _
4
Q
v
00
3
~
+Journal RPL
~
~
rI:I
~ Message RPL
LCT
J-..
v
6
If this jobstep/task
reconstruct SWA.
if part of a restarted job,
~
Return tel> caller
T
LCT
511
,-
d
V
Updated
Diagram 11-1. SW A Create Interface (IEFIB600)
(part 2 of 2)
Extended Description
Module
IEFIB600 first creates an ESTAE environment by
issuing an EST AE macro instruction .. As a result, if
an error occurs during SWA create interface processing,
control will first pass to a recovery/termination routine,
and from there, back to a SWA create exit routine,
IEF1B645. The exit routine takes a dump of storage if it is
required, and specifies retry. It then returns control to
recovery/termination.
a
IEFIB600
IEFIB645
Once the ESTAE environment is established, IEFIB600 sets
the job status flags in the LCT indicating whether the job
is an automatic checkpoint restart, a step restart, or a
warmstart.
IEFIB600
2
IEFIB600
IEFIB600 next issues a GETJSCB macro instruction
and when that is done, it chains the job's JSCBs and
places a pointer to the first JSCB in the LCT. It initializes
the JSCB with the following information:
~
a::
a
S
Q.
So
~
;
g.
::I
-
eN
N
......
3
IEFIB600 then initializes the interpreter entrance
list (NEL) and issues a LINK macro instruction to pass
control to IEFNB903, the first routine of the interpreter.
Register 1 points to the NEL.
When control has returned, if an error occurred during
interpreter processing, I EF I B600 frees appropriate control
blocks, places an error return code in register 15, and returns
to the original calling routine.
When interpreter processing has completed successfully,
IEFIB600 invokes a SWA manager routine to read the job
control table (JCT) created by the interpreter. It places the
Module
Label
If the RACF function is active, check if the userid is
valid. If not, fail the job and issue an error message
(lEF7221). If successful, check if automatic data set
protection was requested. If it was, set the JSCBADSP in
the active job step control block for use by allocation.
5
If the job in processing is not a started task, IEFIB600
builds a command scheduling control block (CSCB)
to represent the job. (If the job is a started task, the started
task control routines have already built the CSCBJ
6
Finally, IEFIB600 checks indicators in the SSOB and
LCT to determine if the SWA for this job must be
reconstructed. For restarted jobs, SWA must be rebuilt to
reflect previous processing, as well as newly begun restart
processing.
Before calling the merge module, IEFIB605 builds a parameter list, the merge entrance list (MEL) and places a pointer
to it in register 1.
IEFIB600
~
~
(:,
eN
IEFIB600
Whenever SWA reconstruction is necessary, IEFIB600
passes control to IEFIB605, the SWA reconstruct module, *
otherwise, it returns control to the original caller.
IEFIB605 first determines if the job is an automatic restart,
step restart, a warmstart, or deferred restart. For any case
but deferred restart, IEFIB605 invokes the SWA merge
routine (lEFXB601)'
• The address of the message request parameter list (RPLl.
• The address of the journal RP L.
.The address of the QMPA.
.• The address of the CSCB for the job, if one exists.
• An indicator that the job is entering the interpreter.
• An indicator that no journaling is required.
• A restart indicator.
• The SWA subpool number.
• The ASI 0 for the job.
~.
::I
Extended Description
4
during interpreter processing.
1
Label
SWA address of the JCT in the first JSCB, in the JCT itself,
and in the LCT.
The SWA create interface routines set up the control
blocks for a job before the job enters the interpreter. The
SWA in which the control blocks will reside is created
CI.l
... ~~
'---_7
~
When merge processing has completed and control is
returned, IEFIB605 checks job status again for an automatic
or deferred restart. In both cases, it invokes the data set
descriptor record processor, IEFXB609, and it passes it a
pointer to the LCT.
This time, when control returns to IEFIB605, a subroutine
checks job status for a warmstart. If the job is a warmstart,
IEFIB605 determines whether the error that caused the
warmstart occurred in allocation, execution, or termination
and sets appropriate indicators.
In every case, I !=FIB605 returns control to I EFIB600, who
then returns to the caller.
*This module is part of Checkpoint/Restart processing .
IEFIB605
IEFXB601
IEFIB605
IEFXB609
IEFIB605
00
~
3·218
OS/VS2 System Logic Library Volume 3 (VS2.03.804)
Converter /Interpreter
The Purpose of the Converter
The following is a brief overview of converter
functions. For a thorough look at converter
processing see the method-of-operation diagrams
and extended descriptions.
In MYS, the converter/interpreter performs most
of the functions performed by the
reader /interpreter in os. However, the
converter /interpreter does not read in-stream JCL
statements or any input stream data. The converter
executes as a subroutine of the job entry subsystem
(JES). JES actually reads JCL statements and input
stream data and spools them to appropriate data
sets. The converter then takes the records from
these data sets and converts them into internal JCL
text to be used by the interpreter. It also merges
JCL that it reads from the procedure library with
the JCL and input stream data spooled by JES.
Identifying JCL Statements
,
Once initialization is complete, the converter GET
routine, IEFYHA, begins processing by obtaining a
JCL statement (an 80-byte card image) from the
JCL data set and/or from a cataloged or in-stream
procedure.
Comments and Continuation
The next converter routine, IEFYHC, continues
processing JCL statements by checking for a valid
continuation. It branches to IEFYHEB if a
continuation was expected and was or was not
received, to IEFYHCB if a continuation was not
expected, and to IEFYHA if a comment was
received.
JOB, EXEC, DD Statements
Once a JOB, EXEC, or DD statement is identified,
the converter pre-scan (IEFYHEB) performs some
initialization functions and branches to the scan
routine, IEFYFA. It is IEFYFA that converts all JCL
card images taken from the JCL data set into
internal text and then moves them to a text data
set that will be used by the interpreter.
NULL Statements
The NULL statement processor, IEFVHL, analyzes
the conditions under which it was entered.
If the NULL statement represents the end of an
input stream job and more statements must be read
from a procedure, control returns to the converter's
GET routine, IEFYHA. When IEFVHA encounters a
procedure end-of-file, it generates a NULL
statement to signify the end of the procedure.
If the NULL statement indicates that there are
no more JCL statements to be read and that the
JCL data set and all procedures have been
processed by the converter, IEFYHL invokes the
converter termination routine, IEFYHF.
PROC and PEND Statements
An EXEC PROC statement identifies a procedure
that exists in the system's procedure library. A
PROC statement marks the beginning of an
in-stream procedure. When the converter
encounters a P~oc statement in the input stream, it
converts it to an EXEC PROC statement. For both
cases, control passes to an in-stream procedure
control routine,· IEFYINA, that in turn calls a series
of special processors.
The first of these, IEFYINE, is a syntax check
routine. If it finds the PROC statement valid, it
returns this information to the control routine.
The next module called, IEFYINB, scans the
entries in the In-Stream Procedure Directory. If
IEFYINB does not find an entry for the procedure
name sepcified on the PROC statement, the control
routine invokes another module, IEFVINC, to build
a new entry.
When the entry is complete, the control routine
branches to another module, IEFZNCODE; this one
compresses the JCL statement and stores an pointer
to the statement next to the procedure name in a
local work area.
The control routine, IEFYINA, continues reading
and compressing data until it encounters some kind
of delimiter. When it reaches a PEND statement
signifying the end of a procedure, it returns control
to the converter GET routine, IEFYHA, for the next
statement.
Symbolic Parameters
A user defines symbolic parameters either in
statements within a procedure itself or in
statements that override the statements in a
referenced procedure (for example, one in the
procedure library). Therefore, the Converter may
encounter symbolic parameters in three places:
• In an EXEC statement that calls a procedure.
•
Section 2: Method of Operation 3-219
• In input stream statements that override
procedure statements.
• In statements within a procedure.
When a symbolic parameter is specified on an
EXEC statement, the converter scan routine,
IEFVF A, uses the symbolic parameter processing
routine, IEFVFB, to place an entry in a table of
symbolic parameters and assigned values
(SYMBUF).
When a symbolic parameter appears in an
input-stream statement or in a statement in a
procedure, IEFVFB, substitutes a corresponding
value already in a symbolic parameter table entry
for the symbolic parameter.
Command Statements
When the converter verb identification routine,
IEFVHCB, cannot recognize a verb, it assumes that
the verb is a command. The command validation
routine, IEFVHM, verifies that the verb is one
allowed in the input stream and issues an SVC 34
(the command scheduling supervisor call) to
execute the command.
Service Routines
During converter processing, most converter
routines use a set of service routines that perform
some common functions.
The message module, IEFVGM, puts the
converter messages into the message data set and
JCL statements into the list data set.
The operator message module, IEFVHR, places
messages intended for the operator into the
message data set.
The SWA (shceduler work area) manager
interface module, IEFVHQ, enables the converter
routines to assign control blocks to swA, to locate
blocks there, and to read from them and update
them on SWA, as well.
The Purpose of the Interpreter
The interpreter operates as a subroutine of the
Initiator but is actually called by SWA create
interface. The purpose of the, interpreter is to build
the scheduler control blocks rquired to execute a
job. The interpreter transforms the keywords and
parameters specified in the JCL statements to
specific table entries. In the interpreter, the JCL
statements appear in the form of JCL text, the
output of converter processing.
3-220
OS/VS2 System Logic Library Volume 3 (VS2 Release 3.7)
When interpreter initialization is done, the
interpreter GET routine, IEFVHE, receives control.
It determines whether a statement it is processing is
a JOB, EXEC, or DD statement and then routes it to
an appropriate processor.
The JOB Statement
The JOB statement processor (IEFVJA), initializes a
job control table (JCT) and the job account control
table (JACT) for a job. It also checks the validity
of the JOB statement keyword values and enters
them into the tables.
The EXEC Statement
IEFVEA processes EXEC statements. It creates a
step control table (SCT) and a step account table
(ACT) for each EXEC statement. IEFVEA also
chains the job file control blocks (JFCB) whenever
a JOBLIB has been specified, and chains the SCT
for data set concatenations.
The DD Statement
The DD statement processor (IEFVDA) creates the
step input/output tables (SlOTs) and JFCBs for a
step and a data set enqueue table (DSENQ table)
entry for all data sets explicity named by the
DSNAME parameter. IEFVDA marks each data set
entry in the DSENQ table as exclusive or shared
according to the user's specifications.
Service Routines
The interpreter initialization routines, perform
several common functions by using a set of service
routines.
The message module, IEFVGM, puts the
interpreter messages into the message data set.
The operator message module, IEFVHR, also puts
messages intended for the operator into the
message data set.
The SWA manager interface module, IEFVHQ,
enables the interpreter to assign control blocks to
sw A, to locate blocks there, and to read from them
and write to them.
The statement processors, IEFVJA, IEFVEA, and
IEFVDA, use a special set of service routines for
functions common to them.
The interpreter GET parameter routine, IEFVGK,
locates each parameter for the command statement
processor. It branches to an appropriate keyword
subroutine to perform a basic check for errors and
then returns to the command statement processor.
The test and store routine, IEFVGT, enables the
command statement processor to determine what
processing must be done for each parameter. There
is a parameter descriptor table (PDT) that lists each
keyword, the operation to be performed for it, and
the location at which the results must be stored.
The EXEC and DO statement processors, IEFYEA
and IEFVDA, respectively, use a dictionary entry
routine (IEFYGI) to place an entry in the
"refer-back" table. They also use a dictionary
search routine, IEFYGS to search the "refer-back"
table for the address of an existing SCT, SlOT, or
JFCB. Both IEFVGI and IEFYGS return to the calling
routines.
)
Section 2: Method of Operation
3-221
3-222
OS/VS2 System Logic Library Volume 3 (VS2 Release 3.7)
,,-~~y
,----"
From the job entry
subsystem or the
Master Subsystem
Input
1
Initialize the converter. (See M.O.
Diagram - Converter:
Initialization (lEFVH1).)
2
Identify verbs on JCL statements. If
necessary, merge them with statements
from a cataloged procedure. (See M.O.
Diagram - Converter: Identifying
Verbs in JCL Statements (I EFVHA,
IEFVHC, IEFVHCB, IEFVHEB).)
3
Process any commands in the input
stream. (See M.O. DiagramProcessing Commands in the Input
Stream UEFVHM).)
NEL
4
Process in-stream and cataloged
procedures. (See M.O. DiagramConverter: Processing In-stream and
Cataloged Procedures (JEFVINA).)
5
Process symbolic parameters.
(See M.O. Diagram - Converter:
Processing Symbolic Parameters
(lEFVFA,IEFVFB).)
List of
parameters
6
LJ
Convert JCL statements to internal
text. (See M.O. DiagramConverter: Converting Statements
to Internal Text (lEFVFA).)
7
Enter defaults into internal text.
(See M.O. Diagram - Converter:
Entering Defaults into Internal Text
(JEFVFA).)
8
Terminate converter processing.
(See M.O. Diagram - Converter:
Termination (JEFVHF).)
NEL
C"Il
it
~.
=
~
a::
~
e.
~
o
"CI
I·=
~
~
eN
Figure 2-17a. Converter Visual Contents
In-stream Directory
and Records
D
Symbolic Parameter
Buffers
w
N
~
Diagram 12-1. Converter: Initialization (IEFVH1)
From the master subsystem or
the job entry subsystem
o
~..,
fI'.l
~
a
i
(')
j
(part 1 of 2)
Input
E
Register 1
~D
1
Register 12
~
E'
a
c
2
I nitialize the converter work area.
3
If SMF processing is required, get
storage for and initialize a job
management record (JMR).
w
'
~
o
Ie·
1:1
~
to.J
to.J
....
3
rEFVHCB checks the JCL statement for a valid verb.
IEFVHCB
4
It updates the statement parameter list based on its
findings.
IEFVHCB
(part 2
Label
of 4)
~
N
Diagram 12-2. Converter: Identifying Verbs on JCL Statements (part 3 of 4)
~
~
N
fI)
~
B
.
i£_M:h.
Register 12
Register 9
S
~
X/
I"
-"
~
II
Overrides Identified
Converter Work Area
-
-...
~
9
10
Perform SMF processing, if
required.
Branch to appropriate routine.
•
To IEFVHA or IEFVFA
~~
~~
~-
Diagram 12-2. Converter: Identifying Verbs on JCL Statements (part 4 of 4)
Extended Description
Module
5
IEFVHCB
IEFVHCB merges JCL statements from the JCL data set
and the procedure library as follows:
When it encounters a procstepname.ddname in a DD
statement from the JCL data set, it sets an indicator in its
parameter list and continues normal processing. Each time
IEFVHCB again receives control to examine a DD statement
from the procedure library, it compares the procstepname
from the JCL data set to the one from the library. If it
finds a match, it uses the override information from the
statement in the JCL data set to process the statement from
the procedure library.
If IEFVHCB does not find a match before it encounters the
next EXEC statement from the JCL data set, it simply adds
the DD statement wit-h the override information to the
other DD statements for the previous step.
6
Whenever IEFVHCB recognizes a RESTART keyword
IEFVHCB
parameter on a JCL statement and has previously found
a SYSCHK DD statement, it sets an indicator in the converter
work area before it passes control to IEFVHEB.
IEFVHEB
IEFVHEB (see Step 8) continues processing JOB, EXEC, and
DD statements.
Label
Extended Description
7
If IEFVHCB has identified a NULL verb on a statement,
it passes control to IEFVHL.
If it has identified a PROC statement, it branches to
IEFVINA.
If it has not been able to identify the verb, it assumes the
verb is a command and passes control to IEFVHM, the
command verb validation routine. IEFVHM uses the print
routine in IEFVHEB to print the command statement.
(See Step 8,)
IEFVHM
8
IEFVHEB
When the print routine in IEFVHEB has received
control from I EFVHC or IEFVHM, it moves the JCL
statement passed to it into an output buffer and branches to
IEFVGM, the converter/interpreter message module.
I EFVGM puts the statement into the list data set. The list
data set contains all the JCL statements that must be
printed on an output listing.
When IEFVHEB has received control from IEFVHCB, it
performs pre~scan processing as well printing the JCL
statement.
9
If necessary, IEFVHEB branches to an SMF user exit
routine.
IEFVHEB
When a comment has been completely processed, and
there are more statements to be processed, I EFVHEB
returns control to I EFVHC which returns to the GET
routine, I EFVHA, for the next statement.
IEFVHEB
10
Otherwise, IEFVHEB branches to IEFVFA, the post-scan
routine for further processing.
fIl
(D
~
e'
=
~
a:
sa-
5"
Q.
S.
o
."
(D
;
~.
=
~
N
N
IoC
Module
Label
_7
~
Diagram 12-3. Converter: Processing Commands in the Input Stream (IEFVHM)
~
From IEFVHCB, the Verb
Identification routine
&5
~
(part 1 of 2)
Output
Input
~
rIl
1
a
1
in
t""
a:
Validate the command by checking
it against the command compare
table.
Error
message
~
i
(D
~
~
~
~
i'
~
~
~
Command Compare Table
(in IEFVHM)
D
2
If the command is valid, issue
SVC 34, the command processor
supervisor call.
To IEFVHA, the converter
GET routi ne.
cJ)
~:~
Data
Set
~
--'"
"'---.7
Diagram 12-3. Converter: Processing Commands in the Input Stream (IEFVHM) (part 2 of 2)
Extended Description
Module
When the verb identification routine, IEFVHCB, is unable
to recognize a verb on a JCL statement, it assumes the
verb is a command and passes control to the command verb
validation routine, IEFVHM.
1
IEFVHM verifies that the command is one that is
allowed in the input stream by checking it against a
command compare table.
IEFVHM
2
IEFVHM
IEFVHM checks a disposition associated with the
command in the interpreter entrance list (NE LL
If the disposition is 0, IEFVHM causes the command to be
executed by issuing an SVC 34.
If the disposition is 1, I EFVHM writes the command into
the list data set by branching to I EFVGM, then it displays
the command to the operator by branching to the operator
message module, IEFVHR; finally, IEFVHM executes the
command by issuing SVC 34.
If the disposition is 2, IEFVHM displays the command to
the operator and requests his authorization to execute the
command. When the operator replies in the affirmative,
IEFVHM executes the command by issuing SVC 34.
If the disposition is 3, IEFVHM ignores the command.
In any case, IEFVHM returns control to the GET routine,
IEFVHA.
en
i
::s
~
a:
[
2o
I
15·
::s
-t
w
Label
'-
-,
~
~
Diagram 124. Converter: Processing In-stream and Cataloged Procedures (IEFVINA)
~
~
~
~
(part I of 2)
From IEFVHCB, the Verb
Identification routine
Input
Output
~
1:1)
~
a
r-
.ir;r-
J
~
f!
~
<
In-stream
Register 9
'\
1
For the first in-stream procedure
statement in a job, build a QMPA.
2
Check for errors on in-stream
procedures.
'\-1--JC-L-sta-te-me-n-t-----,
In-stream Procedure
Parm. List
CJo
Converter Work Area
Procedure name
1:1)
~
~
1
Error Message
(1)
i
r6
~
:....
3
Search the in -stream procedure
directory for the specified procedure.
SVA of first
record in procedure
J
In-stream
procedure
directory
InSWA:
4
If the specified procedure is not
found, build a directory entry for it.
In-stream
procedure directory
i
i
New
procedure
entry
To IEFVHA
~
'~
Diagram 12-4. Converter: Processing In-stream and Cataloged Procedures (IEFVINA) (Part 2 of 2)
Extended Description
Module
~
5'
=
N
~
~
go
Q.
o....
o
"0
(D
~
5'
=
IN
N
IN
IN
Extended Description
Module
3
IEFVINA is the control and GET routine for in-stream
procedures. It receives control from IEFVHCB, the verb
identification routine.
en
(D
Label
1
When IEFVHCB encounters a PROC statement that is
the first statement in an in-stream procedure, it
obtains storage for a queue management parameter area
(OMPA) and an in-stream procedure work area; then it
branches to IEFVINA.
IEFVHCB
2
When IEFVINA receives control, it in turn branches
to IEFVINE, the in-stream procedure syntax check
routine. This routine checks the validity of the label and
operation fields in the PROC statement and passes a
return code to IEFVINA.
IEFVINA
IEFVINE
If the return code is 0, 12, or 16, the PROC statement
contains syntax errors and IEFVINA sets a job-fail
indicator in the JCT and uses the message module,
IEFVGM, to issue an appropriate error message.
IEFVINA
IEFVCM
If the return code is 8, there are no syntax errors in the
PROC statement, and IEFVINA initializes the OMPA
and checks the converter work area to determine if the
procedure being processed is the first in-stream procedure
in this job. If it is. control passes to I EFVINC. the instream procedure directory build routine. If it is not, the
module builds a parameter list and branches to IEFVINB,
the in-stream procedure directory search routine, instead.
IEFVINA
IEFVINC
IEFVINB
IEFVINB
IEFVINB scans the entries in the in-stream procedure
directory searching for the procedure name specified in
the PROC statement. When the procedure name is found.
this routine obtains the SWA virtual address of the first record
containing the procedure and places it in the return code
field of its parameter list. If the procedure is not found. the
routine sets a return code of zero in the parameter list before
branching to IEFVINC. which will build a procedure directory IEFVINC
entry.
4
IEFVINC enters the procedure name in the directory
IEFVINC
and invokes the SWA manager interface routine, I EFVHO,
to assign the entry to SWA. I EFVI NC then takes the SWA
address of the entry returned from I EFVHO and places it
in the directory next to the procedure name. IEFVINC
returns to IEFVINA; IEFVINA then branches to IEFVHA
for the next statement in the procedure.
Label
t
•
Diagram 12-5. Converter: Processing Symbolic Parameters (IEFVFA and IEFVFB) (part 1 of 2)
eN
i
"<
From IEFVHEB,
the converter
routine
Input
Output
Process
fI.)
N
fI.)
'<
Register 2
Register 9
~
~
b
1
, Input Buffer
4!9.
n
Identify symbolic parameters.
JCL statement
t""
rt---,
Error message
i
~
<.
o
[
Symbolic parameter table entry
(II
eN
Address of this entry
~N
Entry
length
I
eN
:...:.
For an EXEC PROC statement,
enter the values assigned to the
symbolic parameter into the
symbolic parameter table.
3
Make required substitutions for
symbolic parameters.
Address of next entry
't"
-
2
~
I
Parameter
length
I
Symbolic Parameter
Value
length
~~
I
Value
L..
T
..
T
Register 9
Input Buffer
4
Continue scan processing in
IEFVFA.
JCL statement
To IEFVHF, the post-scan
and termination routine
Intermediate statement
buffers
~
"---~
Diagram 12-5. Converter: Processing Symbolic Parameters (IEFVFA and IEFVFB) (part 2 of 2)
Extended Description
Module
IEFVFA performs three other major functions:
A symbolic parameter that appears in an input stream
statement that overrides a procedure statement, or in a
statement in a procedure, is immediately preceded by
an ampersand (&)'.
Whenever IEFVFA detects a symbolic parameter, it
branches to the symbolic parameter processor, IEFVFB,
rn
ite'
1:1
~.
I
Co)
"'"
o
1e'
1:1
~
CM
CII
a
IEFVFB
If not, the routine initializes one, and creates an entry
containing the symbolic parameter and its value.
If a symbolic parameter table has been initialized, IEFVFB
searches it for an entry corresponding to the current
symbolic parameter. If no such entry exists, the routine
creates one; if an entry exists, the routine ignores the
current assigned value.
This method-of-operation diagram describes the detection
and processing of symbolic parameters. The other two
functions are described in the two method-of-operation
diagrams following this one.
A symbolic parameter that appears in an EXEC statement that calls a procedure has the format of an EXEC
statement keyword parameter. IEFVFA searches a scan
dictionary for each JCL statement it processes. If it does
not find a match for an EXEC statement keyword, it assumes
that the keyword and its associated parameter are a
symbolic parameter and its assigned value.
Module
For an EXEC PROC statement, IEFVFB verifies that
the EXEC statement calls procedure, then determines
whether a symbolic parameter table has been initialized for
this procedure.
1. Detecting symbolic parameters.
2. Converting JCL statements to internal text.
3. Default processing.
IEFVFA may encounter s\,mbolic parameters in EXEC
statements that call procedures; in input stream
statements that override procedure statements, or in
statements within a procedure.
Extended. Description
2
IEFVFA is the converter scan routine. It scans each JCL
statement for syntax errors and, if necessary, uses IEFVGM,
the message module, to issue an appropriate message.
1-
Label
IEFVFA
3
For symbolic parameters in overriding statements or in
a procedure, IEFVFB searches the symbolic parameter
table for an entry that matches the current symbolic
parameter. If it finds it, it Substitutes the value assigned to
the parameter in the table in an intermediate statement
buffer.
After making the substitution, IEFVFB invokes the ,message
module, IEFVGM, to issue a substitution message.
4
In any case, IEFVFB returns to IEFVFA, which continues
scanning the JCL parameters in the intermediate
statement buffer.
When IEFVFA has completed all processing, it branches to
IEFVHF, the post-scan and termination routine.
IEFVFB
Label
~
Diagram 12-6. Converter: Converting Statements to Internal Text (lEFVFA) (part 1 of 4)
~
~
From IEFVHEB, the
converter pre-scan routine
Input
Output
N
fI}
'<
I
i-
JCL statement
t'""
J
f
1
Register 10
Identify keyword parameters
in the scan dictionary and
check for mutual exclusivity.
Error message
w
~N
'i"
JCL statement
parameter list
(D
~
Scan dictionary entry
w
Length of this entry
~
Keyword
Internal text string
Keyword code
Mutually exclusive code
Overridden code
.....
Keyword
code
No. of
positional
parms.
Positional
parm.
no. 1
No. of
subparms.
-
2
JCL statement
parameter list
Convert keyword and
parameters by entering them
in internal text string.
Length of
parms. and
subparms.
Length of
subparms.
~
~_7
Diagram 12-6. Converter: Converting Statements to Internal Text (IEFVF A) (part 2 of 4)
Extended Description
Module
Label
Extended Description
Module
I EFVFA is the converter scan routine. It scans each JCL
statement for syntax errors and. if necessary. uses IEFVGM.
the message module, to issue an appropriate message.
2
IEFVFA
I EFVFA performs three other major functions:
• The keyword code.
1. Detecting symbolic parameters.
2. Converting JCL statements to internal text.
3. Default processing.
• The number of parameters for the keyword.
IEFVFA converts keywords and parameters into
internal text. Internal text contains the following
information:
• The length of the first parameter.
• The parameter in EBCDIC.
This method-of-operation diagram describes the conversion
of JCL statements to internal text. The other two
functions are described in two method-of-operation
diagrams, the one preceding and the one following this one.
1
As IEFVFA examines a statement, it looks up each
keyword in its own scan dictionary. For each valid
keyword, the scan dictionary entry corresponding to it
contains a one-byte binary code for that keyword and a
code for each keyword mutually exclusive with it. IEFVFA
sets flags in the duplicate table in the converter work area
for the codes corresponding to the mutually exclusive
codes. Every time another keyword is encountered, its
flag is checked in the duplicate table. If the flag is set,
IEFVFA branches to IEFVGM to issue a mutually
exclusive message•.
• The length of the next parameter. if any.
• The next parameter, if any, in EBCD IC.
IEFVFA
If the keyword is comprised of parameters and subparameters,
internal text contains this information:
• The keyword code.
• The number of parameters for the keyword.
• The length of the first parameter.
• The parameter in EBCDIC.
• The number of subparameters.
• The length of the first subparameter.
• The subparameter in EBCD IC.
• The length of the second subparameter.
• The second subparameter in EBCDIC.
The information in internal text varies with the number of
parameters and subparameters.
1:1.1
it
~.
::I
~
a::
a
[
a.
i
~
=8'
::I
~
W
'-I
Label
~
N
eN
Diagram 12-6. Converter: Converting Statements to Internal Text (IEFVFA)
(part 3 of 4)
00
~
N
C'I.I
Input
o
Process
i
i.
n
3
Put internal text string to
text data set.
4
Invoke the job entry subsystem.
5
When the entire job has been
converted to internal text,
invoke converter termination.
r-
J
~
[c
~
~N
~
i'
~
-
Converter work a rea
No continuation
indicated
eN
:....
To I EFVHF, the post-scan and
termination routine.
---------
~
"-___ 7
Diagram 12-6. Converter: Converting Statements to Internal Text (IEFVFA) (part 4 of 4)
g
g.
:I
~
r:
a
[
Sa
o
1g.
:I
~
eN
\C
Extended Description
Module
3
IEFVFA
IEFVFA sets a flag in the converter work area to
indicate that the current statement has been converted
to internal text. Later on, IEFVHCB will check that flag
and write the converted statement into the text data set
before beginning pre·scan processing of the next statement.
IEFVHCB
4
IEFVFA contains an interface to the job entry
subsystem (JES). JES makes any required changes in
the internal text string for SYSIN and SYSOUT processing
and then returns control to IEFVFA.
IEFVFA
5
IEFVFA
When IEFVFA has completed all processing, it branches
to I EFVHF, the post-scan and termination routine.
Label
~
Diagram 12-7. Converter: Entering Defaults into Internal Text (IEFVFA) (Part 1 of 2)
~
~
From IEFVHEB,
the converter
pre-scan routine
Input
Process
Output
w
fI.)
1
~
b
~.
,
.t"'"
ez
!
Register 9
A---~
r-
1
Check JCL statement for
"omitted" parameters with
default values.
2
Add prepared skeletal text
(keywords) to internal text.
JCL Statement
~
~w
ifC'"
In IEFVFA:
Skeleta I text
,----
~
d
NEL
Default
parameters
T ~ T
To IEFVHF, the post-scan
and termination routine
~
~y
Diagram 12-7. Converter: Entering Defaults into Internal Text (IEFVFA) (part 2 of 2)
Extended Description
Module
IEFVFA is the converter scan routine. It scans each JCL
statement for syntax errors and, if necessary, uses IEFVGM,
the message module, to issue an appropriate message.
IEFVFA performs three other major functions:
1. Detecting symbolic parameters.
2. Converting JCL statements to internal text.
3. Default processing.
This method-of-operation diagram describes default
processing. The other two functions are described in the
two method-of-operation diagrams immediately
preceding this one.
1
IEFVFA checks each JCL statement in the input buffer
for omitted parameters that have default values assigned
to them.
IEFVFA
2
IEFVFA
It appends skeletal text that represents the omitted
keyword parameters to the JCL statement that has
already been converted into internal text.
In addition to the keyword parameters, IEFVFA also places
their associated default values obtained from a list in the
NEL into the JCL statement. This completes default
processing.
When I EFVFA has completed all processing, it branches to
I EFVHF, the post-scan and termination routine.
f:Il
g.~
=
~
~
(D
[
o
~
o
"0
~
5·
=
'"fJ
~
~
Label
'_7
~
Diagram 12-8. Converter: Termination (IEFVHF)
~
Input
N
fI)
(put 1 of 2)
From modules (lEFVHL) or (lEFVFA) within the
diagram Identifying Verbs on JCL Stateme~ts
Process
,
i
i
J4
-
t 1I1f!ai1Bii.Jll&lWiiii1JJiiBii#i.....,l
Register 2
Register 12
I
i.
o
1
n
When termination is due to an
error. issue jobfail message.
r-
CN
00
o
If
N
Diagram 12-9. Interpreter: Initialization (IEFNB903)
~
From IEFIBSOO, the SWA
create interface routine
or from JES3
o
!!!
~
N
(part 1 of 2)
Input
Output
nterpreter
Work Area
fIl
I
ir-
c;:
Register 1
h,NEL
1
~w
!<
~
Register 12
Obtain storage for and initialize the
following:
•
Interpreter work area.
•
I/O buffer
•
JMR
•
DSENQ table.
I/O Buffer
c:::J
JMR
a
~
(I)
CN
'';i'J>fPi;'~'I
W
00
~
SCTs
3
Write the JCT, JCTX, and SCTs
for this job into SWA.
See diagram of Analyzing Parameter Values (I EFVH E)
or
Interpreter Termination (lEFVHN)
<=>
W
00
o
~
,----'
Diagram 12-11. Interpreter: Creating and Chaining Tables (IEFVGT)
Extended Description
Module
2
IEFVGT
The control information portion of a parameter PDT
entry defines the operations to be performed when the
parameter is processed, specifies the location in which the
results are to be stored, and may contain data to be used in
the operation. The control information portion may be up
to 15 bytes in length; it consists of the following fields:
• Function: The fi rst four bits of a control information
field contain a number from 0 to 7, which specifies one
of the following operations:
• OR (Code 0): A logical OR operation is performed,
using the bit pattern field in the control information
portion of the entry, against the bit pattern at the
location specified by the table and offset fields.
• CVB1 (Code 1): A convert to binary operation is
performed and a maximum value check is made. The
converted information is stored (right justified) in the
one-byte field specified by the table and offset fields,
and compared against the maximum value, which is
right-justified in the third byte of the control
information part of this entry.
• CVB2 (Code 2): This operation is si milar to eVB 1,
except that the result is right-justified in a two-byte
field, and the maximum value is found right-justified
in the third and fourth byte of the control
information portion of the entry.
• CVB3 (Code 3): This operation is similar to the CVB 1
and CVB2 operations, except that the result is rightjustified in a three-byte field, and the maximum value
is found in the third, fourth, and fifth byte of the
control information portion of the entry.
{I}
~
~
o·
=
N
~
~
g
Q.
....o
o
"0
~
~
S·
=
W
00
$
I
....
U
t"'"
2'
:I
(D
o
p
~
N
'<.
f4.
(part 1 of 2)
y
> 1
Issue message informing operator
that the job was failed.
d
.....
I'
Input/Output Buffers
I
~
I
..1\.
I'
2
Free work areas and control
blocks used by the interpreter.
DSENQ Table
CJ
Updated JMR
JMR
0
"
I'
3
PerformSMF processing, if
required.
4
Deactivate the interpreter
ESTAE environment.
5
Set return code and return to
original caller (SWA create
interface),
0
jI..
"
Register 15
(I EFIB600)
orJES3
.....
"
I
Return Code
I
Diagram 12-13. Interpreter: Termination (IEFVHN) (Part 2 of 2)
Extended Description
IEFVHN is the interpreter termination routine; it receives
control from I EFVHH.
1
If an error occurred during interpreter processing,
IEFVHN uses IEFVHR the operator message module to
issue an error message.
2
IEFVHN frees the interpreter's input/output buffers and
its local work area. If the SWA manager routines were
loaded during interpreter processing, it deletes those.
3
IEFVHN checks to see if SMF processing was performed
by the interpreter. If it was, a user routine was used;
I EFVHN deletes the user routine and writes the JMR
updated by SMF into the calling routine's storage.
4
5
IEFVHN deactivates the ESTAE environment over
the interpreter.
Finally, IEFVHN frees the DSENQ table and the
interpreter work area. It then sets a return code in
register 15 and returns to its caller, SWA create interface.
til
(1)
t')
g.
=
N
fie
(1)
~
~
o
o""'
"C
;
g.
=
~
N
(II
IC
Module
IEFVHN
Label
3-260 OS/VS2 System Logic Library Volume 3 (VS2 Release 3.7)
VS2.03.S04
SWA Manager
In MVS, to eliminate contention for job queue
resources, both the job queue and the queue
manager routines have been replaced. The
scheduler control blocks for all jobs now reside on
a pageable portion of virtual address space called
the scheduler work area (SWA). To access SWA,
system subcomponents must invoke a small set of
routines called the SW A manager.
Figure 2-18 illustrates the general format of a
control block in SW A, and an example of a specific
control block, the JFCB, as it appears in SWA. All
SW A blocks are preceded by prefixes.
The first field in the prefix contains a relative
block number (RBN). The RBN enables the system
to keep track of each job's sw A control blocks at
various points during its execution. In the event
that restart processing is necessary, the system can
use the RBN to reconstruct the SWA for a restarted
job.
The second field in the prefix indicates whether
or not the prefix has been initialized with the
appropriate control block 10 and acronym.
The third field contains the SWA vir;~ual address
(SVA), a pointer back to the beginning of the
prefix. This is for validity checking.
The fourth field is the SWA manager 10 for the
specific control block. The following is a list of
SWA lOs and the associated control blocks:
00
01
02
03
07
JCT
ACT
SCT
SlOT
OSNT
OA
POT
OC
SCT extension table
OF
OSENQ
IB
JMR
IC
JFCB
10
20
21
22
23
JFCX
25
.JWAB
26
VUT
POlO
POIB
POIQ
GOGN
27
DONT
28
AMPX
29
30
JFCE
The fifth field contains the length of the control
block.
The sixth field is the control block acronym.
The SW A manager routines, identified as load
module, IEFQB550, consist of four object modules:
two that actually perform SWA functions, IEFQB:i:iO
and I EFQB555, and two that intercept calls to
previously existing queue manager routines.
The two function modules each operate in a
different mode. IEFQB550 processes "move mode"
requests from calling routines; "move mode"
requests result in actual movement of data to or
from control blocks residing in SWA. IEFQB555
performs "locate mode" operations for calling
routines. A "locate mode" operation will return to
the calling routine either a SW A virtual address
(SVA) or a pointer to a SWA control block; no
actual movement of data occurs.
The following is a list of possible move mode
requests:
• ASSIGN results in initialization of a SWA
control block in a SWA subpool. An ASSIGN
request must be made for each control block
that is to be initialized by the SW A manager.
• ASSfGN/ST ART results in ASSIGN processing
for a job that is just beginning.
• WRITE results in movement of data from the
calling routine's buffer into a SWA control
block.
• READ results in movement of data from a
SW A control block into a calling routine's
buffer.
• DELETE results in a FREEMAIN for a SW A
subpool.
• WRITE/ASSIGN results in the movement of
data into one SW A control block and the
initialization of another block in SW A.
This is. a list of valid locate mode requests:
• ASSIGN/LOCATE results in initialization of a
SW A control block in a SW A subpool.
• WRITE/LOCATE causes a SW A control block
to be updated.
• READ/LOCATE returns the address of the
beginning of a SWA block, the block ID and
the block length, to the calling routine.
• OELETE BLOCK results in a FREEMAIN for a
SWA block.
JCTX
Section 2: Method of Operation 3-261
S{IIA PREFIX
80
1C
BO
JFCB
The JFCB
Figure 2-18. General Format of a SWA Control Block and an Example of the JFCB as it Appears in SWA
3-262
OS/VS2 System Logic Library Volume 3 (VS2.03.804)
~.,
~
SWA Manager
(no diagram)
.~
~
SWA Manager
Move Mode
(IEFOB550)
---
-_.
-
Figure 2-19. SWA Manager Visual Contents
rI)
a
(5'
...,
=
ac
S1
[
o
"""
o
Ie'
=
CoN
~
CoN
SWA Manager
Locate Mode
(lEFOB555)
---~.-.-
~_._7
~
N
:Diagram 13-1. SWA Manager Move Mode (IEFQB550)
(part 1 of 2)
0'1
~
&1
Via IEFOMREO
macro instruction
Input
Process
Output
"<
til
N
til
Register 1
SWA Manager Move Mode
'<
~
~
OMPA
1
&'
(5.
t-
g:
OMPOP
Function Code
Check OMPA for valid function
request:
'OO'X
'01'X
~
=
=
ASSIGN/START
ASSIGN
~
'02'X = WR ITE/ASSIGN
~
'04'X
C
:3
'03'X
~
=
=
WR ITE
READ
'08'X = DELETE
'<
til
N
~
~
i
ril
~
~
Created by the
calling routine
2
Process the indicated request by
branch ing to appropriate
subroutine.
Return to issuer of
IEFOMREO macro
,/IT;
Caller's Buffer
'-~
~
Diagram 13-1. SWA Manager Move Mode (lEFQB550) (Part 2 of 2)
Extended Description
Module
Control routine passes to the SWA manager move mode
function either directly from a routine requesting move
mode processing or from one of two modules that intercept
calls to previously existing queue management routines.
The first intercept module, IEFOB580, is the OMNGRIO
macro interface handler. It first checks for valid input
parameters in the parameter list pointed to by register 1.
The parameter list should contain a request for a READ or
WRITE function. If it doesn't, I EFOB580 issues a OBO
ABEND. When the input parameters are correct,
IEFOB580 uses them to build and initialize a queue management parameter area (OMPA) and an external parameter
area (EPA); it then invokes the move mode processor,
IEFOB550.
IEFOB580
IEFOBVMS
IEFOMLK1
IEFOMSSS
IEFOMRAW
IEFOAGST
c:n
(t
(")
S·
=
IEFOASGO
IEFOASGN
IEFODELO
IEFODELE
~
IEFOB550
IEFOB585
1
READ or WRITE
ASSIGN/START
If a WRITE/ASSIGN code is specified, the calling routine
is requesting a WRITE for one SWA block and an ASSIGN
for another block. I EFOB550 processes these requests
sequentially by branching to the appropriate subroutine.
ASSIGN
DELETE
IEFOB585 also calls IEFOB550. IEFOB550 returns control
directly to the original calling routine.
IEFOB550
Q.
1
If the calling routine has specified an invalid function,
IEFOB550 places an appropriate error code in register
15 and issues a OBO ABEND.
IEFOB550
2
IEFOB550
o
.....
o
'g
~
S·
=
t..I
~
0\
CoIl
For an ASSIGN/START request, IEFOB550 branches
to a subroutine that sets the relative block number in
the OMPA to 0 and then branches to the ASSIGN
subroutine.
For a WRITE request, the WRITE subroutine first determines whether the SWA virtual address (SVA) in the EPA
is valid. If it is, it moves 176 bytes of data from the caller's
buffer to the specified SWA control block, and then updates
the SWA prefix if this is the first time the control block has
been written. It repeats this process as many times as necessary and then calls a journal write routine to update these
same SWA control blocks in the job journal. When that's
done, control returns to the original calling routine.
The DELETE subroutine simply issues a FREEMAIN macro
instruction for the subpool specified in the OMPA and then
returns to the caller.
ANY FUNCTION
~
(t
For one or more ASSIGN requests, the ASSIGN subroutine
issues a GETMAIN macro instruction for 192 bytes from the
SWA subpool specified in the OMPA (queue management
parameter area). * It places the virtual address of the SWA
storage in the external parameter area (EPA) and paritially
initializes a SWA prefix for the new block in SWA storage.
When a READ request is made, the READ subroutine checks
for a valid SVA and then moves 176 bytes of data from a
SWA block into the caller's buffer. It repeats the operation
for each READ request and then returns control to the
caller.
N
g
Extended Description
The ASSIGN subroutine repeats this entire process for as
many ASSIGN requests as there are; when it has finished,
it returns control to the calling module.
When IEFOB550 completes processing, it returns control
directly to the original calling routine.
The other module that intercepts references to previous
queue management routines is IE FOB585. Depending on
the entry point supplied by the calling routine, IEFOB585
inserts an appropriate function code in the OMPA. This
list outlines the possible entry points and their related
functions.
Label
* An important consideration in the assignment of SWA storage is the alternation of SWA subpools. During normal execution of problem programs, SWA consists of subpools 236
and 237. (During master scheduler initialization, the SWA
subpool is 241,) The SWA blocks for a task attached by
started task control (STC) routines reside in subpool 237;
STC's own control blocks reside in 236. SWA blocks for a
jobstep/task begun by the initiator are in subpool 236,
while the initiator's own blocks remain in 237. The alternation of SWA subpools ensures that STC's control blocks,
the initiator's control blocks, and the problem control
blocks always exist in separate subpools.
Module
Label
~
N
Diagram 13-2. SWA Manager Locate Mode (IEFQBSSS) (Part 1 of 2)
0\
0\
otil
Via SWAREO
macro instruction
t
"<
til
>A
~
til
'<
fRegister 1
~
~
(D
r'"
~
n'
r'"
c:
-<
(D
'<
-
V'
<:
o
~
EPA
...
i3
3=-
:
Parameter
List
3
-D;;
-
~
Next EPA
Next EPA
I
- 1
?
p
rocess
-..;
Output
SWA Manager Locate Mode
/,
-'")
r
1
1
Check OMPA for valid function
request:
'AL'
~
'WL'
'RL'
,J
'DB'
;
"
:~
= ASSIGN/LOC~TE
= WRITE/LOCATE
= READ/LOCATE
= DELETE/LOCATE
-
~ .~.
~
',~,
if
c
~
;
• """W,
~
PSA
'"
"
. . f----. TCB
~
~
~
~
"=
~, ~
~
;;,--y
t~
t~
~,
~::;
:i'
JSCB
~
2
;
Perform indicated function .
~;
~,
i
Jo.
"'V
3
EPA
-- -
Return to caller.
-
"'",
11
Return to caller of
SWAREO macro
'"
"'V
r
I
1::
I
r
:::::j
;-
~
;1
v
-
'.~
:<
-
-
"'-
>
:'
,;
.........
r-.......
-'
Job
Journal
'-
D
i
,.....
.;
;.!~
;,
, Next EPA
-
_=A
::'
,
SWAB~~
I,::
.:1H
\\:1
'"
~ ~~fiX
"".
"1,:
"
: >
r
;
:
I~
JSCB
€
{
l;{
':.:
'"
r:r
;;;<
;;;'
i;
~
':
1\.
~
(D
;;
l'
til
n>
§
"'V,;
[,!
J
OMPA
~
"---""
~"~
Diagram 13-2. SWA Manager Locate Mode (IEFQB555) (Part 2 of 2)
Extended Description
Module
The SWA manager locate mode function IEFOB555
receives control from routines that issue a SWAREO macro
instruction.
IEFOB555
1
IEFOB555 begins processing by checking for a valid
function code in the second field of the parameter list
passed by the calling routine. If the function code is invalid,
IEFOB555 places an error code in register 15 and issues a
aBO ABEND.
2
If the calling routine requested an ASSIGN/LOCATE,
IEFOB555 issues a GETMAIN macro instruction for
192 bytes of storage from the SWA subpool specified in
the OMPA.* It places the SWA virtual address (SVA) of
those 192 bytes in the EPA (external parameter area),
increases the relative block number in the OMPA, and
initializes a SWA prefix in the SWA storage it just
obtained. I EFOB555 repeats this entire process for each
ASSIGN request made by the caller.
If the WRITE/LOCATE function was specified by the
caller, IEFQB555 updates the SWA prefix as required and
repeats the operation for each WR ITE request. It also calls
the journal write routine to copy the newly updated SWA
blocks into the job journal.
If READ/LOCATE was requested, IEFOB555 places the
specified SWA block address, 10, and block length in the
EPA. This enables the calling routine to directly address
the SWA block, bypassing the SWA prefix.
til
(D
sa.
~.
=
~
ac
(D
l
~
o
"0
~
=-
~.
=
~
t-.J
0\
"
If DELETE/LOCATE was specified. IEFOB555 simply
issues a FREEMAIN macro instruction for the SWA block.
3
When IEFOB555 has successfully completed processing, it places a zero return code in register 15 and
returns to the calling module.
IEFOB555
Label
Extended Description
*An important consideration in the assignment of SWA storage is the alternation of SWA subpools. During normal execution of problem programs, SWA consists of subpools 236
and 237. (During master scheduler initialization, the SWA
subpool is 241.) The SWA blocks for a task attached by
started task control (STC) routines reside in subpool 237;
STC's own control blocks reside in 236. SWA blocks for a
jobstepltask begun by the initiator are in subpool 236,
while the initiator's own blocks remain in 237. The alternation of SWA subpools ensures that STC's control blocks,
the initiator's control blocks, and the problem program
control blocks always exist in separate subpools.
Module
label
3-268
OS/VS2 System Logic Library Volume 3 (VS2 Release 3.7)
AIlocation/Unallocation •
Allocation/Unallocation can be divided into six
major functions:
• Batch Initialization and Control, which is
invoked by the initiator to provide allocation
and unallocation functions for jobs and
logons.
• Dynamic Initialization and Control, which is
invoked by SVC 99 or the dynamic allocation
interface routine (DAIR) to provide dynamic
functions for both the foreground and
background user.
• JFCB Housekeeping, which retrieves the
information necessary for allocation.
• Common Allocation Control, which processes
allocation requests, both batch and dynamic.
• Common Un allocation Control, which
processes unallocation requests, both batch
and dynamic.
• Volume Mount & Verify (VM&V) Control,
which processes requests from Common
Allocation and Common U nallocation to
unload and/ or mount and verify volumes.
The relationship of these functions is illustrated
in Figure 2-20. Background information on these
functions is presented in the following paragraphs
Figure 2-21 lists the method-of-operation (M.O.)
diagrams that describe each major function.
USER
~)
Batch
Initialization
and Control
Dynamic
Initialization
and Control
Note: Shaded area illustrates functions common to both batch and dynamic functions.
~
Figure 2-20. Relationship of the Six Major Functions of Allocation/UnaUocation
Section 2: Method of Operation
3-269
Related Method -Of-Operation Diagrams
Allocation/Unallocation Function
Batch Initialization and Control
IEFBB401
IEFBB410
IEFBB416
- Initiator/Allocation Interface
- Initiator/Unallocation Interface
- Job Unallocation
Dynamic Initialization and Control
IEFDB4AO
IEFDB400
IEFDB410
IEFDB450
IEFDB460
IEFDB470
IEFDB480
IEFDB490
-
JFCB Housekeeping
IEFAB451
IEFAB454
IEFAB469
- JFCB Housekeeping Control
- DO Function Control
-2JLOCATE
Common AlloOBtion Control
IEFAB421
IEFAB430
IEFAB433
IEFAB434
IEFAB436
IEFAB471
IEFAB476
IEFAB479
IEFAB485
IEFAB486
IEFAB490
-
Common Unallocation Control
IEFAB4AO
IEFAB4A2
IEFAB4A4
- 0 isposition Processing
IEFAB492
IEFAB493
- Allocation/VM & V Interface
- VM & V Control
Volume Mount and Verify (VM& V)
- Dynamic Unallocation Control
SVC 99 Control
Dynamic Allocation Control
Dynamic Concatenation
Dynamic Deconcatenation
Information Retrieval
Remove In -use Attribute
Ddname Allocation
Common A lIocation Control
Fixed Device Control
Specific Volume Allocation Control
Allocate Request to Unit
Nonspecific Volume Allocation Control
Generic Allocation Control
Allocation via Algorithm
Demand Allocation
Recovery Allocation
Offline/Allocated Device Allocation
Common Allocation Cleanup
- Common Unallocation Control
- Unit Unallocation
Figure 2-21. Allocation/UnaUocation Functions and Related Method-of-Operation Diagrams
3-270
OS/VS2 System Logic Library Volume 3 (VS2 Release 3.7)
Batch Initialization and Control
Data Set Requests and Unit Requests
Batch Initialization and Control, invoked by the
initiator, provides allocation and unallocation
functions for job/steps and logons. Common
Allocation Control and Common Unallocation
Control are called to process the allocation and
unallocation requests; the processing performed by
Batch Initialization and Control is basically
preparation: issuing status messages, testing
condition codes, building parameter lists for the
common functions.
Data set requests are represented by SlOTs; each
SlOT (that requires units) is represented by entries
in a volunit table built by Common Allocation
Control. The volunit table contains an entry for
every possible unit that each request might need. It
is/these volume/unit requests (each identified by a
volunit entry) that Common Allocation Control
considers when it allocates requests - not the data
set request as a whole.
For example, a data set was requested by means
of the following DD statement:
Dynamic Initialization and Control
Dynamic Initialization and Control, invoked by SVC
99 or the dynamic allocation interface routine
(DAIR), provides dynamic functions for both the
foreground and background user. Dynamic
functions include: dynamic allocation, dynamic
unallocation, dynamic concatenation, dynamic
deconcatenation, information retrieval, removal of
the in-use attribute, and ddname allocation.
Common Allocation Control and Common
Unallocation Control are called to process dynamic
allocation and dynamic un allocation requests.
JFCB Housekeeping
I~
)
JFCB Housekeeping is a common function, invoked
by both Dynamic and Batch Initialization and
Control when allocation requests are being
processed. JFCB Housekeeping determines what
additional data set information is needed to allocate
each request, places the information in tables
(SlOTS, JFCBs, and JFCBXS), and generates
additional tables if necessary.
Common Allocation Control
Common Allocation Control, invoked by both
Batch and Dynamic Initialization and Control,
processes allocation requests. Common Allocation
Control itself is divided into several functions;
basically, each function processes a certain type of
request or processes requests in a certain way.
Each distinct function is presented in a separate
method-of-operation diagram (listed_in Figure 2-21
and illustrated in Figure 2-26). The basic
philosophy of common allocation and background
information on the more complex functions are
presented in the following paragraphs.
IIDYD
II
DD
DSN=DATA,DISP=OLD,
VOL=SER=(A,B,C),UNIT=(3330)
Three volunit entries are created for this data set
request. The three vol unit entries indicate unit
affinity, which is implied by requesting more
volumes than units. To allocate this data set,
Common Allocation Control will allocate the three
requests represented by the three vol unit entries
(even though, in total, only one unit is allocated).
Order of Processing Requests
To allow as many allocations as possible to process
concurrently, Common Allocation Control is
designed to minimize serialization between different
allocations (that is, allocations for different users).
(Serialization can be defined as sequential
processing, as opposed to concurrent processing.)
To accomplish this, Common Allocation Control
processes requests in the following order:
1. Requests that do not require units and
volumes to be allocated: dummy data set
requests; via requests; subsystem (SYSIN or
SYSOUT) data set requests. No serialization is
required for this processing.
2. Requests that can be allocated to
permanently resident or reserved volumes on
direct access devices. Since these units are
inherently shareable, serialization is required
only with other system functions that might
modify UCBs - for example, pending-unload
processing and pending-offline processing.
Fixed Device Control processes requests in
this category; mUltiple allocations can occur
concurrently.
3. Requests for teleprocessing devices.
Serialization is required only with other
allocations of teleprocessing devices and with
other system functions that might modify
Section 2: Method of Operation 3-271
UCBS - for example, pending-unload
processing and pending-offline processing.
4. Remaining requests. Since the units to be
allocated are not inherently shareable, the
processing of these requests must be
serialized with other allocations and with
other system functions that might modify
UCBs. Generic Allocation Control, which is
invoked by Common Allocation Control to
try to allocate all remaining requests,
minimizes this serialization by serializing only
a subset of units. If all requests cannot be
satisfied by Generic Allocation Control,
Recovery Allocation is invoked; the units
serialized by Generic Allocation that are still
needed by unallocated requests remain
serialized for Recovery Allocation. Both
Generic Allocation Control and Recovery
Allocation are described in greater detail in
the following paragraphs.
Generic Allocation Control
Generic Allocation Control serializes only a subset
of units; it processes only one generic device type
at a time and, within that generic, it serializes only
those units (device groups) needed by u!1allocated
requests. (The order in which Generic Allocation
Control selects device types to process is dictated
by the installation device precedence list,
established during system generation.)
The guidelines by which the system determines
device groups are:
• If a user-assigned name (for example, SYSDA)
includes different generic device types, the
units in each generic belong to different
device groups.
• If a user-assigned name (for example, 3330A)
includes only a subset of the units in a
generic, that subset is a distinct device group.
• The intersection of any subgroups is a distinct
device group.
Note: For specific unit requests (that is, a unit
address was specified), all device groups within a
generic must be serialized.
Group Masks
Device groups are indicated in group masks, which
are simply fields containing bit positions for all the
device groups within all the generics in the system.
There is a mask in the eligible cievice table (EDT; a
sysgen table) for every possible. unit grouping
(either generic device type or user-assigned name).
For' example, the masks representing the unit
groupings illustrated in Figure 2-22 would contain
five bit positions, one for each device group. The
group mask for each unit grouping would be:
2400
2314
3330
SYSDA
3330A
3330B
Device Groups
Generic device types are divided into device groups,
as illustrated in Figure 2-22. The existence of
device groups allows an allocation to serialize on a
subset of units within a generic. For example, using
Fig\lre 2-22, if 3330A is requested, the allocation
needs to reserve only device group 4, rather than
all 3330 devices. As a result, more than one
allocation can process the same generic group as
long as the allocations require different device
groups within that generic.
2314
Device Groups
3330
SYSDA
-
Group Names
(defined by the installation)
Unit Addresses
00001
The masks are used to determine what device
groups must be serialized and when serialized
device groups can be released. Every data set
request (represented by a SlOT) is associated with
a list of the device types and devices to which it is
eligible (that is, to which it can be allocated). This
eligible device list (EDL) points to the mask(s) in
the EDT for the unit group(s) to which it is eligible.
2400
Generic Device Type
10000
01100
00011
00111
0Q01O
131
132
133
134
181
CD
Figure 2-22. The Division of Generic Device Types into Device Groups
3-272 OS/VS2 System Logic Library Volume 3 (VS2 Release 3.7)
182
0
183
----.
3330A
184
G)
191
192
G)
33308
--
~
193
194
G)
195
Recovery Allocation
The Retry Situation
Recovery Allocation receives control if all requests
were not satisfied by or prior to Generic Allocation
Control. (Recovery Allocation, however, will not
be called if a retry situation was detected in
Generic Allocation Control- see "The Retry
Situation.") Recovery Allocation handles the
following four situations:
• One or more tape requests could not be
allocated because the needed volumes are
mounted on a generic different from the
generic selected for allocation. (For
background information on tape requests, see
"Processing Tape Requests.")
• Nonspecific DASD volume requests indicate
volume affinity~ although at least one request
was successfully allocated, a subsequent
request could not be allocated because of a
DADSM error.
• Nonspecific tape or DASD requests could not
be allocated to mounted volumes.
• Needed units are offline or allocated to
another job.
It is possible to encounter a situation called retry, in
which a subset of the units on which a specifically
requested volume may be mounted are serialized.
Retry occurs when a. request could be allocated if
additional device groups were serialized, or if a
different eligible generic (tape only) were being
processed. For example (using Figure 2-22), a
request specified 33 30A, causing device group 4 to
be serialized. The request, however, requires a
volume currently mounted on a unit in device
group 5. Because that device group is not
serialized, the volume cannot be unloaded. This
request is marked for retry.
Retry situations are handled by Common
Allocation Cleanup~ Common Allocation Cleanup
unallocates all requests processed by Generic
Allocation Control and by Recovery Allocation (if
it was called) and then calls Common Allocation
Control. For each request marked for retry, all
device groups within the compatible generics will
be serialized.
Retry situations are detected by Generic
Allocation Control or Recovery Allocation. If a
needed tape volume is mounted on a different
generic device type, Generic Allocation does not
determine if that generic is serialized - the request
is marked for retry processing. See the following
description of "Processing Tape Requests."
Recovery Allocation results in one of the
following situations:
• The retry situation is detected. (See the
description under "The Retry Situation. ")
• The allocation is failed because of operator
intervention or an error detected by Recovery
Allocation.
• All requests are satisfied~ it is unnecessary to
wait for units allocated to other users.
• All requests can be satisfied only by waiting
for a needed device(s) to become available. If
the operator authorizes, the allocation will
wait for the needed device(s) to be
unallocated, either with or without holding
reSources already allocated (as directed by the
operator). If this allocation will wait without
holding resources, Common Allocation
Cleanup unallocates all requests successfully
processed by Generic and Recovery
Allocation and then calls Common Allocation
Control to reattempt this allocation when the
needed units are unallocated.
Processing Tape Requests
The dual density feature for tape devices allows a
tape device to support more than one density. If
tape device types support the same density, they
are considered compatible~ a tape volume can be
mounted on different device types, as long as those
device types are compatible. Figure 2-23 lists the
tape device types and the densities they support.
Using Figure 2-23, device type 2400-4 is
compatible to device types 2400, 2400-3, 3400-3,
3400-4, and 3400-6, because they all support a
common density~ a tape volume that can be
mounted on a 2400-4 can also be mounted on any
of the compatible device types.
Note: Seven-track and nine-track tape devices are
never compatible with each other, even though
they might support a common density.
Section 2: Method of Operation
3-273
Density
Generic Device Type
Nine-track tape device types
2400
2400-3
2400-4
3400-3
3400-4
3400-5
3400-6
Seven -track tape device types
2400-1
2400-2
3400-2
800 bpi
1600 bpi
800 or 1600 bpi
1600 bpi
800 or 1600 bpi
6250 bpi
1600 or 6250 bpi
200,556, or 800 bpi
200, 556, or 800 bpi
200,556, or 800 bpi
Figure 2-23. Tape Device Types and Supported Densities
Requested Generic Device Type
Generic Device Types Eligible to be Allocated to the Request
2400
2400, 2400-4, 3400-4
2400-1
2400-1,2400-2,3400-2
2400-2
2400-2, 3400-2
2400-3
2400-3,2400-4,3400-3,3400-4,3400-6
2400-4
2400-4,3400-4
3400-2
3400-2
3400-3
3400-3, 3400-4, 3400-6
3400-4
3400-4
3400-5
3400-5, 3400-6
3400-6
3400-6
Figure 2-24. Tape Device Eligibility
3-274 OS/VS2System Logic Library Volume 3 (VS2 Release 3.7)
Not all device types that are compatible,
however, are eligible to satisfy a single request.
Figure 2-24 illustrates the device types to which a
request for a· generic device type can be allocated.
For example, a user requested a 2400-4 tape
device for a data set. The data set can be allocated
only to a 2400-4 or 3400-4 device, although a
volume requested for this data set could be
mounted on any of the compatible device types
(2400, 2400-3, 2400-4, 3400-3, 3400-4, or
3400-6). An installation can define a user-assigned
name that includes one or more tape device types.
In this case, the eligible device types are only those
included in the user-assigned name. For example,
T APE A includes all 2400-4 devices. A request that
specifies T APEA is only eligible to the 2400-4
devices. It is not eligible to all the devices that can
be allocated to a request that specified the gen~ric
name 2400-4.
Tape requests are first processed by Generic
Allocation Control. If Generic Allocation Control
finds a needed tape volume mounted on a device
type different from the device type selected for
allocation, it determines if the volume is mounted
on a compatible device type. If so, the request is
marked for retry processing. Retry processing will
mark the request for processing by Recovery
Allocation. Otherwise, the· request is failed.
Recovery Allocation determines if the volume is
mounted on a device type eligible to the request. If
it is, the request will be allocated where the volume
is mounted. Otherwise, the volume must be
unloaded. If the device group containing the
required volume is not serialized, the request will
be marked for retry. (Retry is described under
"The Retry Situation.")
Common UnaUocation Control
Common Unallocation Control, invoked by both
Batch and Dynamic Initialization and Control,
processes unallocation requests. Its functions
include disposition processing, private catalog
unallocation, data set release, unit unallocation, and
volume release.
Volume Mount & Verify (VM&V)
Control
Volume Mount & Verify (VM&V) Control
processes requests from both Common Allocation
and Common Un allocation to unload, to rewind,
and/ or to mount and verify volumes. (Common
Unallocation calls VM&V Control only to unload
and/ or rewind volumes.) Volumes are rewound
and/ or unloaded as the need arises; volume
mounting and verifying, however, is not performed
until the end of Common Allocation Control
(during Common Allocation Cleanup).
AIlocation/UnaUocation Module Name
Conventions
Each allocation/unallocation module name has the
following format:
IEF_B4_
The IEF indicates the routine is part of the
scheduler; the B4 identifies the module as an
allocation/unallocation module. (A few allocation
modules begin with lEE; these allocation modules
are part of the Master Scheduler.) The fourth
character indicates the following:
• If A, the module is common to both batch
and dynamic processing.
• If B, the module performs batch processing
only.
• If D, the module performs dynamic processing
only.
The last two characters are a unique module
identifier.
Organization of
AIIocation/Unallocation
Method-of-Operation Diagrams
Figure 2-25 illustrates the processing hierarchy of
the diagrams for batch and dynamic processing;
Figure 2-26, the processing hierarchy of common
allocation diagrams. Figures 2-25 and 2-26 do not
indicate all calls to each module represented by an
M.O. diagram; they are intended only to provide a
general structure to the M.O. diagrams.
The method-of-operation (M.O.) diagrams are
arranged in alphabetic order according to the
module name of the major module described by the
diagram. As a result, diagrams for all functions
common to both batch and dynamic processing
(module titles of the form IEFAB4nn) precede the
diagrams for batch only processing (module titles
of the form IEFBB4nn), which in turn precede the
diagrams for dynamic only processing (module
titles of the form IEFDB4nn).
Section 2: Method of Operation
3-275
Selected Terms Used in
AIIocation/UnaUocation
Following 'are definitions of selected terms that are
not discussed in the preceding paragraphs but that
have special meaning to allocation/unallocation.
demand request: a request that requires a specific
unit; that is, a unit address was specified (for
example, UNIT= 190).
nomhareable request: a direct access request that
might require demounting and that therefore must
be allocated to a nonshareable device. A direct
access request is considered nonshareable if more
volumes than units were requested (implicit unit
affinity), if DEFER was specified in the UNIT
parameter, or if, in the case of explicit unit affinity,
more than one volume will use the unit.
private request: (1) for tape requests, a request
that specified PRIVATE; or that requires a specific
volume; or that does not request a temporary data
set. (2) for direct access requests, a request that
specified PRIVATE. (Note: Storage requests can be
changed to private requests if sufficient· storage
volumes are not available.)
public request: for both tape and direct access
3-276
OS/VS2 System Logic Library Volume 3 (VS2 Release 3.7)
requests, a request th~t did not specify PRIVATE,
that does not require a specific volume, and that
requests a temporary data set.
Segment: functional division of code in a module.
scratch request: identical to public request.
specific volume request: a request that requires a
particular volume; for example, a volume serial
number was specified; the data set is passed; the
data set is cataloged.
storage request: a direct access data set request
that did not specify PRIVATE, that does not require
a specific volume, and that is not temporary. (Note:
Storage requests can be changed to private requests
if sufficient storage volumes are not available.)
unit affinity: more than one request requires the
same unit. Unit affinity can be either explicit
(between data set requests when UNIT =AFF is
specified) or implicit (within a single data set
request when more volumes than units are
requested) .
volume affinity: . more than one request requires
the same volume. For example, two requests
specified the same volume serial number or a
request made volume reference to another request.
________=iT
~
Note: Shaded areas indicate functions common
to batch and dynamic processing.
I nitializing and
Controlling Batch
Allocation/Unallocation
(no diagram)
IEFBB410 Initiator/Unallocation
Interface
fIl
(II
~
e:t
~
a::
~
[
~
o
I
eN
~
~
Figure 2-25. Batch and Dynamic Allocation/Unallocation Visual Contents (Part 1 of 2)
~
~
~
o
~
Note: Shaded areas indicate functions common to
batch and dynamic processing.
Initializing and
Controlling Dynamic
Allocation/Unallocation
(no diagram)
~
til
1
I
i
t"'I
IEFDB400 SVC99
Control
ez
!
~
E'
g
~
IEFDB450 Dynamic
Concatenation
~
~
~
IEFDB470 Dynamic
Information
Retrieval
IEFDB490 Ddname
Allocation
i
~
~
,::,
IEFDB460 Dynamic
Deconcatenation
IEFAD480 Remove In-use
Attribute
IEFDB481 Remove In-use
Processor
Note: The processing of module IEFDB481 is
described on the diagram for IEFDB480, part
30f 4.
Control
Figure 2-25. Batch and Dynamic Allocation/Unallocation Visual Contents (part 2 of 2)
"'---"
' 14-1
I
EFAB421~
Common
Allocation
Control
r
~
IEFAB471 -
IEFAB430 -
I
1
, 14-3
IEFAB433 -
I
=r
I
Allocate
Request to
Unit
Allocate
Request to
Unit
VM&V
Control
~
t
r
1
E
IEFAB434 -
a::
Specific Volume
Allocation
Control
Allocate
Request to
Unit
I
114-4
o
o
ti
g"=~
.....
\0
IEFAB434 -
Allocate
Request to
Unit
Figure 2-26. Common Allocation Visual Contents
t
1
14-5-
T14-10
IEFAB436 -
IEFAB476 -
Specific Volume
Allocation
Control
Nonspecific Volume
Allocation
Control
Allocation
via
Algorithm
I
1 14-4-
er
I
14-3
IEFAB433 -
1
IEFAB433 -
"1:S
1 14-16
Allocate
Request to
Unit
(D
~
E
T
IEFAB493 -
(I}
[
Allocationl
VM&V
Interface
IEFAB434 -
IEFAB479 -
(D
Offlinel Allocated
Device
Allocation
IEFAB434 -
Demand
Allocation
=
~
IEFAB492 -
I
E
1 14- 15
IEFAB486 -
IEFAB434 -
r
~
, 14-13
Nonspecific Volume
Allocation Control
T14.4·
Common
Allocation
Cleanup
1
1
IEFAB436 -
Specific Volume
Allocation
Control
IEFAB490 -
Recovery Allocation
~
114-14
114- 12
IEFAB485 -
Generic
Allocation
Control
Fixed Device
Control
I
1
I
1 14-2
1 14-4
r
144 -
1
~
IEFAB434 -
IEFAB434 -
IEFAB434 -
Allocate
Request to
Unit
Allocate
Request to
Unit
Allocate
Request to
Unit
~
N
00
Diagram 14-1. IEFAB421 - Common Allocation Control (part 1 of 12)
Q
~
~
N
Ul
'<
;
b
~.
InDut
ENTRY from IEFBB404 (see IEFBB401 - Initiator/Allocation
Interface) or IEFDB413 (see IEFDB410 - Dynamic
Allocation Control) or IEFAB490 - Common
Allocation Cleanup
~
OutDut
/0 ~,- '''~.,/F;:J.;:<,,~>;.::Y··/
UCBs-updated
Common
Allocation
I.,
Common Allocation Control:
allocate units and volumes to requests.
lli
A
volumes
~UnlOaded
l""
J
1
~
Change status of devices,
if necessary.
J
J
Count Table
(II
w
J
'<
, #VIO Requests
Ul
N
i
II
-
#Dummy Requests
#Teleprocessing Requests
2
Prepare for allocation.
w
~
3
Process requests that do not
require units or volumes to be
allocated:
a)
B
# Specific Volume Requests
#Private Nonspec. Vol. Req
#Public Volume Requests
# Storage Volume Requests
# Subsystem Requests
#Graphic Unit Record Req
#Req to Allocate (variable)
dummy data set requests
\ #Total Requests (static)
b)
V 10 requests
c)
subsystem requests
If all requests are satisfied, go to
step 14.
\ #VOLUNIT entries
ALCWA
Count
able
BTI
Processed
SlOTs
counts
decreased
DSAB
TIOT
"""":"'-:7
~
~
Diagram 14-1. IEFAB421 - Common Allocation Control (part 2 of 12)
Extended Description
Module
Segment
Extended Description
Module
ENTRY
Common Allocation Control (I E F AB421)
controls the allocation of units and volumes
to requests. It is called by:
3
To eliminate unnecessary processing, Common Allocation Control first processes requests that do not
require units and volumes to be allocated:
IEFAB421
• Step Allocation Control (lEFBB404), when the allocation is batch (jobs and logons).
a) Dummy data set requests. If the DMYREOS field in the
count table does not equal 0, Common Allocation Control searches the SlOTs for the indicator that DUMMY
or DSN=NULLFILE (SCTDUMMY=1),
ONAME (SIOTONAM=1), or TERM=TS (SIOTTERM=1)
was specified. For each of these requests, Common
Allocation Control:
• Creates a DSAB and a TIOT entry.
• Marks the SlOT allocated (SIOTALCD=1).
• Decreases the DMYREOS and TOTREOS fields in
the count table.
IEFAB421
PROCSDMY
IEFAB428
IEFAB421
IEFAB421
PROCSDMY
PROCSDMY
b) VIO requests. If the VAMREOS field in the count table
is not equal to 0, VIO Allocation searches the SlOTs
for the VIO indicator (SIOTVAM=1). For each VIO
request, VIO Allocation:
• Places default space information in the JFCB, if
space information does not exist. (Default space
information is included in the non-executable
module IEFAB445.)
• Interfaces with DADSM to obtain a virtual UCB
a~dress and places the address in the SlOT.
• Creates a DSAB and a TIOT entry.
• Marks the SlOT allocated (SIOTALCD=1).
• Decreases the VAMREOS and TOTREOS fields in
the count table.
IEFAB431
• Dynamic Allocation Control (lEFDB410), when the
allocation is dynamic.
• Common Allocation Cleanup (lEFAB490), when the
allocation is being reattempted because of a retry situa-"
tion or because the operator autporized the allocation
to wait for a device(s) without holding resources.
1
If IEEBASEA indicates that units are" pending a
change of status (MSSUM=1), Common Allocation
Control searches the lOS UCB LUT to locate UCBs whose
status is to be changed. Depending on indicators in the UCB,
Common Allocation Control:
IEFAB421
OFFLINES
• Takes a unit offline.
• Unloads the volume on the unit.
• Changes a device's status to an active console.
Common Allocation Control issues a message to the operator informing him of the changed status.
2
CIJ
~
:4.
o·
=
~
i:::
~
[
o
~
o
"0
~
~
o·
=
~
N
00
""'"
Common Allocation Control issues a GETMAIN
macro instruction for the allocation work area
(ALCWA) and places information from the common
allocation parameter list in ALCWA. The allocation workarea serves as the communications area for all subsequent
processing. (For details on ALCWA, see "Section 5: Data
Areas.") Common Allocation Control also builds a count
table in ALCWA, containing both the total number of
requests and the different types of requests (see output
of step 2) that must be processed. At this time, the counts
in the count table reflect the number of SlOTs. The
TOTVOLUN field, representing the number of unallocated volunit entries in the volunit table (which is built in
step 4), is not initialized at this time. The count table is
updated to reflect unallocated volunit entries, rather than
SlOTs, in step 6. The counts in the count table are
decreased during allocation processing, as each request is
satisfied.
IEFAB421
IEFAB421
INITWORK
BLDCOUNT
c) Subsystem requests; for example, sysin and sysout.
If the SUBREOS field in the count table does not
equal 0, Subsystem Request Allocation searches the
SlOTs for the subsystem data set indicator (SIOTSSDS=1).
For each such request, Subsystem Request Allocation:
• I nterfaces with J ES2 to allocate the request.
• Creates a DSAB and a TIOT entry.
• Marks the SlOT allocated (SIOTALCD=1).
• Decreases the SUBSREOS and TOTREOS fields in
the count table.
If the TOTREOS field in the count table reaches 0, all
requests have been satisfied and processing continues
with step 14.
Segment
IEFAB431
VAMSPACE
IEFAB431
VAMDADSM
IEFAB428
IEFAB431
IEFAB431
IE FAB427
IE F AB427
IEFAB428
IEFAB427
IEFAB427
IEFAB421
B I LDSSA L
H
~
N
i
Diagram 14-1. IEFAB421 - Common Allocation Control (part 3 of 12)
Process
Input
A LCWA
4
i
5:
A LCWA
Determine device requirements for
requests not yet allocated.
a) Create volunit table, summarizing:
volume and unit requirements for
each unallocated requests.
!
i
Output
Volunit Table
Vol unit
Entry
::I
Volunit
Entry
CD
w
~N
~
f
~
A LCWA
ALCWA
b) Create eligible device lists (EDLs)
summarizing the devices eligible
to satisfy each unallocated request.
CSD
D
5
'"3
~
~
. - Last
\....SIOT
EDL
r=::r--L:J
Serialize further proceSSing of this
allocation with other processing
that can modify UCBs.
..
''Z-.3''
~
Diagram 14-1. IEFAB421 - Common Allocation Control
tI.l
~
a(5.
=
t-.J
:::
~
[
o
.....
o
"0
~
g.
=
w
~
00
w
(part 4 of 12)
Extended Description
Module
4
IEFAB423
a) Device Requirements Determination issues a
GETMAIN macro instruction to obtain space
for a volunit table. The volunit table summarizes the
volume and unit requirements of each request not allocated in step 3. For each unallocated SlOT, Device
Requirements Determination creates one or more volunit
entries in the volunit table; an entry is created for every
possible unit the request might need. As the entries are
created, Device Requirements Determination assigns the
same unitid to the entries for SlOTs that requested unit
affinity. (A unitid is an internal number used to identify
a unique unit request.) After the volunit table is built,
Affinity Resolution receives control to resolve volume
affinities. For direct access requests, where duplicate
volids are found (whether or not the unitids match),
Affinity Resolution creates a new unitid and propagates
the new unitid to all duplicate volids. For tape requests,
if duplicate volids exist and the unitids are different,
Affinity Resolution creates a new unitid and propagates
the new unitid to all duplicate vol ids. The volunit table is
then completed by initialiZing the status field of each
volunit entry. The status field includes bits that indicate
the type of request (for example, specific volume request,
public request, storage request, private request) and the
device class (for example, tape, direct access, unit record).
For details on the vdlunit table, see OS/VS2 Data Areas,
SYB8-0606.
b) EDL Build creates an eligible device list (EDL) for each
unallocated SlOT; information in the eligible device table
(EDT) is used to construct the EDLs. Each EDL summarizes the devices eligible to satisfy a request. EDL Build
issues a GETMAIN macro instruction to obtain space for
the EDLs. Before the EDLs are created, EDL Build saves
the DDR (dynamic device reconfiguration) count from
the CSD (common system data area). After the EDLs
are created, EDL Build again obtains the DDR count
from the CSD and compares it to the saved DDR count.
If the count has changed, DDR was invoked during creation of the EDLs and, therefore, the EDLs might be
invalid - EDL Build then frees the EDLs and repeats
this processing to build new EDLs.
Segment
IEFAB423
BLDVOLUN
IEFAB423
INITVOLN
IEFAB423
IEFAB426
UNAFFPRC
IEFAB424
IEFAB438
Extended Description
Module
5
IEFAB421
Common Allocation Control·enqueues shared on
SYSIEFSD (minor names Q4, CHNGDEVS,
DDRTPUR, DDRDA) in order to serialize the processing of
this allocation with other processing that might modify the
UCBs (for example, pending-unload processing, pendingoffline processing for units that become unallocated during
this allocation).
Segment
~
N
Diagram 14-1. IEFAB421 - Common Allocation Control
(part 5 of 12)
~
~
N
i
in
i
~
~
§
~
if
tI
w
:....
~
~stSIOT
Jo.
i,'"
tl 6
J
1
EDLs
I
If
I Updated
U
SlOTs
l
I
J
I' U~· U
List of UCB
Addresses
Selected by JES3
VOLUNIT Table
I U~·
q t
*Updated only if JES3
makes device selections.
"
ALCWA
,....--
A LCWA
r---
'bb
i. ;.~ ."
~
Volunot
Count
Table
~,
,Table. \. :,;.
i
TOTREOS=O
I
1
f
Pr_~
'=.~
~
.
'>,
•
.;.A
Count Table
I
JI.
Set up to handle any
device selections made
by the'JES3 subsystem.
VOlUNIT Table
SSOB
Return Code
0: JES3did
not make
selection
4: JES3did
make
selection
SSOBINDV
. 'J
EDL
Common allocation
function area in
SSOB· extension.
....
Output
A LCWA
fD
W
~N
((
Process
Input
It
r
>
7
If all requests are satisfied,
go to step 13.
Q
JFCB
C, SlOTs
Allocate direct access requests that
:. .'.• ,. •. . "
can be.nocated to pemoanently
resident or reserved volumes.
~
•
Count Table TIOT
.:.•.;.: . .
~
see
Fixed
Device
Control
(lEFAB430)
----71
......_ __
space obtained
(except tor ISAM)
~
Diagram 14-1. IEFAB421 -Common Allocation Control (Part 6 of 12)
Extended Description
Module
6
For each unallocated request, the JES3 interface
routine invokes the JES3 subsystem (via the SSOB
interface) to determine if JES3 has made device selections.
If it has, the EDL is updated so that only those devices
selected by JES3 are eligible for allocation. It also stores
the selected UCB addresses in the VOLUNIT table and
turns on the SlOTJES3 bit to indicate that this is a JES3
request .. If JES3 did not make device selections, all
units which are managed by JES3 are marked ineligible
for allocation in the EDL.
IEFAB422
7
IEFAB430
Fixed Device Control allocates requests eligible to per~
manently resident and reserved direct access volumes.
During Fixed Device Control, the count table is updated to
reflect the number of volunit entries still to be allocated,
rather than the number of SlOTs. (The TOTREOS field is
the only field that continues to represent a number of
unallocated SlOTs.) Individual fields (for example,
SPECREOS) and the TOTVOLUN field are decreased as
unit requests (that is, volunit entries) are allocated; the
TOTREOS field is decreased as SlOTs are completely
allocated. If the TOTREOS fieldin the count table reaches
0, all requests have been satisifed and processing continues
with step 13. For details on Fixed Device Control, see the
M.O. diagram Fixed Device Control (lEFAB430).
fI)
CD
$4-
e'
:s
!'t
~
CD
[
o
"""
o
Ie'
:s
::!
8:
IEFAB430
Label
UPDTCNT
~
Diagram 14-1. IEFAB421 - Common Allocation Control (part 7 of 12)
~
~
~N
rn
i
Input
A LCWA
i;;.
t""
er
!
8 Allocate requests for teleprocessing
f
y,
~:
devices.
~
~N
t'"
ALCWA
•
If all requests are satisfied, go to
step 13.
~
~
~
ALCWA
~
Volunit
Table
,
9
Reserve removable volumes
specifically requested by requests
not yet allocated.
volume serial
numbers enqueued
~
'-.7
Diagram 14-1. IEFAB421 - Common Allocation Control
Extended Description
(part 8 of 12)
Module
Segment
8
If the number of teleprocessing requests in the count
table is not zero (TPREOSf(}), Common Allocation
Control calls IEFAB425 (Process TP Requests). IEFAB425
.. enqueues exclusive on the allocation resource SYSIEFSD
(minor name ALLOCTP) to serialize its processing with
other allocations of teleprocessing devices. IEFAB425 then
searches the status field of each volunit table entry for the
indicator that a teleprocessing (communications) device is
requested. When it finds the indicator, IEFAB425:
IEFAB421
IEFAB425
• Selects a teleprocessing device from the EDL for this
SlOT.
IEFAB425
• Allocates the device to the request (see the M.O. diagram
Allocate Request to Unit (lEFAB434), if the device
is unallocated, is not an active console, and is not in use
by a system service. Otherwise, this allocation is failed.
IEFAB434
• Marks the volunit entry as allocated.
IEFAB425
• Marks the SlOT allocated (SIOTALCD=1) if allvolunit
entries for the SlOT are allocated.
IEFAB425
TPEDLSEL
IEFAB425 repeats this processing for each teleprocessing
request, decreasing the TPREOS alld TOTREOS fields of
the count table as each SlOT is allocated. When all teleprocessing requests are completed, IEFAB425 dequeues from the
allocation resource SYSIEFSD (minor name ALLOCTP).
9
r:I'.l
~
~
5·
:=
N
ac
t
~
Q
o"""
1a
e·
:=
w
N
00
.....
Common Allocation Control enqueues on the
volume serial numbers of removable volumes specifically requested by unallocated requests. The enqueue is
either shared or exclusive, depending on whether other
requests can share the volume. (For example, if the
volume might be demounted during execution of the
problem program or if the volume is tape, the enqueue
must be exclusive.) The status field in each volunit entry
indicates if a volume is specifically requested and if the
volume is shareable.
IEFAB421
DOVOLENO
:cco
Diagram 14-1. IEFAB421 - Common Allocation Control (part 9 of 12)
co
~
~
CIJ
N
f'-l
Input
Process
Output
'<
~
~
i
(s'
t:
A LCWA
r----
Count
Table
~
~
Attempt to allocate all remaining
requests by means of Generic
Allocation,
see
Generic
Allocation
Control
(lEFAB471)
~
[
(I)
CoW
~N
i
fe
CoW
~
If necessary, call Recovery
Allocation,
Count
Table
-.-
see
Recovery
Allocation
A
L-.3
.. DSAB
space obtained
(except for ISAM)
" (I EFAB485)1.....i.........:.,;;.;;.:.,..._--'-.......:.,;;_..:........;.;....,.,..;.;..;.;.;~___.......-........-..................._
~
Diagram 14-1. IEFAB421 - Common Allocation Control
fIl
0
The processing that occurs in each of these cases is
described in the M.O. diagram "IEFAB490 - Common
Allocation Cleanup."
(Allocate from Groups the Algorithm Picked) allocates
the outstanding requests, interfacing with ICBME for
Mass Storage System (MSS) mount equalization and the
System Resources Manager, to select the device to be
allocated. I EFAB434 actually allocates the device - see
I EFAB434
the M.O. diagram "IEFAB434 - Allocate Request to Unit."
~
Segment
An error occurring in any routine causes control to be
returned to the calling routine. In this diagram, errors in
steps 1-12 cause control to be passed to step 13.
When IEFAB421 receives control, it creates an ESTAE
environment so that its exit receives control if the
program abnormally terminates.
3-292
OS/VS2 System Logic Library Volume 3 (VS2.03.804)
Common Allocation
2 bytes
..
_,...£===;::===:::===;::==~
:=~F=u=n=ct=io=n:=M=a=p==:= ==== I ~ X X xl X X X xl X X X xl X X X X"
Parameter List
Conditions When Bit is On (=1)
Bit
Location
Meaning if Bit is On (=1)
Caller is Step Allocation
Control or Common
Allocation Cleanup for
batch allocation
Caller is Dynamic
Allocation Control or
Common Allocation
Cleanup for dynamic
allocation
Always
Depends on what user
specifies
1
Volumes can be mounted
2
Allocation messages to be written
3
Allocation can wait for units allocated
to another user
Only if request is not
a logon
Only in two situations
described in note 1
4
Allocation can wait for volumes
Only if request is not
a logon
Only in two situations
described in note 1
MSGLeVEL=(,1) was coded
5
Reserved
6
Allocation can consider offline devices
Always
Depends on what user
specifies
7
Mount requests to be issued in form
ofWTOR
Never
If bit number 1 is set on
8
Entire generic to be reserved for some
specific volume requests
9
Reserved
10
Allocation header message to be written
11
Allocation message for unit record
devices to be issued to console
12
Unallocation should indicate that
scratch function should not enqueue
on TIOT
13-16
Reserved
Retry is being performed
Never
Always
Monitor job names in effect
Always
Never
Note 1: Bits 3 and 4 are set on (=1) if the caller is Dynamic Allocation and if:
* A checkpoint data set is being allocated for use by the scheduler.
* A private catalog is being allocated for use by JFCB Housekeeping.
Figure 2-27. Function Map of Common Allocation Parameter List
Section 2: Method of Operation 3-293
C.N
~
Diagram 14-2. IEFAB430 - Fixed Device Control (part 1 of 4)
~
ENTRY from IEFAB421 Common Allocation Control
~
~N
Process
Input
t"'-I
~
Allocation Work
Area (ALCWA)
9
~(is"
~
CT
8<
e.
ALCWA
D
§
Fixed Device Control: Allocate
requests eligible to permanently
resident or reserved direct
access volumes.
1
':,?/<;ji::;.;~:{~
ALCWA
r----
--ALCWA
Count Table
2
Vol unit Table
Update count table to
reflect number of volunit
entries remaining to be
allocated.
Parameter
List
ALCWA
3
Build list of units on which
perma nently resident or
reserved direct access
.L
PRUST
(Permanently
Resident/Reserved List)
....
~
~
Diagram 14-2. IEFAB430 - Fixed Device Control (part 2 of 4)
Extended Description
ENTRY
Module
Segment
Fixed Device Control (Main Path Control) is
This step is performed only if the SPECREQS field
in the count table is not zero - that is, only if there
are specific volume requests to be processed. Specific
Volume Allocation Control allocates specific volume
requests if the requested volume is a permanently resident
or reserved direct access volume. For details, see the
M.O. diagram Specific Volume Allocation Control
(lEFAB433).
IEFAB433
2
IEFAB430
For each SlOT not yet allocated (SIOTALCD=O),
Fixed Device Control examines the unallocated
volunit entries and updates the count table to reflect the
number of volunit entries to be allocated. (Up to this
point, the count table represented the number of SlOTs
to be allocated.) The following fields in the count table
are updated:
• TOTVOLUN - total number of volunit entries remaining to be allocated.
• SPECREQS - number of specific requests.
• PVTNREQS - number of private, nonspecific requests.
• PUBLREQS - number of public requests.
• STRGREQS - number of storage requests.
til
(D
sa.
5'
=
!'t
a::
[
o
~
o
"I:t
q
ae'
=
w
~
\C
(A
Module
Segment
3
IEFAB430
BLDPRLST
This step is performed only if there are storage or
public requests to be processed (in the count
table, STRGREQS +- 0 or PUBLREQS +- 0). Fixed Device
Control builds a list of pointers to devices on which permanently resident or reserved direct access volumes are
mounted. To do this, Fixed Device Control searches
through the lOS UCB LUT for direct access UCBs that
meet the following conditions:
called by Common Allocation Control} to allocate direct-access requests that can be assigned to permanently resident or reserved volumes and to update the
count table.
1
Extended Description
• The volume mounted on the direct access device is
permanently resident (UCBPRES=1) or reserved
(UCBRSVD=1 ).
• The unit is not pending offline (UCBCHNGS=O) and
not pending unload (UCBUNLD=O).
UPDTCNT
• The unit is online (UCBONLI=1) and ready
(UCBNOTR 0=0).
• The unit is not being used by a system task
(UCBNALOC=O).
This permanent resident/reserved list (PR LIST) is used
by Nonspecific Volume Allocation Control - see step 4.
~
Diagram 14-2. IEFAB430 - Fixed Device Control (part 3 of 4)
~
~
~
...,
Input
~
~
II
]
i.
n
Allocate nonspecific direct
access volume requests that
can be allocated to
permanently resident or
reserved volumes.
t:
f
i
A LCWA
(II
eN
@
~
...,
i
R
eN
:..,
ALCWA
t:
1st SlOT
1
Y;
lLast
=VOIUnitTabl e
Perform validity check for
demand requests.
SlOT
I
Return to Common
Allocation Contro1
(lEFAB42U
space obtained
(except for ISAM)
Diagram 14.,2. IEFAB430 - Fixed Device Control
(part 4 of 4)
Extended Description
Module
4
IEFAB436
Nonspecific Volume Allocation Control processes
nonspecific volume requests that can be allocated
to permanently resident or reserved volumes. Fixed Device
Control calls this routine to allocate:
IEFAB430
=
~
a::
(D
g
Q.
o
"00)
o
't:I
Q
=-
(5'
=
\N
N
IC
.....,
IEFAB430
CHEKDMNC
5
Two or more requests can specifically request the
same unit (for example, two DD statements specify
UN IT=190) only if the following conditions are true:
• For nonspecific volume requests, none of the
requests are private or nonshareable.
To determine if the preceding conditions are satisfied
when two or more requests specify the same unit,
Fixed Device Control searches the SlOTs for demand
requests (SIOTDMND=1) and checks the status field
of the volunit entries for those SlOTs that request the
same unit. If the preceding conditions are not satisfied,
further processing of this allocation is terminated.
The parameter list includes a function map that indicates
the type of request Nonspecific Volume Allocation Control
should allocate. The parameter list also contains a pointer
to the permanently resident/reserved list (PR LIST) built
in step 5 - Nonspecific Volume Allocation Control uses
the PRLlST to build a list of units eligible to satisfy
fndividual requests. For details on Nonspecific Volume
Allocation Control, see the M.O. diagram Nonspecific
Volume Allocation Control (lEFAB436).
~
(5'
Segment
• Identical volume serial numbers are coded or
volume affinity is indicated; or,
c) Public requests to storage volumes if all public requests
were not allocated in the preceding call (4b).
(D
Module
b) The same volume can be used for both requests:
b) Public requests to public volumes if PUBLREas " 0 in
the count table.
I:'-l
Extended Description
a) The unit is a direct access device.
a) Storage requests to storage vol umes if STR G R E as " 0
in the count table.
When processing is complete, Fixed Device Control
issues a FREEMAIN macro instruction to release the
permanently resident/reserved list.
Segment
Error Processing
IEFAB430
An error in_any routine causes control to be returned to
the calling routine.
In the event of an abnormal termination, the EST AE
exit routine established by I EFAB421 performs any
necessary cleanup.
~
~
o
\N
00
~
~
Diagram 14-3. IEFAB433 - Specific Volume Allocation Control (part" of 4)
N
~
o
{Il
~
N
ENTRY from caller
(see extended description)
Input
A LCWA
§
it:;
~
I
~
~
r~
1st SlOT
'"
~
00
~
r __ OBIOCk
SlOT being
processed
IEFAB435
Parameter List
Return
to
Caller
cB
VM&V
Vol unit Table
~
IEFAB435
Parameter List
If error, retry, or recovery
situation detected, return
to caller.
UCB
b) Unload volume, if
necessary.
c) Build VM&V request block,
if necessary.
d) Update UCB.
SlOT being
processed
I
volume
unloaded, if
necessary
VM&V
yfuestbr
'----.Y
Diagram 14-4. IEFAB434 - Allocate Request to Unit (part 2 of6)
Extended Description
Module
2
IEFAB435 (Update UCB Routine) allocates the unit;
the processing of I EFAB435 includes the following
steps:
IEFAB435
• IEFAB425 to allocate teleprocessing requests.
a) If indicated by the caller of IEFAB434, IEFAB441
(Volume Validity Checker) receives control to validity
check this request. (The validity check is indicated
only if a specific volume was requested and that
volume is not mounted on the unit to be allocated.)
IEFAB441 scans the UCBs pointed to by the EDT
group entries to determine if the volume is mounted. If
the volume is not mounted, the validity check is
unnecessary; processing continues with step 2b. Otherwise, IEFAB441 determines if the request can be allocated. The following are the possible error conditions
that can be detected:
IEFAB441
• IEFAB436 to allocate nonspecific volume requests if a
volume is mounted.
• IEFAB441 to allocate requests when the needed volume
is found on an eligible unit other than the unit being considered (for example, a unit affinity request is being processed) and the volume is permanently resident or reserved.
• The device type of the unit containing the volume is
not compatible with the requested device type.
• IEFAB479 to allocate a unit that was specifically
requested.
• The volume is permanently resident or reserved and is
mounted on a unit that is not eligible to this request.
• IEFAB489 to allocate online devices during recovery
allocation.
1
IEFAB428 creates or updates a DSAB and TIOT
entry for this request, based on the parameter list it
receives as input from IEFAB434. If the volunit entry
being processed is the first volunit entry to be allocated
for this SlOT, the DSAB and TIOT entry must be created;
a group ID list is also created, indicating the device group
allocated to this request. If this is not the first volunit entry
to be allocated for the SlOT, IEFAB428 updates the existing DSAB, TIOT entry, and group ID list.
t;.
=
~
..S
a::
CD
Q.
....
l'II
Segment
• The unit is in use by a system task (UCBNALOC=l).
• IEFAB478 to allocate requests processed by the algorithm.
CD
Module
IEFAB434 (Allocate Request to Unit) is the
common service routine that actually allocates
a request to a unit. It is called by:
• IEFAB433 to allocate specific volume requests if the
volume is mounted.
$4
Extended Description
ENTRY
• IEFAB432 to allocate requests that specified affinity to
an allocated request.
rI}
Segment
IEFAB428
• The volume is mounted on a unit allocated to another
user, and this allocation is not allowed to wait for
units, as indicated in the common allocation parameter list (see figure 2-27). (If this allocation can wait
for units, the request is marked for recovery
processing.)
If the volume is located on a device group that is not
serialized, the request is marked for retry processing
(SIOTRTRY=l); ALCWA is also updated to indicate
retry is necessary (lNDRETRY=l).
If no error, retry, or recovery situation is detected,
allocation of this request continues.
b) IEFAB49C unloads the volume currently mounted on
the unit, if that volume cannot be used.
IEFAB49C
c) IEFAB435 builds a VM&V request block for this
SlOT, if a volume must be mounted on the unit. (The
volume will be mounted after all requests have been
satisfied - see the M.a. diagram Common Allocation
Cleanup (lEFAB490).
IEFAB435
VMVSETUP
d) IEFAB435 updates the UCB to indicate it is allocated.
IEFAB435
UPDUCB
0
0
"C:I
~
at;.
=
w
W
Q
w
Diagram 14-4. IEFAB434 - Allocate Request to Unit (part 3 of 6)
~
w
2
0f:I)
~
N
Input
Output
Process
f:I)
'<
=-~
cin·
t!
2"
~
~
cr
a
w
00
~
ALCWA
Volunit
Table
1st SlOT
/VfJbein
g
~
2
Locate eligible volunit entry to be
processed.
•
If all eligible volunit entries
processed, go to step 1 to select
next SlOT.
ALCWA
1st
SlOT
/~LJ
\
SlOT being
processed
LJ
Diagram 14-5. IEFAB436 - Nonspecific Volume Allocation Control (part 2 o(6)
Extended Description
ENTRY
Nonspecific Volume Allocation Control
(lEFAB436) is called by Fixed Device Control (lEFAB430), Allocation Within Generic (lEFAB475),
and Recovery Allocation (IEFAB485) to allocate nonspecific volume requests to mounted volumes. IEFAB436
allocates one of the following types of requests each time
it is called:
• Storage requests to storage volumes.
• Public requests to public volumes.
• Public requests to storage volumes.
The type of request to be allocated is indicated in the
function map of the parameter list passed to IEFAB436.
Note: The processing of IEFAB436 isa series of loops.
Step 1 locates a SlOT to be processed; steps 2-8 are performed to locate and process each eligible volunit entry
for a selected SlOT. The processing of a single volunit
entry can involve loops through steps 3-6 or through
steps 3-7, if the volume mounted on a unit selected for
the volunit entry cannot be used. The extended description of each step describes the circumstances under which
it is performed.
en
(D
a
~.
::I
~
iC
(D
[
Sa
o
."
g.9
::I
eN
W
$
Module
Segment
Extended Description
Module
1
IEFAB436 scans the SlOT chain to locate a SlOT that
is not allocated (SIOTALCD=O) and that is not marked
ineligible (SIOTGIGN=O). (When the caller is Fixed Device
Control, no SlOTs are marked ineligible; Allocation Within
Generic is part of Generic Allocation Control, which processes only one generic device type at a time - all SlOTs
except those eligible to the device type being processed are
marked ineligible; when the caller is Recovery Allocation,
all SlOTs except those to be processed are marked ineligibleJ If all eligible SlOTs have been processed, step 10
receives control.
IEFAB436
2 . IEFAB436'checksthe status field of unallocated
IEFAB436
volunit entries for this SlOT to locate a unit request
. to be processed: a request for a public volume if public
requests are being processed; or a request for a storage
-volume if storage requests are being processed. If no eligible volunit entries are located, IEFAB436 selects another
SlOT - see step 1.
Segment
«f
w
e
o
~
til
N
til
'i
9
i-
Diagram 14-5. IEFAB436 - Nonspecific Volume Allocation Control (part 30(6)
..
Input
Parameter List
PSLlST*
~~
t-
J
~
2'
a
CD
w
ALCWA
.....---
<.J
"-
3
Build or update list of UCBs
eligible to this volunit entry
(PSLlST).
•
PUblic/Storage List
(PSLlST) -created or updated
If PSLlST does not contain
entries:
a) Change storage requests to
private, if necessary.
1st
SlOT
'
tN
00
~
,.
JFCB Housekeeping
Parameters
Function Map
--
-.- --..
~
Housekeeping
Workarea (HSKPWA)
JFCB Housekeeping Control: Retrieve information
necessary for allocation.
Controls
, 1st SlOT to process
1
Step Number
r
Establish EST AE environment and prepare for
JFCB Housekeeping processing .
Data Area
• JCT
tSCT
Return Info
...~ Last EPA Pointer
~
4Special EPA Ch~in or 0
"
.IOS UCB LUT
reason code area
.
I yo
~
SCT
n
Current
SlOT
Controls
--
:
v
I
Current
JFCB
I
0
" ,
HSKPWA
a)
~
Prepare for further processing.
"
IV
)
1 Active
,,~ JSCB
I
:,,~
~
I
Initiator
c) Create private catalog control block
(PCCB) to represent catalog.
"
I .'
...
b) Retrieve information required for catalog
allocation and complete tables.
"
....... ~JSCB
dsname
JFCB
current SlOT = SlOT to be
processed
.
Process STEPCAT request(s) if present; for
each request:
,...
I
(output of
step 2a.)
T
..
.v
L-J
Current
SlOT
~
HSKPWA
2
"\
JFCB
(output of
step 2.)
HSKPWA
Current
SlOT
"'- ~
HSKPWA
HSKPWA
""
HSKPWA
• Initiator's JSCB
6
v
See DD
Function
Control
(lEFAB454)
for details.
j:"OT
~I
Updated
HSKPWA
Current
JFCB
I
>,
,
Current
SlOT updated
Controls
Updated
Current
,
I .... J FCB updated
-
HSKPWA
•
I
Current
,,/
Initiator
JSCB
VI
--'-
]
,
Active (Problem
Program) JSCB
1
,
I
~PCCB
LJ
~
~
Diagram 14-6. IEFAB451 - JFCB Housekeeping Control (part 2 of6)
Extended Description
ENTRY
JFCB Housekeeping Control, called by either
Step A"ocation Control (I EFBB404) or
Normal Dynamic A"ocation (lEFDB4l3), is responsible
for retrieving the information necessary to allocate each
request. The only functions actually performed by JFCB
Housekeeping Control are initialization and clean-up. To
process the requests, JFCB Housekeeping Control calls
other routines. DD Function Control, which retrieves
necessary information and completes tables (SlOTs,
JFCBs, and JFCBXs), is described in detail in the
M.O. diagram DD Function Control (lEFAB454).
Input to JFCB Housekeeping Control is the parameter list
created by Dynamic A"ocation Control or Step A"ocation
Control. In the parameter list, the pointer to the special
EPA chain is passed only from Dynamic Allocation Control; it is used for SlOTs, JFCBs, and JFCBXs created by
JFCB Housekeeping. The pointer to the last EPA is used
for updated tables (such as the JCT), when housekeeping
is called by dynamic allocation; and for generated SlOTs,
JFCBs, and JFCBXs, as we" as the JCT, when housekeeping is called by step allocation. The function map is
illustrated in figure" lB.
C"I'J
(l)
~
o·
=
~
s::
(l)
g
Q.
o....
o
"C
~
~
o·
=
IN
W
<.II
Module
Segment
Extended Description
Module
Segment
1
After establishing an ESTAE environment, JFCB
Housekeeping Control issues a GETMAIN macro
instruction to obtain space for the housekeeping workarea
(HSKPWA) and places the JFCB Housekeeping parameter
list into HSKPWA. The HSKPWA includes a control area
that indicates what processing should be performed; it
consists of global controls, local controls, and counters.
Global controls are set according to the input function
map and pertain to all data set requests to be processed
during this invocation of JFCB Housekeeping. Local controls are set by the individual routines and pertain only
to the current SlOT (the specific SlOT being processed;
SlOTs are processed one at a time); they are turned off as
the functions they indicate are performed. Global controls always override local controls if indicators in each
conflict. The counters are used to monitor the processing
of generated SlOTs in the case of DSN recursion or
volume/unit recursion. For details on HSKPWA, see
OS/VS2 Data Areas, SY38-0606.
IEFAB451
HSKPINIT
2
DD Processing Control is responsible for selecting
SlOTs to be processed; one SlOT is completely
processed before the next SlOT is selected. DD Processing Control first selects STEPCAT requests, if present.
(Note: JOBCA T requests are treated as STEPCAT requests; each JOBCA T DD statement is propagated to
every step in the job that does not include a STEPCAT DD
statement.) In the SCT, the SCTPCAT field contains a
pointer to the first STEPCAT request and the SCTCATCT
field contains the number of STEPCAT requests.
(STEPCAT requests are chained together within the
SlOT chain.) For each STEPCAT request:
IEFAB452
a) DD Preparation places the address of the JFCB for the
current DD request (SlOT) into the HSKPWA.
IEFAB453
b) DD Function Control controls the retrieval of required
volume and unit information. For details, see the
M.O. diagram DD Function Control (lEFAB454).
IEFAB454
c) The PCCB Routine creates a private catalog control
block (PCCB) for the STEPCAT request and adds it to
the chain of PCCBs for this step.
IEFAB4EF
FINDPCCB
~
Diagram 14-6. IEFAB4S1 - JFCB Housekeeping Control (part 3 of6)
CP\
~
Input
~
~
~
Process data set requests other than
STEPCATs; for each request:
in·
a)
Prepare for further processing.
I
b)
Determine if further processing
can be eliminated:
§
to-
f
c
•
CM
~
Data sets do not require units
or volumes to be allocated.
Controls
Updated
~
i
16
•
CM
:....
PGM parameter refers to
previous DD statement.
If no further processing is required
for this request, process next
request; return to step 3.
c)
Retrieve unit information:
•
Convert unit information, if
unit name was specified.
II
~
•
Copy unit information, if unit
affinity was specified.
],;;'
•
Check for VIO·eligible or
subsystem data set.
d) Retrieve information required for
allocation and complete tables.
~;
ul
~
Diagram 14-6. IEF AB451 - JFCB Housekeeping Control (part 4 of 6)
C"J'.l
~
~
o·
=
~
~
~
~
Q.
o....
o
1a
~.
=
~
~
"
Extended Description
Module
3
After STEPCAT requests are processed, DD Processing Control selects remaining requests, one at a
time, for processing; each SlOT is completely processed
before the next is selected. When all SlOTs have been
processed, control is returned to JFCB Housekeeping
Control for clean-up processing (step 4). For each SlOT:
IEFAB452
a) DD Preparation places the address of the JFCB for the
current SlOT into the HSKPWA.
IEFAB453
b) DD Preparation determines if any further processing
can be eliminated:
IEFAB453
• If ONAME (SIOTONAM=1 in the SlOT) or
TERM=TS (SIOTTERM=1 in the SlOT) was specified for this request, DD Preparation sets the local
controls to indicate that no further processing is
required (HWDDDON E=1 ). If the request is a dummy
data set (DUMMY or DSN=NULLFI LE was specified; SCTDUMMY=1 in the SlOT), a subsystem data
set (for example, sysin or sysout; SIOTSSDS=1 in the
SlOT), or a via data set (SIOVAMDS=1 in the
SlOT; for checkpoint restart only), DD Preparation
indicates in the local controls that Dsname Resolution is not required (HWDSNROD=O).
IEFAB453
• When PGM=*.stepname.ddname or
IEFAB453
PGM=* .procstepname.ddname was specified, DO Preparation calls the SWA Manager Interface to read the
SlOT and JFCB of the referenced DO statement; the
SCTGOTTR field in the SCT contains the SWA virtual
address (SVA) of the referenced SlOT. DD Preparation
copies unit, volume, and data set information from the
referenced SlOT and JFCB to the current SlOT and
JFCB and sets the local controls to indicate no further
processing is required (HWDDDONE=1). If the referenced SlOT was not allocated, processing is
terminated.
If no further processing is indicated (HWDDDONE=1),
DO Preparation returns to DO Processing Control,
which selects the next SlOT (step 3),
Segment
Module
c) DD Preparation is responsible for retrieving unit information, if unit information was not previously converted (SIOUCNVT=O, in the event of check point
restart):
• If the first subparameter of the UNIT parameter was
coded (i.e., a unit address, device type or group name
was specified), Unit Name Conversion searches:
FASTPATH
FETCHLIB
IEFAB4F7
IEFAB453
Extended Description
FETCHLIB
IEFAB470
- The eligible device table (EDT) for a matching
unitname. If a match is found, Unit Name Conversion places the EDT look-up value (LUV) in the
unit conversion list in HSKPWA and sets local
controls to indicate: the unit was converted from
the EDT (HWEDT=1); the unit is via eligible
(HWVAME=1) if the EDT LUV is via eligible;
the unit is an override candidate (HWOVCAND=1),
if the matching unitname in the EDT consists of
only one generic device type. The generic device
type is also placed in the unit conversion list.
(Note: The unit information is placed in the SlOT by
IEFAB464 - see the M.a. diagram DO Function
Control (lEFAB454).
- The UCBs (by means of the lOS UCB LUT), if a
matching unitname was not found in the EDT.
Unit Name Conversion searches the UCBs for a
unit address that matches the specified unit
information. If a match is found, Unit Name
Conversion places the device type and UCB
address in the unit conversion list in HSKPWA
and sets local controls to indicate: the unit
was converted from a UCB (HWUCB=1); the
unit is an override candidate (HWOVCAND=1).
If the specified unit information is not found in the
EDT or in a UCB, processing is terminated.
Step 3 continued on Part 6
IEFAB453
IEFAB453
IEFAB470
Segment
~
...co
~
~
N
Diagram 14-6. IEF AB4S 1 - JFCB Housekeeping Control (part 5 of 6)
Output
Process
In
fI.)
'<
~
a
HSKPWA
4
i
Cleanup housekeeping processing:
a) If housekeeping was invoked by Step
Allocation Control, unallocate private
catalogs allocated during housekeeping
processing.
~;-
t""
J<
~
~
w
~
N
~
f
w
~
HSKPWA
Additional
Volume List
-------,
I
(if obtained)
b) Release any storage obtained during
processing, release JFCB Housekeeping
workarea, and release ESTAE
environment.
I
'-------~
Return to IEFBB404
(See Initiator/Allocation Interface OEFDB401)) or
IEFDB413 (See Dynamic Allocation Control (lEFDB410))
,_7
"----'
~
Diagram 14-6. IEF AB451 - JFCB Housekeeping Control (Part 6 of 6)
Extended Description
3
Module
Segment
4
c) continued
• If unit affinity was specified, DD Preparation locates
the referenced SlOT by comparing the affinity-DD
number in the current SlOT (SIOTUNAF field) to
the DD numbers of the SlOTs in the SlOT chain
(SCTDDINO field).
IEFAB453
The following processing occurs:
- If the referenced SlOT contains converted unit
information, DD Preparation copies it into the
unit conversion list in HSKPWA.
- If the referenced SlOT indicates a via data
set (SIOVAMDS=l), DO Preparation indicates
in the local controls that the unit is VIOeligible (HWVAME=l).
- If the referenced SlOT indicates a subsystem
data set (SIOTSSDS=l), Unit Name Conversion
converts the unitname SYSALLDA and places
the converted information into the unit conversion list in HSKPWA.
d) DO Function Control controls the retrieval of
volume and unit information required for allocation; if necessary, DO Function Control also generates a JFCBX(s). For details, see the M.a. diagram
"tEFAB454 - DD Function ControL"
Extended Description
SRCHSIOT
I EFAB451
(11
=
~
~
(11
[
....
o
o
"C
~
ao·
=
w
W
\0
Segment
HSKPCLUP
a) If JFCB Housekeeping was called by Step Allocation
Control and private catalogs were allocated during
housekeeping processing (see the M.a. diagram
JLOCATE (lEFAB469)):
• Close Private Catalog (a data management routine) closes the catalogs.
IDACAT12
• Unallocate Private Catalog Routine issues SVC 99
to unallocate the catalogs.
IEFAB4F4
.The PCCB Routine releases the private catalog
control blocks (PCCBs).
IEFAB4EF
FINDPCCB
IEFAB470
IEFAB454
b) JFCB Housekeeping Control issues FREEMAIN
macro instructions to release any storage obtained
during housekeeping processing (for example, storage
for a volume list if the CRI is too small), to release the
housekeeping workarea (HSKPWA), and to release the
EST AE environment.
Error Processing
In general, an error occurring in any routine causes control to be returned to the calling routine with appropriate
return and reason codes. Return and reason codes are
listed in Section 6, Diagnostic Aids. Errors occurring in
steps 1-3 cause control to be passed to step 4.
When I EFAB451 receives control, it creates an EST AE
environment so that its exit routine receives control if
an abnormal termination occurs.
<:
CI.l
N
(:)
W
The active (problem program's) JSCB is used to
determine if any private catalogs have been allocated (the pointer to the PCCB chain does not
equalO).
CI.l
o·~
Module
00
o
~
IEFAB451
HSKPCLUP
3-320 OS/VS2 System Logic Libruy Volume 3 (VS2.03.804)
2 bytes
.
JFCB Housekeeping
~P_ar_a~me~te_r~l~i_st~__~
____
~F_u_n_ct_io_n_M_a_p_~ _
- p_ _ _ _ _ _- p_ _ _ _ _ _~_ _ _ _ _ _~_ _ _ _ _ _~
_ _ _
Bit
location
I
X X X X
I
XX XX
I
X X X X
I
X X X X
I
Conditions when Bit is On (=1)
Meaning if Bit is On (=1)
Caller is Step
Allocation Control
Caller is Dynamic
Allocation Control
1
POI can be searched
Always
Never
2
Do not update last SlOT pointer in
SCT, if S10T created
Never
Always
3
Catalogs may be mounted
Always
Depends on what
user specified
4
Wait for units during catalog allocation
Always
Depends on what
user specified
5
Perform catalog recovery
Always
Never
6
Do not create SlOT and JFCB for
catalogs
Never
Always
7
Wait for volumes during catalog
allocation
Always
Depends on what
uSer specified
8
Do not process JOBCATs/STEPCATs
Never
Always
9
Consider offline devices during
catalog allocation
Always
Depends on what
user specified
10
Do not enqueue on TlOT
Never
Always
11
Change active JSCB to allocate
catalog to initiator
Always
Never
12
Add EPA to chain if JCT is updated
Never
Always
13
Bypass data set integrity ENQ
Never
Oepends on what
user specified
14
Program authorized to bypass data
set integrity if no JOBllB or STEPllB
If program is
authorized
Never
15-16
Reserved
Figure 2-28. Function Map of J'FCB Housekeeping Parameter List
Section 1: Method of Opeution 3-321
eM
W
N
Diagram 14-7. IEFAB4S4 - DO Function Control (Part 1 of 12)
N
~
~N
fI'J
I
in'
ENTRY from IEFAB452 (See IEFAB451 JFCB Housekeeping Control)
Input
ut
ali
JFCB
Housekeeping
Workarea
(HSKPWA)
DO Function Control: retrieve
required information and complete
tables necessary for allocation.
HSKPWA
i
Current SlOT
,
Controls
r-
1
J
Locate existing cataloged or passed
data set.
'2'
OSNAME
"-
~
!"
a
(II
eM
~N
~
r
HSKPWA
HSKPWA
i
Controls
+POI or 0
fC
eM
~
Controls
Updated
Current SlOT
a)
Search passed data set information
(POI), if caller of JFCB
Housekeeping was Step Allocation
Control.
tl
.Ai
JFCB
OSNAME
b) If data set was not found in
PO I or if PO I was not searched,
search catalog.
Volume List
obtained if
CR I not large
enough.
~
~
Diagram 14·7. IEFAB4S4 - DO Function Control (part 2 of 12)
Extended Description
ENTRY
DO Function Control, called by DO Processing Control (lEFAB452; see the M.O. diagram
JFCB Housekeeping Control (lEFAB451)), determines
what additional information is needed to allocate a request,
obtains that information, and places it in tables to be used
by allocation. Every SlOT that does not complete processing during DO Preparation (HWoooONE=l in the local
controls if no further processing is required) is processed
by DO Function Control. However, not all the steps in DO
Function Control are performed for every SlOT - the type
of request (for example, GoGALL request, existing cataloged data set) determines what DO Function Control will
do to retrieve needed information. The extended description for each step describes when that step is performed.
In general, steps 1-4 are concerned with retrieving unit
and volume information; step 5 copies unit and volume
information into the SlOT, JFCB, and, if needed, JFCB
extension (JFCBX); steps 6 and 7 complete oCB and
olSP information in the JFCB and SlOT.
Module
Segment
Extended Description
Module
Segment
1
IEFAB454
ESTABoSN
When this step is processed, two functions are
performed:
• This step determines if a request is GoGALL (all levels
of a generation data group are requested).
• If the request is not GoGALL, this step retrieves data
set name, volume, and unit information from the POI
(passed data set information) or from a catalog. (osname,
volume, and unit information for a GoGALL request
is retrieved in step 2b.)
This step is processed only if the following conditions are
true:
• The unit requested is tape or direct access (HWTAPE=1
or HWoA=1 in the local controls).
• The data set is not a single generation data set
(SCTSGoGS=O in the SlOT), or it is a single
generation data set at restart. (osname, volume,
and unit information for a single generation data
set is retrieved in step 2a.)
• The data set disposition is not new (SCTSNEW=O in
the SlOT).
• Volume information is not specified: by explicit
volume serial numbers, or by a volume reference
(SCTVOLAF=O and SCTVOLCT=O in the SlOT),
or by volume serials which were retrieved from the
catalog.
til
i-
1:1
~
==
(D
~
j:I.
o
o"'"
~
~
=-e·
1:1
CN
~
N
CN
• The SlOT being processed is not a SlOT generated in
response to a GoGALL request (oSN recursion;
HWoSNREC=O in the local controls) or a SlOT
generated in response to a request for a data set residing
on more than one device type (volume/unit recursion;
HWVUREC=O in the local controls).
• The data set is not a subsystem, or dummy data set
(HWoSNRQo=1 in the local controls).
DO Function Control calls JLOCATE to search the POI
and/or catalog(s) for the required information, or to
update the POI and allocate a VSAM private catalog or
CVOL. For details on the processing of JLOCATE,
see the M.O. diagram JLOCATE (lEFAB469)'
IEFAB469
~
w
Diagram 14-7. IEFAB4S4 - DD Function Control
(part 3 of 12)
~
~
~
~
Process
Input
til
'<
;=-
HSK~A
HSKPWA
2
n
t ~rDoGNT J?I
l'
t:
2"
~
I
Current
..... JFCB
~.
E'
a
~
(D
w
Output
JCT
Controls
i-
7
I-I
';
:: >
If request is GOG, resolve data set
name and retrieve unit and volume
information; current SlOT is one
of the following:
j
a) GOG-single request.
GDGNT
1
Controls
Updated
~;;
1\:1
CRI updated
t
Volume List *
- --,
LCRI (catalog
' - - - - -.........' \ \ return information)
'f.;:
['.
,.>< :,>~:tf;'~'.>:;)'L...r<
<:.~:' ,':,""';"'
HSKPWA
;: ""0",
.<..:: ",::.:"./
',. ;~. >~
-
volume
~
List *
---,
I
I
IL... _ _ _ .JI
* Volume List exists if CR I too small.
I?
1
J
CRI updated
:.~. ,~',
Current SlOT
Controls
Updated
CRI.
<,6
IL- _ _ _ .JI
* Volume L i s t -
Volume
List *
r-- ---.
I'- _ _ _ .JI
,"; '" ,.,\""'" /":" ~~':'0:;;:.Y;
~
'~
Diagram 14-7. IEF AB454 - DD Function Control
Extended Description
2
til
(D
ac)"
::I
~
r:c:
(D
[
o
"'0)
o
I
~.
::I
CoN
W
N
~
(part 4 of 12)
Module
The purpose of this step is to obtain the fullyqualified dsname of a generation data group (GDGI
and to locate volume and unit information for the GDG
request. A SlOT processed by this step is: al a SlOT
representing a GDG-single request (SCTSGDGS=1 in the
SlOT); or, bl a SlOT representing a GDGALL request
(HWGDGALL=1 in the local controlsl; or, cl a SlOT
generated in response to a GDGALL request (DSN
recursion; HWDSNREC=1 in the local controlsl. The
following processing is performed:
IEFAB456
al For a SlOT representing a GDG-single request, GDG
Single Processing:
IEFAB461
Segment
• Obtains the base level of the GDG:
IEFAB461
GNTLCUPD
I EFAB461
GNTSCAN
IEFAB461
IEFAB4F7
GNTRDLOC
• Calls JLOCATE to obtain the fully-qualified data
set name and unit and volume information for the
data set. JLOCATE is described in the M.O. diagram JLOCATE (lEFAB4691.
IEFAB461
IEFAB469
IEFAB4F7
IEFAB469
Module
• JLOCATE obtains the fully-qualified dsname and
unit and volume information for the zero-level of
the GDG. For details on JLOCATE, see the
M.O. diagram JLOCATE (lEFAB4691.
cl For a SlOT generated in response to a GDGALL
request, DSN Resolution:
IEFAB469
IEFAB456
• Increases the generated-DD counter (HWDDCTRI
in the control area of HSKPWA by 1.
• Modifies the dsname in the JFCB to appear as a
request for the desired level of the GDG; the
relative generation number is the negative of the
generated-DD counter.
• Turns off the DSN recursion indicator (HWDSNREC=OI
and sets the counters in the control area to 0 if this is
the last generated SlOT - that is, if the generated-DD
counter (HWDDCTRI equals the number of DDs
generated (HWDDSTEPI.
• Calls JLOCATE, which obtains the fully-qualified
data set name and unit and volume information for
the data set. For details on JLOCATE, see the
M.O. diagram JLOCATE (lEFAB4691.
Segment
IEFAB456
IEFAB456
• Tables are created for all the levels of the GDG except
the zero level. DSN Resolution turns on the DSN
recursion indicator in the local controls
(HWDSNREC=11 and updates the counter in the
control area with the number of SIOT/JFCB pairs to
be created (HWDDSTEP=nl. Table Creation generates
IEFAB466
the required number of SlOTs and JFCBs and chains
IEFAB452
them to the zero level SlOT. DD Processing Control
(see the M.O. diagram JFCB Housekeeping
Control (I EFAB451II will select the generated SlOTs, one
at a time, for processing immediately after the
SlOT representing the zero-level of the GDG is completely processed.
IEFAB461
- If the dsname is not found in a GDGNT or if no
GDGNTs exist for the job, GDG Single Processing
calls JLOCATE to obtain the base level. The processing of JLOCATE is described in the M.O. diagram "IEFAB469 - JLOCATE." If JLOCATE
returns with the base level, an entry is created in
a GDGNT, which itself is created if necessary.
If JLOCATE is unable to locate the base level,
processing terminates; IEFAB454 returns to the
caller.
Extended Description
bl For a SlOT representing a GDGALL request, two
functions are performed:
• Checks the data set name for correct syntax. If the
base name (not including the level number) is greater
than 35 characters, control is returned to the caller
and processing is terminated.
- If any GDG name tables (GDGNTsl exist for the
job (JCTGDGNT'IOI, GDG Single Processing
searches the GDGNTs for the dsname. (If
HSKPWA does not include a pointer to the
GDGNT(sl, the SWA manager is called to read
the GDGNT(sl for the job and a pointer is placed
in HSKPWA.I
..7
IEFAB469
GDGACODE
~
w
Diagram 14-7. IEFAB454 - DD Function Control (partS of 12)
~
~
~
~
>~,
tI.l
I
HSKPWA
Controls
irs'
~
to-
~
"
~
CRI
c
~
r1
J
"') 3
"
Current
...... "" .... JFCB
&
iw
HSKPWA
Current
SlOT
I
Controls
Updated
t
..
14]
~
J
i\t---,*
J
IU
List -
I
I
(
'-- - - - '
*
HSKPWA
J
..,.1/
~
lPDI or 0
CRI
HSKPWA
Controls
4
SCT
Controls
w
Current
SlOT
.~
JI
DSNT
(data set
name
table)
.
)
If VOL=REF was specified, resolve
reference:
a) reference to dsname.
y
J
Controls
Updated
t
t
J
--
Current
SlOT
Current
JFCB
'fi
Genemw~
JFCBs
If found in PDI:
Referenced
SlOT
..
- -,
J
J
If found In catalog:
_
Volume
*
/{ CRI
List
---,
1)1 updated Jor
j
Current
SlOT
rr*
J
,~
/'l, .
HSKPWA
,
.. ~ Current
JFCB
1
Generated
SlOTs
r
Volume List exists if CRI too small.
~
f
If data set spa~s devi~ types, set
up volume/Unit recurSion.
Current
SlOT
L ___
Volume List obtained
if CRI too small.
~. Referenced
SlOT
I
:,~",
I
....
)
v
~
b) reference to ddname.
Current
-t--..... JFCB
I
I
1
"
HSKPWA
Controls
Updated
Referenced
SlOT
./ ~
]
~
'-...-y
Diagram 14-7. IEFAB454 - DD Function Control (part 6 of 12)
Extended Description
Module
~
~
~
5'
=
~
:::
~
~
Q.
o
~
o
"0
~
~
5'
=
~
~
~
.....
Extended Description
4
3
The purpose of this step is to determine if volume/
unit recursion is necessary. If the data set was
located in a catalog (HWDSNCAT=1 in the local controls,
set by J LOCA TE), the data set resides on more than one
volume, and the current SlOT was not generated in
response to a GDGALL request (HWDSNREC=O), Multiple Device Type Determination searches the CR I
(volume list) for a change in device type. If more than
one device type is found, Volume/Unit Resolution
sets the generated-DO counter in the control area
to the total number of different device types minus 1
and sets the volume/unit recursion indicator in the local
controls (HWVUREC=1). Table Creation creates SlOT/
JFCB pairs for the total number of different device
types minus 1 and chains them to the current SlOT. DO
Processing Control (see the M.a. diagram JFCB Housekeeping Control (lEFAB451)) selects the generated
SlOTs, one at a time, for processing immediately after
this SlOT is completely processed.
Segment
If VOL=REF was specified, Volume/Unit Resolution locates the source of volume and unit
information:
IEFAB463
IEFAB466
IEFAB452
a) For a reference to a dsname (SCTDSNRF=1 in the
SlOT), Volume/ Unit Resolution reads the data set
name table (DSNT) to obtain the dsname. The
SCT ADSTB field of the SCT contains the SWA
virtual address (SVA) of the DSNT for this step.
JLOCATE searches the POI and/or the catalog for
the dsname. (For details on JLOCATE, see the
M.a. diagram JLOCATE (lEFAB469)). If
JLOCATE determines that the dsname is GDGALL,
processing is terminated.
b) For a reference to a previous DO statement, either
in this step (intra-step) or in a previous step (interstep), Volume/Unit Resolution reads the SlOT of
the referenced DO statement and places a pointer
to it in HSKPWA. (The SWA virtual address (SVA)
of the referenced SlOT is in the SIOTVRSB field of
the current SlOT.) If the reference is inter-step, the
JFCB and JFCBXs are read. If the reference is
inter-step (SCTVREF=O in the current SlOT) and
the referenced data set was not allocated
(SlOT ALCD=O in the referenced SlOT), processing
is terminated. Volume/Unit Resolution also updates
the local controls to indicate the referenced SlOT
is present (HWRESIOT=1L
Module
IEFAB457
Segment
VOLREF
IEFAB469
IEFAB457
VOLREF
t
Diagram 14-7. IEFAB4S4 - DD Function Control (Part 7 of 12)
~
o
~
~-,
N
fIl
HSKPWA
'<
fQ.
Current SlOT
~
1
~
Controls
*
Current J FCB
~
't9.
()
, -1
Volume List *
CRI
t:
1
Sf
---"
HSKPWA
V
5
olume
list
exists if
CRI
too
small.
a)
...
l. ____ .JI
I
~
"V
fA
~
'jr..
Controls
CD
W
':
"
"
b) Process VIO-eligible requests.
(Y
I
?~:
I
I
)
Current SlOT
~:j
:;
,;;
';{J';'!;;'J"i~:
;,,,,:','¥'.',,
HSKPWA
"
T
1
"
Volume
List
,:
;:-tJ
1
~Unit COn{erSiOn
",
::,
>
d) Copy information from unit
conversion list.
"
"V
Current
'" SlOT
L
,
il;
f.
r
m
L,:;;
:,::;
HSKPWA
Unit
Conversion
List
~\
,,?
t
.>:
,~;'
~;
;
,,':';
List
>
Controls
Updated
,
'f
t!:.",;,:::;
Controls
If a unit was specified and unit
information was also retrieved
(from PO I, catalog, or volume
reference), check if specified
unit overrides retrieved unit.
i
1
I
'- ...... CRI
c)
icY
;
Referenced
I - I,t". SlOT
J')
~
One of following
is present:
Controls
')
~h:,
')"
HSKPWA
Controls
Updated
,'C
"
Current SlOT updated
,
1
,.. Vt
i
:;X:"'<
1
',.'
i;'
.- f......IiI.. updated
',;
~~
HSKPWA
'
HSKPWA
Referenced
I
I
CRI (volume list)
T
~JFCB
~
•
"V
~
Current
JFCB
1
1
-
'")
Current SlOT
HSKPWA
[
Copy information from:
•
)
Current SIOTupdated
Controls
Updated
Place unit and volume information
in tables.
:
f
i
'"
:' ;+ c,'"
.,,.":,'
6
{,'nt",'(,!,.' 'H<;>:,;::':
.. '
:;,
:
'j'", ",' ",', " "
'"
"
,
',",
"IIII!!!!!!III
Diagram 14-7. IEF AB4S4 - DD Function Control
Extended Description
5
"'--__ 7
(Part 8 of 12)
Module
Segment
The purpose of this step is to:
a) Place volume information and certain unit information
retrieved in the previous steps into the SlOT and JFCB.
b) Process VIO-eligible requests.
c) Determine if specified unit information overrides
retrieved unit information.
d) Copy unit information into the SlOT.
Step 5 is performed for every SlOT that enters DD
Function Control and whose request hasn't already failed.
a) Volume/Unit Table Completion copies retrieved
volume information and certain unit information
from a referenced SlOT or from the CRI (volume
list) into the current SlOT and JFCB. The retrieved
source of volume and unit information (CR I or
referenced SlOT) was determined in a previous step:
rJ'.)
(I)
~
5·
=
~
a:
(I)
io....
o
"1::1
~
a5·
=
w
~
~
I,Q
• Unit and volume information exists in the CRI (or
volume list) in three cases:
- Volume/unit recursion is indicated (HWVUREC=l
in the local controls, set in step 3).
- VOL=REF=dsname was specified and the dsname
was found in the catalog (HWDSNCAT=l in the
local controls, set in step 4a).
- A cataloged data set was located by searching the
catalog (HWDSNCAT=l in the local controls, set
in step 1b or step 2) .
• Unit and volume information is copied from a
referenced SlOT in two cases:
- Volume reference was coded to a ddname
(HWRESIOT=l, set in step 4b).
- The referenced data set was located in the PDI if
VOL=REF=DSN (HWRESIOT=l, set in step 1a
or4a).
Unit information is copied into a local field; for
volume/unit recursion, Multiple DeviCe Type Determination uses the generated-DD counter to reference
the correct device type in the CRI. The only unit
information placed in the SlOT at this time is unit
count (SCTNMBUT).
Volume information is copied into the JFCB. Volume/
Unit Table Completion copies all the volume serial
numbers from the CRI or referenced SlOT, except in
two situations:
~
IEFAB464
IEFAB464
CRIRFCMP
Extended Description
Module
Segment
• If information is copied from the CRI and more than
one device type exists (volume/unit recursion),
volume serial numbers are copied only for one device
type. (The generated-DD counter is used to reference
the correct device type in the CRI J
IEFAB464
CRIRFCMP
• If the data set resides on tape and VOL=REF was
coded, only the last volume serial number is copied
(if more than one exists), because a volume reference
implies that the volume can be shared and tape volumes
cannot be shared. (This precaution, however, does not
guarantee that the data set can be successfully opened.)
The volume count in the current SlOT is set to 1 for
tape volume references.
IEFAB464
DDVLCOPY
Before copying the volume serial numbers, Volume/
Unit Table Completion determines if a JFCB extension (JFCBX) is needed; up to five volume serial numbers can be placed in a JFCB and up to fifteeh in a
JFCBX. If more space is needed and sufficient
JFCBXs were not generated by the Interpreter or by
Dynamic Allocation, Volume/Unit Table Compietion
generates the required JFCBXs.
IEFAB464
JFCBXGEN
- If the referenced SlOT contains volume information
that was itself copied from a previous SlOT, Volumel
Unit Table Completion reads that SlOT and copies
information from it.
IEFAB464
TAPEVREF
- If the device type is tape, Volume/Unit Table
Completion updates the unit type to reflect the
greatest device range that can satisfy this request.
For example, the user specified 2400-4 for a data
set with a density of 1600 bpi. Volume/Unit
Table Completion updates the device type to
2400-3, which includes dual-density devices (which
would have been included in 2400-4) and tape
devices that can read only in 1600 bpi.
IEFAB464
TAPEONLY
Volume/Unit Table Completion also updates the
volume counts in the SlOT (SCTVOLCT) and the
JFCB (JFCBNVOL).
For volume reference to tape volumes, the following
additional processing is performed:
IEFAB464
IEFAB464
IEFAB463
DDREFCMP
IEFAB464
Step 5 continued on Part 10
~
Diagram 14-'. IEFAB4S4 - DD Function Control (part 9 of 12)
~
~
~
~
Input
Output
Process
fI)
i
HSKPWA
i
5
Current
SlOT
HSKPWA
e) Copy altalog device type.
r-
;Z
!
CRI
f
eN
~
~
HSKPWA
~
i
6
f
eN
~
CRI
,HSKPWA
Update JFCB with data set
characteristiCs:
al ~lh~'b~eqUest is lor single level
b) when DCB=dsname was
-n
.JJ-'
specifi~.
HSKPWA
CurrentJFCB~upd~~
/f -
L..-I
_-J
~
"'-_'?
Diagram 14-7. IEFAB4S4 - DD Function Control
(part 10 of 12)
Extended Description
5
Module
Segment
(continued)
b) Volume/Unit Table Completion marks the current SlOT
IEFAB464
as a VIO data set (SIOVAMDS=1) if the data set has a
system-generated dsname, is not ISAM, is not dummy, and:
VIOCOMP
• The referenced SlOT (either from the POI or a volume
reference) is VIO; or
• No information was retrieved from a catalog or
referenced SlOT, the disposition is NEW, no volumes
were specified, and the unit is VIO-eligible.
c) Volume/Unit Table Completion determines if specified
unit information overrides'retrieved unit information.
This step is performed when:
IEFAB464
'UNOVERID
• A unit was coded and is an override candidate
(HWOVCAND=1 in the local controls, set by
IEFAB470 (Unit Conversion Routine) - see the
M.O. diagram JFCB Housekeeping Control
(lEFAB451)).
• Unit information was retrieved from the POI or an
inter-step volume reference (HWRESIOT=1 in the
local controls and SCTVREF=O in the current SlOT)
or from the catalog (HWDSNCA T=1 in the local
controls).
1:"1)
(D
g.
=
~
a::
Volume/Unit Resolution compares the unit information in the unit conversion list to the unit information in the CRI or in the referenced SlOT. If the unit
information in the unit conversion list is' the same device
type group as the retrieved unit information, the "unit
overridden" indicator is set (HWOVRDN=1) in the
local controls. This indicator is not set, however, if the
referenced SlOT is a dummy, VIO, or subsystem data
set. (A specified unit cannot override a retrieved unit
in these cases.)
(D
[
o...,
o
1
g.
=
IIJ
~
CN
CN
"""
'-~
IEFAB464
d) Volume/Unit Table Completion copies unit information
into the SCTUTYPE field of the current SlOT. If the
unit was converted from a UCB (that is, a unit address
was specified; HWUC.B=1 in the local controls), the
SlOT is also marked as a demand request (SIOTDMND=1).
NOREFCMP
Extended Description
Module
e) Volume/Unit Table Completion creates a JFCBX (if
none exists) and updates the JFCBX with the device
type retrieved from the catalog. This allows the
unallocation routine IEFAB4A2 (Disposition Processing) to recatalog the data set using the device type
from the catalog.
IEFAB464
6
DCB Resolution updates the JFCB with data set
characteristics from the DSCB (for example, data
set organization, record format, logical record length,
expiration date). DCB Resolution is performed in two
cases: DCB=dsname was specified (SIOTDCBR field in
the SlOT); the request ,is a single level of a GOG
(SCTSGDGS=1 in the SlOT). The method of obtaining
the DSCB differs in the two cases.
IEFAB458
a) If DCB=dsname was specified, DCB Resolution obtains
the dsname from the data set name table (DSNT).
JLOCATE issues a system locate using the dsname to
determine the volume serial number of the volume
containing the DSCB. For details on JLOCATE, see the
M.O. diagram JLOCATE (lEFAB469).
IEFAB458
b) For a new single-GDG request, DCB Resolution obtains
the base level data set name from the JFCB and the
volume serial number of the pattern OSCB from the
CRI. (The volume serial number of the volume on which
the GOG is cataloged was placed in the CRI when the
GDG-single request was located - see step 2. The
pattern DSCB exists on this volume.)
IEFAB458
DCB Resolution issues SVC 27 to obtain the Format 1
DSCB and transfers the data set characteristics from it to
the JFCB.
IEFAB458
IEFAB458
Segment
CATDEVT
IEFAB469
OBTNDSCB
UPDTJFCB
t
w
Diagram '14-7. IEFAB4S4
~
DO Function Control (part 11 of 12)
N
~
N
i
i
Input
Ii.
HSKPWA
ISlOT
I.
Resolve data set disposition
information:
a)
r-
f
HSKPWA
~
I t -.,
HSKPWA
Current
updared
Complete default dispositions in
SlOT.
is
Current·
SlOT
§
HSKPWA
~"
b)
Update passed data set·information
(PO I), if necessary.
c)
Update SlOT to indicate private .,...-""""------,
tape, if necessary.
CD
W
~N
rI~
w
~
rt
KPNA
~~~nl
I
HSKPWA
Controls
HSKPWA
Controls
Current SlOT -
d) Retrieve catalog information; jf
necessary.
e)
,j
Enqueue alias-named, or GOG,~
or temporary data sets.
Return to IEFAB452
(See JFCB Housekeeping
(lEFAB451))
JCT
I
~
~
Diagram 14-7. IEFAB4S4 - DD Function Control
(part 12 of 12)
Extended Description
7
~.-~
Module
Segment
The purpose of this step is to resolve data set
disposition information.
a) DISP Resolution completes the data set disposition
information in the SlOT:
Extended Description
d) DISP Resolution calls JLOCATE to retrieve catalog
information for a data set which has a qualified
name (JFCBDSNM field in the JOCB), if the
following conditions are true:
IEFAB459
• If no disposition is specified, data sets that existed
at the beginning of the job are marked KEEP
(SIOTKEEP=1); and data sets that specified MOD
but for which no unit or volume information could
be located are marked DELETE (SIOTDLET=1).
(The Interpreter marked as DELETE data sets that
specified NEW but that did not specify a disposition.)
~
5'
::I
~
a:
~
[
So
o
"0
~
a
5'
::I
I.f
~
~
~
IEFAB459
IEFAB469
• A disposition of UNCATLG (SIOTUNCT=1 in
the SlOT) was specified, and no STEPCATs exist.
• A disposition of DELETE (SIOTDLET=1 in the
SlOT) was specified, and volume information was
retrieved from the catalog.
b) If the request specified PASS (SIOTPASS=1) and POI
processing is allowed (HWDOPDI=1 in the global controls), DISP Resolution updates the POI with an entry
for this data set. If the data set was received by this
step (SCTRECVD=1), the original POI entry (POlE)
is updated; otherwise, a POI E is created.
IEFAB459
c) This step marks a tape data set as private (SIOTPRIV=1),
so that it will not be deleted, if attributes of the data
set indicate it should be kept.
IEFAB459
PDIBUILD
<:
r.n
N
o
~
For details on JLOCATE, see the M.O. diagram
JLOCATE (lEFAB469).
e) If an alias name or GOG was specified for a passed
or cataloged data set, DISP Resolution creates a
JFCBX (if none exists), updates the JFCBX with
the alias data set name, and enqueues the major
data set name. Non-VIC temporary data set
names are enqueued.
Error Processing
An error in any routine causes control to be returned to
the calling routine. In the event of an abnormal termination, the ESTAE exit routine established by IEFAB451
performs any necessary cleanup.
~
Segment
• A disposition of CATLG was specified
(SIOTCTLG=1 in the SlOT), and no STEPCATs
exist for this step (SCTPCAT=Q in the SCT).
• An existing JOBLIB request is marked PASS
(SIOTPASS=1 ).
til
Module
00
o
~
IEFAB459
IEFAB469
REALDSN
IEFAB459
ENQDSN
~
Diagram 14-8. IEFAB469 - JLOCATE
~
ENTRY from caller
(see extended
description)
otil
~
(part I of 4)
In
Output
~
til
'<
rc.
a
i
POIupdated
HSKPWA
Controls
Updated
JLOCATE: Retrieve dsname,
volume, and unit information
from the POI or a catalog.
HSKPWA
(;.
t'"
a:
1
~
~
a
Search passed data set information,
if indicated.
•
dsname
Return
to
Caller
If information found in POI,
return to caller.
(D
(,N
~
~
(:)
(,N
HSKPWA
JCT
GDGNT*
Controls
00
~
'-'
DSNAME
CRI
* GDGNT exists as input
only when caller is GOG
Single Processing.
** a new volume list exists
if CRI too small or if
obtained during previous
call to JLOCATE.
2
I ssue system locate to search
catalog, if indicated.
a) System locate is successful -
ga ta step 5.
-u ~
Controls
Updated*
.-
bl System lacate Is unsuccessful'
because catalog is not allocated
go ta step 3.
I
* on Iy if system locate
s successful.
HSKPWA
lume List
___ ...J
----,
1]''If
CRI
CRI or volume list
pdated.
dill
c) System locate is unsuccessful
because CRI (volume list! is too
small - flO to step 4.
Return Code
d) Data set name not found.
Return to Caller
(See beginning of
extended description)
~
~~i?'
'~.7
Diagram 14-8. IEFAB469 - JLOCATE (part 2 of 4)
Extended Description
ENTRY
a
• Reads in the SlOT and JFCB of the request that passed
the data set.
• Marks the POI entry as received.
• Sets the local controls to indicate that the referenced
SlOT is present (HWRESIOT=1).
IEFAB455
Q.
o
100)
o
1a
=
~.
w
~
w
VI
IEFAB4EB
POIOORO
IEFAB455
IEFAB455
This step is performed only if both of the following
conditions are true:
• OSN Resolution (lEFAB456) to obtain volume and unit
information for a specific level of a GOGALL request.
• Volume/Unit Resolution (lEFAB457) to locate volume
and unit information when VOL=REF=dsname was
coded.
Input to this step is the data set name or, if JLOCATE was
invoked by GOG Single Processing, the data set name and
the GOG base level.
• OCB Resolution (JEFAB458) to obtain the volume
serial number of the volume containing the OSeB for a
data set, when OCB=dsname was coded.
JLOCATE issues a system locate (SVC 26) to search:
1) private catalogs defined for this step by means of
JOBCAT or STEPCAT DO statements; 2) the master
catalog; 3) catalogs implied by the data set name.
The system locate results in one of the following
situations:
IEFAB469
PARMINIT
a) The system locate is successful; the dsname is found.
Catalog management places unit and volume information in the CRI (volume list), if the request is. not
GOGALL. If the request is GOGALL, catalog management places the number of levels of the GOG in the
CRI (volume list).
IEFAB469
LOCATECT
b) The system locate is unsuccessful because the catalog
to be searched is unallocated. Catalog management
returns the name of the catalog to be allocated and
the catalog connector (alias), if any, in the CRI
(volume list). See step 3.
. .
IEFAB469
LOCATECT
Most of these routines use JLOCATE only to search
catalogs; the POI is searched·only when:
• the SlOT does not represent a STEPCAT request,
and,
g
2
Segment
• The dsname was not found in the POI or the POI was
not searched.
• Local controls indicate a system locate should-be
issued (HWSYSLOC=1).
==
(I)
1
• DO Function Control (I EFAB454) to determine if a request is GOGALL (all levels of a GOG are requested).
If the request is not GOGALL, retrieves dsname, volume,
and unit information for the data set, or updates POI for
restarting steps, or allocates private catalogs for restarting
steps.
• JLOCATE is called by DO Function Control, GOG
Single Processing, or Volume/Unit Resolution, and,
~
Module
IEFAB455
=
~.
Extended Description
POI Scan searches the POI if allowed, as indicated in
the local and global controls (HWPOISCN=1;
HWOOPOI=1). If the POI pointer in the housekeeping
workarea is nonzero, POI Read and Chain updates the
HSKPWA with pointers to the first and last POI entries.
If the dsnarne is found in the POI, POI Scan:
• OISP Resolution (I EFAB459) to make a private
catalog available for unallocation.
(I)
Segment
JLOCATE is a service routine used by
several housekeeping routines to retrieve
dsname, volume, and unit information from the passed
data set information (POI) or from a catalog. It is called
by the following modules (all these modules are described
in the M.O. diagram DO Function Control (lEFAB454)):
• GOG Single Processing (JEFAB461) to obtain the base
level of a GOG and to obtain the fully-qualified dsname
and volume and unit information for the data set.
CI.)
Module
• JFCB Housekeeping Control was called by Step Allocation Control (that is, this is a batch request).
Note: A catalog will already be allocated only if it
was previously allocated during JLOCATE processing
and if it was not subsequently unallocated to release
Step 2 continued on Part 4
~
~
Diagram 14-8. IEFAB469 - JLOCATE (part 3 of
4)
.
0'1
of'-I
~
N
f'-I
Ib
~.
t:
-- -.- -
.
:'
lnitiator
JSCB
HSKPWA
Controls
VI l
'."
HSKPWA
I
\ 3
,
%
!
i
..
,'::'s
tq,:
'-- ~OIU_
List
---,
..
/
•
I
Initiator
JSCB
V-, .
~
."
Active JSCB
I
Allocate catalog, if necessary.
a
\
Reissue system locate;
go to step 2.
~N
1
-' PCCB
I
I
CR I or volume list contains
dsname of catalog and
catalog connector (alias),
if any.
~
Active JSCB
l
L ___ .J
CRI
(II
1
'\:ACB
CJ
i
~
~
:..,
HSKPWA
HSKPWA
Volume
List
~---,
,
L __ J
4
Initiator
JSCB
)PI
;f'
HSKPWA
Controls
/
,.
Current
... SlOT
I
I
Current
_!-..JFCB
I
I
\
Volume
List
--]
Active
JSCB
Obtain new volume list, if
necessary.
•
CRI or existing volume list
contains required size of
new volume list.
CRI
CRI
>
5
Reissue system locate;
go to step 2.
Update tables and controls.
1 L
"P'
~
HSKPWA
J
Initiator
JSCB
Active
_ JSCB
Curren,
SlOT-
Z
~ updated
L-J
Return to Caller (See
beginning of extended
description)
I
l
1fL---f -r
Controls
Updated
~CBS
I"
__ Volume List
/
-
Current
JFCB.___ updated
1
I
I
PCCBs ,updated
~" 0 Th
~
',,---~
--"
Diagram 14-8. IEFAB469 - JLOCATE (part 4 of 4)
Extended Description
2
Module
Segment
(Continued)
needed resources. Catalogs are allocated during
JLOCATE to retrieve information needed for allocation, if JFCB Housekeeping has not been called
by Dynamic Allocation. All catalogs will be
unallocated during housekeeping clean-up processing,
before JFCB Housekeeping Control returns to its
caller, if the request is batch (that is, Step Allocation
Control called JFCB Housekeeping Control) {see the
M.O. diagram JFCB Housekeeping Control
(I EFAB451) l-
c) The system locate is unsuccessful because the CRI (or
volume list, if one was obtained during a previous call
to JLOCATE) is too small. Catalog management returns the required size of the volume list in the CRI
or existing volume list. See step 4.
{/)
(D
a
5'
..=
N
a::
(D
;.
8-
....
0
0
'0
...
(D
a
5'
=
w
W
w
.....
If the catalog to be searched is not allocated, the
system locate is unsuccessful. JLOCATE will
attempt to have the catalog allocated. Allocate Catalog
Control issues SVC 99 to have the catalog dynamically
allocated; Open Catalog Routine (a data management
routine) opens a private catalog and catalog management
opens a CVOL (control volume); the PCCB Routine
builds or updates a private catalog control block (PCCB)
for the catalog. If Housekeeping was called by Step Allocation Control, Table Creation also creates a SlOT and
JFCB to represent the catalog (HWMAKTAB=l and
HWDNCCDD=O in the controls).
If allocation of the catalog is unsuccessful, processing is
terminated unless the failure is due to insufficient
resources and Step Allocation Control invoked JFCB
Housekeeping. In this case, Unallocate Private Catalog
issues SVC 99 to dynamically unallocate all private
catalogs previously allocated during housekeeping processing and marks the PCCBs of the unallocated catalogs
as inactive (PCCACTIV=O) (so that they will not be
searched when the system locate is re-issued). Allocate
Private Catalog then reattempts the allocation; if the
catalog still cannot be allocated, processing is terminated.
Module
Segment
IEFAB469
REDOPREP
JLOCA TE reissues the system locate if the required
catalog is successfully allocated.
4
The system locate is unsuccessful if the CR I (or
volume list, if one was obtained during a previous
call to JLOCATE) is too small. JLOCATE:
• Issues a FREEMAIN macro instruction to release a
previous volume list if one existed (HWNEWVL=l).
• Issues a GETMAIN macro instruction for the required
amount of storage.
IEFAB469
REDOPREP
• Places a pointer to the volume list in the HSKPWA.
<
• C)ets local controls to indicate an additional volume
list is in use (HWNEWVL=l).
N
{I)
<=>
W
00
o
This volume list is used for all subsequent JLOCATE
processing unless it is too small; in this case, it is
released and JLOCATE obtains a new volume list.
If the required volume list is successfully obtained,
JLOCATE reissues the system locate.
d) The system locate is unsuccessful because the dsname
could not be found. If this occurs, control is returned
to the caller and processing terminates.
3
Extended Description
IEFAB469
REDOPREP
IEFAB4F5
ALCATLG
IDACATll
IEFAB4EF
FINDPCCB
5
If information is successfully retrieved from a
catalog, JLOCATE·:
• Copies DSORG information from the CRI (or volume
list) into the current JFCB.
• Ensures that the disposition is KEEP (SIOTKEEP=l)
if the data set is a VSAM data set.
• Sets the GDGALL indicator in the local controls
(HWGDGALL=l) if the system locate determined
this request was GDGALL.
IEFAB466
• Sets the local controls to indicate the data set was
found in the catalog (HWDSNCAT=l).
IEFAB4F5
RECOVERY
IEFAB4F4
• Updates the PCCBs with the catalog connector (alias),
if any, and ensures that all the PCCBs are marked
active (PCCACTlV=l) so that the associated catalogs
can be searched on subsequent calls to J LOCA TE.
Error Processing
An error in any routine causes control to be returned to
the calling routine.
IEFAB4F5
ALCATLG
In the event of an abnormal termination, the EST AE
exit routine established by I EFAB451 performs any
necessary cleanup .
~
IEFAB469
CLEANUP
~
w
Diagram 14-9. IEFAB471 - Generic Allocation Control
(part 1 of 10)
w
00
~
~
~
CIl
~
a
i
..
ENTRY from IEFAB421 Common Allocation Control
Allocation
Work Area
(ALCWA)
,
Input
Output
Function Map
I
Generic Allocation Control: Attempt
to allocate remaining requests.
()
~
c;:
~
ALCWA
,
Volunit Table
,
Algorithm
Interface
Tables
I
II
i
s-a~
1
'I
(Cover/Reduce
Request List;
Cover/Reduce
Group List;
Group Count
Table)
Build tables needed for generic
allocation.
(II
w
<
CIl
~
o
w
00
~
--
Extended Description
ENTRY
Common Allocation Control calls Generic
Allocation Control (lEFAB471) to attempt
to allocate all remaining requests. The processing of
IEFAB471 must be serialized with all other allocations.
(For a description of serialization and when it is required
see "Common Allocation Control" in the "Introduction
to AliocationlUnallocation.") To minimize serialization,
IEFAB471 processes one generic device type at a time;
within a generic, it serializes only those device groups
needed by unallocated requests. (Device groups and their
representation in group masks are described under
"Generic Allocation Control" in the "Introduction to
Allocation/Unallocation. ")
To avoid deadlock situations, all allocations must choose
generics in the same order. The installation device
precedence list (defined during system generation) dictates the order in which generics are chosen. The generic
to be processed is selected in step 2 of this diagram; steps
3-12 are a loop performed for every generic selected.
Within this loop, there are four basic allocation processes:
Module
Segment
Extended Description
Module
• Demand (specific unit) allocation (step 6).
• Specific volume allocation (step 8).
• Allocation via algorithm (step 9).
• Nonspecific volume allocation (step 10).
Not all of these processes are necessarily performed for
each generic group selected in step 2 - the processes
performed depend on the types of unallocated requests
that are eligible to the generic. See the individual steps
for details.
1
Generic Table Build issues a GETMAIN macro
instruction to obtain storage for the following
tables required by generic allocation: a) a,lgorithm
tables; b) a request-id-mask table; c) an allocation queue
manager request block; d) three work masks.
a) The purpose of the algorithm tables i.s to summarize
the unit requirements of each request, the device
groups to which a.request is eligible, and information
about the units in each device group. Allocation via
IEFAB472
Segment
~
',-
Diagram 14-9. IEFAB471 - Generic Allocation Control
Extended Description
1
Module
Segment
For example, there are four unallocated SlOTs, each
with the following group mask:
• The group count table (CRPCOUNT) includes an entry
for every device group. Each entry summarizes the
number of units available, the number allocated, the
number offline, the total number of units, and the
number of units not used by the allocation.
SlOT
SIOT1
SIOT2
SIOT3
SIOT4
For details on these tables, see Section 5, Data Areas.
(I)
o·
=
t-.)
a::
(I)
[
So
o
"t:I
~
=-o·
=
(N
~
(N
\Q
b) The request-id-mask table is used to determine when
device groups must be serialized and when serialized
device groups can be released. Each entry in the
request-id-mask table contains a request identifier (id),
the number of unallocated SlOTs associated with the
request id, and a group mask indicating the device
Module
To build the request-id-mask table, IEFAB472 does
multiple scans of the SlOT chain to find unallocated
SlOTs whose group masks intersect. (The EDT contains group masks of the unit groups to which each
SlOT is eligible; the EDL for each SlOT points to the
group masks in the EDT.) All SlOTs whose group
masks intersect are assigned the same request id
(SIOTGIID in the SlOT) and are represented by the
same entry in the request-id-mask table. The mask
placed in the entry is a composite mask of the individual masks, showing all the device groups required
by the associated SlOTs.
• The cover/reduce group list (CVRGPLST) contains an
entry for each request in the cover/reduce request
list; the entry lists the device groups to which the
request is eligible. Each device group listed points to a
corresponding entry in the group count table.
tf.)
Extended Description
groups required by the associated SlOTs. (For a
description of group masks, see "Group Masks" in the
"Introduction to Allocation/Unallocation.")
• The cover/reduce request list (CVRRQLST) contains
an entry for every unallocated volunit entry - that is,
for every unallocated possible request for a unit. The
entries are updated as they are allocated; each entry
points to a corresponding entry in the cover/reduce
group list.
S4.
':_7
(part 2 of 10)
a) (Continued) Algorithm (lEFAB476 - step 9) selects
device groups from which requests should be allocated when a choice of units exists; it uses the algorithm
tables to determine from which device groups units should
be allocated so that all requests can be satisfied. There are
three main sections in the algorithm tables:
To initialize the tables, Generic Table Build (I EFAB472)
scans the SlOT chain for SlOTs that have not been
allocated; for every unallocated volunit entry of each
unallocated SlOT, it creates an entry in the cover/reduce
request list. The EDL for each SlOT contains the
generic groups eligible to this request and, within each
generic group, the eligible device groups. This information is used to initialize the cover/reduce group list. The
group count table is initialized by means of the EDT,
which contains all the device groups; an entry is created
for each device group but is not further initialized
until step 3.
.7
IEFAB472
DOALGTAB
device groups
1 2 3 4 5
0
0
0
o
o
0
0
0
0
0
1
o
1
0
0
0
The mask of SIOT1 does not intersect with any of the
other masks. It is assigned a distinct request id and has a
single entry in the request id mask table; the mask in the
entry is its group mask, 0 0 0 0 1. The masks of
SIOT2, SIOT3, and SIOT4 intersect.
Note: Although the mask of SIOT2 does not intersect
with the mask of SIOT4, both intersect with the mask
of SIOT3.
IEFAB472
DORIMTAB
These three SlOTs are assigned the same request id and
are represented by the same entry in the request-id-mask
table; the mask in the entry is the combination of the
three masks, 1 0 1 1 O.
The purpose of associating SlOTs is to allow allocations
to be rearranged; none of the device groups for the
associated SlOTs are released until all the SlOTs are
allocated. (For more information on rearranging
allocations, see the M.O. diagram Allocation via
Algorithm (lEFAB476)).
Step 1 continued on Part 3
Segment
~
w
~
o
~
ALCWA
N
rn
2
Installation Device
Precedence
I
Select generic device type to
process and serialize needed device
groups.
~
•
~.
j
If all generic device types
have been considered or
all requests are allocated,
go to step 14.
device groups
searialized
LGENLOCK
updated
ALCWA
Group Count
Table
~
updated
[
3
(D
w
Determine availability of devices
in device groups serialized in step 2.
~N
Parameter
List
i
4
Do AVR processing if generic device
type is tape or non-MSS direct access.
Generic
rlCBLinl
II
w
a) Build list of UCBs.
~
List
VI I
UCB List
Extended Description
1
b) Read premounted volumes.
If error, unload volume .
•
Module
(Continued)
c) The allocation Queue manager request block (AQMRB)
serves as the interface to the allocation queue manager,
which actually serializes and releases device groups. In
the AQMRB, Allocation Within Generic indicates if this
allocation can wait for units; the Allocation Queue
Manager then builds the necessary data structures for
handling requests from this allocation.
IEFAB472
d) The work masks are workareas, pointed to by ALCWA,
that are used in determining the group mask of device
groups that must be serialized and the group mask of
device groups that can be released.
IEFAB472
Segment
2
The purpose of this step is to:
• Select the first generic group from the installation device
precedence list that has not yet been selected and that
contains devices required by one or more unallocated
requests.
IEFAB471
• Serialize the needed device groups within the selected
generic.
IEFAB4FA
To determine what generic group and which device groups
are needed, the following processing is performed:
IEFAB471
a) To obtain a mask of all needed device groups, Generic
Allocation Control combines (by means of an "or"
function) all the group masks in the request-id-mask
table associated with entries that include unallocated
Step 2 continued on Part 4
SlOTs.
~
"--'"
Diagram 14-9. IEFAB471 - Generic Allocation Control
Extended Description
2
(part 4 of 10)
Module
Label
d) If a retry is being performed (GENLOKSW=1 in the
function map), Generic Allocation Control determines
if the entire generic device type must be serialized for
direct access, or for additional compatible generic
device types, or for tape. (Retry is described .under
"The Retry Situation" in the "Introduction to
Allocation/Unallocation.") Generic Allocation Control
searches the SlOT chain for a SlOT marked for retry
(SIOTRTRY=1). If the SlOT is eligible to the selected
generic, the mask of device groups to be
set to the mask of 1) the generic device type for direct
access, or 2) all compatible device types for tape.
The entire generic must also be serialized if a specific
unit was requested. Otherwise, the mask of device
groups to be serialized is the mask obtained in step 2c.
IEFAB471
e) The Allocation Queue Manager serializes the device
groups indicated in the mask.
IEFAB4FA
3
IEFAB471
DETLOCK
=
~
ac:
('D
[
o
....
o
~
Q
a
5'
=
~
~
~
Generic Allocation Control determines the status of
the UCBs in the serialized device groups and updates
the unit information in the group count table. The EDT
contains the device groups and indexes into the
lOS UCB LUT for the units in each device group. The
group count table is updated to indicate the number of
units that are:
• Offline (UCBONLI=Ol.
• Allocated (UCBALOC=1l.
• Available.
a) If the generic group is tape or direct access,
Generic Allocation Control builds a list of the UCBs in
the serialized device groups (generic UCB list!. The EDT
contains the device groups and indexes into the lOS
UCB LUT for the units in each device group.
IEFAB471
CALLAVR
b) AVR Control checks the generic UCB list to locate
UCBs that are unallocated, online, ready, and do not
contain a volume serial number. For each such unit,
Direct Access Label Read (if the device is direct access)
or Tape Label Read (if the device is tape) reads the label
of the volume. If no error is encountered in reading the
label, AVR Control places the volume serial number in
the UCB and, for tape, sets the label-type indicator in
the UCB. If an error is encountered, AVR Control
issues an appropriate error message to the operator and
the Unload Interface has the volume unloaded. Errors
are encountered in the following situations:
IEFAB473
Automatic volume recognition (AVR) allows the
operator to premount tape and direct access volumes
IEFAB4F8
IEFAB4F9
IEFAB49C
• A tape volume does not have labels. (Unlabeled
volumes cannot be premounted.!
• A tape volume has non-standard labels and a user
routine to read non-standard labels was not included
in the system or the user routine did not return a
volume serial number.
• A tape volume has ANSI labels and the ANSI converter routine was not included in the system at system generation.
('D
5'
Segment
prior to the initiation of.the job step that requires the
volumes. The purpose of this step is to recognize that
these volumes have been mounted.
c) Generic Allocation Control combines (by means of an
"and" function) the mask of the selected generic group
(from the EDT) with the mask obtained in step 2a to
determine if the generic group contains needed device
groups. If no common device groups are found (the
resulting mask contains only zeroes), step 2b is repeated
to select the next generic. If common device groups are
found, the LGENLOCK field in ALCWA is updated with
the id of this generic. (The generic id is included in the
EDT.)
tI.l
Module
4
(Continued)
b) Generic Allocation Control selects the first generic
listed in the installation device precedence list that has
not yet been selected.
a
Extended Description
DESTATUS
• Duplicate volume serial numbers were found. (AVR
Control uses the lOS UCB LUT to check if the volume
serial number it has read is a duplicate.!
IEFAB473
B473DPCK
After AVR Control completes processing, Allocation
Within Generic issues a FREEMAIN macro instruction
to rE!lease the generic UCB list.
IEFAB471
CALLAVR
~
Diagram 14-9. IEFAB471 - Generic Allocation Control (part 5 of 10)
~
~
~
InDut
Qutput.
~
rIl
1
~
ALCWA
ALCWA
5
E
(S'
rc;:
!
Prepare to allocate demand requests
eligible to this generic device type,
ra
"\:'
","
Last SlOT
LGENLOCK
~
E"
, SlOTs
updated if
ineligible
Algorithm
Tables
~
w
'<
rIl
6
~
::a
t
~
w
Allocate demand requests eligible
to this generic device type,
Count
Table
~
ALCWA
Volunit
Table
E@
7
Prepare to allocate remaining
requests eligible to this generic
device type,
space
obtained
(except for ISAM)
~
l '
{Last SlOT
' SlOTs
updated if
~ineligible
'-~7
"IIIII[!!!!!!!
Diagram 14-9, IEFAB471 - Generic Allocation Control (part 6 of 10)
Extended Description
Module
Segment
Extended Description
Module
Segment
5
IEFAB475
FLAGDMAN
7
IEFAB475
FLAGIGEN
Allocation Within Generic marks as ineligible
(SIOTGIGN=1) all unallocated SlOTs except those
representing demand requests (a unit address was specified;
for example, UNIT=190) that are eligible to the generic
device type selected in step 2. The LGENLOCK field in
ALCWA contains the id of the selected generic; the EDL
for each S lOT contains the ids of the generic device types
to which the SlOT is eligible; the SlOT itself indicates if it
represents a demand request (SIOTDMND=1)~
a) Allocation Within Generic marks as ineligible
(SIOTGIGN=1) all unallocated SlOTs except those
that are eligible to this generic and that do not represent
demand requests. (Demand requests eligible to this
generic were processed in step 6,)
If no demand requests eligible to this generic are found,
proCessing continues with step 7.
6
Demand Allocation processes those SlOTs that were
not marked ineligible instep 5 - that is, all SlOTs
representing demand requests that are eligible to the
generic device type being processed. Demand Allocation is
not called if step 5 determined that there are no demand
requests eligible to this generic. For details, see the
M.a. diagram Demand Allocation (lEFAB479);
This step has two functions: a) to determine which
SlOTs are to be processed; b) to determine what
processing is required for those SlOTs.
IEFAB479
b) To determine what processing is required for the
unallocated SlOTs eligible to this generic, Allocation
Within Generic categorizes the requests by examining
the volunit entries:
• Specific volume requests. These will be processed
in step 8 by Specific Volume Allocation Control if
the volume is mounted. (If the volume is not mounted,
step 8 will indicate that Allocation via Algorithm must
process the request.)
• Non-tape and non-DASD requests; nonspecific volume
requests for private volumes. These will be processed
in step 9 by Allocation via Algorithm. (Allocation via
Algorithm will also process specific volume requests
if indicated by step 8.)
• Nonspecific requests for public volumes. These
requests will be processed in step 10 by Nonspecific
Volume Allocation Control.
C"Il
CD
14e'
::s
!'t
iC
~
8.
e.
o
1lf
~
t
~
If one of the preceding types of requests is not found,
the corresponding allocation processing is not performed;
for example, if there are no specific volume requests,
Specific Volume Allocation Control (step 8) is not
called.
t
Diagram 14-9. IEFAB471 - Generic Allocation Control (part 7 of 10)
t
~
Process
w
ut
C'n
1
8
~
it-
r
Allocate specific volume requests,
if volume is mounted.
Count
Table
~
~
r
9
CD
w
~N
ALCWA
i
!
-
For details,
see Specific
Volume
Allocation
Control
(lEFAB433)
Allocate requests by means of the
algorithm :'
• non-tape and non-DASD requests.
•
nonspecific volume requests for
private volumes.
•
specific volume requests not
allocated in step 8.
@
space
obtained
(except for ISAM)
w
~
10
Parameter List
-----..Y1st
ALCWA
SlOT
~
Parameter
List
Allocate nonspecific volume
requests for public volumes to
mounted volumes:
a) Build listof eligible devices.
~Ial.
I
Algorithm Tables }
Eligible UCB List
-I
Eligible
UCB List
1
Volunit Table
b) Allocate requests.
d ReleaseUCB list. ------..........,,.,,...----,
.~
updated
~
Diagram
14~9.
IEFAB4,71 - Generic Allocation Control
(part 8 of 10)
Extended Description
Module
8 .This step is performed only if step 7 determined that
IEFAB433
unallocated· specific volume requests are eligible to
this generic device type. Specific Volume Allocation Control allocates specific volume requests if the volumes are
mounted. If a volume is not mounted, the request will be
processed by Allocation via Algorithm (step 9). For details
on Specific Volume Allocation Control, see the
This step is performed if any of the following conditions are true:
Extended Description
Module
Segment
IEFAB475
ASCRMONT
10
This'step is performed only if step 7 determined
that unaltocated nonspecific volume requests for
public volumes are eligible to this generic device type.
a) Allocation Within Generic (lEFAB475) builds a list
of all the UCBs in the device groups serialized for
this generic that meet the following conditions:
• The unit is online, ready, and is not pending offline.
M.O. diagram Specific Volume Allocation Control
(I E F AB433).
9
Segment
• The unit is not pending an unload or a mount.
IEFAB476
• The unit is not in use by a system task (UCBNALOC=O).
• The unit is not allocated as nonshareable.
• Step 7 determined that unallocated requests for nonDASD or non-tape devices are eligible to this generic
device type.
• The unit contains a non-private volume.
• Another request within this allocation is not waiting
for this unit.
• Step 7 determined that unallocated nonspecific volume
requests for private volumes are eligible to this generic
device type and volume mounting is allowed (as indicated in the common allocation function map - see
figure 17).
The EDT contains indexes into the 105 UCB LUT for
all the units in each device group. The mask of the
serialized groups indicates which device groups should
be searched.
IEFAB436
~
b) Nonspecific VOlume Allocation Control (lEFAB436)
allocates nonspecific volume requests for public
volumes to mounted volumes. If a request cannot be
allocated to a mounted volume, it will be processed
during the processing of another generic device type
(if the request is eligible to more than one generic)
or by Recovery Allocation (see the M.O. diagram
RecOvery Allocation (lEFAB485)). For details on
Nonspecific Volume Allocation Control, see the
M.O. diagram Nonspecific Volume Allocation
Control (lEFAB436)'
IEFAB475
~
c) Allocation within Generic (lEFAB475) issues a
FREEMAIN macro instruction to release the
UCB list.
• Specific volume requests were not allocated in step 8
because the volumes were not mounted and volume
mounting is allowed (as indicated in the common allocation function map - see figure 2-27).
Aliocation via Algorithm processes the requests; for details,
see the M.O. diagram Allocation via Algorithm
(lEFAB476).
fI'.)
~
e·
=
!'!
~
[
0
~
0
"a
ie·
=
w
c:w
-110
CI'I
..
IEFAB476
ASCRMONT
~
~
Diagram 14-9. IEF AB471 - Generic Allocation Control (Part 9 of 10)
.a:.
Q\
~
"
~
~N
o
~
00
Use algorithm to determine
from which device groups
requests should be allocated.
L..-_ _-I
ALCWA
Algorithm
Tables-updated
LJ
1st SlOT
or---
ALCWA
1st
SlOT
Vol unit
Table
EDLs & SlOTs
updated if
necessary
2
o~
'-'
Ensure that each multi-unit/
multi-generic request will be
allocated to a single generic,
if necessary.
ulJiD
DSAB
ALCWA
3
Unallocate requests that must
be rearranged.
.£0£'
EJ
space
released for
unallocated
requests
TIOT-
...
~J
'--'
Diagram 14-10. IEFAB476 - Allocation via Algorithm (Part 2 of 6)
Extended Description
Module
Segment
Allocation via Algorithm is called by Alloca·
tion within Generic (lEFAB475) and Recovery
Allocation (I EFAB485) to process requests when a choice
of units exists: a specific unit was not requested; the
request cannot be satisfied by allocating it to a mounted
volume; the request cannot be allocated to a permanently
resident or reserved volume.
ENTRY
1
The Cover/Reduce Algorithm selects device groups
from which unallocated requests should be allocated;
the caller indicates in the cover/reduce request list of the
algorithm tables the requests that should be processed by
the algorithm (CVRSKF LG=O). The Cover/Reduce
Algorithm updates the algorithm tables to indicate its
selections; a return code indicates if all or only part of the
requests to be considered were processed. Further proc·
essing of requests not processed by the algorithm (that is,
for which the algorithm did not select a device group) is
deferred.
Vl
fD
er
=
N
::::
~
Q.
fD
e.
o
"c::I
~
a(5'
=
~
~
If the MUG request can be satisfied with a single generic,
IEFAB474 indicates its selection in the algorithm tables;
IEFAB481 (Eliminate Ineligible Groups) updates the
EDL and the algorithm tables to mark every other generic
ineligible (thereby preventing the algorithm from later
rearranging this request to another generic) and sets to
zero the SIOTAFID field (thereby indicating that the
MUG request is successfully processed). IEFAB481 is also
called to update the algorithm tables and the EDL and to
set to zero the SIOTAFID field for MUG requests that
the algorithm did assign to a single generic.
IEFAB480
If IEFAB474 cannot successfully process the MUG
request, it updates the algorithm tables to cancel the
algorithm's selection of device groups for this request.
The request is not further processed at this time. (When
the caller is Allocation Within Generic, the MUG request
might be satisfied with a single generic when a subsequent
generic is serialized; otherwise, the request will be processed
during recovery allocation. When the caller is Recovery
Allocation, MUG requests that cannot be successfully
processed at this time will be handled by Offline/
Allocated Device Allocation - IEFAB486.)
~
IC
When the algorithm chooses device groups from
which requests should be allocated, it does not ensure
that a multi-unit request eligible to more than one generic
is allocated to a single generic. Only certain multi-unit tape
requests can be allocated to more than one generic because
of the dual density feature. Each multi·unit request that
must be allocated to a single generic - each MUG request was assigned an id (SIOTAFIDI0 in the SlOT) by
IEFAB472 during generic allocation. Requests that specify
affinity to a MUG request were assigned the same
SIOTAFID. The purpose of this step is to ensure that each
MUG request will be allocated to a single generic.
Segment
IEFAB481
IEFAB474
3
IEFAB474 (Process Multi-Unit/Generic Requests) locates
MUG requests with the same SIOTAFID that were assigned
to more than one generic by the algorithm, and that were
completely processed by the algorithm. (If requests with
the same SIOTAFID were not completely processed by
the algorithm, further processing of them is deferred.)
IEFAB474
HOWALGC
IEFAB474 tries to satisfy each such MUG request by
considering the units that the algorithm selected for
the request and:
IEFAB474
FORCEGEN
• The excess (unused) units in the last generic acquired
if the caller is Allocation Within Generic.
Module
• The excess (unused) units in each acquired generic to
which the request is eligible if the caller is Recovery
Allocation.
2
l4.
Extended Description
In order to find sufficient units to allocate a request,
the algorithm might have had to rearrange requests
already allocated - that is, indicate that an allocated
request must be assigned to a different device group in
order to free units needed to satisfy an unallocated
request. Requests to be rearranged are indicated in the
group list entry of the algorithm tables - the number
of units already allocated (CVRGRPAL) is greater than
the number of units the algorithm can select for allocation (CVRGALL). The purpose of this step is to unallocate
requests that must be rearranged.
IEFAB477 (Unallocate Requests to be Rearranged)
updates the TlOT, volunit table, SlOT, group id list, and
the UCB for each request to be unallocated; Common
Unallocation Control releases any space obtained for
the request.
IEFAB477
IEFAB4AO
GIVEBACK
Cf
~
Diagram 14-10. IEFAB476 - Allocation via Algorithm (part 3 of 6)
Q
~
OutP~t
Inout
N
i:;
ALCWA
4
....--
r-
Parameter
List
Allocate request.
For each request:
~l
~.
r-
a)
i
Build list of eligible units.
UCB
Candidate List
"
eo~
~
w
'
~
Recovery Allocation: Attempt
to allocate o~tstanding requests.
1
o
ut
2
Q
Process tape requests marked
for recovery processing.
Tape volumes unloaded
a) If a device is not required
(implicit unit affinity),
unload volume.
1st SlOT
Volunit
Table
~
'<
•
Process
, i i
Mmm
ALCWA
b) If a device is required,
attempt to allocate
request.
Count
Table
00
-""
o
Count Table
ITOTREQS~I
If all requests are satisfied,
return to caller.
Return to
Common Allocation
Control (IEFAB421)
Algorithm
Tables
JFCB
~_3'
~.~
~
Diagram 14-12. IEFAB485 - Recovery Allocation (Part 2 of 8)
Extended Description
Module
Segment
Recovery Allocation is called by Common
Allocation Control if both of the following
conditions are true:
ENTRY
Recovery Allocation attempts to allocate all remaining
requests; the four steps in this diagram reflect the four
different situations that result in Recovery Allocation. In
the first three steps, only unallocated, allocated but
shareable, and online devices are considered for allocation;
in the fourth step, Recovery Allocation will consider offline andlor allocated (nonshareable) devices, if allowed for
this allocation (as indicated in the function map of the
common allocation parameter list).
N
:::
~
;.
o
Q.
....
o
o
'0
S
g.
::s
~
w
'"
VI
1
During Generic Allocation Control, tape requests were
marked for retry processing. Then in retry processing
such tape requests were also marked for recovery processing,
if a needed volume was located on a generic different from
the generic selected for allocation. This step processes these
requests. (For background information, see "Processing Tape
Requests" in the "Introduction.to Aliocation/Unaliocation.")
Recovery Allocation scans the volunit table for tape
requests (VOLTAREQ=l) that indicate recovery processing is necessary and that indicate the needed volume
was mounted on a device type other than the one selected
by Generic Allocation. Processing of these requests depends
on if 1) a device is not required for this volunit entry; Or
2) a device is required for this volunit entry.
a) A device is not required if more volumes than units
were requested (implicit unit affinity) - for example,
the user coded:
IEFAB485
TVALUNLD
b) If a device is required, Specific Volume Allocation
Control tries to allocate the volume where it is mounted.
(For details on Specific Volume Allocation Control,
see the M.O. diagram Specific Volume Allocation
Control (IEFAB433). If the request cannot be allocated where it is mounted (for example, although the
volume is mounted on a compatible device type, the
request is not eligible to that generic - see "Processing Tape Requests" in the "Introduction to
Allocation/Unallocation") and if volume mounting
is allowed (as indicated in the function map of the
common allocation parameter list):
In the first three steps, unsuccessful attempts to allocate
requests do not necessarily. result in failure of the allocation, because of the possibility that the requests can be
satisfied in step 4 if offline andlor allocated devices can be
considered.
~
Segment
During generic allocation, volume A was successfully
allocated to a 2400 device but volume B was mounted
on a device of a different generic type. Recovery Allocation searches the UCBs (by means of the lOS UCB
LUT) to locate the needed volume. If the volume is
found, the Unload Interface unloads the volume. (If
the volume is not found, it has already been unloaded;
for example, another request needed the unit on
which it was mounted and had the volume unloadedJ
• Retry is not .indicated (lNDRETRY=O in ALCWA).
(Retry is indicated 1) when a needed DASD volume was
mounted on a unit not included in the serialized device
groups, or 2) a needed tape volume was found on a unit
of a different device type, but the device type is compatible with the one being processed by Generic Allocation.
For retry, allocated requests are unallocated and the
allocation is reattempted; therefore, it is unnecessary to
perform recovery allocation.)
til
Module
/IDOl DO DSN=ALLOC,DISP=OLD,UNIT=2400, *
II
VOL=SER=(A,B)
• Requests still remain to be allocated. (The TOTREQS
field in the count table does not equal 0.)
Po
o·
::s
Extended Description'
IEFAB485
TAPEVALI
IEFAB49C
IEFAB433
• Demand Allocation receives control, if there are
demand requests. For details on Demand Allocation, see the M.O. diagram Demand Allocation
(lEFAB4791.
IEFAB479
• Allocation via Algorithm receives control if there
are requests other than demand requests. For details
on Allocation via Algorithm, see the M.O. diagram
Allocation via Algorithm (JEFAB476).
IEFAB476
If volume mounting is not allowed, this allocation is
failed. Recovery Allocation returns to Common Allocation Control.
Note: Unsuccessful attempts to allocate requests by
Demand Allocation or Allocation via Algorithm do
not result in failure, because of the possibility of allocating these requests in step 4 if offline andlor allocated devices can be considered.
~
Diagram 14-12. IEFAB48S ~ Recovery Allocation (part 3 of 8)
c
~
~
Process
Input
Output
fI.)
I
2
~
1·
j
Process affinity requests that
were not allocated due to a
recoverable DADSM error.
-
ALCWA
a) Unallocaterequests that
must be rearranged.
~
Rspace
UreleaSed
a"
!
C.H
~
b) Build UCB candidate list.
~
L
~
rIS
-
Parameter List
t---- i
UCB Candidate List
--ALCWA
C.H
:....
-:=r-
...
List
,---~
1 st SlOT
UCB
Candidate List
L:J
Volunit Table
c) Allocate requests to
mounted volumes.
UCB Candidate. List
I
Count Table
I
TOTR EQS"Il
I
d) Release. UCB candidate
list.
If all requests are satisfied,
return to caller.
UCB candidate
list released
Return to Common
Allocation Control OEFAB421)
..,
"'../
~~
Diagram 14-12. IEFAB485 - Recovery Allocation (Part 4 of 8)
Extended Description
Module
Segment
Extended Description
Module
Segment
2
IEFAB485
DADAFFER
b) Recovery Allocation uses the SYSALLDA entry of the
EDT to search the lOS UCB LUT for direct access units
with mounted volumes that are eligible to satisfy nonspecific volume requests. To be eligible, a UCB must
meet the following conditions:
IEFAB485
DAFERLST
IEFAB485
IEFAB436
DADAFFER
IEFAB485
DADAFFER
This step .handles the following situation: two or
more nonspecific direct-access volume requests
specified volume affinity to each other; at least one of
these requests was successfully allocated, but a subsequent request could not be allocated to the same volume
because of insufficient space (that is, a recoverable DADSM
error). Recovery Allocation unallocates the request(s) that
were allocated and tries to find a volume to which all the
requests specifying affinity to each other can be allocated.
• The UCB is online, ready, and not pending offline.
• The UCB is not in use by a system task
(UCBNA LOC=O l.
• No unload or mount is pending for the UCB.
Recovery Allocation searches the volunit table for entries
that indicate a recoverable DADSM error occurred while
allocating an affinity request (VUDADSME=l). The following steps are performed for these requests:
a) IEFAB477 unallocates the requests that were successfully allocated: this routine updates the TIOT, volunit
table, SlOT, and UCB; Common Unallocation Control
releases the direct access space.
• The volume on the unit is shareable and has a use
attribute of public or storage.
IEFAB477
IEFAB4AO
• No other request is waiting for this unit to be unallocated so that the volume mounted on the unit can be
moved to another unit.
Pointers to eligible UCBs are placed in a UCB candidate
list; this list is used by Nonspecific Volume Allocation
Control to determine the units eligible to satisfy
unallocated requests.
c) Recovery Allocation calls Nonspecific Volume Allocation Control to allocate:
• Storage volume requests if there are any.
• Public volume requests if there are any.
CI.l
('D
()
g.
=
~
g==
('D
Q.
o....
o
"0
(1)
;
g.
=
~
W
0'1
The parameter list for Nonspecific Volume Allocation
Control includes a function map that indicates what
type of request should be processed and a pointer to
the UCB candidate list. For details on Nonspecific
Volume Allocation Control, see the M.O. diagram
Nonspecific Volume Allocation Control (lEFAB4361.
d) Recovery Allocation issues a FREEMAIN macro instruction to release the UCB candidate list.
~
~
N
~
~
N
Diagram 14-12. IEFAB485 - Recovery Allocation (part 5 of 8)
Input
Process
Output
fI}
'<
~
ALCWA
3
EDL
i
(is.
J
(D
~
'<
fI)
N
~
i
~
~
~
ALCWA
,.-..--
Vol unit
Table
a) Process multi-unit/multiiJeneric
requests that must be allocated
to a single generic.
t-
i
Allocate scratch requests that could
not be entirely allocated to
mounted volumes.
n
ALCWA
•
Choose generic from which
to allocate.
•
Build UCB candidate list.
•
Try to allocate secondary
unit requests to mounted
volumes.
•
Release UCB candidate list.
IOSUCBLUT
ALCWA
Count
Table
Parameter
List
r-
r
UCB
Candidate
List
"1L..-_ _
---6
space obtained
(except for ISAM)
SlOT
Diagram 14-12. IEFAB48S - Recovery Allocation
Extended Description
1:1}
(I)
a
e·
::I
~
a::
(I)
~
o....
o
"0
~
ao·
::I
~
W
0\
~
'-_7
-~,
~-CY
(part 6 of 8)
Module
Segment
3
Generic allocation allocated scratch requests only
if they could be completely allocated to mounted
volumes - for example, if a SlOT needed two volumes
and two units, it was allocated only if two mounted
volumes were available. In this step, Recovery Allocation
processes scratch requests not allocated during generic
allocation. This step is not performed if volume mounting
is not allowed (as indicated in the function map of the
common allocation parameter list - see figure 2-27).
IEFAB485
SCRATALG
a) Recovery Allocation first processes mUlti-unit/multigeneric requests (that is, multi-unit requests that are
eligible to more than one generic) that must be allocated to a single generic. (Allocation of a single request
to more than one generic device type is allowed only
for tape requests; this is possible because of the dualdensity feature.) Nonspecific Volume Allocation Control will try to allocate as many of the secondary unit
requests as possible to mounted volumes. The following steps are performed:
IEFAB485
SCRATALG
• For each multi-unit/multi-generic request, Recovery
Allocation determines which generic eligible to the
request contains the most mounted volumes that
can be allocated to scratch requests. (If no mounted
volumes are found in any of the eligible generics,
the SlOT is marked ineligible (SIOTGIGN=1) so that
Nonspecific Volume Allocation Control will not try
to process it.) The EDLNSCNT field of the EDL contains the number of mounted volumes that can be
allocated to nonspecific requests. IEFAB481 (Eliminate Ineligible Groups) updates the EDL and the
algorithm tables by marking as ineligible all generics
except the generic selected.
IEFAB485
IEFAB481
PICSCRAG
Extended Description
Module
• Recovery Allocation searches the lOS UCB LUT for
units eligible to satisfy scratch requests. To be eligible,
a UCB must meet the following conditions: the unit
is an unallocated tape or a shareable direct access
device; the unit is online, ready, and not pending
offline; no mount or unload is pending for the unit;
the unit is not in use by a system task UCBNA LOC=Q);
the use attribute is public or storage, not private; and
no other request is waiting for this unit. Pointers to
eligible UCBs are placed in a UCB candidate list to be
used by Nonspecific Volume Allocation Control.
IEFAB485
• Nonspecific Volume Allocation Control allocates as
many secondary unit requests as possible to mounted
volumes. (The function map in the parameter list for
Nonspecific Volume Allocation Control indicates
"partially allocate" - that is, allocate only secondary
unit requests.) For details on Nonspecific Volume
Allocation Control, see the M.O. diagram
Nonspecific Volume Allocation Control
(lEFAB436L
IEFAB436
• Recovery Allocation issues a FREEMAIN macro
instruction to release the UCB candidate list.
IEFAB485
Segment
SCRAMLST
SCRATALG
~
...
Diagram 14-12. IEFAB485 - Recovery Allocation
(part 7 of 8)
.@
~
N
I
i
f
Input
ALCWA
Output
Process
1st SlOT
3
Count
Table
(continued)
B) Try to allocate remaining
scratch requests via
algorithm.
~
Return to
Common
Allocation
Control
[
CD
W
'<
(lEFAB42U
fIj
N
i
w
~
Count Table
ITOTREQS=O I
A LCWA
If all requests are satisfied,
return to caller.
4
Consider offline and/or
Return
to
Common
Allocation
Control
(lEFAB421)
Requests satisfied
or
Job cancelled
or
Allocation instructed to wait with or without
holding resources already allocated.
See Offiine/ Allocated Device Allocation
OEFAB486)
~
"'~_J
~,--~7
Diagram 14-12. IEFAB485 - Recovery Allocation (Part S'of S)
Extended Description
3
Module
(Continued)
b) Allocation via Algorithm attempts to allocate all remaining scratch requests, including those secondary unit
requests that Nonspecific Volume Allocation Control
was unable to allocate. For details on Allocation via
IEFAB476
Algorithm, see the M.O. diagram Allocation via
This step is performed only if:
• this allocation is allowed to consider offline and/or
allocated devices (as indicated in the function map of
the common allocation parameter list - see
figure 2-27).
IEFAB485
control.
Offline/Allocated Device Allocation first determines if
all requests can be satisfied by considering offline and/or
allocated devices. If not, this allocation is terminated. If
all requests can be satisfied, the following processing
Module
a) Requests eligible to available devices are allocated.
IEFAB478
b) For each request that cannot be allocated to an available device, IEFAB487 (Allocation Recovery Interface
with Operator) queries the operator for instructions.
The operator can:
IEFAB487
IEFAB486
• Instruct allocation to wait for an allocated device(s),
holding resources. Recovery Allocation returns to
Common Allocation Control, which calls I EFAB491
(Wait Holding Resources). IEFAB491 waits for the
needed unit(s) to be unallocated and then allocates
the outstanding requests. For details, see the
M.O. diagram Common Allocation Control
(lEFAB421).
• Instruct allocation to wait for an allocated device(s),
without holding resources. Recovery Allocation
returns to Common Allocation Control. Common
Allocation Cleanup handles the wait-withoutholding-resources situation - see the M.O. diagram
Common Allocation Cleanup (IEFAB490).
occurs:
For details on Offline/Allocated Device Allocation, see
the M.O. diagram Offline/Allocated Device Allocation
(lEFAB486).
Error Processing
t"-l
(1)
n
S·
::I
~
~
~
:::s-
O
Q,
o
.....
o
'0
(1)
i3
S·::I
IN
W
0\
VI
Segment
• Instruct allocation to use an offline device, which
allocation will then bring online .
• all requests still have not been allocated; and
If requests remain to be allocated, but neither offline nor
allocated devices can be considered, Recovery Allocation
returns to the caller and further processing is terminated.
Otherwise, Offline/Allocated Device Allocation receives
Extended Description
• Cancel the job. Recovery Allocation returns to
Common Allocation Control.
Algorithm (lEFAB476l.
4
Segment
An error in any routine causes control to be returned to the
calling routine.
In the event of an abnormal termination, the EST AE
exit routine established by IEFAB421 performs any
necessary cleanup.
<:
C/J
N
o
W
00
o
~
~
~
Diagram 14·13. IEFAB486 - Offline/Allocated Device Allocation (part 1 of 12)
0'1
o
fIl
~N
fIl
I
ci
ENTRY from
IE F AB485 - Recovery Allocation
Output
Input
ALCWA
Function Map
,
"- ___ IAL~tf~:~~;tth }
Offline/Allocated Device Allocation
1
(1;'
j
Update algorithm tables to
indicate offline and/or allocated
devices should be considered.
ALCWA
o<
E'
a
Offline and/or
allocated devices
marked eligible
Algorithm
Tables - updated by Cover/Reduce
--Algorithm
(D
C.N
~N
2
Determine if all requests can be
satisfied by considering offline
and/or allocated devices.
-
..
Q
ALCWA
C.N
00
~
•
If not, return to Caller.
1st SlOT
-----,
}
SlOTs and
EDLs updated
if necessary
3
Ensure that each mUlti-unit/
multi-generic request can be
allocated to a single generic
device type, if necessary.
•
-
...
If multi-unit/multi-generic
request cannot be
allocated to single generic,
return to caller.
Return to Recovery
Allocation· (I E F AB485)
~
"'-_J
Diagram 14-13. IEFAB486 - Offline/Allocated Device Allocation
(part 2 of 12)
Extended Description
Segment
Module
ENTRY
Offline/Allocated Device Allocation is called by
Recovery Allocation (lEFAB485) only if the
following conditions are true:
• this allocation is allowed to consider offline and/or
allocated device (as indicated in the function map of
the common allocation parameter list - see figure 2-27).
Offline/Allocated Device Allocation updates the
algorithm tables to indicate that:
IEFAB486
• Allocated devices can be considered if the function map
indicates this allocation can wait for allocated devices.
• Offline devices can be considered if the function map
indicates this is allowed.
Note: The algorithm tables are always updated inat least
one of the preceding ways; if neither offline nor allocated
devices could be considered, Offline/Allocated Device
Allocation would not have received control.
2
The Cover/Reduce Algorit~m is called to determine:
IEFAB480
• If all outstanding requests can be satisfied by considering offline and/or allocated devices.
• The device groups from which unallocated requests should
be allocated. The algorithm's selections are indicated in the
algorithm tables.
CIl
~
If all requests cannot be satisfied, this allocation is terminated; Offline/Allocated Device Allocation returns to
Recovery Allocation.
n
g.
=
~
==
~
g
Q.
o....
o
"0
~
~
o·
=
~
~
0\
......
3
When the algorithm chooses devices to be allocated to
requests, it does not ensure that a multi-unit request
eligible to more than one generic is allocated to a single
generic. (Only multi-unit tape requests can be allocated to
more than one generic, because of the dual density feature.
Each multi-unit request that must be allocated to a single
generic - each MUG request - was assigned an id
(SIOTAFID'i 0 in the SlOT) by IEFAB472 during generic
allocation. Requests that specify affinity to a MUG request
were assigned the same SIOTAFID.) The purpose of this
step is to ensure that each MUG request will be allo~ted
to a single generic. If this is not possible, the allocation is
failed .
Extended Description
__ 7
Module
Segment
IEFAB474
HOWAlGC
IEFAB474
FORCEGEN
Two processes are performed to ensure that MUG requests
can be allocated correctly:
• all requests still have not been allocated; and,
1
'-~
IEFAB486
AlGAPREP
a) IEFAB474 (Process Multi-Unit/Generic Requests) locates
and processes each MUG request assigned to more than
one generic by the algorithm. IEFAB474 tries to satisfy
each such request by considering the units that the
algorithm selected for the requests and the excess
(unused) units in each acquired generic to which the
request is eligible. If one of the eligible generics can
satisfy the request (by considering only the excess units
and the units already assigned to the request), IEFAB474
indicates its selection in the algorithm tables; IEFAB481
(Eliminate Ineligible Groups) updates the EDl and the
algorithm tables to mark every other generic ineligible
(thereby preventing the algorithm from rearranging
this request to other generics) and sets to zero the
SIOTAFID field (thereby indicating that the MUG
request is successfully processed). If IEFAB474 cannot
successfully process the MUG request, it updates the
algorithm tables to cancel the algorithm's selection of
units for this request; the request will then be handled
in step 3b.
IEFAB481
IEFAB474
IEFAB481 is also called to update the algorithm tables
and EDl and to set to zero the SIOTAFID field for
MUG requests that the algorithm did assign to a single
generic.
IEFAB481
b) Offline/Allocated Device Allocation processes any MUG
requests that were not successfully handled by the
algorithm or by IEFAB474 (SIOTAFID'iO). For each
request, IEFAB486 considers each generic eligible to the
request: it temporarily marks all other generics ineligible
in the algorithm tables and then recalls the algorithm.
This is repeated for each eligible generic until a generic
is found that can satisfy the request or until all eligible
generics have been considered. If no single generic can
satisfy this request, the allocation is failed; IEFAB486
returns to Recovery Allocation. Otherwise, IEFAB481
updates the algorithm tables and the EDl to permanently
mark every other generic ineligible and sets to zero the
SIOTAFID field.
IEFAB486
IEFAB481
GIVEBACK
FORCMUlT
~
\ Diagram 14-13. IEFAB486 - Offline/Allocated Device Allocation (part 3 of 12)
00
~
N
..9
Input
Output
.Process
fI'J
'<
i
n
ALCWA
DSAB
TlOT
UCB
ALCWA
4
t:
DSAB
Unallocate requests. that must
be rearranged.
f
f
w
·
space released
. . ·for unal.,ocated
requests
U
~N
.:;0
t
II
w
~
ALCWA
5
Validity check unallocated
requests that require a specific
volume:
•
If volume is permanently
resident or reserved and
unit;is eligible'lto the
request, allOCate request.{':.<.""
...,
~.spaceobtained
L.::::1
(exceptfor-ISAM)
TIOT-
~
'----'"
Diagram 14-13. IEFA8486 - Offline/Allocat«i Device Allocation (Part 4 of 12)
Extended Description
Module
Segment
4
In order to find sufficient units to allocate a request,
the algorithm (called in step 2 and step 3b) might
have had to rearrange requests already aHocated - that is,
indicate that an allocated request must be assigned to a
different device group in order to free units needed to
satisfy an unallocated request. Requests to be rearranged
are indicated in the request list entry of the algorithm
tables - the number of units already allocated
(CVRGRPAL) is greater than the number of units the
algorithm selected for allocation ·(CVRGAlU. The
purpose of this step· is to unallocaterequests that must
be rearranged.
IEFAB477 (Unallocate Requests to be Rearranged)
updates the TlOT, volunit table, SlOT and the UCB for
each request to be unallocated; Common Unallocation
Control releases any space obtained for the requests.
!;Il
(D
Sl
e'
::s
~
==
;.
(D
.&.
0
"'"
0
.
"C
(D
~
g.
:I
IoN
W
0'1
\Q
Module
• If another request(s) indicates unit affinity to this<
request, IEFAB442 cancels the unit affinity by
increasing the number of units required. (Unit·
affinity can be either implied or explicit- see
"Selected Terms' Used in Allocation/Unallocation"
in the "Introduction to Allocation/Unallocation.")
If, as a result of increasing the unit requirements, a
SlOT would require more'than 59 units; the allocation is failed. Otherwise, the unit requirements are
increased and IEFAB4F2 updates the algorithm
tables to reflect the changed unit requirements.
IEFAB442
IEFAB442
IEFAB434
IEFAB4AO
• IEFAB434 (Allocate Request to Unit) allocates the
request. For details onIEFAB434, see the
M.O. diagram Allocate Request to Unit
(I E FAB434).
IEFAB441
IEFAB486
• IEFAB441 (Volume Validity Checker) marks the
volunit entry as allocated and decreases the
appropriate counts in the count table. If the SlOT
is now completely allocated, the SlOT is also
marked allocated and the TOTR EQS field in the
count table' is decreased,
IEFAB477
5
The purpose of this step is to validity check. unallocated requests: to determine if.a volume needed
by an unallocated request is mounted, and if the volume
is mounted, whether the request can be allocated.
Offline/Allocated Device Allocation scans the volunit
table to find unallocated requests that require a specific
volume; IEFAB441 (Volume Validity Checked performs
the validity check for each needed volume.
Extended Description
ENDVAlID
d) If the volume is not permanently resident or reserved,
I EFAB441 (Volume Validity Checked determines if
the device group containing the unit has.been serialized:
IEFAB441
IEFAB441 scans the EDT group entries to determine if the
volume is mounted. If the volume is not mounted, the
validity check is unnecessary and processing continues with
step 6. Otherwise, IEFAB441 performs'the following
checks:
a) The unit containing the volume must not be in use by
a system task (UCBNALOC=O). If it is, this allocation
is failed.
b) The device type of the unit containing. the volume is
compatible with the requested device type. If not,
this allocation is failed;
IEFAB441
c) If the unit containing the volume' is in a serialized
device group and the volume is permanently resident
or reserved, theUCB must be included in the EDl
for this request - that is, the unit is eligible.to this
reqiJest. If not, this allocation is failed. If the unit is
eligible, the following processing is performed:
IEFAB441
IEFAB441
CHEKTYPE
SERCHEDl
INCRUNIT'
IEFAB4F2
IEFAB441
• For the direct access device class, .retry ismecessary if
the device group on which the volume is mounted is not
serialized. For the tape device class~ the-group on which
the volume is mounted may be serialized, but a retry is
still necessary if the devices are compatible, but the'
device on which the volume is mounted belongs to a
generic device type' other tham the.first device type in
the eligible devices ·!ist·(.EDL). Offline/Allocated
Device Allocation returns to Recovery Allocation; the
retry situation will be handled by Common Allocation
Cleanup (seethe.M.O. diagram Common Allocation
Cleanup (lEFAB490).)
• If the device group is serialized, but the unit allocated
to another user, IEFAB441 (Volume Validity Checker}
indicates that this allocation must w~t for the unit. (The
wait condition is processed in step 9 of this diagram.)
• If the device group is serialized and the unit is not
allocated, IEFAB49C unloads the volume.
Segment
IEFAB49C
DOARURTN·
~
Diagram 14-13. IEFAB486 - Offline/Allocated Device Allocation (part 5 of 12)
~
i
~
~
Output
Process
Input
~
i
51
5
i
t)'
r-'
r
ALCWA
SlOT
Volunit
Table
~
Algorithm
Tables
(continued)
•
~
J
•
(II
w
~
Count
Table
If volume is removable,
device group is serialized,
and unit is unallocated,
unload volume.
'.,
I't;{
~
volume unloaded
If error or retry situation is
detected, return to caller.
~
6
i-'"
S
-
Allocate requests that can be
allocated to available devices.
w
~
a) Build list of eligible units.
CVT
I
CVTICB
V
Parameter List
~
.
~
~ I EZSSC
I.
ICBME
1
) UCB Candidate List
Parameter List
b) Perform mount equalization
for Mass Storage System
(MSS) request.
,,%I
,-A;
I~----~
UCB
Candidate List
c) If necessary, interface with
System Resources Manager
to select unit to allocate.
Parameter
List
UCB
Candidate List
selected
entry
~
Diagram 14-13. IEFAB486 - Offline/Allocated Device Allocation
(part 6 of 12)
Extended Description
Module
Segment
6
IEFAB478 (Allocate from Groups the Algorithm
Picked) allocates requests that can be allocated
at this time to available devices. IEFAB478 scans the SlOT
chain for unallocated SlOTs; for each unallocated volunit
entry, the following steps are performed:
IEFAB478
a) IEFAB478 builds a list of UCBs (UCB candidatelisd
that are included in a device group selected by the
algorithm and that meet the following conditions:
IEFAB478
GENAPREP
IEFAB478
ICBME
MONTEQAL
IEFAB478
IEFAB440
GALGALOC
• The UCB is online and unallocated.
• The UCB is not in use by a system task.
• The volume on the unit is not permanently resident
or reserved.
The EDL for the SlOT contains the addresses of UCBs
in the device groups eligible to the request. If the UCB
candidate list contains no entries - that is, no eligible
units meet the preceding conditions - IE F AB478
locates the next unallocated volunit entry to be
processed.
b) If the request is for a Mass Storage System (MSS)
device, I EFAB478 interfaces with ICBME, which
will return a preferred list of UCBs. This list will
then be used to merge into and update the UCB
candidate list. (See OS/VS2 Mass Storage System
Communicator (MSSC) Logic for information on
module ICBMEJ
~
(D
~
~.
:::I
~
at:
(D
[
Q
0-1)
o
"C
~
a
~.
:::I
~
w
~
.-
c) If the UCB candidate list contains more than one entry,
IEFAB478 interfaces with the System Resources
Manager to select the device to be allocated. IEFAB440
builds a list of allocated UCBs. The System Resources
Manager uses this list and the UCB candidate list to
determine which unit should be allocated.
~
.....
N
i
~
N
fIJ
I
i-
f
Diagram 14-13. IEFAB486 - OfOine/Ailocated Device Allocation (part 7 of 12)
Input
Parameter
List
UCB
Candidate List
~ selected.
~
ALCWA
Output
Process
ALCWA
I
-
SlOT
6
d) Allocate request to unit.
1&1
...
Volunit Table
~
go
w
~N
i:
r5
~
w
~
ALCWA
e) Release UCB .candidate list;
update volu"'t table, count
table, and if necessary,
SlOT.
A LCWA
UM
"Q
space obtained
(except for ISAM)
1st SlOT
Volunit Table
~
updated
Volunit Table
..--~
7
Release device groups no
longer needed.
AU
~Jj
Device groups no longer needed released
~
~~J'
Diagram 14-13. IEFAB486 - Offline/Allocated Device Allocation
Extended Description
6
Module
d) IEFAB434 (Allocate Request to Unit) allocates theunit.
For details, see the M.O. diagram, Allocate Request to
Unit (lEFAB434).
IEFAB434
e) IEFAB478 releases th~ UCB candidate list, marks the
volunit entry as allocated, and decreases the TOTVOLUN
field in the count table. If the SlOT is completely
allocated, IEFAB478 also marks the SlOT as allocated
and decreases the TOTREQS field in the count table.
IEFAB478
IEFAB478
IEFAB478
GENAPREP
GARURTN
7
IEFAB486
FREGROUP
• The algorithm indicates might be used to satisfy an
unallocated request.
• Include a specific offline or allocated unit that is needed
by this allocation.
• Include an allocated volume that is needed by this
allocation (for example, the volume must be moved to
another unit when it is unallocated)'
• Include a direct access unit that requires a scratch
volume to be mounted.
The Allocation Queue Manager is called to release the
device groups that are no longer needed.
fI'.)
:J
~
a::
.[
2-
..,o
ie:J
~
w
w
....
Segment
(Continued)
Offline/Allocated Device Allocation determines which
device groups are no longer needed and can be released.
Device groups that must remain serialized include those
that:
S!
S-
(part 8 of 12)
IEFAB4FA
--~
~
.....
Diagram 14-13. IEFAB486 - Offline/Allocated Device Allocation (part 9 of 12)
~
i
~
N
Input
Output
Process
fI'J
I
i
~IOS
ALCWA
.------..---
~
(s'
UCB LUT
ALCWA
,
8
Determine if requests that
are waiting for volumes can
be allocated to available
deviCes when the volume
becomes unallocated.
9
Inform operator of recovery
situation.
t:
!
~
~
(II
~
ALCWA
Function Map
i
'<
updated
~
".
r---vfL\
fI'J
N
Process requests that must wait
for a specific allocated unit.
i
PB
~
a) Issue messages to
operator.
~
b) Process operator's reply.
•
If CANCEL, return
to caller.
•
If WAIT, continue.
ALCWA
Volunit Tableupdated
c) Update volunit entry.
A LCWA
1st SlOT
11
Process remaining unallocated
requests.
a) If request requires offline or
allocated device:
•
Issue message to
operator.
•
Process operator's reply.
If CANCEL, return to
caller.
Return to Recovery Allocation (I EFAB485)
~
"'-~
Diagram 14-13. IEF AB486 - Offline!Allocated Device Allocation
(part 10 of 12)
Extended Description
Module
Segment
8
IEFAB486
SETHANDL
This step determines if requests that must wait for
a needed volume(s) to be unallocated (so the volume
can be moved to an eligible device) can be allocated to an
available unit, once the volume is unallocated. IEFAB486
searches:
I'D
=
~
a::
I'D
[
o
o-t)
o
"t:I
~
e!-
o"
=
<...I
c:w
.....
til
IEFAB488
BLDRMSG
IEFAB488
• If the reply is WAIT, IEFAB488 sets an indicator to
note a reply of WAIT was processed; this allocation
continues to process unallocated requests.
c) IEFAB487 updates the volunit entry of each request
The Cover/Reduce Algorithm is called to limit its final
selection of device groups from which to allocate.
IEFAB480
9
IEFAB487
IEFAB487 (Allocation Recovery Interface with
Operator) first processes demand requests if the
needed unit is allocated, and requests for a specific volume
that is mounted on an ineligible allocated unit. IEFAB487
searches volunit entries of each unallocated SlOT to locate
these requests.
IEFAB487
a) IEFAB487 issues message IEF4881 for each request,
informing the operator and appropriate device pools
of the allocated unit or the volume on an allocated
unit that is required. No operator response is required
IEFAB487
IEFAB487
SPECWAIT
requiring a specific allocated unit to indicate that no
further recovery processing should be done
(VURCVVPR=1 ).
RHDRMSGS
To determine the number of units needed, IEFAB487
searches the volun~t table (for demand requests) and the
algorithm tables (for non-demand requests) for each
unallocated volunit entry.
10
to this message. IEFAB488 (Allocation Recovery Reply
Options Processor) then issues message IE F238D,
requesting a reply from the operator. In this case
(specific waits), the only valid replies are CANCEL or
WAIT .
Segment
• If the reply is CANC E L, IE F AB488 returns to the
caller; this allocation will be failed.
For each request that can be allocated to an available
unit, IEFAB486 updates the algorithm tables to bind
the request to the device group containing the available
unit, and updates the volunit table to indicate that the
request can be allocated to an available unit
(VURCVYPR=1) .
(I}
Module
• If the reply is invalid (it is not CANCEL or WAIT),
IEFAB488 issues an invalid reply message (lEF4901)
and then reissues message IEF238D .
• the algorithm tables to determine if an available unit
can be used to allocate a request waiting for a volume.
ao·
Extended Description
b) IE F AB488 processes the operator's reply:
• the units in each serialized device group (by means of
the EDT and lOS UCB LUT) to locate available units;
and,
IE F AB487 (Allocation Recovery I nterface with
Operator) issues message IEF2441, informing the
operator of the number of units needed to complete
this allocation. If there are requests that require either
an offline or an allocated unit (but are not eligible to
both), a second line of the message is issued, indicating
the minimum number of offline and/or allocated devices
that are needed. This message is for information only
and does not require an operator response.
'_3'
SPECWAIT
SPECWAIT
11
IEFAB48A
a) If an offline or allocated device is needed for the request,
IEFAB48A issues the following messages to the operator
(and to appropriate device pools):
IEFAB48A
IEFAB48A (Process Offlines/Allocateds) searches
the volunit entries of each unallocated SlOT to
locate requests that have not yet been processed
(VURCVVPR=O). Remaining requests fall into two
categories: a) an offline or allocated device is needed to
satisfy the request; b) the request is not allocated but is
not eligible to any offline or allocated devices. (This
situation can occur if a needed device was brought online
before this step.)
• Message IEF4891 informs the operator of the number
of units that must be made available before the
request can be allocated.
IEFAB48A
BLDDDHDR
• If offline devices are needed, message IEF2471 lists
the devices that could be allocated to the request, if
the status of the devices were changed. The message
indicates which devices are offline or not accessible
(for example, the channel is offline).
IEFAB48A
BLDOLMSG
Step 11 continued on Part 11
~
Diagram 14-13. IEFAB486 - Offline/Allocated Device Allocation (part 11 of 12)
.....
0\
i
~
W
Process
Input
Output
til
'i
a
t"'"
A LCWA
ti
1st SlOT
~.
ALCWA
t"'"
cr
!<
a
c
:I
CD
w
b) If no offline or allocated
device is eligible to the
request, try to allocate
request to devices that have
become available.
'B1
VM&V
SlOT. Request Block •
~
iII
Output
Situation B: All requests are satisfied:
·'UstSIOj
A. LCWA
9
1·L.-J
_
• ,) B2 Mount and verify volumes.
:
:: >83
~1i
w.," )
Obtain space for new ISAM data
sets.
to.
84
Check multi-unit tape requests.
6
Volumes mounted.
Space assigned for
new data sets
(except ISAM).
to.
~
.A;
.J\
II
~ Space obtained for
~.
new ISAMdata sets.
TIOTentries'
rearranged, 'if
necessary
~
"'--7
Diagram 14-14. IEFAB490 - Common Allocation Cleanup
Extended Description
SITUATION B
(part 4
Module
of B)
Segment
Steps B1-B8 are performed if all requests
have been satisfied.
B1
Common Alloca·tion Cleanup searches the SlOT
chain for requests that were changed from storage to
private (SPVTAMSG=1 in the SlOT). (If insufficient storage
volumes were available to satisfy storage requests, Nonspecific Volume Allocation Control changed the requests to
private.) The System Message Interface Routine issues a
"private-assumed" message for each such request.
B2
The Allocation/Volume Mount & Verify (VM&V)
Interface (I EFAB492) receives control to mount
and verify needed volumes. During allocation, a VM&V
request block was built for every request that required a
volume to be mounted. For details, see the M.a. diagram
AllocationlVolume Mount & Verify Interface (IEFAB492).
IEFAB490
ASUMPVTS
IEFAB492
a
5·
::2
~
a:
~
[
ex:
~
IEFAB490
CHEKISAM
IEFAB490
ISAMSPAC
Data sets with and without automatic data set protection
are concaterated.
o
a5·
If no error is found, Common Allocation Cleanup interfaces
with DADSM for space for new ISAM data sets.
"0
(D
::2
~
w
00
-
DUAL TIOT
t-.J
New and old ISAM data sets are concatenated.
If any of these errors is detected, this allocation is failed the cleanup processing described in Situation Cis
performed.
o
-.
IEFAB490
This step is performed for multi-unit tape data sets
that have been allocated to both single-density and
dual-density devices. Common Allocation Cleanup switches
device entries in the TIOT, if necessary, to ensure that the
first device entry in the TIOT entry for this data set is a
single-1
Prepare for VM & V proc~ssing.
-
..
IEFAB493
Parameter
1st VM&V
Request
Ust
Block
7
~'
.
t'""
,.
g:
~
~
i:
:3CD
w
~
N
<=>
W
00
$
.....
>-
Last VM&V
Request
Block
Updated if
duplicate
~
* VM&V request block exists if volume(s)
must be mounted for this request.
JEFAB493
Parameter
:
"2
v'
1st VM&V
Request Block
r 1~~uv~&v
Mount all volumes and verify
•
v?lumes mounted for nonspecific ----'!iiMII--------'.ml
dIrect access volume requests.
•
'----
Request Block
3
Process nonspecific direct access
volume requests. For each request:
a)
DADSM
Parameter
List
VM&V request
block being
Volunit
'T
~
Table
+-1
SlOT
I
.---r-
IEFAB493
Parameter
List
I
ti
VM & V
Request Block
I
L.-----
EJ
Volume mounts
verified for
nonspecific
direct access
requests.
Enqueue on volume.
•
I
ssed
If mount unsuccessful, go to
step 7.
Mount
Messages
Issued
If volume cannot be used,
go to step 3c.
b) Interface with DADSM for space
(except for ISAM data sets),
• If recoverable DADSM error
occurs, go to step 3c.
• If unrecoverable DADSM
error occurs, go to step 6.
e) If volume can't be used or
recoverabl,~ DADSM error
occurred:
• Delete any data sets allocated _"""""_ _ _ _ _..."
to this volume.
ii0JI
• Dequeue from volume, if
necessary.
• Unload this volume and
•
r.J
mount and verify new volume.
- If mount unsuccessful,
go to step 6.
• Process new volume - go to
step 3a.
o
E§
U
EJ
Space obtai ned
(except for ISAM)
Space relea",d
Unacceptable volume unloaded;
new volume mounted and
verified.
..
~
'~---- ~
""='----'"
Diagram 14-15. IEFAB492 - AllocationNolume Mount and Verify (VM&V) Interface (part 2 of 4)
Extended Description
Module
Label
ENTRY
The AliocationlVolume Mount & Verify
(VM&V) Interface (IEFAB492) is called by
Common Allocation Cleanup (IEFAB490) to process
requests that require volume mounting. I EFAB492 prepares for VM&V processing, calls VM&V Control to mount
and verify volumes, and interfaces with DADSM for space
for new data sets on di rect access devices.
1
til
To prepare for VM&V processing, the Allocation/
VM&V Interface:
Extended Description
Module
Segment
b) If the volume can be used and the data set is not an
ISAM data set, the Allocation/VM&V Interface interfaces
with DADSM for space. (Space for new ISAM data sets
is obtained by Common Allocation Cleanup - see the
IEFAB492
DADSMINT
IEFAB492
DADSERR3
M.O. diagram Common Allocation Cleanup
(lEFAB490). One of the following conditions results:
• The space is successfully obtained; the next nonspecific direct access request is processed. If all
requests are processed, go to step 4.
IEFAB492
• Searches the SlOT chain for VM&V request blocks,
chains them together, and places a pointer to the first
request block in a parameter list.
IEFAB492
VMVCHAIN
• If more than one request block needs the same volume,
marks as duplicates all but the first request block for
that volume.
IEFAB492
VMVDUPCK
2
VM&V Control is called to issue all mount messages
and to verify volumes mounted for nonspecific direct
access volume requests. For details on VM&V Control, see
the M.O. diagram VM&V Control (lEFAB493).
IEFAB493
If the return code from VM&V Control indicates that the
operator cancelled the job (if the allocation is batch),
cancelled this request (it the allocation is dynamic), or the
mount failed for a Mass Storage System (MSS) volume,
control is passed to step 7. This allocation will be failed.
IEFAB492
3
The AliocationlVM&V Interface completes the processing of all nonspecific direct access volume requests.
For each request:
IEFAB492
IEFAB492
a) IEFAB4FO (Conditional ENQ/DEQ Routine) enqueues
on the volume just mounted. The enqueue results in
one of the following situations:
IEFAB4FO
• A recoverable DADSM error occurred (for example,
the volume does not contain sufficient space to
satisfy the request). Processing continues with
step 3c .
• An unrecoverable DADSM error occurred (for
example, the SPACE parameter was not coded). Processing continues with step 6.
c) This step receives control if the volume cannot be used
because of an enqueue error or a recoverable DADSM
error. The following processing is performed in the
event of a recoverable DADSM error:
NSPDACTL
NSPDAVOL
IEFAB492
• If any other requests were allocated to this volume,
IEFAB4AO (Common Unallocation Control)
releases the space obtained for those requests. (This
situation occurs when more than one nonspecific
request needs the same volume and one or more of
the duplicate requests has already been successfully
allocated to this volume.)
IEFAB4AO
• IEFAB4FO dequeues from the volume.
IEFAB4FO
For both enqueue and recoverable DADSM errors, the
Allocation/VM&V Interface rebuilds the VM&V request
block to indicate the current volume must be unloaded
andanew volume mounted and verified. IEFAB493
receives control to perform the unload, mount, and
verify. Step 6 receives control if the operator cancels
this job (for a batch allocation) or the request (for a
dynamic allocation), or if the mount Or verify fails for
an MSS volume. OtherWise, the newly mounted
volume is processed - go to step 3a.
IEFAB492
(!l
ao·
=
~
~:::
':(!l
[
....o
o
'e
~
g.
=
Cof
w
00
-..J
• The enqueue is unsuccessful because the volume is
already owned by this job. The volume can be used if
the enqueue is share and no unallocated specific volume
requests need this volume .
• The enqueue is unsuccessful because another user owns
this volume and this allocation cannot share the volume;
the volume cannot be used.
• The enqueue is successful; the volume can be used.
If the volume cannot be used, processing continues with
step 3c.
IEFAB493
VMVRQBLD
Cf
~
Diagram 14-1 S. IEF AB492 - AUocationNolume Mount and Verify (VM&V) Interface (Part 3 of 4)
00
&1
" Updated
I
I
I
J
b) Verify WTOR tape and specific
direct access volume requests.
r
c) Interface with DADSM if space
is required on direct access
volumes (except for ISAM
data sets).
I
m'
•
~
Volume mounts
~Verified.
R
DADSM
Parameter
~r.,JFCB
f%
:
: >6
~
If an error occurr~d in step 3, delete
mount messages, If necessary, and
release mount control blocks.
r M-;';;;- -
I
Messages
Deleted
I
L
Local
I
- m
i
w
Block
11
~
W
1st VM&V
iReqUest
'" Last VM&V
Request Block
1st VM & V
~
~
~
Processed request blocks and device
groups releaSed.
:
: >7
Release remaining VM & V request
blocks.
"'I
~
,::
*.11
Return to Common Allocation
Cleanup (lEFAB490)
OW
-----
Space obtained.
- , Mount control
I blocks for this
allocation released.
,..--
..J
Remaining VM&V request blocks
released.
"-_7
'----- ~-J'
~
Diagram 14-15. IEFAB492 - Allocation/Volume Mount and Verify (VM&V) Interface (part 4 of4)
Extended Description
Module
Label
Extended Description
4
I EFAB492
NSPDACTL
6
After all nonspecific direct access volume requests
are successfully processed, the Allocation/VM&V
Interface releases the request blocks associated with them.
The Allocation Queue Manager (I EFAB4FA) then releases
all device groups that are still serialized for this allocation.
5
The AllocationlVM&V Interface next processes all
tape and specific direct access volume requests:
IEFAB4FA
IEFAB492
a) The AllocationlVM&V Interface updates the chain of
VM&V request blocks so that it contains only specific
direct access requests and WTOR tape requests. (If the
mount message for a tape was issued in the form of a
WTO, it is unnecessary to verify the volume - the
volume verification is done when the data set is opened.
No further processing is required for these requests and
therefore they are released from the chain of VM&V
requests.)
IEFAB492
b) VM&V Control verifies all remaining requests _. specific
direct access volume requests and WTOR tape volume
IEFAB493
UPDCHAIN
c) The AllocationlVM&V Interface interfaces with DADSM
for space if the data set is new and is not ISAM. (Space
for new ISAM data sets is obtained by Common Allocation Cleanup - see the M.a. diagram Common
Allocation Cleanup (lEFAB490).) If a DADSM
error occurs, this allocation will be failed.
CI}
a5·
=
N
::
~
Q.
o
....,
o
'"C:I
~
5·
=
(,H
~
00
\0
Segment
This step is performed only if an error occurred in
step 3. In step 2, IEFAB493 issued all mount
messages and verified volumes mounted for nonspecific
volume requests; to verify volumes, IEFAB493 created
mount control blocks. (For details on both the mount
control blocks and when they are created, see the
M.a. diagram Volume Mount & Verify Control
(IEFAB493).) If an error occurs in step 3, the
mount control blocks must be released.
IEFAB49A (VM&V DOMR and Cleanup Routine)
receives control to delete mount messages for direct
access and WTOR tape volume requests; when all
messages have been deleted, IEFAB498 (MVCA Chain
Processor) releases the mount control blocks for this
allocation.
7
The AliocationlVM&V Interface issues a
FREEMAIN macro instruction to release remaining
VM&V request blocks.
requests. For details, see the M.a. diagram Volume
Mount & Verify Control (I EFAB493l.
Module
Error Processing
IEFAB492
DADSMINT
An error in any routine causes control to be returned to
the calling routine.
IEFAB492
DADSERR2
An ESTAE exit routine established by IEFAB493
deletes mount control blocks for this allocation if an
abnormal termination occurs in step 3.
IEFAB49A
<
c;n
IEFAB498
N
o
~
00
o
+:-
IEFAB492
w
~
Q
~
"<
f'-)
N
f'-)
'<
~
§
Diagram 14-16. IEFAB493 -Volume Mount and Verify (VM&V) Control (Part 10f6)
-
ENTRY from caller(see extended description)
Input
B493
1st VM&V
I ~p:JeqUestrock
i
,ast
(;'
i
~
i
(D
w
~
N
b
w
00
~
VM&VCount
Table
D
VMrV Request Block
Process
Volume Mount and Verify
(VM& V) Control: Unload,
mount and verify volumes.
1
Build VM & V count table to
determine types of requests
to be processed,
2
If there are unload or rewind
request(s) to be processed,
unload or rewind volume(s).
Parameter
List
Output
Local
rO
inte
,]
Unload
Message(s)
Issued
.1
r
VM&V
able
Count
VM&V Count
Table - Updated
D
'~7
~
Diagram 14-16. IEFAB493 - Volume Mount and Verify (VM&V) Control (Part 20f6)
Extended Description
Module
Label
2
ENTRY
Volume Mount & Verify (VM&V) Control
has three functions: to unload or rewind a
volume; to mount a volume; and to verify that a volume
mounted by the Mount Control Routine is an acceptable
volume (verify label or verify device end!' Not all of these
functions are necessarily performed each time VM&V Control is called - the functions performed depend on the
caller:
If the count table indicates that unload or rewind
requests exist, IEFAB494 (Volume Unload Control) receives control. IEFAB494 searches the chain of
VM&V request blocks to locate unload/rewind
requests.
• The Allocation/VM&V Interface (IEFAB492) calls
VM&V Control to do one qf the following: mount all
volumes and verify those volumes mounted for nonspecific volume requests; unload an unacceptable volume
and mount and verify a new volume; verify volumes
mounted for specific direct access volume requests and
WTOR tape volume requests.
The parameter list passed to VM&V Control includes a
pointer to the chain of VM&V request blocks - the VM&V
request blocks indicate what functions must be performed.
tI)
(1)
(')
g.
• Unload or rewind requests.
::I
t-.J
• Mount requests.
3:
(1)
• Verify requests (to verify a direct access label or to
verify that a device has become ready).
[
....
o
o
"'0
...
g.
(1)
~
::I
~
~
-..0
The VM&V count table also includes a field called the
DOM count. The DOM count represents both the number
of mount messages to be deleted and the number of
volume mounts to be verified - direct access volume
mounts and WTOR tape volume mounts are verified;
after the mount is verified, the message is deleted. (For
WTO tape mounts, the data management OPEN routine
verifies the volume and deletes the mount message.)
Segment
IEFAB494
• For volumes not used for the Mass Storage System
(MSS), IEFAB499 (VM&V WTO/R Format Routine)
builds the unload message; IEFAB494 issues the
message. (The message text exists in the message
module IEFAB4M4.)
I EFAB499
IEFAB494
• If a tape volume is being unloaded, IEFAB494 initializes
and issues the channel commands necessary to have the
tape rewound and unloaded.
IEFAB494
ISUEEXCP
IEFAB494
VIRTDEMT
• IEFAB494 clears all fields in the UCB that pertain to
this volume.
IEFAB494
UCBCLEAN
• IEFAB494 decreases the count of unload/rewind
requests in the VM&V count table. If this count reaches
0, IEFAB494 returns to VM&V Control.
IEFAB494
If an MSS volume is being unloaded, IEFAB494 interfaces
with the 3850 Mass Storage System to demount the
volume.
• The Verify Control Routine (IEFAB496) calls VM&V
Control to unload an unacceptable volume and to mount
an acceptable volume.
To determine what functions must be performed
(unload/rewind, mount, or verify), VM&V Control
searches through the chain of VM&V request blocks and
builds a VM&V count table. The VM&V count table contains fields that indicate the number of:
Module
For each unload request, the following steps are
performed:
• The Unload Interface (IEFAB49C) calls VM&V Control
to unload or rewind a volume.
1
Extended Description
IEFAB493
VMVSETUP
For e~ch rewind request, IEFAB494:
• Initializes and issues the channel commands necessary
to have the tape rewound.
IEFAB494
• Clears the file sequence number and file sequence count
in the UCB.
IEFAB494
• Decreases the count of unload/rewind requests in the
VM&V count table. If this count reaches 0, IEFAB494
returns to VM&V Control.
IEFAB494
ISUEEXCP
~
Diagram 14-16. IEFAB493 - Volume Mount and Verify (VM8tV) Control (part 30f6)
\Q
N
~
~
N
..
;
fIj
'<
i;.
t""
;:
!.
i
VM&VCount
Table
D
Parameter
List
~
'"
3
last VM&V
Request
Block
If there are mount requestCs)
to be processed, mount
volume(s):
--I
CD
w
~N
IEFAB495
Parameter
List
a) If necessary,
build mount control
blocks.
i
I
w
~
VM&V'
Count
Table
D
b) Build and issue mount
messages for non-MSS
mount requests.
VM&V Count
TableUpdated
c) Handle MSS mount
requests.
Mount
Messages
Issued
~
'--'*""
Diagram 14.:.16. IEFAB493 - Volume Mount and Verify(VM8tV) Control
Extended Description
Module
3
IEFAB495
If the.counuable indicates that mount requests must
be processed, lEFAB495 (Mount Control Routine)
receives :control. The following steps are performed:
a) Ihhe' DOM count in the VM&V count table does not
" equal 0 (that is, mount requests will have to be verified),
mount control blocks are built if none exist. (Mount
control blocks are necessary to keep track of which direct
access and WTOR tape mount requests are not yet completed and what messages must be deleted.)
The mount control blocks include:
• An MVCA and MVCA extension (MVCAX), which
include general information such as pointers to ECBs
and pointers to other MVCAs on the MVCA chain.
These blocks are created the first time IEFAB495 is
called by this allocation, if they are necessary (the
DOM count does not equal 0).
• Mount entries. One mount entry exists for each
call to tEFAB495; each mount entry points to a list
of device entries, 'which identify the units on which
volumes must be mounted and verified, and a list of
domid entries, which identify the messages that must
be deleted once the volumes are mounted and
verified.
For details on the mount control blocks, see OS/VS2
Data Areas, SYB8-0606.
fn
ite'
::I
~
a:
[
2.
o
1
::I
eN
W
..c
eN
Label
(part 4 of 6)
Extended' Description
Module
IE-FAB498 (MVCA Chain Processor) Searches the
existing MVCA chain' to determine if an MVCA exists
for this alloCation. (An MVCA will not exist if this is
the first time IEFAB495 is called by this allocation.)
If an MVCA does not exist, IEFAB495 obtains space
for the mount control blocks and IEFAB498 adds
them to the chain.
IEFAB498
b) For each non-MSS mount request, IEFAB499 builds
a mount message; I EFAB495 then issues the message.
If the mount must be verified and the message deleted
(that is, if .it isa direct access or WTOR tape mount
message), IEFAB495 places the id of the message
(DOMI D) into the list of domid entries (which is pointed
to by the mount entry .,.. see step Ja). As each mount
message is issued, IEFAB495 decreases the mount
request count in the VM&V count table - when the
reaches 0, IEFAB495 returns to VM&V Control.
IEFAB499
IEFAB495
c) For each MSS request I EFAB495 interfaces with the
3850 Mass Storage System to mount the volume.
IEFAB495
IEFAB495
IEFAB498
Segment
B495MSPC
B4951WTO
IEFAB495
VIRTMONT
~
:
Diagram 14-16. IEFAB493 - Volume Mount and Verify (VMAV) Control
~
Process
N
til
i
oin'
t::
J
~
(partS of 6)
VM&VCount
Table
D
4
r
If there are verify requesds)
to be processed, verify that
correct volume(s) is
mounted:
VM&VCount
w
'
Allocation
Start Time
Initiator/Allocation Interface
--. JCT
1st EPA
:,t""'
ReturnLi~
I
~
o<
c
a
<1>
w
JCT
D
CVT
IEEBASEA
C3-1
I
:
~"
=:>
1
Perform job/step preparation.
TCT
~
N
•
53'
..
:t:=:=J
00
~
'-'
~
Initiator
,Last EPA ~Last
Interface
Parameter List
~TIOT Lin
T. lOT
I
JFCB
<::>
w
* virtual address
'~1nSI£ .YB
e=
J
I~_-,rl..._--,
* SWA virtual address
LCT
SCT
~
JCT
r-:J.
L-..J
Data Set
Enqueue Table
-I'-____
-
LCT
~
DSAB ODB
11
c=J
=')
I",
NY
2
Determine if step should be
executed:
•
If step to be bypassed,
release data sets; go to
step 5.
1
l'
~I.·
-
u
7
I
L*
5
SlOT .-
I
JSCB
JFCBX
JFCBX
Data Sets
Dequeued
FCBX
I
"---~,
~
'--j
Diagram 14-17. IEFBB401 - Initiator/Allocation Interface (part 2 of 6)
Extended Description
Module
Segment
ENTRY
The Initiator/Allocation Interface initializes and
controls batch allocations; that is, jobs and
logon requests.
1
~
~
CS·
=
~
~
(1)
;.
&.
o-.
o
"0
S
g.
=
1M
W
\C
......
To prepare the job/step for allocation, the Initiator/
Allocation Interface:
IEFBB401
• Issues one of three job status messages, if necessary: job
not run, job started, or user logged on. The message issued
depends on several factors. If the job failed prior to allocation of the first step (determined by checking the step
number, which is included in the LCT, and the failure
indicator in the JCTJST AT field of the JCT), message
IEF4521 is issued: job not run. If thejob didn't fail prior
to allocation of the first step and if th is is the first step,
IEFBB401 determines if MONITOR JOBNAMES or SESSIONS is active. (tEEBASEA includes three fieldsBASFL, BAMONITR, and MSBTN - that indicate
whether MONITOR JOBNAMES or SESSIONS is active.)
I f so, it issues either message IE F 1251, job started, or
message IEF4031, user logged on.
IEFBB401
IEFBB401
• Issues the time macro instruction and places allocation
start time in the TCT (timing control table), if it exists.
IEFBB401
• Locates SlOTs, JFCBs, and JFCBXs in SWA, via the SWA
Manager, and chains them together by means of the virtual
addresses the SWA Manager returns. In SWA, each of these
control blocks includes a prefix to which the SWA virtual
address (SVA) points. The Initiator/Allocation Interface
creates a SWA Manager external parameter area (EPA) for
each control block; the EPA includes both the SVA and
the virtual address of the actual beginning of the block,
not including the prefix.
IEFAB4FE
Extended Description
Module
Segment
• Builds the TIOT Manager request block; the TlOT size (in
multiples of 4K) is in the LCTTSIZ field of the LCT; if
this is 0, the Initiator/Allocation Interface sets the TlOT
size to 32K.
IEFBB401
STEPINIT
• Calls the TIOT Manager to create and initialize the TIOT
and DSAB QDB (queue descriptor block).
IEFAB4FC
2
To determine if a step should be executed, the Initiator/Allocation Interface processes step condition codes
as specified in the COND parameter of the EXEC statement.
Return codes from previous steps are included in the SCT.
IEFBB402
If the step is to be bypassed, Data Set Release releases data
sets enqueued by the initiator. The data set enqueue table
includes, for each data set, the step number of the last job
step that needs the data set. The SCT contains the current
step number. If the current step number matches the step
number associated with a data set in the data set enqueue
table, Data Set Release issues the DEQ macro instruction
for that data set. After the data sets are released, control is
passed to step 5.
IEFAB4A6
JSTPPREP
JOBINIT
BUILDMSG
STEPI""IT
~
Diagram 14-17. IEFBB401 - Initiator/Allocation Interface (part 3 of 6)
\Q
00
o
tIJ
~
N
Input
Process
Output
tIJ
'<
~
~
CVT
t""
~
Et
LCT
ci:,
c:r
~
~
IEEBASEA
SCT
CSCB
r
c::r--Lj -,
Step Allocation Parameters
Function Map
If step to be executed, prepare f o r ' ' ' '
step allocation processing.
First SlOT
~
~ Initiator JSCB
+Problem Pgm JSCB
I
~ JCT
Step number
~
i
• SCT
+
TCB
~
(D
I
(see extended
description for
details of function
mapJ
Reason code area
~
~ First SlOT
~
N
• Last EPA
• lOS UCB LUT
• Cancel ECB
TIOT
4 EST AE parameters
~
i
~
!
+
~
~
Function Map
41st SlOT to allocate
Step Number
Step
Allocation
Parameters
D
4
• JCT
Perform step allocation processing.
See output of
step 3 for details
a) Prepare to retrieve the information
necessary for allocation.
map.)
o
"j
JFCB Housekeeping
D
(See figure 18 for
details of function
• SCT
• Last EPA
b) Retrieve the information
necessary for allocation.
J
• Initiator JSCB
• lOS UCB LUT
'-----Fl__e~~n_Code Area
__
1st SlOT
Housekeeping
Control
(IEFAB451)
'
1SIO~s. JFCBs. and JFCBXs updated
'-.
I _ _ _ _--'. and If necessary. created
"-~
~
Diagram 14-17. IEFBB401 -Initiator/Allocation Interface (Part4of6)
Extended Description
Module
Segment
Extended Description
Module
3
IEFBB401
CALLALOC
4
IEFBB404
If the step is to be executed, the Initiator/ Allocation
Interface constructs the parameter list for step alloca·
tion processing. The function map indicates if allocation
should:
Step Allocation Control (lEFBB404) performs step
allocation processing:
a) Step Allocation Control (lEFBB404) constructs the
parameter list for JFCB Housekeeping Control. For
details on the function map, see figure 2-28.
IEFBB404
b) JFCB Housekeeping Control (lEFAB451) places the
information necessary for allocation in the SlOTs,
JFCBs, and JFCBXs, and creates additional tables if
necessary. For details, see the M.O. diagram JFCB
Housekeeping Control (I EF AB451 ).
IEFAB451
• Issue an allocation message to the operator for unit
record devices. This indicator is set on if MONITOR JOBNAMES is active.
c) Step Allocation Control (lEFBB404) constructs the
IEFBB404
The CHTRKID field of the CSCB indicates if this request is
a logon; the BASFL field in IEEBASEA indicates if MONITOR JOBNAMES is active.
d) Common Allocation Control OEFAB421) allocates
units and volumes to the data set requests. For details
on Common Allocation Control, see the M.O. diagram
Common Allocation Control OEFAB421).
IEFAB421
e) The TIOT Manager (lEFAB4FC) compresses the TIOT
and re-orders the TIOT entries and DSABs to conform
to the order of the SlOTs.
IEFAB4FC
• Wait for units. This indicator is set on if the request is not
a logon.
• Wait for volumes or data sets. This indicator is set on if
the request is not a logon.
• Consider offline devices for recovery. This indicator is
always set on by the Initiator/Allocation Interface.
parameter list for Common Allocation Control. For
details of the function map, see figure 2-27.
f) If steps 4b or 4d indicated errors (return codes of 4 or
8 were returned), Step Allocation Control searches each
SlOT for a non-zero reason code and the System Message
Interface Routine issues the appropriate error message.
tI.l
~
(')
~.
::s
~
~
~
g-
oQ.
o
....
o
"0
~
a
o·
::s
w
~
\Q
\Q
IEFBB404
IEFAB4FD
Segment
SETFUNMP
SETFUNMP
:t.
g
Diagram ! 4-17. IEF BB40 1 - Initiator/Allocation Interface (part 5 of 6)
~
~
N
f'-I
'<
=~
r-
i
n·
r-
&
8
~
r
w
'<
f'-I
N
~
f
Input
Output
Process
'
0
Step Allocation
Parameters
4d
See output of step 3
for details.
..J
Prepare to allocate units
and volumes to the data
set requests.
+ 1st SlOT to allocate
....
• JSCB
• IOSUCB LUT
See
Common Allocation
Parameters
O
Common Allocation Parameters
,
Function Map
•
See output of step 4c
for details.
-
15i1~
Reason Code Area
Common
Allocation
Control
(lEFAB421)
d) Allocate units and
volumes to data set
requests.
(See figure 17 for
details of function map.)
TCB
• T lOT Header
• Cancel ECB
Step Allocation
Parameters
w
DSAB
~
n
'----....
;:t
Step Allocation
Poramet'"
e) Reorder TlOT to
conform to order of
'requests.
.,
!~
II~asf
EPA
I
:~
.,.
-
t,jIl.
1st SlOT
~
I .1(UdSIOT , =j~o
1st EPA
@
srOTs,
JFCBs,and
JFCBXs
o
~
1)
~5
!
f
Issue DO related error
messages.
Release tables and storage
used by EP As.
I
Reason Code
I
~6
I
6
DSAB
I :
H
Issue step-related error
messages.
:t
Return to Initiator
(lEFSD162)
11
TIOT
tr:~'---I
II
f
Step Allocation
Parameters
SlOTs
VOlumes
mounted; space
obtained.
lM~edl
l
Storage released; tables
released in SWA
I
',---7
~~
Diagram 14~ 17. IEF BB40 1 - Initiator/Allocation Interface (Part 6 of 6)
Extended Description
Module
Segment
5
IEFBB401
B401CLNP
The Initiator/Allocation Interface:
• Releases control of the tables in SWA used during
allocation.
I:=FAB4F7
• Issues the FREEMAIN macro instruction to release the
storage used by each EPA.
IEFBB401
6
IEFAB4FO
The System Message Interface Routine (lEFAB4FO)
issues step·related messages for any error (non-zero)
reason code returned by means of the step allocation
parameter list.
RETURN
The Initiator/Allocation Interface returns to
the Initiator. The Initiator Interface Parameter List is updated with a pointer to the TIOT list, which
points to the TIOT created by the Initiator/Allocation
Interface. The LCTERROR field of the LCT indicates if~
• The job failed.
• Any data sets were allocated for the job.
• Any data sets were allocated for the step.
• The step was not run due to condition codes.
Error Processing
An error in any routine causes control to
the calling routine.
b~
returned to
When IEFBB401 receives control, it creates an ESTAE
environment so that its exit routine receives control if
the program abnormally terminates.
c;n
CD
a
o·
=
!t,
:::
CD~
i"
Q.
o
~
o
"0
io·
=
eN
~
g
B401CLNP
<
c;n
N
o
W
00
~
~
o
Diagram 14-18. IEFBB410 - Initiator/Unallocation Interface (part 1 of 8)
...
N
ENTRY from
Initiator (lEFSD164)
o
CIl
~
N
CIl
'<
~
R1
Initiator Interface
Parameter List
~
~
~.
+LCT
+JCT
j
+TIOT List"
~
c
ac
!!.~~ !-;:r~"'''S
~N.
~
-i
X JCTWARMS
I:
::> 1 Prepare for unallocation.
:
First SlOT
=:> It ~I';;;
LCT
Q
(,H
Output
Length
of TIOT
JCT
(,H
00
~~
Input
I
.~
1 JSCB
.....
First +
Last DSAB
JSCB
~
~
;SABQDB-'1------~
a) Issue end -of . step status
message.
ro---u
JFCB
End -of ·Step
.....
~
D
1__~1
JCT
LCT
L..--
: >2
Determine if step is to be
restarted.
If on, step will automatically
restart from beginning
~
~
Ifon, step will automatically
restart from checkpoint.
If on, job will continue with the
next step.
......
~-~,
~_:f
Diagram 14-18. IEFBB410 - Initiator/Unallocation Interface (part 2 of 8)
Extended Description
Module
ENTRY
IEFBB410
The Initiator/Unallocation Interface initializes
and controls batch unallocations, that is, job
step and logoff requests. Step unallocation is called if at
least one of the step's data sets was allocated. During step
unallocation, data set dispositions are processed, units are
unallocated, and data sets and volumes are released. If the
step being processed is the last step or if the job has been
failed because of a job condition code, job unallocation is
invoked. During job unallocation, disposition processing
is done for all passed, unreceived data sets, and the job's
private volumes are unloaded. Also, at end of job, this
routine issues a generic dequeue to release all volumes and
data sets associated with this job.
Segment
Extended Description
Module
Segment
1
The function of this step is to locate in the scheduler
work area (SWA) all SlOTs, JFCBs, and JFCBXs. The
job control table (JCT) contains an indicator (JCTWARMS)
that indicates if the job is in a warm start environment. If
the environment is a warm start, the SlOTs are read via the
first SlOT pointer in the step control table (SCT) and the
chain pointers in the SlOT themselves; otherwise, they are
read via the chain of data set association blocks (DSABs).
An EST AE environment is created so that the exit
routine receives control if the program abnormally
terminates.
IEFBB410
B410lNIT
a) One of the following messages is sent to the programmer:
IEFBB410
ISSUMSGS
• Determine whether steps will automatically restart.
• Call step unallocation.
• Call SMF to perform end-of-step processing.
• Free the TIOT.
• Process job condition codes.
• Call job unallocation if the present step is the last step to
be executed, or if the job is being failed.
C'-l
(D
II
o·:=
~
a:
(D
g
Q.
o
.....
o
"0
~
a
o·
:=
~
J:.
o
~
• If the job is ending or failing, call SMF to perform
end-of-job processing, and issue job status messag~.
• Use the SWA manager to release the control of tables
used by unallocation.
00
<:>
• Step was not executed.
• Use the SWA manager read/locate function to obtain the
addresses of SlOTs, JFCBs, and JFCB extensions (JFCBX)
and chain them together.
• Issue step status messages.
~
• Step was executed.
The major functions of this routine are to:
~
• Step was abnormally terminated. (This message is also
issued to the operator.)
2
In this step the "DUMMY" TCB is checked to see if
the job has abnormally terminated (except for cancel
ABEND). If it has, IEFRPREP is invoked, IEFRPREP will
determine if a restart is possible and is authorized by the
operator. It then sets the proper indicators in the JCT.
Then the restart information from the SCT and JCT is used
to decide whether the job is eligible for an automatic
step or checkpoint restart, or a continue restart.
Note: Because the original TCB was removed by a
DETACH command from the initiator, a "DUMMY" TCB
created by the initiator contains the ABEND indicator
and completion code.
~
t-J
(:,
IEFRPREP
i
&1
~
"-J
C'Il
'<
,Ii/)
~,
a
ic;.
t""
51
~
Diagram '14-18. IEFB8410....,- Initiator/Unallocation Interface (part 3 of 8)
-
II
W
~
Parameters for Step
"D.ummy" TCB
J---=l_______. . . .
LCTTCBAB
k
..
JCT
·1
SCTSNUMB
.
Function Map Byte 1
~ x
:
::>
3
Set up for step unallocation.
:
: :>
CVTMSER
IEEBASEA
rt-x
(5eeoutput of step 3
for details.)
"'"
Free DSAB
~pdate JFCB for MOD data set
MOnitor status
Ifon, unaHocate units
L.........'ff on, issue DISP MSGS
......., If on, issue allocat~on MSGS
L-If on, process disposition
I xxxxxxxx I
Mo
Count
os
• Job Step Proc Name
Step Number
VUT SVA orO
Reason code
Function Map Byte 2
------'
Step
Unallocation
.
xxxxxxx-
,..;:C;...;VT~_ _ _,
SCT
I
N
--1
...:::t'
Unallocat~n
• F unction Map
• PIP JSCB
• FirstSIOT
DSENQ Tbl SVA
---i:..__x__
If,on, MSGLEVEL=1
w
(:,
...
Output
~
LCT
Restart Switches
,~
C'Il'
"-J
y
Warm Start Indicator ---;,'
,.._x__--1
<
~
'<
Process
Input
II IIIIII
Check initial status
Purge D.A. data sets
Always process PASS as PASS
L - - - UCB addresses in SlOT invalid
L-'If on, keep old, delete new
L--Ifon, use conditional DISP
L - . If on, keep a II data sets
'--If on, process normal DISP
'
,
n,
.
Build ETIOT for 'scratch'
Treat public tape volume as private
Bypass VUT processing
4
Invoke common unallocation.
(For details, see the M.O.
diagram Common Unallocation
Control (I E FAB4AO).)
-0
'"
If
Data sets disposed of, volumes released, data sets
released, units unallocated
Return Codes
o I Step Unallocation Successful
4
I Step Unallocation Not Successful
J
I
I
~
~
Diagram 14-18. IEFBB410 -' Initiator/Unallocation Interface (part 4 of 8)
Extended Description
Module
Segment
3
The function of this routine is to use the information in the LCT, JCT, SCT,and CVT; and to construct
the parameter list for step unallocation, indicating the
unallocation processing to be done.
IEFBB410
CALLUNAL
4
IEFBB414
IEFBB414
BLDCMRBS
SETRBDSP
The common unallocation function map and common
unallocation request blocks are built requesting
common unallocation to release volumes and data sets,
unallocate units, and process data set dispositions. (For
details, see the M.O. diagram: Common Unallocation
(lEFAB4AO),Disposition Processing (lEFAB4A2), and
Unit Unallocation Process (lEFAB4A4).
til
a
er
::s
~
a::
a
8:o
....
o
"tS
i
~r
::s
w
Ja.
~
~
~
Diagram 14-18 ° IEFBB410 - Initiator/UnaUocation Interface (part S of 8)
i
~~
,
~
LCT
r4.
~
LCTTCBAD
i
_
(i)0
Co
,
I
LCTJSCB
---'\
~
[
~
'
I"
Return Codes
.. 6
..
"Dummy"TCB
1
TCBFA
C:CT
Process job statement condition
codes.
6
SCTSEXEC
JCTTCODE
r
I
I
I 4 I Fail the job
... SCT
,<
JCTJDEC
SMF Accounting Routine invoked.
I 0 I Job can continue
I
-D
~
:....
..
\J
If on. step abended
LCTTCBAD ...
is
End-of-step processing.
DSAB ODB
JSCB
V:
LCT
~
....
.,> 5
I
I
[
~
-
... "Dummy" TCB
....
LCT
..
LCTJFAIL set on
if job to be failed.
~
~'----'
'IIJIIII!!III"
Diagram 14-18. IEFBB410 - Initiator/Unallocation Interface (part 6 of 8)
Extended Description
Module
Segment
5
In this step the TIOT manager (lEFAB4FC) is
invoked to free the TlOT and the OSAB OOB (queue
descriptorbloek). The SMF accounting routine is invoked
to do end·of-step processing_
IEFBB410
ENOOSTEP
6
IEFBB412
Job statement condition codes from the JCT are
checked against the return code of the current step
to determine whether the job is to continue.
C'-I
til
n
g.
=
N
ac
til
[
e
~
o
~
5
g.
=
w
~
-.J
,~
~
~
Diagram 14-18. IEFBB410 -lnitiator/Unallocation Interface
(part 7 of 8)
&1
"<
fIl
Process
Input
~
fIl
I
ro-
u
Output
Parameter List for
JobUnaliocation
LCTJFAI. L
IT U,
9
x----
I
Reason Code
~
'<
fIl
~
:;.:I
Job Status Msg
f
~
~
/':
JCT~::
*f
~
~~x------LCT
. .'> 8
:~"
iis
Performend-of-J·obprocess·lng .
JCTTSOID
ia
.
U2
'd ")
20211
Fxx
SM F accounting routine
invoked
Return Code to Initiator
o
LLCTJFAIL - indicates job
has been failed
LCT
SCT
SCTANSCT
I
D
Ii'
pull
P'
n
:litlast0,step
indicates
~
9
...
Perform clean up.
p
·~1
8
v
c;>
I Continue normal
initiation
4 I Step will automatically
restart
l'
I
Job has ended or has
been failed
SCTSNAME
Return to Initiator
(\EFSD164)
It
I x------jl SCTSCLPC
Reason Code
o
JCT
I
JCTJNAME
I
CJ
Unallocation error
message,s
"'-__7'
~
Diagram 14-18. IEFBB410 - Initiator/Unallocation Interface
(part 8 of 8)
Extended Description
Module
7
IEFBB416
Job Unallocation performs the following functions:
• Process final dispositions of passed, unreceived data
sets.
Segment
IEFAB4AO
• Unload the job's private volumes.
• Release any volumes retained for the job.
This step is performed only if the job is ending. For
details, see the M.O. diagram Common Unallocation
(lEFAB4AO) and Job Unallocation Processing
(lEFBB416).
Note: Common unallocation is called to do any disposition
processing necessary.
8
The SMF/User Accounting (lEFBB410) routine
is invoked to issue an end-of-job record. One of
the following messages is issued to the operator:
"Iogged off," "job ended," "job failed - JCL error."
This step is performed only if the job is terminating.
IEFBB410
IEFBB410
ENDOFJOB
ENDJMSG
9
IEFBB410
B410CLNP
The SWA manager (lEFBB410)is used to write
in locate mode all records read in for unallocation processing. If any error conditions occur during
the unallocation process that required messages, the
messages are now issued. The reason code(s) set
during unallocation processing determines what
messages to issue. The EST AE environment is
cancelled. Any unallocation messages still in
write-to-programmer buffers are written.
rn
ao·
=
!':J
a::
a
6'
Q.
So
o
"0
~
o·=-
=
~
~
"""--'"
~
.aa.
Q
~
<
Diagram 14-19. IEFBB416 - Job Unallocation (Part t of 2)
ENTRY from IEFBB410Initiator/Unaliocation Interface
L.proceu
Input
{IJ
N
{IJ
Output
Job Unallocation ParametE'rs
'ia
Job Unallocation
Function
Map
i
rxxxx - - --=J
4 JSCB
~
C'-a.
:)
:'I'
T
use conditional
dispositions
Issue disp msgs
+JCT
It IOSVUT
r-
f
9,
!
EJ
Do disp processing
~
Monitor status is
active
f
fD
W
'<
Data Sets Scratched
Catalog Updated
{IJ
N
Next
POI
i
D
I
w
-
SlOT
:...
SlOT
Y1
FC
SlOT
Volume Unload
Table (VUT)
JCT
I
VUTSVA
rI
VOUER
:
:~
"
JFCB
lrf- I
UCB
+UCB
:l
I FFFF_J
JFCB
Dismount
Message(s)
Issued to
Operator
-
VUT
Y"';'I~-
~ 2
-ASIO
1
I.
- Via Extract
Macro
:#:
>3
Unload the job's private
volumes and public MSS
volumes, rewind it's
public tape volumes,
update the UCB's.
Release volumes retained
for this job.
A
.".
I
Public Tape VOls
Rewound. Private Tape
Vols Unloaded.
0[[5
to.
.".
JCT
JCTJNAME
Process disposition of this =:::===::::;>ti~
job's passed, unreceived
data sets via common
unallocation.
~
IVOLSER
r
T.
>1
r::J
T
105 UCB LUT
Disposition
Messages
Issued
JCT
Release
Message
Issued to
Operator
Return to Initiator/Unaliocation
li,m>Y:\?f£f"lill&;A;;',Z&4it:0/45hikMw&mti:t""!llfaYiBTikf.S'cl
Interface (I EFBB41 0)
______ -.7
'------~
"t~5'
Diagram 14-19. IEFBB416 - Job Unallocation (Part 2 of 2)
Extended Description
Module
ENTRY
IEFBB416
The functions of job unallocation are to process
final dispositions of unreceived passed data sets
and to perform volume clean-up:
Segment
• Unload the job's private volumes and rewind scratch
tapes.
• Issue messages for
1
r~leased
volumes.
All passed data set information (POI) blocks are
located via the SWA manager locate function. There
is one POI entry per data set passed within the job. For
each passed, unre<;eived data set, the associated SlOT and
JFCB are located via the SWA manager read/locate function. The POI entry, SlOT, and JFCB are used to construct
a common unallocation request block for each data set.
When all the request blocks are built and chained, they are
passed as input to the common unallocation routine
(I EFAB4AO). Common unallocation performs all disposition processing and issues any disposition messages for the
data set(s) associated with this job. For details, see the
M.a. diagram "IEFAB4AO - Common Unallocation."
til
tN
00
0
,J:o.
Each of these routines is described in a separate M.O.
diagram - see Figure 11: Allocation/Unallocation Functions and Related Method-of-Operation Diagrams.
To serialize dynamic allocation with data management
and other dynamic allocations under the same job step,
SVC 99 control enqueues on the caller's TIOT, if not already enqueued (shown by bit 5 in FLAGSON). The major
name is SYSZTIOT, and the minor name is the two-byte
ASID field of the caller concatenated to the address of the
DSAB queue descriptor block.
3
IEFDB401
If the dynamic request is allowed, SVC 99 Control sets
up the input to the requested function and calls one of
the following routines:
2
CI.I
Segment
5
The format of the request block pointer, and the request
block, is verified. If privileged functions are requested, the
caller's authorization is checked. Any error found in these
checks will cause step 7 to be done next.
g
Module
4
ENTRY
The caller's parameter list (request block, text unit pointer
list, and text units) is copied into a scheduler-key, fetchprotected storage area to ensure the integrity of the parameter list and to allow reference by SVC 99, which runs in the
scheduler key.
Extended Description
6
After the requested function has completed, any updated SWA control blocks are written to the SWA.
SVC 99 Control dequeues Qff the caller's TIOT (if it
~ enqueued) and restores the parameter list with any returned
. information. The EST AE environment is canceled.
IEFDB400
IEFAB4F7
IEFAB4FE
READSWA
7
After the return code is set in register 15 and the reason code (two-byte error code and two-byte information code) is set in register 0, SVC 99 Control returns to the
SVC interrupt handler.
IEFAB4F7
RESTORE
t
Diagram 14-21. IEFDB410 - Dynamic Allocation Control (part 1 of 2)
~
..
ENTRY from SVC 99 Control (lEFDB400)
(see extended description)
~
"<
CI.l
N
CI.l
I
i-t:
~
~
~
+~ Text Ptrs.
Reason Code
I
/
I,
0
I~ ~
+Text Unit
I
l Key
I
Info. Code
--... Text Unit
~~
1
Error Code
No-l Length
Paramo
l_:J
p
o
Dynamic Allocation
Control: Dynamically
allocate a data set.
Control Blocks Updated for Freed DDNAME
JCT
DSAB
r---1'
[""""l'
;'" 1
Check .for valid text
units.
S
00
~
I·
DSAB
.·ASCB
~
+TCB
4 JCT
TSO Only
L ___
'i
PSCB
.J\.
2
If possible, convert
an existing allocation.
l.-I
4
DSAB
+onLastwrite
~PA
chain
ESTAE exit
parms.
Return requested
information.
"SIOT
• JFCB
JFCBX
+
Return to
SVC99
Control
(lEFDB400)
VI
JFCB
DSNAME
I
DSAB
I
I
JFCB
SlOT
1+TIOT Entry 1 rl4
14 SlOT
1+
I
I.
Last EPA
I
I
"I
JFCB
JFCBX
JFCBX
I
1
I
I
Updated for
SWA control blocks
to be written
I
Tl
I
I
• TIOT Entry -
• SlOT
rl
Control Blocks Updated
TCTIOT
UCB
TIOT Entry
VlDDNAME
JFCB
• JFCBX
Control Blocks Created
If no conversion, do
normal allocation.
No~zero--~
Indicates
TSO User
~
TIOTEn.ry
• SlOT
It
I"'--
ASCB
JII+
JFCB
Updated for SWA
Control Blocks
to be written
Last EPA
3
Includes
flags from
caller's
parm.list
SlOT
SlOT
PSCBVMNT - - - -..,
I
On ifTSO
•
user can have
volume
-~DSAB aDB
mounting
JSCB
• SCT
Function Map
I
-Control Blocks Updated for Converted DDNAME
(D
+JSCB
JCTNARST
".
+Text Unit
w
1
l DDNChanged J
~
~N
I. TIOT Entry 1
l4 SlOT
Messages
Reason Code
c::"J I
I
,,-
.........
~
.........
'-
,/
I'-..
./
Catalog
Updated
'-
Data Set
Created
/
'-
./
~y
~
Diagram 14-21. IEFDB410
~
Dynamic AUocation Control
Extended Description
(part 2 of 2)
Module
Segment
ENTRY
Dynamic allocation control (lEFDB410) is
called by SVC 99 control to allocate a data set
that was requested by a currently processing job step.
1
The internal text is checked for format errors and for
invalid, duplicate, mutually exclusive or inclusive keys,
or for conflicting values specified for the keys. A key table
of text unit pointers is built with the addresses of the specified text units at fixed table offsets. If a keyword is not
specified, the table pointer for that key is set to zero. After
the key table is built, the text units are edited to supply
default values or to modify values as required.
IEFDB412
IEFDB410
FXSYNTX
2
If possible, dynamic allocation control will convert
an existing allocation to satisfy a request, rather
than perform a normal allocation. The existing allocation
environment is checked to see if this is possible.
IEFDB410
IEFDB411
CKCONVRT
3
IEFDB413
If an existing allocation cannot be converted, normal
allocation control is called to create and fill in the
necessary control blocks and perform the new allocation.
To retrieve additional information required for allocation,
I EFDB413 calls JFCB Housekeeping Control (see the M.O.
diagram JFCB Housekeeping Control (tEFAB451).) To
perform the allocation, IEFDB413 calls Common
Allocation Control (see the M.O. diagram Common
Allocation Control (tEFAB421).)
4
~
a
~.
:I
~
a::
~
::r
8.
....o
o
."
i
~.
:I
.~
( ,A
Following conversion, or a normal allocation, dynamic
allocation control returns to SVC 99 control. The text
units will indicate the ddname, DSNAME, DSORG, and
VOLSER parameters used to satisfy the request, if they
were requested by the caller. The error and information code fields of the reason code contain appropriate
information.
IEFDB413
HSKPINTF
IEFDB413
ALLOCINT
I EFDB41 0
CLEANUP
.~
,.Diagram ·14..22~ ·IEFDB4AO ~ Dynamic Unallocation Control
0'1
- -
-.-- --
-
. ,.:<:•. i ..•., . •
w
'\.!C<';:
n.
fIl
1
"~
'i
,+ Text Ptrs.
i
\.
2'
.
~
I
I.
0 • te~t,/
umt
'r-'
.~
'
Reason Code
'n'
J
~
1 '
..
I
Error Code
Text Unit
.,.. ....
Key
I No.
length
I
Info. Code
I param.I:~
I
DSABNUSE=O
I
DSAB Moved to
End otChain
1
.l'I'
:. ASCB
JSCB ,. ~T+ DSABOOB
~ASCB
4TCB
• JCT
4SCT
;
DSAB ODB
Nonzero 'I ndicates - - .,...
TSOUser
4 TSB.
-
•
,
IstDSAB~
...
-..
,2
~- -
• SlOT
I
t-
Includes
'. flags from
caller's
parm.list
+on
Last ~PA
write
chain
~
- - Updated for
SWA Records
DDNAME
Restored
1
"
3
4
Function Map
-I
I + TIOT Entry
,....J
DSABs
4TIOT Entry l-
.
TIOT Entry
DSAB
Remove in-use
DSABs.
~
......
~
Find DSABs to
process
•
-
Paging
Space
Released
,.--...I
Check for valid text
units.
.......
,.... VIO
Alternate
Disposition
Removed
:( +To Last Write EPA
JSCB
'4
~
!
SlOT
,;
<
~
DSAB
+te~t
UOit
(D
~
..
-y
a
t
Dynamic Unallocation
Control: Dynamically
unallocate a data set.
:
~~
~~
~
fIl
N
..
ENTRY from SVC99 Control HEFDB400)
(see extended description)
&1
~
N
(part 1 of 2)
I
Check unallocation
environment.
DSAB
Deleted
If allowed, unallocate
data set.
Marked
Unallocated
or
SlOT, JFCB
and JFCBX
deleted
...
d
Set return codes.
::
;.
:
SCT
II
Updated
I
Updated
If required, do
deconcatenatioii.
SlOT
6
JCT
I ~?if
ESTAE
exit parms.
5
c5
UCBs
TIOT Entry
Return to
SVC99
Control
(lEFDB400)
B
Messages
~eason Code
I,
'
r-
'
.
-.....
"""Data Sets
-'
........
-"
r-l+
I
To Last
'Write EPA
Uncataloged, :f
Recataloged, f
f
Cataloged. 0< --- Updated for
'Scratched
SWARecords
' •
as requlf~d
JS~F Recordsl
Written
~
Diagram 14-22. IEFDB4AO- Dynamic Unallocation Control (part 2 of 2)
Extended Description
Module
Segment
ENTRY
Dynamic unallocation control (lEFDB4AO) is
called by SVC 99 control to un allocate a data
set that was requested by a currently processing job step.
1
The Dynamic Unallocation Control routine first checks
the input request for valid text units by calling the
syntax checker. The input is checked for invalid, mutually
exclusive or duplicate keys, and for invalid number and
length values. The key table, which contains pointers to
specified keys, is filled in by the syntax checker. If there
were no errors found in the previous checks, inclusive keys
and invalid parameter values are checked. Any error condition detected in this step will cause step 6 to be done next.
IEFDB4AO
2
IEFDB4FC
IEFDB4FA
Depending on the request, the ddname or dsname
search routine is used to find the DSABs to be unallocated. If both dsname and ddname were specified, the
search is by ddname, and the dsname is checked to ensure
that it matches. For each DSAB found, processing is as .
follows:
IEFDB4FF
• If the DSAB is for a nonpermanently allocated non&dsname data set with a disposi·tion of delete, it is unallo-'
cated regardless of the input option specified.
5-
:s
~
iC
~
[
o....
o
"C:S
ell
;I
g.
:s
~
~
-..J
If there are DSABs for remove-in-use, the remove-in-use
•
processor IS cal1ed.
Segment
3
Dynamic Unallocation Control scans the DSABs to be
unallocated. It checks for open or cataloged data sets,
or overriding dispositions of delete for-shared data sets. If
any of these conditions is detected, the DSAB is not
unallocated.
IEFDB4AO
UNAENVCK
For a dsname specified, Dynamic Unallocation checks each
DSAB to be unallocated to ensure that a permanently con·
catenated group is either a GDGALL dsname,group.or a
VSAM group spanning device types. Otherwise, the data set,
is not unallocated.
IEFDB4AO
PCATCHKS
4
IEFDB460
Deconcatenation (lEFDB460) is called to process
any DSABs to be unallocated thatare·members of
a concatenated group.
5'
Dynamic Unallocation Control calls the Unallocation
Processor to do the required unatlocation for the eligible DSABs.
On completion of processing, the reason code field is
set (two-byte error code and two-byte information
code) and control is returned to the SVC 99·controlroutine-.
• If neither of the above options was specified and ·the
DSAB is not permanently aUocated, unallocation process"
ingis done; otherwise, remove-in-use processing is done.
g
DDNPRCSS
DSNPRCSS
Module
6
• If unallocation or remove-in-use was specified, the
appropriate processing is done.
rI)
VALIDCHK
Extended-Description
IEFDB481
IEFDB4A1
~
;;
Diagram 14-23. IEFDB4S0 - Dynamic Concatenation (Part I of 2)
Entry from SVC 99 Control
(lEFDB400)
o
0
~
i'D'\f4f-tt,
:::""10l:.
(
~
N
Via standard PUS linkage
Dynamic Concatenation
I
{I)
l
1
~
{.
Invalid text
Valid text
•
l-
f
~
,:1
~
=
a
Len
Search T lOT for
OONAMES specified.
DO N not found
DON found
1Parm 1
+3
CoN
~
if
r.l
CoN
:....
4J5CB
-
Make environmental
checks.
Env. conflicts
No env. conflicts
--See environment
44
+ASCB
+TCB
+JCT
+SCT
Reorder DSABs and
TIOT entries.
Error in reordering
No error
ALFNCMAP •
DEPARMS
I+
Last EPA on chain
+OSAB
Next
+Prevo
DSAB
t
5
Blank ODNAMES,
update OSABs.
6
Write SlOTs when
permanently
concatenated.
4-)
7
J
8
TlOT
entry
+SlOT
To SVC 99 ContrOl
(lEFDB400)
DONAME
r
1 J
,~
II"
~
ODNAME
DDNAME
~
-
L
OONAME blanked in TIOT.
DONAME blanked in SlOT for permanent
concatenation' only.
Invoke Change
ODNAME/JES3
exit when
permanently
concatenated.
Clean up and return.
I
SlOTs
DSABTCBP
*.f.
• Common input
not used in this
routine
nOT
DSAB chain
2
(»
~N
Syntax check internal text.
Reason code
Reg .15
I
Return code
'- -If syntax error,
I~ Always 0 failing key
"-~
"'---...../""
~
Diagram 14-23. IEFDB4S0 - Dynamic Concatenation (Part 2 of 2)
Environment
'*';'lb~~B'~~i~~: '
bSABODB
t
DSABO
....
I
~
+ 1st DSAB
...
TIOT
,",../1
+TIOT entry - ~ L
• SlOT entry .
DDNAME
~~NAME-
I
Extended Description
Module
Dynamic concatenation provides the user with a means of
logically connecting allocated data sets into a concatenated group. These data sets must not be OPEN, or the
request for dynamic concatenation is denied and an error
return code is returned to the user.
IEFDB450
Label
,~
I
DDNAME
Extended Description
3
Module
An error code is set if any of the specified ddnames
is associated with an OPEN data set.
Label
CCDDSRCH
4
TIOT entries and DSABs are re-ordered prior to
concatenation, i.e., entries are made contiguous in
the order of ddname specification.
IEFAB4FC
IEFAB4FC
CONCATIO
CCATDSAB
5
IEFAB4FC
IEFDB450
CONCATIO
CONCAT
All members of the dynamically concatenated group will
be assigned the 'In-Use' attribute. The permanently
concatenated attribute may optionally be assigned. If one
member of the permanently concatenated group is permanently allocated the entire group becomes permanently
allocated.
1
Text is checked for invalid syntax or duplicate text
units. If the ddname key is not specified or one of
IEFDB4FF
CCSYNCHK
the specified ddnames is blank or JOBUB, STEPUB,
JOBCAT, or STEPCAT, an error code is set.
(I)
(1)
~
~.
:=
l\J
==
sa.
6'
o
....
Q.
o
"d
~
a-
S'
:=
~
\0
2
The DSAB chain is searched for a TIOT entry with
the specified ddname (done for each ddname
supplied). If a ddname is not found or a duplicate
ddname was specified: 'an error code is set.
The ddnames in the TIOT are blanked. DSABDCAT,
DSABNUSE and DSABCATM are set to 1. The TCB
address (from the input parameters) is stored in
DSABTCBP. If permanent concatenation was requested,
(DSABPCAT is set to 1); if any member of a PCAT group
is permanently allocated (DSABPALC is set to 1), all
members of the group are marked permanently allocated.
To reflect the concatenation, the TCTlOT is updated
and an SMF record 40 is written.
6
IEFDB4FC
IEFDB4F9
For a permanent concatenation request, SlOT
ddnames are blanked and the SlOTs are written.
IEFAB4F7
For a permanent concatenation request, invoke the
Change DDNAME/JES3 exit to notify the subsystem
of any changes in DDNAME and relative position number.
IEFDB4FB
CCDDSRCH
7
8
Return is made to the caller with register 15 set to O.
!
Diagram
14~24,
IEFDB460 - Dynamic Deconcatenation (part 1 of 2)
N
C
o
~
<
f'-I
Entry from IEFDB400,
IEFDB410, or IEFDB4AO
Input
Via standard PL/S linkage
N
f'-I
1
a
i
o
ut
Dynamic Deconcatenation
+ Text ptrs
1
Syntax check internal text.
(i)'
I:"'"
DSAB chain
e;:
lot
~
f
Reason code
t Prevo
DSAB
t
(D
~
<
f'-I
N
~
i
~
~
~
TIOT
+JSCB
4 ASCB
+TCB
-
+·JCT
- --See environment
+SlOT
entry
Env. conflicts
No conflicts
•
4
I
+ SCT
ALFNCMAP
*
*Common input not
used by th is routine
5
Restore DDNAMEs &
clear DSAB bits.
Clean up and return.
DEPARMS
+ DSABQ
To IEFDB400, IEFDB410,
or IEFDB4AO
+ 1st DSAB
v
+TIOT entry"
_
SlOTs
TIOT
DSAB chain
DSABQDB
-
~1i
/t':
•.
Return code
Environment
~
./Ie'
R~15
I+ Last EPA on chain
JSCB
TIOT
entry
v1
'!:~
DDNAME
~
!
DDNAME
• SlOT entry'
1\
,
I
error,
failing
~y
I-Always 0
~
'-----'
Diagram 14-24. IEFDB460 - Dynamic Deconcatenation (Part 2 of 2)
Extended Description
Module
Dynamic deconc;:atenation provides the user with a
means of logically disconnecting the members of a
concatenated group. The user must specify the
ddname of the concatenated group. No data set
within the concatenated group may be OPEN. A
permanently concatenated group or members of a
concatenated group which are permanently
concatenated will remain concatenated.
IEFDB460
When a concatenated group is dynamically deconcatenated,
the ddnames that were associated with the data sets before
they were concatenated are restored unless this would
result in duplicate ddnames. This situation could arise if
a dynamic allocation with the ddname to be restored
occurred after a dynamic concatenation. In this case the
deconcatenation request is failed.
Note: Dynamic deconcatenation has no effect on the
"In-Use" attribute.
Label
Extended Description
Module
Label
1
Text is checked for invalid syntax or duplicate text
units. If the ddname key is not specified, or the
specified ddname is blank or is JOBLlB, STEPLlB,
JOBCAT, or STEPCAT, an error code is set.
IEFDB4FF
SYNCK460
2
IEFDB4FC
ENVIRNCK
The DSAB chain is searched for a TIOT entry with
the specified ddname. If the ddname is not found, an
error code is set.
3
An error code is set if the specified ddname is associated with any OPEN data set or if deconcatenation
would cause duplicate ddnames in the TIOT.
4
For permanently concatenated members, DSABDCAT
is set to O. For temporarily concatenated members,
DSABDCAT and DSABCATM are set to 0 and ddnames
from the appropriate SlOT are restored in the appropriate
TIOT entry.
5
til
(D
$l
~.
=
~
a:
~
g:
sa.
o
~
~
o·
=
CoN
.;:..
N
Return is made to the caller with register 15 set to O.
ENVIRNCK
SIOTDDCK
IN
~
Diagram 14-25. IEFDB470 - Dynamic Information Retrieval (Part 1 of 2)
I-.J
I-.J
oell
<
ell
I-.J
Entry from SVC 99 Control (lEFDB400)
In
Via standard PUS linkage
P
rocess
Dynamic Information Retrieval
ell
'<
~
~
3
Syntax check internal text.
~n·
Invalid
Valid
r-~
.$
=
3~
ell
• JSCB
~
+ ASCB
+ TCB +JCT
+SCT
I-.J
ir6
IN
~
Search for DSAB by
DDNAME, DSNAME or
relative number.
Not found
Found
IN
'<
•
•
2
~
~
V
ALFNCMAP *
SCTNIUSL
3
Retrieve data requested
and store into text units.
4
Cleanup and return.
A
*Common input not
used in this routine
DEPARMS
1+ Last EPA on chain
To SVC 99 Control
(I EFDB400)
Reason code
Error
code
Environment
Reg 15
JFCB
4 DSABQ
Info
code
If syntax
t--error.
fai ling key
IReturn Code r-- Always 0
~
'
Diagram 14-25. IEFDB470 - Dynamic Information Retrieval
Module
Information retrieval provides the user with information about his current allocation environment. The
user can request the information via the ddname or
dsname. In addition, the user may ask for information about any of his currently allocated requests by
specifying a relative entry number. For example,
information about all requests can be acquired by
asking for information about the first, second, and
successive entries in order. A unique return code is
provided when information is requested for a nonexistent relative entry number.
IEFDB470
1
IEFDB4FF
2
til
n>
$a.
o·
=
~
3:
n>
[
o
'"0)
o
"0
~
~
o·
=
"'~"
"'"
~
(part 2 of 2)
Extended Description
Text is checked for invalid syntax or duplicate text
units
__ ..Y?
Label
DINSYNCK
The DSAB chain is searched by ddname, dsname, or
relative number. If the entry is not found, an
error code is set.
DINRTSRC
3
Requested data from appropriate control block
(see environment) is stored into text units.
RETRIEVE
4
Return is made to the caller with register 15 set
toO.
w
...t
~
Diagram 14-26. IEFDB480
~
Remove In-Use Attribute (Part I of 4)
Entry from SVC 99
iliiilllll"IIIEII§lIIBlilEClo~ntarO~I(lEF~400) iPirioice~sis~II~IDII~~IIIIIIIIII~
N
fIl
Via standard PL/S linkage
Output
Remove "In -use"
1
~
.in
r-
J
f
1
Syntax check internal text.
2
Search DSABs for "REMOVE
'IN -USE' ".
<
.JSCB
w
• ASCB
'<
fIl
+TCB
N
~
iS
- - See environment
.JCT
sa
vfLt
4SCT
+
4
w
~
ALFNCMAP*
DEPARMS
I+OSABot
4
List of DSABPTRs
, . . - - -.....
P;;;;-- for "REMOVE
'IN-USE' " processor
Input to
Step 3.
,--_----'ltili....
""_
Environment
JSCB
I xx X I
*Common input
not used by this
routine
DSABQDB
+1st DSAB
Count of
DSABPTRs
in list
~~
Diagram 14-26. IEFDB480 - Remove In-Use Attribute (part 2 of 4)
Extended Description
Module
The function of the Remove "In-Use" routine is to handle
dynamic allocation (SVC 99) requests for Remove "In-Use"
processing.
IEFDB480
Checks are made to ensure that exactly one of the two
valid remove in-use keys was specified, and that
valid number and length fields were also specified for it.
The syntax checker is called to assist in these checks. If an
error is detected, step 4 is processed.
IEFDB4FF
1
2
The DSABs for remove in-use processing are determined as follows:
• If the current task option key was specified, a scan up the
mother TCB chain to the initiator's TCB (or, if 0, the job
step TCB) is made. Looking at each in-use DSAB in the
DSAB chain not for a private catalog, remove in-use processing will be done for any of these DSABs whose TCB address
does not match that of a TCB found in the TCB scan .
• If the TCB address key was specified, a scan of the DSAB
chain is made and remove in-use processing will be done
for any in-use, non-private catalog DSAB which has the
specified TCB address.
rI'.I
ao·
=
N
a::
a
[
o
100)
o
"0
ao·
=
~
~
N
Ul
Label
CUTSKSCH
TCBADSCH
t
Diagram 14-26. IEFDB480 - Remove In-Use Attnoute (put 3 of 4)
~
i
~
w
..
~
DSABCHAN
I
b
I,,
E:
DSABQDB
1·
f:.
r
DSABsprocessed
have DSABNUSE
turned off and are
placed at end of
dlain.
ID
'"
I
• First
DSAB - Updated if
necessary
4 Last
G
w
DSAB - Updated
~w
i
w
~
14
Last write EPA
I
• JSCB
• ASCB
JI..>
3
y
Invoke "REMOVE 'IN-USE'
processor .
~
II
)
'"
4TCB
4JCT
4SCT
I
EJ
EJ
TIOT
entry
VAM paging
data sets released
Clean up and return.
Return to SVC 99
Control (lEFDB400)
....
...
I
Messages
DSENQ table
DSNAME
entry
deleted
-.~
Register 15 - always 0
I
I
L
Updated: SCT,
JSCB, TCTIOT ;
SlOTs, UCBs
Ptr to last EPA
Written
SMF
record 40 .
Data sets
cataloged!
recataloged!
uncataloged!
scratdled
4
J
=
I~~r I
If syntax
j-:~r:r, failing
"
..
'
"-7
~
Diagram 14-26. IEFDB480 - Remove In-Use Attribute (Part 4 of 4)
Extended Description
Module
Label
3
The remove in-use processor is invoked for any
DSABs found as a result of the search in step 2. It
performs the following functions:
a. When a DSAB pointed to in the input list is either OPEN
or a member of a concatenated group, functions band
c are bypassed.
IEFDB481
b. When a DSAB is not permanently allocated with a DISP
of DELETE:
• If the DSAB is for a non-&DSN its address will be
placed in the list for unallocation and the unallocation
count updated. Functions c and d are bypassed for
this DSAB .
• If the DSAB is for an &DSN V AM data set, V AM
paging space is scratched and function d is processed.
c. When a DSAB is either not permanently allocated, or has
a disposition other than DELETE, a check is made to see
if the conditional disposition was specified. If it was
specified and is different from the normal disposition,
it is removed from the SlOT and an EPA for the updated
SlOT is placed on the write chain.
d. The in-use bit in the DSAB is "turned off and the DSAB
is moved to the end of the DSAB chain. (If the DSAB
is concatenated, this processing is done for all members
of the group.)
e. If there are DSABPTRs in the list for unallocation from
function b above, the unallocation processor is invoked.
4
~
(1)
a
5'
=
~
a::
sa.
=8....o
o
"0
~
a5'
=
~
J:.
~
......
Return is made to the caller.
VAMSCTCH
DISPPRCR
DSABCHNR
IEFDB4A1
~'--7
t
Diagram ,14-27. IEFDB490- Ddname ADoeation (Part 1 or 2)
~
Entry from SVC 99 Control (IEFDB400)
~
~
W
fIl
..I
i
'<
Ir-+~,-T-ex-t-p-tr-s-,---~"',<
I
rc;:
I
K
!<
I
~ -f 1
\
I+
,+
Text unit
:)
1
IKey
I
•
Error
code
JSCB
Ij ASCB
1
I
-
1
Syntax check internal text.
"
Invalid text.
, Valid
;
Text unit
.'
•
2
Parmi
lnd
1# I Len I Parm I
3
I nf 0
"
code,
~---See environment
Updated DSAB
...
TCB
and store TCBPTR in
DSAB(s).
.1'......-.-----1
DDNAME '
-y
-
JCT
SCT
ti:?,\;ifi:g1~~;:;}J'sll*;il;;;;;tt'j;'*3';);,;,,,,:}t;;*\ttVir?~!r03!fuz;;;;12#£\~?:ie.~c~~pJ$i{f0~r:tt:.
I
ALFNCMAP *
I
DEPARMS "
I
..
Last EPA on chain
*Common input not
used by this routine
0;
(,
:~
~l
1 ; (
I
5
If necessary, check'for:
dummy data set.
"
f
:;
:;;;,:;::',,:,,::;;'
Environment
JSCB
DSABQDB
..
/
+1st DSAB
DSAB thain
;
I+
~..
.
TIOT E t n t r i e s : '
"'"",II
nOT entr,y _II
"I-' " : ,)
DDNAME
UCBPTR;'
,
,-
"
,
.
,
'
fo"
Text unit) ,
/',t.~:
14 Text unit T
-
1-------......-------
l{
.
To SVC 99
",Control
:. OEFD8400)
I
Text ptrs
If a dummy datat:- -T1
set X'80'
,4"
'
/'
", return~ I
> otherwIse,
Key
#
;: X'OO'
'.... 0002 0001
~ ~
::
: ; i
6 Clean up and return.
:
1
II..
~;..
Len
Parm
0001. 80
" " I t o "
~1I1I1I!l1I1I1I1I1I1I1I1I1I1I~1I~~~~~~~~~~'E0"~\'''~;~~s:£~s~'''~.~"~0~"'~'~~~'
• DSAB.Q
TIOT entry,
TCBPTR
4 .Assign, "'n-use" attribute' .......""":_ _/F'p)
*
I.
Make environmentalchecks.
• ,TIOT entry...
•
j
{,'
Search TIOT for
DDNAME.
.N~~~
~R_e_a~
__n_'~~,~e_~______
w
~
')::
0
\
, I Key 1#1 Len ·1
itw.
~
/i
"
DDNAME Allocation
I ""
~
~w
.~
Via standard P.USlinkage· .
t
':<:/,:.;;::~\,
f+;Y;J<{/"
R~~
I
LJ
,.
:;
Error
code
I
Info
code
Reg 15
I
Return cOOe
(,X/::<',' '.J,"\Y
:',<, ,
I"
"
~
If sy.ntax
}
error,:'"
failing key :;{
j
I - Always 0
1,
"
.;:;
~
Diagram 14-27. IEFDB490 - Ddname Allocation
(part 2 of 2)
Extended Description
Module
This module assigns the "In-Use" attribute to the
resources associated with the specified ddname. This
function can be specified using the verb code X'06'
with one or both valid textkeys~
• Key X'000 1 ' - This key is used to specify the ddname
to be allocated. This key must be specified.
IEFDB490
Label
• Key X'OOO2' - This key is used to request an indication that a DUMMY data set is being associated with
the specified ddname.
1
A subroutine is invoked to check text for invalid
or duplicate keys. If an error is found, step 6 is
processed.
If key '0001' is not present, an error code is set. and
step.6 is processed~ If specified ddname is JOBUB,
STEPLlB, JOBCAT, or STEPCAT, an error codeis
set and step 6 is processed.
IEFDB490
IEFDB4FF
DDNLCCHK
Extended Description
Module
2
A subroutine is invoked to search the DSAB chain
for a TIOT entry with the specified ddname. If
the ddname is not found, an error code is set and step 6
is processed.
IEFDB4FC
3
IEFDB490
The following checks are made on the DSAB entry:
If entry is not in-use
If entry is permanently allocated
If entry is not convertible .
If entry is member of concatenated
If group entry is not OPEN
DSABNUSE=O
DSABPALC=1
DSABCONV=O
DSABCATM=1
DSABOPCT=O
If any of the above are not true, an error code is set and
step 6 is processed.
4
The "In-Use'! attribute is assigned. If member of a
concatenated group, the in-use bit is turned on for
each entry. The TCB address.is stored in the DSAB(s).
5
If text key '0002' is present, a check is made to
determine if data set isa dummy .. Ifit is, '80'X is
returned in parameter field of key '0002'. Otherwise,.
'OO'X is returned.
Note: All members of a concatenated group must be dummy
in order to have the dummy indicator returned.
6
i
::t
ht
~
[
2.
f
e'
::s
~
\C
Return is made to thftcallerwith register 15 set
to zero.
Label
DDNLCCHK
~
J;.
Diagram 14-28. IEFAB4AO - Common Unallocation Control (Part 1 of 10)
~
Q
o
Overa II Input
CIl
....-
<:
CIl
.....
te 1
~
CIl
Function map
'<
~
a
b
'!S.
f')
t:
/
,
• First request blk
JSCB pointer
•
I xxxxxxxx I
Next RB or 0
+ SlOT
Unalloc
flags
DISP
processing
indicators
• First alloc'd SlOT
~
I/",
DISP
error
flags
Subsystem
flags
....
.... c
DSENQ table SVA
~
Override
DISP
Step number
~
=
3
Override
SYSOUT
class
VUT SVA
Informational
return code
i - Pre
--- Mor
1.--..
Irr •• .o.
Optional field
Reason code area
(D
--
~
-
Function map byte 2
-
--
e3
-----
'<
ree DSABs
ease volumes
locate units
se data sets
nect private catalogs
dispositions
tatus
sition msgs
-UTITInVOke.JES3
CIl
TIOT is ENQ'D on
Use purge option of scratch
Issue no error msgs
Release TIOT DD entries
Do generic dequeue for volumes
Change VOL attribute in UCB being unallocated
Bypass VUT processing
Bypass POST function
Function map byte 4
I X --
- - -- - ]
L
Last call to JES3 for step
'-n~:queue DSNs from current TeB
Dequeue volumes from current TCB
Build ETIOT for scratch
Change public tape to private
Scratch from first volume only
D()n't issue SM F record at scratch
Release all data sets with step number in DSENQ table
~
L
"i
~
~
~
(See extended description for Callers)
Parameter list to
disposition processing
Process
Common Unallocation Control
Function map
+ First req blk
J
JSCB
Build ETiOT for 'scratch'
Scratch from 1st vol only
Suppress SMF record at scratch
'Purge' D.A. data. sets
Scratch not to ENQ on TIOT
Don't issue error msgs
Monitor status active
Issue DISP msgs
1
Perform disposition processing, if
necessary (for details, see
M.O. Diagram: Disposition
Processing).
0/1
Diagram 14-28. IEFA84AO - Common Unallocation Control (part 2 of
Extended Description
Module
The functions of the common unallocation routine are:
IEFAB4AO
• Data set disposition - Disposing of a data set as directed
by the user through the DISP parameter in the job control
language or as specified through the dynamic interface.
• Data set release - Releasing the data set for use by other
jobs, after the data set's last use by this job.
• Unit unallocation - Unallocating the unit(s) to which a
data set is allocated.
• Volume release - Releasing volumes allocated to requests.
Note: All four processes are not always performed for every
request for unallocation. For example, a unit record device
may not have a volume associated with it, or a data set
may not be released if it is required in a later step of the job.
The callers of this routine are: IEFBB414,IEFBB416,
IEFAB477, IEFAB490, IEFAB4DE, IEFAB492,
IEFDB4A 1, IEFDB413, and IEFDB418.
1
Disposition processing is invoked unless the input
function map indicates that it is to be bypassed. The
subsystem interface is invoked for all subsystem data sets,
i.e., SYSOUT and SYSIN data sets.
it5'
::s
~
a:
ff ~ I #
# entries in list
~
JFCB
9
h.
1/,____
i%tl/
4
Build I.ist of volumes to be
released, if required.
;
~
~1t
VOLSER
I ' TIOT entry
I;
entries to
be released
I
'*'
~B
VOLSER n
JFCBXs
~
" ' - UCB
~
*Flags
I
*
t--- 8~ytes ---t
* Flags
o and 1 - Unused by common
unallocation
2 - Check for multiplyalloc'd
3 thru 7 - Reserved
IVOLSER
--XX---Check for multiply alloatted
volumes
check for multiply alloatted
volumes-DA only
.
Parameter hst for
unit unallocation
Unit unallocation
function map
.
X XX - - - - -
•+ Function map
LChange use
• First req blk
• DSAB aDB
+VUT SVA
+ ESTAE parm area
1
5
Do unit unallocation, if required
(for details, see M.a. diagram
Unit Unallocation).
attribute
.... Bypass .VUT
processing
- Bypass POST
function
6
........
I/'
Units unalloatted (UCBs updated).
Volume unload table (VUT) entries made.
~
"'_.f
Diagram 14-28. IEFAB4AO - Common Unallocation Control
Extended Description
Module
Label
4
If volume release is to be done, a list of volumes to
be released is built unless a generic DEO is to be
issued. The list contains all the VOLSERs in the JFCBs and
JFCBXs for the request as well as those from the UCBs of
the unit(s) allocated to the request.
IEFAB4AO
BVOLRLST
GETVLSER
5
IEFAB4A4
If unit unallocation is to be done, the following functions are performed:
1. Updating the unit control blocks (UCBs) associated with
the requests being unallocated.
2. Creating/updating the volume unload table (VUTI.
3. Posting generic allocation via the allocation O-manager,
for all device groups unallocated.
til
(Il
g.
o·
::I
!';J
is:
(Il
~
Q.
o....
o
"C:S
~
fa.
o·::I
~
~
~
VI
(part 6 of 10)
,--_/
~
Diagram 14-28. IEFAB4AO - Common Unallocation Control (part 7 of 10)
~
~
.
....---
N
fI
in
t:
2"
~
i
ft
W
< ~:
Input
parameter list
Function map
..........
I x------- J
+ VOL list *
L Do generic
• TCB
t
J.
wlume DEQ
r
6
Release volumes (DEQ).
7
Invoke TIOT manager to free
DSABs, if required.
v
Volumes released.
First aim SlOT
l+ Reason
code
area
*See output from
step 4.
~
N
i'"
I
w
~
t
TIOT_
req blk
ICP
~)
F
Functionf #to
map
free
+ JSCB
~~
~
DSAB list
+DSAB1
•
DSAB list
• DSAB2
d~~
1.
DSABN
~ I-C
j
2-bytes
-1
I------x-x--- J
L Ifon,
free DSABs
- If on, free DSABs
and release TIOT
entries
~--'
,
..
v
DSABs freed.
TlOT entries released.
'-,
'2#
Diagram 14-28. IEFAB4AO - Common Unallocation Control
(part 8
Extended Description
Module
6
IEFAB4A8
If a generic DEQ is requested the DEQ is issued
specifying the major name SYSZVOLs. Otherwise,
the DEQ parameter list is built and a conditional DEQ is
issued for the volumes that can be released (Volumes still
in use by the job cannot be released). The major name used
is SYSZVOLs and the minor names are the VOLSERs that
can be released.
of 10)
Label
The input TCB pointer is used to direct the DEQ to the
owning task.
7
If DSABs are to be freed~a TIOT manager request
block is"built. If storage is available for the list of"
DSABs, the list is built, and the TIOT manager (lEFAB4FC)
is invoked. The core for the DSABs is freed. The TIOT DD
entries are released if required.
(I.)
(I>
~
(5'
=
~
ac:
(I>
[
o
"'"
o
'C
~
a
cs·
=
w
J.
(N
'-.I
IEFAB4AO
IEFAB4FC
FDSABINT
UNALCTIO
'-'---""
!
Diagram 14-28. IEFAB4AO - Common Unallocation Control
(part 9 of 10)
~
00
~
"<
!:I}
~
~1
!:I}
~
~
Parameter List
~
(
£
~.
r-
I
t
Function Map
11 ~
"
8
1st Request
Block
Invoke JES3 subsystem to
notify it of release of data
set and associated resources.
~11
'4/,9
~ "J
i5
iii
;;'j
:,f
1
\OBINDVl
i
i
~1;(.:
/
<:
o
;
{
SSCU
:.
~;
Step Number
(D
",. ";i
SSOB
;;:;
·Z,
=
9
,"
;:\,
• DDNAME
Relative Position
Number
!
• Step Number
,~
t
~
'<
!:I)
~
:=
C',
(
• Unload Routine
t
I--- 4 bytes ---1
X X
I
r
~
~
~
~tLL
Last call to
JES3 for step
'
"
,'~""',
',.
Register 15
9
~
Clean up and return to caller.
'"
~~;
;
Invoke JES3
(See Common Unallocation Control,
Part 1 of 8.1
"
'
";~"
'<>,"
'"
Callers are named at beginning
of extended description
EJ
EJ&
I
Reason code array
~ 2-bytes ~ ;;
::
OR
l}
+0
+4
2. If data sets not
released, 7=0.
+8
3. If VO Ls not
released. 7=0.
+12
4. If unable to
create ESTAE
environment,
7=0.
\
:~;
.'W"
.,.,
.••.
,:i'
..
,
v,.,
,. c ..
;
?i
;;
"",i;(f
----
""!'"'~
Diagram 14-28.IEFAB4AO - Common Unallocation Control (Part-IOof 10)
ff
~
eo
::t
~.
a:
[
c....
o
Ieo
::t
rw
\0
Extended Description
Module
Label·
8
If the JES3 subsystem is to be invoked, build the
subsystem interface and invoke JES3 once for
each request block (except for DUMMY. TERM,
QNAME, SYSIN, and SYSOUT). JES3 tables are
updated to reflect the unallocation~
IEFAB4AO
EXITJES3
9
IEFAB4AO
Control is returned to the caller with a return code
in register 15.
,----'"
i
&l
~
~
..
Diagram 14-29. IEF AB4A2 - Disposition Processing (Part I of 3)
Entry from Common Unallocation
Cont,oIIiEFAB4AOI
~
Input
t--1 byte---t
fIl
'<
=-
a
i;:;.
t::
2"
~
~
c
a
(D
w
~
~
~
8
I
"'.
lillilF'
Build 'dummy' ETIOT
for scratch
Scratch from first volume only
.... If on suppress SMF record issued
by scratch
.... If on purge D .A. data set when
scratch
L If on TIOT is enqueued
L. If on suppress error msg(s)
L.. If on monitor status is active
L If on issue msg(s) to SYSOUT
Function
map
s
-
For each request block
,r=:>'
JI
.,.
Build volume list for
request, if necessary.
~
____
------~v~--
Function map
2
~1~
Determine processor to
invoke, and build processor
function map.
.VOL list
tData set
name
~
Invoke appropriate processor.
L ---.
«_
4
Status
info
L-.J...
'----.
Data set
name
o
Bits to indicate
• Data set was located
• VOLSER list changed
Data set
name
Uncatlg
~
F unction map
• VOL list
DISPIDI MSGID
EJ EJ
Catalog
updated
t SlOT to
. process
t
I
DISPIDI MSGID
Return to Common
Unallocation Control
(IEFAB4AO)
• VOL list
DISPID MSGID
t
Return to caller.
,.
F unction map
+UCB or 0
+TIOT
DO
entry
CATALOG
RECATALOG
• VOL list
Last
request block
~
DISPIDIMSGID
~ F unction map
DISP
info
DELETE
.DSCB TTR
.' 3
===:!>
______
1 entrylVOLSER
KEEP (+PASS)
Step name
step name
~
VOL list
Disposition Processing
Job name
PRoe
w
Output
D
Message
issued
Data set
scratched
0
t
Diagram 14-29. IEFAB4A2 - Disposition Processing (Part 2 of 3)
Input
Output
Indicators
@
Byte 1
Bit 0 Bypass DISP proc
1 Use normal D ISP
2 Use condo DISP
3 Use override DISP.
4 Use override userid for
SYSOUT
5 Don't check UCB status
6 Reserved
7 Reserved
Byte 2 (55 interface flag)
Bit 0 Delete at unallocation
1 Hold at unallocation
2 Dynamic unallocation
3 WAn
4 Use override SYSOUT class
5-7 Reserved
.""- - - - -
Suppress
error msg
Monitor status
active
Issue msg to
SYSOUT
-
D.A. data set
Suppress error msg
Monitor 5tatl,lS active
Issue msg to SYSOUT
Override DISP
®
Bit 0-3 Reserved
4 KEEP
5 DELETE
6 CATLG
7 UNCATLG
Extended Description
Module
This routine controls the processing required to dispose of the data sets associated
with the input requests.
IEFAB4A2
Before any disposition processing can be done on a non-subsystem data set, a volume
list must be successfully built.
{I'}
I'D
5·
If the volume list is successfully built, this routine will perform the appropriate
process from among the following:
~
• Process KEEP or PASS disposition, and build and issue the appropriate message.
a::
I'D
• Process DE LETE disposition, and build and issue the appropriate message.
[
• Process CATLG disposition, and build and issue the appropriate message.
o....
• Process UNCATLG disposition, and build and issue the appropriate message .
~
::s
o
"0
~
a5·
::s
c.t
~
t
• Unallocate subsystem request, and build and issue appropriate message.
If the volume list is not successfully built the routine will:
• Process DELETE (tape only), KEEP, PASS, and UNCATLG.
• Build a disposition message, using JFCBs and JFCBXs via the alternate
disposition message routine (IEFAB4B2).
Label
Suppress SMF record
Purge D.A. data sets
TIOT is enqueued
UCB addr not valid
Msg only for VIO data sets
VIO data set
UNCATLG data set
No rewind
Tape da ta set
D .A. data set
Suppress error msgs
Monitor status active
Issue msgs to SYSOUT
3-442
OS/VS2 System LOJic Libnry Volume 3 (VS2 Release 3.7)
'
___ ::T
~
Diagram 14-29. IEF AB4A2 - Disposition Processing
(part 3 of 3)
Extended Description
Module
Label
Extended Description
1
Unless the data set is a subsystem data set, a volume
list is built containing the va LSERs and device type
of the current data set. The device type is obtained from a
UCB allocated to the data set, unless the data set is to be
recataloged, in which case the cataloged device type is used.
The volume list is used as an interface to the various disposition processors and to the message processing routine,
(lEFAB4BO)' Function maps and other indicators are set as
required for the disposition to be processed.
IEFAB4A2
BVOLLST
Note: For a DADSM scratch only data set, a dummy
ETIOT entry will be created if it is indicated in the common unallocation function map.
IEFAB4A3
c. CATLG disposition
If tape data set:
Check density and update device type field of VOL
LIST, to allow the widest possible range of devices,
unless the data set is being recataloged, in which case
use the cataloged device type.
If necessary invoke catalog management to catalog (or
recatalog) the data set.
Determine the message to issue, if any, and call
I EFAB4BO to issue message.
2
IEFAB4A2
Each request block is checked to determine what processor should be invoked. One of the following processes
will be performed:
PRCSDSP
BDSPINT
Module
Label
CTLGPRCR
Note: IfCTLGPRCR is being used only to update the
DSCB TTR in the catalog, no message will be issued. If
data sets were cataloged when allocated, the "cataloged"
message will be issued, but catalog management will not
be invoked.
d. UNCATALOG disposition
Indicate uncatalog in parameter list for CATLG management.
Invoke CATLG management to uncatalog data set.
Invoke message processor, IEFAB4BO, if disposition
messages are to be issued.
UNCPRCR
e. Subsystem data sets
Build the subsystem interface, using information from
the data set's SlOT, JFCB, DSAB, and common unallocation request block.
Issue IEFSSREQ macro to generate a CALL statement
for the subsystem interface routine, SSREQ, so that the
subsystem can dispose of the data set.
PRCSSSDS
NVLSTPRC
:so
Note: If no core is available for the volume list, a special
message routine, IEFAB4B2, is invoked, which uses the
JFCBs and JFCBXs to obtain volume information for the
disposition message. If the disposition being processed is
DELETE (DASD data sets only), CATALG, or RECATLG,
a "NOT DISP 5" message is issued but no processor (j.e.,
Catalog Management or DADSM) is invoked.
o
.....
4
3
CI'l
t1)
()
S·
:I
N
::
~
a. KEEP (and PASS)
Identify message to issue (KEPT or PASSED).
Invoke the message processor, IEFAB4BO.
Update DSCB TTR in catalog, if required, using
RECATLG interface in segment CTLGPRCR.
KEEPPRCR
b. DELETE disposition
If the data set is direct access:
Set up for DADSM SCRATCH.
Invoke DADSM SCRATCH function.
Whether the data set is direct access or not:
If the data set was cataloged invoke UNCATLG. Invoke
IEFAB4BO, to issue DELETE and/or NOT DELETED
message(s). A data set may be partially deleted, in
which case both messages will be issued.
If tape, indicate 'REWIND NEEDED LATER' in the
UCB(s).
DELPRCR
Q..
o
~
~
Ql
S·
:I
<.H
t
<.H
Control is returned to Common Unallocation
Control (I E F AB4AO).
w
t
.-.
Diagram 14-30. IEF AB4A4 -Unit Unallocation (Part I of 3)
Input
Entry from Common Unallocation ContrOl (lEF~AO)
~
~N
UCB
C"I.l
Process
Output
Unit Unallocation
'<
For each request:
~
~
. . S'
"QQ
;:;.
'') 1
DOMiDI
"
DOM pending MOUNT
message(s) .
§]
UCB
!
"-
"
Message I D cleared
!:
~
~
~
~
(D
w
'<
C"I.l
N
l=I'
(D
i
0
~
VUT
#
w
~
VUT
SVA next VUT blk
..') 2
v
entries this blk
VOLSER
I
VOLSER
t:~
t
176
II
}u
T
p to 28
VOLSERs
per blk
Update VUT.
"
·V
New VOLSER
VOLSER added
toVUT
~
Diagram 14-30. IEFAB4A4 - Unit Unallocation
"',~
~?
(part 2 (if 3)
Extended Description
Module
This routine unallocates the devices associated with each
input request. Functions performed are:
IEFAB4A4
Label
- Unallocating units no longer needed - A direct access
unit is not unallocated until the use count becomes zero.
- Rewinding tape volumes - Volumes on tape units being
unallocated will be rewound or unloaded if necessary via
the volume mount and verify function.
- Deleting outstanding messages - Any mount message
pending for a tape data set is deleted.
-Identifying volumes to be unloaded - VOLSERs for
private volumes, for public MSS volumes, and for
volumes containing passed data sets are placed into
the volume unload table (VUT).
~.
=
~
f
1..
e'
~
o
=
i
00
~
IEFAB4A4
DOMMSG
2
IEFAB4A4
CRVUTAB
If VUT processing is requested, the volume serial of
any volume which is private, public MSS, or contains
a passed data set is placed in the VUT.
I:'-l
to..)
1
If there is a mount message pending for tape, it is
deleted using the DOM macro, and the DOM identifier and mount pending indicator in the UCB are cleared.
it
-<
r.IJ
(:)
w
~
~
Diagram 14-30. IEFAB4A4 - Unit Unallocation (Part 3 of 3)
~
0\
Input
o
C"I)
_-----O-v..,crall input
"<
I· Function
C"I)
N
C"I)
X X X - - - - --
lL
4 DSAB ODB
~
~
ESTAE parm
area
t"'"
J
L...
<
va L
attribute
Output
)
~
3
Bypass POST
Unallocate units.
Updated UCBs
Tapes
rewound/unloaded
DSAB
DSAB ODB
2-a
Change
7
Bypassing VUT processing
VUT SVA(or 0)
(
Process
TI
• 1st req blk
'<
£;:;.
map
• First DSAB
Previous DSAB
• Last DSAB
TIOT entry
~
(D
~
4Group ID list
~
~
o~
00
~
4
SlOT
Request block
4Next blk (or 0)
~
4SlOT to be unalc'd
~
X
\E
.t
U I ' , "11'ti ..... ~
Return to caller.
t
. . : . " . .. .. , . . -
III
4 Group mask
ASID
N
,-l"
U
T
T
Return to Common Unallocation
Control (lEFAB4AO)
IU
Passed
d8t5UC
... B pending
MOUNT
set
on VOL
Use count
(a.A.
only)
DSAB
It TlOT entry
,....
~
~
N
Group
list 10
Group ID list
X
Allocated
bit
Extended Description
Module
Label
3
IEFAB4A4
UNALUNIT
CHKMALCD
For direct access devices, the use count is decreased
and if the count is zero the allocated bit in the UCB
is turned off, and other required fields are cleared (e.g.,
attention table index, data management count, and ASIO).
Msg ID, if pending
MOUNT
DDNAME
For non-direct access devices, the allocated bit is turned
off unless the unit is to remain allocated to the step.
UCB1}
Tape volumes are rewound or unloaded if needed (via
volume mount and verify), unless they are reserved or
they contain passed data sets.
UCBN
Length
Group 101
Group 102
Use attribute
,.,."
changed from
Group I D N I p~blic to
prtvate
T
5
Build request block and invoke
allocation a-manager to POST
allocation.
00
~
O-HCR Request block
'".... , Code=61--
• DSAB
multiplyalloc'd
units
t
I
Device type
I
~
N
Q
r
Device
entries
Tape volume
must be rewound
Use attribute
changed from
none to private
4
Allocations which are waiting for units just unallocated are allowed to proceed by invoking the
allocation queue manager.
Note: The local lock and CMS lock are held while UCBs
are being updated in step 3.
5
Control is returned to Common Unallocation Control
(lEFAB4AO).
IEFAB4A4
System Management Facilities
System management facilities (SMF) routines collect
data, provide for user-supplied data collection
routines, and record the collected data in a data
set. There are two cataloged direct access data sets,
SYS1.MANX and SYSl.MANY, that are filled
alternately. While the system records on one of the
data sets, the other may be written out (or
'dumped').
Master scheduling task routines initialize the
SMF routines. Then, the scheduling task uses the
ATT ACH macro instruction to establish the SMF
task. The following components contain SMF data
collection routines and exits for user-supplied data
collection routines:
• The interpreter.
• The initiator/terminator.
• The command processor.
• The timer supervisor.
• The real and auxiliary storage manager.
• The real and virtual storage manager.
• The system resource manager.
• The JEs2 subsystem.
As these various components record and collect
data, they are building records. Eventually they use
SVC 83 to transfer the records to an SMF buffer.
The SVC 83 routine also writes the records to the
SMF data set and, as needed, initializes and
•
switches data sets.
The following list contains the types of record
information that may be recorded on the SMF data
sets:
• Records describing the resources used by
tasks the systet.J1 processes.
• Records describing changes in status of the
system, such as changes brought about by use
of VARY and HALT commands.
• Records describing the usage of data sets and
volumes by users.
• Records describing the resources used by a
TSO user.
Some components collect a single data item and
accumulate the value of the item in an SMF control
block. Some components format a record of various
data items and transfer the record to a central SMF
buffer. Other components provide control program
interfaces to installation-supplied exit routines for
data-collection functions.
Section 2: Method of Operation
3-447
3-448
OS/VS2 System Logic Library Volume 3 (VS2 Release 3.7)
System
Management
Facilities
Recording
(no diagram)
Writing SMF
Records
(lEEMB829
and
IEEMB830)
Switching SM F
Data Sets
(lEEMB829)
.~
STAE Exit
Processing
for SMF
(IEEMB825)
Figure 2-29. System Management Facilities (SMF) Recording: Visual Contents
til
a
o·
=
~
~f
.;:="
~.&.
o
o""'
."
S
g.
=
w
~
~
\0
SMF CrossMemory Post
Error Exit
(IEEMB827)
~
.Diagram IS-I. Writing SMF Records (IEEM8829 and IEEMB830)
(part 1 of 4)
~
o
~
~
SMF Recording
Initialization (IEEMB822)
In
N
fI.)
'<
=.
B
CVT
~
Steps 1-3: Initialization
in'
1
t""
Set up STAEenvironment.
,.~
!i)
~.
•
I
J
r
~N
~
t
R
SMF Writer
Routine
T~CB
O
.,jSCB
C]-
SM~CA SMCAPOEV O~CB
~
w
STAE Exit
JFCB
i
43
~JFCBDSNM
~JFCBVOLI
.12
.
0
1: ;",
Open the SMF data s e t s . . '
Error: fail to open the SMF
data sets.
t;~"
;"
.........Caller
~(via
POST)
3
~sMF/user Record
~
SMCAOPT
SMCASWA
SMCABSIZ'
-
Inform operator of SMF data set
ready -for -record ing condition.
Wait for notification of function.
)1
Fii'
."
Issuer of
SVC83
R1
SMCA
.
OCBBlKSI
w
User Type
SMCAAOEV
SMCAPMTY
~
'1 I~
.
I
Steps 4-10: Handling Buffer Data
10
!mI"-~-----'~'; 4
.wEi
'V4
15,
h. , ;
5
Enqueue on SMF buffer and provide
time stamp for records.
Take user exit if specified.
,.;1
Il"'"
)1
It;:
"
'---~
~
Diagram IS-I. Writing SMF Records (IEEMB829 and IEEMB830)
Extended Description
(part 2 of 4)
Module
Label
IEEMB829
WTRINIT
This routine places SMF records in a buffer and
writes the buffer to the recording SMF data set.
Initialization
1
This environment protects the SMF record writing
function by handling abnormal end situations.
2
The data sets SYS1.MANX and SYS1.MANY are
opened (via OPENJ) and one is selected for
recording data.
INITOPEN
3
WRITEMSG
The routine uses a WTO macro instruction to
inform the operator that'SMF is recording.
Note: Modules IEEMB829 and IEEMB830 communicate
with each other via the cross-memory posting facility.
After the initialization phase, module IEEMB829 enters
the wait state, having been set dispatchable (via the
STATUS SVC) by module IEEMB822. When module
IEEMB829 completes its processing, it issues a POST
macro instruction for module IEEMB830, then waits
for the next function to process . .If an error occurs in the
cross-memory posting process, module IEEMB827 gets
control to perform cleanup processing. This eventually
leads to a termination of the SMF function.
Handling Buffer Data
4
This procedure serializes the SMF record processing
resource. (A time stamp is omitted from records
4,5,34,35, and 128-255.)
IEEMB830
IEEMB830
r;n
(D
=
Note: For a record for a HALT (EOD) situation, the
active SMF data set is closed and a switch is made to the
alternate data set.
~
5
a
o·
~
(D
gQ.
o.....
o
't:I
~
6·
=
w
J:..
til
User exits may be specified at initialization. If exits are
specified (via field SMCAOPT), the exit I EFU83 is taken.
USEREXT
"""'-_7
~Diagram
15-1. WritingSMF Recerds(IEEMB&29'and IEEMB830)
,(part 3 of 4)
N
~
'N
1
i
Output
'Process
Input
SMFRecord
~TU:s~ -1
~,....O/ ·6
, _ - - - - - - - - ....
Split
(~ntl recordi! necessary:
.A
-
:>
G }
Record Segmenu
t'"
r
.s
f
CD
w
~
N
Buffer
SMF'Record
SMCABSIZ·~
7
Put SMFrecordin a buffer.
,ua
a) If buffer not full.,
0 .1
.L~
SMF Record
__/
Step 9
User Size
b) If buffer full, continue.
~
r
w
8
~
Write the buffer to the SMF
data set.
,•
If the alternate data set is.
needed, but is unavailable,
&&
;/
SMF DataSet
I I
Step 10
Issuer of
SVC83
EEMB830)
9
'Dequeue off the SM Fbuffer
resource.
New SMF Buffer
10 ' Error:
-Build record type 7 with
a count of the records lost.
Ita
Waits on writer ECB
ilMl
if
I
\::: Record 7
Diagram IS-I. Writing SMF Records (IEEMB829 and IEEMB830) (Part 4 of 4)
Extended Description
Module
Label
Handling Buffer Data (Continued)
6
Record splitting occurs if the record size is greater
than the buffer size. Before splitting a record, the
following steps occur:
IEEMB830
EMPTYBUF
• The SMF buffer is emptied.
• The routine determines whether the number of segments required to hold the record will fit into the
space remaining in the actively-recording data set.
IEEMB829
This assumes that the record size is less than or
equal to the empty buffer size.
SPACECHK
DSWITCH
• The routine switches to the alternate SMF data set if
the current data set lacks the necessary space for the
record. (Record truncating may be necessary if a
, segmented - 'split - record is too large for an empty
SMF data -set.) (See the diagram Switching SMF Data
Sets for data set switching.)
7
SPLITREC
Extended Description
Module
Label
8
IEEMB829
BWRITER
The routine uses a BSAM write mode to transfer
the buffer contents. Before writing, the following
processing occurs:
• A check is made for available space on the currentlyrecording SMF data set.
RECWRITE
• If the current data set lacks space for the record
waiting to be written, data set switching occurs. (See
the diagram Switching SMF Data Sets.)
DSSWITCH
• The routine closes the former (currently active)
'primary' data set and issues a message to have the
operator dump the full data set.
SMFOPEN
.The routine opens the new 'primary' data set.
SMFOPEN
The writing of the buffer occurs if either of the following conditions are true:
IEEMB830
RECPROC
• The current size of the record waiting to be written
is greater than the remaining buffer space. (That is,
the buffer must be emptied before it can hold another
record.)
• A HALT command is being processed and the buffer
contains at least one record.
• After writing the buffer to the recording data set, a
TCLOSE macro instruction is used to close the active
data set for the writing of an end-of-file label that will
preserve any already accumulated data in case a subsequent system failure occurs. The next buffer written to
the same data set will overlay the label and another
TCLOSE action is performed.
fI)
a
~.
:I
~
~
t
o
o"""
"0
~
a
~.
:I
w
~
w
9
This procedure removes the serialization protection
on the buffer resource. (That is, the routine no
longer controls the use of the resource.)
10
Recovery will occur when an SMF data set becomes
available after being dumped and successfully
re-opened.
IEEMB830
!
Diagram 15-2. Switching SMF Data Sets (IEEMB829) (Part I of 4)
CIl
~
oCI'.I
"<
CI'.I
N
CI'.I
'<
=-
9
t""
SMF Writer
(tEEMB829)
Input
r~~W·[]N
Output
~.~
1
C§.
Clo.se the currently active data set.
Issue dump message to operator.
,,
'..",
DCB
"
D
()
t""
CT
8
~
c
a
(I)
w
',
",",,'
t):
~;~
j:;
Open Failure
SMCA
....
~
...
~SMCAPSTA
4
SMCA
Record time/date of failure.
Issue message to operator.
.>~
I"
'.
[Message~
SMCAPSTA
2"
5
~
[
R15
SMCA
to.
v
(D
w
)
5
Update count of last SMF records.
B-SMCADSCT
.\1
16
SMCA
I~
MANX
~
MANY
~
i
~
w
:....
SMCA
·~SMCADSTM
'f
...
..)
6
Build "last data" record and put
it in buffer.
(lEEMB830)
\
I"
Buffer
I
Ij
--r--
SMF Record 07
',,--_7
~:::Y
Diagram IS-2. Switching SMF Data Sets (IEEMB829) (part 4 of 4)
Extended Description
Module
Label
4
IEEMB829
WRITEMSG
If the alternate data set contains data, switching is
prohibited. A WTO message informs the operator and
an indicator is set in the field SMCAPSTA.
5
For each subsequent attempt, beyond the first, to
write an SMF record, the count of lost records is
updated. A return code of 16 indicates the failure to
write a record. The data sets are then switched for the
next attempt.
RECOVERY
6
RECOVERY
SMF data set recovery occurs when a data set is
dumped and successfully opened. At that time,
recording on the data set is possible. The "Iost data"
record includes the count of SMF records lost during
the non-recording time, and it resides in a new SMF
buffer.
CIl
<»
ao·
::s
N
a::
6
~
~
e.
o
"I:S
io·
::s
w
~
....oJ
"'<,--,
~
Diagram 15-3. STAE Exit Processing for SMF (IEEMB82S)
~
Input
00
SMF Writer
(I EEMB829)
Output
~SDWAABCC
i
ea
;, ~.
"
code)
!
1
;
(ABEND completion
r-
..
')
--v
ig
"*~"
......,..
STAEWork
Area
I
R15
~~Q
Dump the storage in response to a
program check entry or a
PSW restart.
l~
Core Dump
Issue operator message.
3
Prompt operator for continuation
response.
"'Y
CVT
h
C3-
'<
fIl
N
"
SMCA
[Message
.
')
'V
1
> ...
CVTSMCA
")
'V
4
"
.
..)
Provide clean up operations after
operator responds "U".
w
~
R1
I
~STAE
'Work Area
~
.,
LMessage
J
l
SMCA
~SMCAUSER
,SMCAMAN
Exit
_ Parameters
[11
I
SDWAPARM
I
Dump
Indicator
"--,
...
2
---""~,.p,~
w
i-S
Process
"'
fIl
N
fIl
:;c
(part 1 of 2)
....
')
,"Y
5
....
Clean up SMF (SVC 83).
')
r'V
1;';
.
~
•
Reason Code
ToRTM
SMCA
~SMCABECB
-
,-
'--~
Diagram 15-3. STAE Exit Processing for SMF (IEEMB825)
Extended Description
(part 2 of 2)
Module
This routine provides clean up processing for abnormal
end situations that occur during SMF writer processing.
(The same routine handles ABEND occurrences during SMF
initialization - see the publication, OSNS2 System Ini-
tialization Logic.
1
The SVC Dump service (via the SDUMP macro instruction) provides this function. Register 15 = 0 indicates
a successful dump.
IEEMB825
2
A WTO macro instruction issued to the operator indicates the ABEND completion code, the existence of a
termination condition, and an indication of a successful
dump (if R 15 = 0).
3
The message (step 2) prompts the operator to respond
with a "u" or a re-IPL. Until he responds with a "U",
other job terminations are suspended. A non-"U" response
results in a reprompting.
4
The routine frees the SMF buffers and frees the DCB
storage. The recording flags in the SMCA are also set
to zero.
5
~
a
§'
~
~
~
5'
~
o
'"0)
o
~
~
5'
=
w
J:,.
~
\0
If the reason code (see step 2) is 0, the STAE routine is operating for the SMF writer and the
SMF SVC (83) routine must be cleaned up. The routine
issues a conditional ENO macro instruction for the SMF
buffer resource cleanup. The writer routine must then
post the SVC routine before the SVC routine can continue.
(The flag SMCABECB carries the posted indication.) If
the ENO is not obtained, the SVC routine is not waiting
for the SMF writer routine to complete the function that
failed and the buffer resource cleanup is unnecessary.
IEEMB825
Label
i
Diagram 15-4. SMF Cross-Memory POST Error Exit (IEEMB827) (part 1 of 2)
SMF STAE
(lEEMB825)
or
SMF Writer
(lEEMB829)
i
~
w
1
i
Input
R1
t)
~
~
1
Serialize a save area.
2
Determine SMF activity.
~
~
SMCA
J
CD
w
~
i
I
BSMCAMAN
SMF not active.
I I
Step 4
I I
Step 5
RO
D-.
3
Abnormally end the SM F writer
function.
4
Abnormally end the task that is
currently waiting for ECB to be
posted.
5
Release the save area resource.
w
,:,
Dispatcher
(lEAVEDSO)
j'
~C:JT
Diagram 154. SMF Cross-Memory POST Error Exit (IEEMB827) (part 2 of 2)
Extended Description
Module
This routin~ handles the abnormal ending of the
SMF cross-memory posting function.
1
Routine gets a iocal lock to serialize the resource in
the ASCB extension. This routine was entered to
handle a failure in the SMF Writer (module IEEMB829).
2
If SMF recording is inactive, the failure occurred
when the SMF STAE routine (lEEMB82S) posted
the SVC 83 routine after an abnormal end situation
occurred in the SMF writer routine.
If SMF recording is active, the failure occurred either
when the SMF Recording (SVC 83) routine posted the
SMF writer routine or when the writer routine posted
the SVC 83 routine.
3
The routine issues a CALLRTM macro instruction.
This causes the SMF STAE routine to receive control to stop the system's SMF function.
4
This routine was entered from the SMF STAE
routine (lEEMB82S). The routine issues a
CALLRTM macro instruction to set up an ABEND for
the current task that is waiting in the SMF recording
(SVC 83) routine.
5
~
g
g.
::t
!'t
iC
a-
S
Co
o
....
o
'C
;
g.
::t
w
~
-
The routine releases the local lock.
IEEMB827
Label
'-
_7
3-462
OS/VS2 System Logic Library Volume 3 (VS2 Release 3.7)
System Log
The system log provides a record of system
activity. The log function handles the logging of
messages from a system operator, from user
routines, and from the operating system routines.
All MVS systems contain the log function. Previous
systems had to request the log function as a
SYSGEN option. Now, after the job entry
subsystem (JES2) is active, module IEEVWAIT (the
master scheduler wait routine) automatically
attaches the system log task. The system procedure
library (SYS 1.LINKLIB) contains the process
defining the initialization of the system log. After
the system log data set is open, it may receive
messages 'resulting from a WTL macro instruction or
a LOG command. When a given data set is full
(based on a limit value previously supplied in the
parameter library member IEASYSXX), a new log
data set is obtained.
For MVS systems, the log task operates in the
master scheduler's region and has its own job
identification. To replace the system data sets
(SYS1.LOGX and SYS1.LOGY) used in previous
systems, the log task dynamically produc,es
internally-created data sets which the job entry
subsystem (JES2) and JES3 processes as output data
sets.
For MVS, a WRITELOG command with the
START operand causes reactivation of the system
log should the log become inactive due to system
failure or the issuance of a WRITE LOG CLOSE
command. A re-IPL procedure is unnecessary.
In order to close a system log that is also the
system hardcopy device, it is necessary for an
operator to issue a VAR Y command to re-define the
hardcopy device. Then the operator may close the
log by issuing a WRITE LOG CLOSE command.
Users communicate with the system log through
the use of the WTL (Write-to-Log) macro
instruction and the commands LOG and
WRITELOG. The WTL macro instruction (which
results in an SVC 36 instruction) is used to
schedule the entering of information into the log.
To enter information into the system log from an
operator's console, a user issues a LOG command.
By using a WRITELOG command, a user may
request the closing of the currently recording log
data set (with subsequent queueing of the data set
to a SYSOUT writer). If the system log is acting as
the hardcopy log, write-to-operator/reply
(WTO/WTOR) messages and the system and
operator LOG and WRITELOG commands with their
responses may be entered on the system log.
Depending on the source of the message or
command, either the communications task or the
command scheduler (SVC 34) routines convert the
message/command into a Write-to-Log macro
instruction in order to enter it into the system log.
Section 2: Method of Operation 3-463
3-464
OS!VS2 System Logic Library Volume 3 (VS2 Release 3.7)
~
"----.7
""----"
The System Log
(no diagram)
System Log
Initialization
Terminating the
System Log
Switching Log
Data Sets
Log Writer
Processing
(J EEMB803).
(JEEMB803)
(lEEMB803)
(lEEMB803)
Figure 2-30. System- Log Visual Contents
c;n
tD
54
e·
=
~
ac
~
[
o
~
o
";
g.
=
eM
~
U\
Processing Log
Task AbnormalTermination
Writing Data
on the
System Log
(lEEMB806)
(JEEMB804l
~
~
Diagram 16.. 1. System Log Initialization (IEEM8803) (part I of 4)
Initial Entry at
IPL from Master
Scheduler Wait
Routine (lEEVWAIT).
Subsequent Entry from
Terminating the system log
(lEEMB803) - Process
o
Ie
~
N
...
rn
'<
=a
i
t""
Input
"
CVT
cr
!
~
c::a--V""
BASEA
~
...
y
> 1
2
MSLOGIPL
w
' 5
, Y
Initialize job entry subsystem
blocks.
"
},
....
I
I
SSOB
I~
Y
:
JSCB
~
».".
~:'
"
TCB
I
. ' .:, . , . <
D
, . .> 6
...
Assign job 10 to log task.
I
,Y
Y
55IB
~JOBID
I
,,",Y,"'P',
.
'
t
",,>
I
I
~ ~
¥tRfif.i&x.1t0
»",~>. "~~',
~
~ ,f''--y
_:l~~~.·ffi
• ECB for WRITELOG CLOSE
"
I
I
-'"
Obtain and initialize storage.
Verify user IPL parameters.
~
"'
I
I
....
Et
'0$,
Allocation Parameter Area
{MSLOGCLS }
I
I
WTLQueue
"
I
I
DD
~
.'
~
II
crT\
f
Output
""
.'
'-----'
~
Diagram 16-1. System Log Initialization (IEEMBS03) (Part 2 of 4)
Extended Description
Module
Label
IEEMB803
IEEMB803
This routine initializes the system log; opens and
closes the log data set; writes information to the log
data set; and shuts down the system log.
1
Entrance is either IPL-initiated or via WRITELOG.
(For WRITELOG, the log is waiting on a POST macro
instruction.)
2
The EST AE routine will handle abnormal (error)
situations.
3
The routine waits for indication that a WRITELOG
ST ART command is ready to be executed.
4
Parameters LOGMT and LOGCLS refer to WTL
number and output class. They are in the PARMLIB
member. The format of the allocation parameter list
(used when terminating the system log) is as follows:
tSYSOUT class
Ddname of log data set to be unallocated
5
6
~
~
::I
N
ac:
S1
5'
Q.
Q
o"""
I
5'
::I
w
~
....,
IEEMB805
LOGPVRTN
4
4
Storage comes from subpool 0 (LSOA).
This permits JES2 to process the log data sets as
SYSOUT data sets. The macro instruction IEFSSREO
causes JES2 to be invoked for this purpose.
5"
LOGSTART
GETCBLKS
'-~
i
~
w
Diagram 16-1. System Log Initialization (lEEMB803) (part 3 of 4)
Input
Output
Process
i
i
t:
~
~
7
Establish ACB and RPL;
Initialize allocation parameter list.
8
Allocate SYSOUT data set for
log output.
9
Open log data set.
• If error, write message.
~
E'
!I
(D
w
'<
fI)
w
i-II'"
BASEA
~BALOG
10
Activate log if it was inactive.
11
Issue waits for log ECBs.
12
Check the posted ECB and
process accordingly.
I I
WTO Message
log
Termination
(lEEMB803)
w
:..,
From Log Data
Set Switcher
(lEEMB803) or
from Log Writer
(IEEMB803)
13
.
Diagram Terminating
. . . the System log
•
For Log termination ..
•
For Data set switching.
Diagram Switching
Log Data Sets
•
For Log writer.
Diagram Log Writer
Processing
For ESTAE/ABEND (error)
situations see the diagram
Processing Log Task Abnormal
Termination.
Processing Log Task Abnormal
Termination (lEEMB806)
I
___ ,>-7
Diagram 16-1. System Log Initialization (IEEMBS03)
(part 4
Extended Description
Module
Label
7
I EEMB803
ACBINIT
RPLINIT
IEEMB803
OPENRTN
VSAM routines use the access control block (ACB)
information to build a DCB. The log writer uses the
request parameter list (RPL).
8
The routine issues SVC 99 for this allocation function.
9
Use an access control block "open".
a. Error routine writes message.
10
Post the communications task.
11
The log function to be performed determines the
routine that may post the ECB.
12
Module IEEMB803 contains subroutines to perform
each task.
• Log termination: IEEMB804
IEE1603D
IEE70110
JES2 processing
• Switching log data sets: I E EM 8804
IEE1603D
• Log writer: IEEMB804
13
ie·
::s
~
rc
~
0-
o....
o
1
i
e·
::s
CN
~
\Q
The abnormal end situations are handled by the
EST AE routine.
of 4)
IEEMB807
NEWLOG
CHKPOST
IEEM8803
LOGTERM
SWITCHDS
WTLREC
?
;
Diagram 16-2. Terminating the System Log (IEEMB803) (part 1 of 2)
c:>
Diagram System
Log Initialization,
Step 12
otil
"<
til
t-J
til
Input
'<
=-
~
~
1
Deactivate the log function.
2
Issue WAIT to clean up any
executing Write-to- Log
situations (indicated by
MSLOGSVC :/: 0).
3
Close and unallocate the log
data set.
4
Release log data set 10.
5
Release all storage obtained for
this process.
~.
r~
~
Purged Queue
~
c
WTLQueue
a
I
(D
w
~t-J
~
r
~
w
~
B
Allocation
Parameter Area
(See Diagram System
Log Initialization)
I
I
WTO Message
I
I
55IB
~JOBID
* LCA Fields Referenced
LCACBONE}
LCACBTWO
Closed Log Data Set
ACB Addresses
LCADDONE} Current Log Data
LCADDTWO
Set DO Names
6
Set up for reactivation of the l o g . .
Diagram System Log
Initialization, Step 1
VI,'
U
~
Diagram 16-2. Terminating the System Log (lEEMBS03) (Part 2 of 2)
Extended Description
Module
Label
SHUTDOWN
This routine closes the system log.
1
Set BALOG field to zero. Issue a POST macro
instruction to the Communications task.
IEEMB803
2
The last WTL will post the wait condition.
IEEMB803
The WTL queue is emptied by writing to the log data
WTLREC
PUTREC
set.
3
4
Unallocation may fail, in which case the error routine
receives control.
IEEMB803
CLOSRTN
UNALLOC
FRESUBS
This job I D was assigned by the job entry subsystem
and is now released by JES2 or JES3.
f:Il
a
!So
::I
~
~
~
[
o....
o
"CS
(D
t.1
....
o·::I
1M
J.
....
5
The routine uses a FREEMAIN macro instruction.
6
A WAIT is issued for a WRITELOG START command.
WTLCLOSE
IEEMB803
LOGSTART
~
.....
N
Diagram 16-3. Switching Log Data Sets (IEEMB803) (Part 1 0(2)
o
en
~
Input
Diagram System
Log Initialization
Step 12
Output
U
N
en
~
;
i
f!j.
r-
1
;:
~
Allocate and open another
(new) log data set.
Message
I
a) If unsuccessful:
-<
o
c
ao
w
~
N
~
Log Data Set
Diagram
System Log
Initialization
Step 11
If step 1 is successful:
2
iI
Close and dynamically unallocate
the current (old) log data set.
Message
w
a) If unsuccessful:
~
Diagram
System Log
Initialization
Step 11
If step 2 is successful:
3
Issue successful allocation
message.
Diagram
System Log
Initialization
Step 11
Message
~
Diagram 16-3. Switching Log Data Sets (IEEMB803)· (part 20f2)
Extended Description
Module
Label
This routine switches log data sets when the currently
recording set is full.
IEEMB803
SWITCHDS
1
This will be done after a specified limit of write-to-Iog
commands have been executed 'or after. an operator
issues a WRITELOG command ..
IEEMB803
ALLOCRTN
OPENRTN
a. Issue write-to-operator message. Continue to use existing
log data set.
IEEMB807
2
Write-to-operator message. An unallocation failure may
occur before the log data set is queued to an output
class. This may result in a loss of data.
IEEMB807
3
IEEMB803
The routine was able to close the system log data set
and queue it to a SYSOUT class, for disposition by
JES. Message is issued by IEEMB807.
l"'-I
a
~.
::s
~
a:
~
~
So
o
"C
I
~.
::s
w
~
....,
w
CLOSERTN
UNALLOC
J;:
Diagrani- 164. Log Writer Processing (IEEMB803) (Part 1 of 2)
~
~
Diagram System
Log Initialization
Step 12
o
fIl
"<
fIl
W
ii
n'
r-
Input
RPLDACB
(fASCB)
I
1- RPLAREA
"""--OJ"'"
(+Message)
f
~
~
Output
~ LogDa~~1
RPLRLEN
(Message Length)
;r
a
(II
~
'
1
Determine type of entry.
R1
~ Parameter List
Chain for Deferred Restart
, JCT
SCT
SlOT
JFCB
m~~
:
:>
:
: >3
:
:: >
2
....
)
Set up parameter list for dynamic
allocation's use.
y
pointer for Automatic Restart
C'-l
~
~
i
~
w
:...t
-
Initiator's
JSCB
I
Active
.JSCB
~""'"------'_T
DCB
~SYSCHK
ECBLlST
I
:t::
4
Open the checkpoint data set.
5
Wait for posted,ECB.
Complete
~
y
cancel
§f
D~namically allocate the check-"']
data set.
•
~
SCT
PGMNAME
~~
II
.. .ty
[
",';;:.
6
Vb"
!-
MI
!
POI nt
If the restart is cancelled, free
the checkpoint data set.
Change program name to
tEFRSTRT.
,~
I
~
"'Diagram
17~L.Ptocessing·Data.·Set
Descriptor Records (IEf'XB609)
Extended Description
Module
(part 2 of6)
Label
o
The field LCTRFDBC indicates whether the entry
is 'for ·automaticrestart .or deferred restart.
IEFXB609
SETUP
If the dynamic allocation fails, the DAIRFAIL routine
(WTP) indicating the nature of the failure.
ALOCCHEK
If VSAM private catalogs exist, they are allocated to
ensure proper catalog search during DSDR merge
processi ng .
IEFXB609
4
IEFXB609
The routine attaches the module IEFXB610 to open
the data set. Then it waits on the ECBs (see step 5).
=
~
a::
a
S
Q.
o....
o
"tS
o·~
=
w
J.
00
.......
<:
CI'.I
N
00
0
The ECBsindicate either successful 'open' processingor an external job cancellation during the
'open' processing.
OPENCHEK
O'PENCHEK
If cancelling occurs, the routir:'e posts the subtask,
(lEFXB610) that was to open the checkpoint data set.
This permits module IEFXB610 to terminate its
processing.
The program name is that of the restart program
that issues the SVC REST ART to cause data sets
to be repositioned.
CI'.I
ALOCAT
0
W
5
6
a
o·
ALOCCHEK
The routine issues,the DYNALLOCmacro instruction (via SVC 99). Prior to issuing the macro instruction, the routine sets the initiator's JSCB to point to itself
as the active JSCB. This permits dynamic allocation routines to use the initiator's SWA. After the checkpoint data
set is allocated, IEFXB609 resets the pointer so the active
(I KJEFFIS) is invoked to issue a write to programmer
.If the entry is for deferred restart, interpreter routines
. have created the control blocks for the step. Control
,block. pointers will .Iocate the JFCB for the checkpoint
data set to be dynamically allocated.
Dynamic allocation routines use this list; which contains information from the JFCB. Entries in the
parameter list include the ddname (SYSCHK), the
data set name (DSNAME), the volume serial number,
and the unit specification.
Label
JSCB pointer indicates the problem program's SWA.
• If the entry is for automatic restart, the JCT contains
the virtual address of the JFCB used for the checkPQint data set. The SWA merge routine (lEFXB601) has
already merged the job journal to the SWA. The JFCB
information will be used in dynamically allocating the
checkpoint data set.
2
Module
3
This routine·.processes theSWA information in the
checkpoint data set DSDR recorduo that the SWA
entries reflect the checkpoint environment.
'1
Extended Description
IEFXB609
RNAMEPGM
~
Diagram 17-1. Processing Data Set Descriptor Records (IEFX8609)
(part ),of6)
00
~
N
Process
Input
Output
C"I.)
1
9
i
t-
ez
!<
=
a
.
SWA
A~DSDRg
l2J ~
DSENG
7
Process DDname table (DDNT)
entry/entries in the checkpoint
data set.
_
~
~
N
Q
~
00
Table
.---,
L-J
DSDR
c:::JCJ
r-
..JI
L _
=:;;;.
DSDR
IpI::J1 ~I
j. ~DDNT ~l
SWA
SCTDDN;
Checkpoint
Data Set
·0
(D
_ ,/
Ii
For matdling DDnames, m e r g e .
the fields to the SlOT and JFCB.
s
;:> I~
seT
9 For unmatched DO names,
rechain the unmatched SlOT
to the end of the chain.
_ _."I~Step8
More SlOTs to check.
SlOT
~f
~
Diagram 17-1. Processing Data Set Descriptor Records (IEFXB609)
Extended Description
Module
7
IEFXB609
Prior to processing the ddname table, the routine
processes the checkpoint header record (CHR) and
saves the CHR for the restart parameter list.
Number of
checkpoints taken
21
DDNTPROC
10 of checkpoint data set entry
16
Ddname of chElCkpoint data set
Beginning (low order) address of
problem program storage
4
Size of problem program area
4
Checkpoint data set
user's blocksize
Flagbyte 1* 1
21
8
t
til
(D
2-
5'
=
N
a(
(D
g
Q.
o....
o
~
(D
;
g.
=
~
ct
\C
X'40'
X'20'
X'08'
X'02'
X'Ol'
**Flagbyte 2
X'04'
Other than
X'04'
196
21
-
JFCB at checkpoint time
8
DDnames from TIOT (or from SlOT if
the entry is dynamically concatenated)
SCT fields (from SIOT)**
DEB volume
4
8
CHR identifier
*Flagbyte 1
Identifier
-
3
19
Meaning
Track overflow is specified.
Checkpoint data set is on tape.
Task is in real storage (that is, request is V = R).
Checkpoint modules opened the checkpoint data set.
The checkpoint is using (was opened for) BPAM.
Meaning
A user has suppl ied the checkpoint data set entry.
The operating system supplied the checkpoint data set entry.
The DDNT contains ddnames for all JCL-specified data
sets dynamically unallocated prior to the checkpoint. The
routine insures that alloCation for these data sets does not
occur at restart time.
DDNTSIOT
The first available SlOT in the SWA is obtained. Then,
the module matches the ddname in the SlOT with the
ddname field in the DSDR being processed. The format of
the DSDR appears below.
4
Unittype(s) descriptors
Unused
Label
8
3
Checkpoint work area
1\
Module
The module places the DDNT record in the SWA. After
all DDNTs are processed, they are chained together in
the SWA. The module also updates the SlOT chain and
the DSENO table. The updated data set enqueue
(DSENO) table reflects data set changes resulting from
dynamic allocation processing.
2
SVRB used by checkpoint routines
System 10
Extended Description
TIOT length
Checkpoint work area size
Flagbyte 2** 1
t
2
Length of checkpoint
data set entry's 10
(part 4 of 6)
Label
The format of the checkpoint header record (CHR)
appears below. (The OSNS2 Checkpoint/Restart Logic
publication, Form SY26-3820, contains further information about the CHRJ
~
~quence
31
flags
1
1\
Meaning
Data set dynamically allocated (from DSAB)
Data set dynamically concatenated (from
6
DSAB)
Data set was open at checkpoint time
5
0-4
reserved
**SCT fields (1 byte each) in order from low to high block location.
Status field from SlOT; Disposition field from SlOT;
Conditional disposition field from SlOT
*Flag Bit
7
Status and data set disposition fields are merged from the
DSDR to the SlOT. Non-volume information is moved
from the "DSDR to the JFCB in the SWA. Volume information (for example, VOLSERs) is conditionally moved to the
JFCBto reflect the SWA environment at checkpoint time.
SIOTPROC
JFCBPROC
VOLSERS
JFCBXJOB
The DEB volume sequence field of the DSDR is used
by the checkpoint data set utility to obtain the correct
volume of a multiple volume data set.
9
By putting unmatched SlOTs at the end of the chain,
the final order of the SlOT chain will be that of the
DSDRs on the checkpoint data set. For deferred restarts, a
SIOT/JFCB pair is built for a dynamically-allocated data set.
IEFXB609
NOMATCH
t
Diagram 17-1. Processing Data Set Descriptor Records (IEFXB609) (Part S of6)
8
~
N
I
,i
Process
Input
Output
SlOT Chain
r-;:-
~.
r-
f
~
~
SCT
FSIOT
a-
a
G
!!WI
M
"\.
10
LSIOT
w
~N
t
-
After all DSDRs have been processed
for the remaining unprocessed
SlOTs:
a. For automatic restart, remove
SIOT(s) from SlOT main.
b. For deferred restart, leave
SIOT(s) on chain.
I
Same as Input
w
:....
SCT
SCTX
I~R
il!!!!I
w;
''\.
11
Set the checkpoint data set for
a restart.
SWA Reconstruct
(lEFIB605)
SCTX
~p.rameter List
""-c:.Y"
Diagram 17-1. Processing Data Set Descriptor Records (IEFXB609)
Extended Description
CIl
N
a::
~
Q.
o
"'"
o
~
!o·
::s
w
~
~
Label
10
These SlOTs are the ones remaining on the SlOT
chain after all DSDRs have been processed.
a) 'Automatic restart' SlOTs are those created dynamically
after the checkpoint was taken. They are deleted so the
user can re-allocate them.
b) 'Deferred restart' SlOTs represent DO cards added to the
JCL input stream when the job was resubmitted. The
number of DDs is updated to reflect these SlOTs.
LEFTOVER
11
SCTXPROC
RNAMEPGM
The routine sets up a parameter list for the restart
SVC. The list contains the TTR of the core image
record (CIR) on the checkpoint data set and checkpoint
header record information. To pass the list to the restart
SVC, the routine uses the SCTX control block.
it
o·
::s
Module
(part 6 of 6)
~
Diagram 17-2. Job Journal to SWA Merging (lEFXB60I) (Part 1 of 2)
N
~
~
N
C'Il
'<
f4.
~
SWA Reconstruct
(lEFIB605)
Input
R1
~e~rt
~
n~
l"""
~
a
MEL
~~)~~~----I
l"""
J
Output
Indicator
1
Determine type of restart and do
either step 2, 3,4, or 5. Then
do steps 6 -9.
2
For system restart:
Diagram, System Restart Processing
3
For step continue processing:
Diagram, Step Continue Processing
4
For automatic checkpoint restart:
Diagram, Automatic Checkpoint Restart
5
For automatic step restart:
Diagram, Automatic Step Restart
6
Process non-SWA control blocks
if system, automatic checkpoint
restart, or step continue.
Diagrams, System Restart Processing or
Automatic Checkpoint Restart
Step Continue Processing
7
Update chaining fields in SWA.
Diagram, Updating the Virtual Addresses in SWA
8
Error processing.
Diagram, Journal Merge Error Processing
9
Free resources.
Diagram, Merge Cleanup
See Appropriate Diagrams
Location 16
(D
w
'<
C'Il
TCB
N
~
i
~
w
~
* The CVT actually points to a
double word, the last half of
which points to the TeB.
SWA Reconstruct
(lEFIB605)
or
~
Diagram 17-2. Job Journal to SWA Merging (IEFXB60 1) (Part 2 of 2)
Extended Description
Module
Label
This routine reconstructs the SWA (from the job
journal) so it has the control blocks in effect at the
Extended Description
Module
3, 4, 5
time indicated:
• For automatic checkpoint restart: Control blocks at time
checkpoint was taken.
For each case, a full merge of the control blocks
for the non-failing steps is performed, and selective merging of fields in critical control blocks for the failing step is performed.
SYSMERGE
CKPTMRGE
STEPMRGE
6
VATPUT
VAMPROC
For each non-SWA control block on the job journal,
an appropriate exit routine performs the required
processing.
• For automatic step restart: Control blocks at beginning of
the failing step.
Label
• For system failure: Control blocks at the point of failure.
7
The routine updates the SWA control block chaining
fields to reflect the new virtual addresses reSUlting
from the SWA reconstruction.
This diagram refers to several other diagrams covering the
checkpoint/restart functions. Each of the latter diagrams
represents a subroutine (within module IEFXB601) that has
a given function to-perform. This present diagram contains
general module entry-information that is also applicable to
these subsequent diagrams. (See also, the introduction to
this section.)
1
In the 6th byte of the merge entrance list (MEL) contains the restart indicator as follows:
X'OS' = system restart
X'20' = step continue
X'40' = automatic checkpoint restart
X'SO' = automatic step restart
The MEL also contains the address of the LCT (in the first
word) and the failing step's number (in the last two bytes).
2
fI)
!t
e'
~
~
a:
t
Sa
o
'C
S
g.
~
~
w
For this case, a full merge of all control blocks for all
steps is performed.
8
The Routine sets a return code of X'24' in register 15
and sends an appropriate message to the programmer
and/or the operator.
IEFXB601
IEFXB601
SYSMERGE
9
The routine releases the virtual address table and any
extensions to it.
Note: There is one entry in the virtual address table (V AT)
for each control block that the interpreter writes to the
SWA. This entry points to the 16-byte prefix to the control
block. When dynamic allocation routines cause the SWA's
control block structure (that is, the relative control block
addresses) to change during restart, the VAT updating
routines insert the new control block addresses (of other
journalled control blocks) into the appropriate fields of the
control blocks in the SWA.
IEFXB601
ADDRUPDT
ERRPROC
~
~
Diagram 17·3. Step Continue Processing (IEFXB60 I) (Part 1 of 2)
J
•
~
~
N
Job Journal to
SWA Merging
(I EFXB601)
Input
Process
Output
f'-I
'<
~
a
i
Failing step's
number
r~
1
Merge the journal entries for each
step onto the SWA in the
manner shown for system restart.
(see Diagram System Restart
Prooessin!;lJ
2
Replace the JCT pointer to the first
step's SCT with the SCT pointer
in the failing step's SCT .
~
~
c
a
JCT
(D
~
(For failing
step)
-<
f'-I
N
~
i
~
. SCT
~
~
SCTANSCT
(lEFXB601)
.
%&I
. ;/
14M
SCT (Restarting step)
----,
Diagram 17-3. Step Continue Processing (IEFX8601) (Part 2 of 2)
Extended Description
Module
Label
IEFXB601
SYSMERGE
This routine handles the processing that allows a
user's job to continue at the next step.
1
This processing occurs when a step was being terminated at the time a system failure occurred. Since the
job journal entries are complete, they are processed in the
same manner as for system restarts.
2
step.
til
a
5·
:s
~
~
~
&:
So
1
i3
g.
:s
w
~
VI
By resetting the JeT pointer (to the SCT), the
restart will occur at the job step following the failing
CLEANUP
!
Diagram 17-4. System Restart Processing (IEFX8601)
(part 1 of 2)
\Q
~
~
~
W
fIl
l
~
iro&
8
~
=
a
Job Journal to
SWA Merging
U'.... -
Input
UEFXB601)
" I i liUillin.J. . ._ _. .
Daughter
JSCB
Virtual Address
Table (VAT)
It=i]wffd1'
t
Process
·iin}=
•.
~=_!FJ'!I!l"n.;n:.Z;;;=
. =',:l!!'!!m::!m.
lli1!mn.!m.rr~'lI:!m.~="
.
!!I!atJn!m:.:m.na='!'!"jTilq"'!!!:,i!!l:t!m,_rr':!Ir:
Zl",!Ir!Ir,.n:!m;*I_
1
Check SWA for the control blocks
corresponding to the ones read from
the job journal. Look for matching
entries.
2
For a match, update the V AT entry
and overlay the control block i n .
SWA with the journal version of
the block.
entry
Output
JSCBVATA
(II
w
m"
til V ....------I,
<
fIl
W
i
R
w
~
3
Job Journal
~
~
Control block
RBN in record's
prefix
4
VIObIOCk
::: Prefix
-..&..I_(_~~_-----,
f~
!WI
'eW"
Job journal
R1
Job Journal
-
If the SWA lacks a block _ _ __
corresponding to a job journal block,
a specific 'assign' is performed.
Update the VAT to reflect the new
block's entry. Write the block to
the SWA.
·
5
For non-SWA (for example, VIO)
control blocks on the job journal,
create new entry in VAT and give
control to the non-SWA merge
routine.
Update block's VAT entry after
non-SWA merge.
WIll
I%t "'-
Parameter List
4 Block
»
VAT
B lock address
VATNVA
VA_T----I
1--1
:SCBVATA
(lEFXB601 )
Diagram 17-4. System Restart Processing (IEFX8601)
Extended Description
(part 2 of 2)
Module
Label
For a system restart, all control blocks for all steps
in a job will be fully merged from the job journal to
the SWA. (See also the diagrams Merge Cleanup and
Updating the Virtual Addresses in SWAJ
1
The SWA prefix (in the block) contains journal
record identifications. The V AT contains representations of all blocks in the SWA. The relative block number (RBN) and block 10 fields in the SWA prefix (for the
block on the journal) are matched against entries in the
VAT.
t Block being merged
of block
11 Length
being merged
IEFXB601
f:'-I
~
o·
=
~
ac
[
Q
~
o
"0
~o·
::I
w
~
IC
'-01
VATPUT
3
4
New virtual address* *
4
4
*The block 10 field has the following meanings:
Block 10 Control Block
VATPUT
FLOMERGE
3
ASGNRITE
The subroutine uses an interface parameter list to obtain
the merge information.
Label
4
Relative block number
t GETMAIN storage area***
X'FE'
Data set page control
table (OSPCT) header
VIO Routine
Performing the Merge
Virtual Block
Processor (VBP)
Virtual data set
Window Intercept (WI)
control block (VOSCB)
**The new virtual address is that passed to the
appropriate V 10 merge routine for all except the first
occurrence of the control block on the job journal.
X'FC'
The SWA manager assign routine uses the 'assign'
function in the IEFQMREQ macro instruction to get
storage for control blocks initially created by allocation
routines and JFCB housekeeping routines. The assign routine uses the RBN in the block prefix. An entry for the
new block is made in the VAT, and the corresponding
block is written to the SWA.
(D
Module
10 of block
being merged*
If the RBN and 10 fields of the prefix match those
in the VAT, the old virtual address is placed in the
VAT entry and the job journal form of the control block
overlays the corresponding form in the SWA. (In the
'output' part of this diagram, the SCT is used as an
example.)
Based on the control block's 10 (in the block prefix)
the journal merge routine creates a new entry in the
VAT and fills in the R BN, control block 10, and the old
virtual address. The merge routine then calls a subroutine
(lOOWIMRG or IDAVBPJ2) to merge the block to the
SWA.
Extended Description
The parameter list used for this appears as follows:
2
4
': __7
,,~
~
***The GETMAIN area address is passed back to the
journal merge routine by a VIO merge routine when
the VIO merge routine issues a GETMAIN macro
instruction for the block to be merged.
All merges subsequent to the first one (for this non-SWA
block) use this information.
IEFXB601
VATPUT
VAMPROC
The control block's 10 given in the block prefix is compared against an internal table of block IDs in the SWA to
determine if the block (on the journal) is also in SWA.
The journal version of the block overlays the block as it
resides in storage. After the block has been updated, the
pointer fields in the block and the block's address (as given
in the VAT) are updated.
5
The information returned from the non-SWA merge
routine indicates the location of the merged control
block. This address is placed in the block's VAT entry.
VAMPROC
VATPUT
i
Diagram 17-S.Automatic Checkpoint Restart (IEFXB601) (Part 1 of 2)
~...,
Also,. see Input for the Diagram Step Continue
Processing
i
it:
2"
.5
~
r
o
·eM
'
,
t - - -.......",-
APLABAA
:
:>
;
For the failing step, read the control
block records from the job journal
to find critical- information blocks.
Update VAT entries.
4
Selectively merge the failing step's
control blocks.
5
Restore blocks created by dynamic
allocation routines. Create VAT
entries.
6
Output
Job Journal
::~
L
:','. "
, Ii"
*I V
\...J
-
Aeconstructed
1-----
............
• .. SWA
Job Journal
r::.
Merge nOI1-SWA blocks.
Point where
..
checkpoint was taken
7
Reposition both the job journal d a t a :
set and system message data set.~·
::
f¥£
>
\
~ .~
\.........
Y
.......
~
----
Also done for System Message
Data Set.
~ This is the ABA for
the JCT that is
written by the
checkpoint SVC
(lEFXB601)
)
'----,'
\'-_/
Diagram 17-5. Automatic Checkpoint Restart (IEFXB601)
Extended Description
(part 2
Module
,~
of 2)
Label
This routine merges control blocks from the job
journal to the 5WA for failed jobs that are eligible
for an automatic checkpoint restart (checked via indicator
in MEL). See also Diagrams, Merge Cleanup and Updating
the Virtual Addresses in SWA.
1
Compare the step number in the step header record
with the step number in the MEL. For a step header
record, the SWPID field of the block prefix is X'CO'.
2
IEFXB601
See the Diagram, System Restart Processing for
processing of steps prior to the failing step.
<:
tf.l
~
3
For example, the checkpoint and job statu~ information fields of the JCT, the volume and label information fields of the JFCB, and the chain pointer fields of the
SCT, SlOT, and JFCB. In addition, the routine updates the
old virtual address field of the block's entry in the V AT.
CKPTMRGE
VATPUT
4
FLDMERGE
The fields containing the critical information are
merged from the job journal to the SWA.
5
See the Diagram, System Restart Processing for assign
details. The blocks include the SlOTs, JFCBs, JFCBEs, and
JFCBXs created by dynamic allocation and JFCB housekeeping routines. The SWA manager assign and write routines specifically assigns these blocks and writes them to the
SWA. The newly-created VAT entries for these blocks contain the RBN, 10, old virtual address, and new virtual
address.
tf.l
(1)
o
5·
=
N
a::
a
S
~
....
o
o
~
ao·
=
~
.l:..
I.C
I.C
6
7
ASGNRITE
VATPUT
See the Diagram, System Restart Processing, step 3.
From the job control table written by the checkpoint
SVC routine, save the RBA (relative block address)
field for the system message data set. From the journal
RPL (JNL RPL), save the RBA of the JCT written by the
checkpoint SVC.
CKPTMRGE
o
~
00
o
~
Diagram 17-6. Automatic Step Restart (IEFXB601) (part 1 of 2)
8
o
til
~
Job Journal to
SWA Merging
Input
(I EF XB601 )
Output
Process
~
i
r-
~.
a:r-
!<
~
~BIOCk
1
~stepnu.-r
For eadl step header record read
from job journal, dleck for failing
step number.
SWA
MEL
JSCB
.....---
Failing step nu mber ••"-""1t:::t:::.......J
~
(N
'
eN
-
Note: If the step numbers do not match, the step is nonfailing.
00
o
3
The RBA fields saved are for the job journal and the
system message data set. The fields are located in the
step header refords.
For each critical control block associated with the step, the
routine updates the old virtual address field in the VAT.
VATPUT
For example, selective merging involves the following fields
in the indicated blocks:
FLDMERGE
JCT: job status information and restart switches.
JFCB and JFCBX: volume information.
JFCB: MOD data set information for TTR and track
balance considerations.
JFCBE: 3800 printer parameters.
CI)
(D
~
o·
=
N
s::
(D
~
Q.
o
....
o
'0
i0'
=
eN
~
o
4
Pointers are established using the RBAs saved from
the step header record. The pointers show the step's
entry in each data set.
~
s
~
~N
Diagram 17-7. Merge Cleanup (IEFXB60 1) (part 1 of 2)
Job Journal to
SWA Merging
(lEFXB601)
Input
Process
Output
~
i
~
~.
BJCTJSB
JSCB
JCT
1
Update job status byte.
..
.. "
t:
2'
~
~
[
~
~
<
(;I'l
N
b
~
-
Daughter
lor;:§l
JSCBJJSB
2
VAT
D D
SWA
For automatic checkpoint and step
restarts, reposition the job journal
and the system message data sets.
i!!i!!I
-"
SWA
(Updated entries)
3
Free the VAT.
4
Set appropriate return code.
00
S
R15
D
(lEFXB601)
'--_I
"'--_/
Diagram 17-7. Merge Cleanup (IEFX8601) (part 2 0(2)
Extended Description
Module
Label
IEFXB601
CLEANUP
This routine does the clean-up functions for automatic
checkpoint or step restart or for step continue
processi ng.
1
The latest version of this field information comes from
the job journal (the JCT block). The JCT JSB information overlays that in the JSCBJJSB.
2
The relative block addresses used for repositioning
the data sets are obtained from the step header record
for automatic step restart or from the JCT and request
parameter list (APt) for automatic checkpoint restart.
3
4
The VAT and any extensions to it are released.
An error return code of X'24' causes the job to be
purged from the system. A normal return code of
X'OO' permits restart to continue.
CI.l
a
o·
=
~
~
!1
g
Q.
o
100)
o
1g.
=
~
V!
Q
~
'c~
~
Diagram 17-8. Updating the Virtual Addresses in SWA (IEFX8601)
2
&1
"<
CIl
~
~
=a
irs·
t"I
J
~
Job Journal to
SWA Merging
(tEFXB601)
Input
~
I£::3} ~IVAT
v--
VATBLK~
An entry
Process
~
<
Control block
(
;:
•
::;>
":
!"":
'
Determine which control block is
being processed.
>
2
Find the block's location in SWA.
Updated SWA
,
-
CIl
~
f
~
~
;'
I
~
~
1
VATNVA
Merged SWA
and prefix
Output
~"'IE!llElIsnlElIlIlIlIlIlIlIlIlI~1
2'
~
(part 10(2)
Update Information
Table
Displacement of
.
field from beginning
of block.
m:
Length of field.
This table consists of one 2 byte entry
(as shown) for each pointer field
(in the control block) requiring an
( update.
va
::
>3
/
Determine fields to be updated.
/
'
I
I
~I
. '
....
L..-------'hl!!ir*ij.>
4
Replace old virtual addresses (that
is, pointers to other control blocks)
currently in the block being updated
with new addresses from the VAT
based on the reconstructed SWA.
(lEFXB60U
!)
~
Typical
control block
Updated pointer field
y
f
~
Another control
block on SWA
~
~31"
. Diagram 17-8. Updating the Virtual Addresses in SWA (IEFXB60 1)
Extended Description
(part 2 of 2)
Module
Label
IEFXB601
ADDRUPDT
For each entry in the VAT, this routine updates the
virtual address of all the block's fields that are changed.
1
The block 10 field in the VAT contains an indication
of the control block being processed. The routine then
processes consecutively all entries in the VAT.
2
The new virtual address field in the VAT entry for the
block provides the new location in the merged SWA.
The routine then reads the control block being processed.
The SWPID field in the SWA prefix indicates the control
block that is being updated.
3
An internal table contains the necessary update information. This information. includes the displacements
and lengths.of all fields that require updating. There is one
table per control block being updated.
4
For each address to be updated, the value in the new
virtual address field (of the V AT entry for the changed
control block field) replaces the existing old virtual address
field in the control block.
CI.I
(D
()
g.
=
~
a::
a
[
o....
o
"d
(D
io·
,
=
IN
~
~
UPDATE
PTRUPDTE
.-~
/'
/
//
t
Diagram 17-9. JoumaI Merge Reading (lEFXB60 1) (part 1 of 2)
i
Job Journal to
SWA Merging
(lEFXB60U
0
~
N
(I.)
"Process
Input
'i
~
i
JSCB
.-R_PL_ _.--,
I JSCBJNLR
to-
e;:
8
~
~
---- --If. '" 1
r"1_ _ _...,jJLIllOiI%L,j:!\
Read Buffer (JNLBUF)
'"
Read a record from the job
journal.
I
--v
SWA Prefix
Record
--v
tBuffer
~
c
a
Output
RBA
(D
w
'<
;> 2
(I.)
N
iI'"
Job Journal
EJ
w
~
I
RPL
RPLAREA
!J1
SWA Prefix
~3
~ReCOrd I
"
/
\
,
I
I
4
I
I
I
RPL
0
I
A~
:4\
IT,:
JSCBJNLR
RBA
'"
Job Journal
(JHRJRBA
Register 15
1
i
RPL
JSCBFRBA
Read Buffer
/
If the record is a Job Header
Record (JHR), save Its
address in the JSCB.
JSCB
RPLFDBK
4
I
...----'
5
%2)
If the record is a JHR
modified by a restart,
reposition the job journal
to the proper entries.
If an error is encountered
during a GET or POINT
operation, set the return
code to indicate a journal
error .
error:
If no error is encountered,
continue journal merge
processing.
(lEFXB60U
"
V
151
Journal
f)Ositioned to
proper entries
~ based upon
data in
JHRJRBA
field of JHR
ERRPROC
Diagram 17 -9, Journal Merge Reading (IEFXB60 I) (part 2 of 2)
Extended Description
Module
Label
IEFXB601
REAOPROC
This routine is responsible for all reading from the job
journal required for merge processing.
1
A record is read from the job journal using the request
parameter list (RPL) pointed to by the active JSCB
(JSCBJN LR).
2
A job header record has a control block 10 (X'Cl') in
the SWA prefix. Save the address, which was passed
~ck in the RPL, (RPLRBAR) in the active JSCB
(JSCBFRBA) for journal data set repositioning.
3
A job header record written as a result of a restart
contains job journal repositioning information in the
field JHRJRBA. This value is used to issue the POINT macro
to position the job journal to the proper entries.
4
Any non-zero return code in register 15 (other than
a logical error indicating end of file - R15=8,
RPLERRCO=OOO4) is considered an error condition. An
error return code is set and ERRPROC receives control.
(Refer to Journal Merge Error Processing diagram), If
normal return code, journal merge processing is continued.
f'-)
a
e'
=
~
a:
i
~
o
'a
iS'
=
~
til
S
~
///
.~
i
~
Diagram 17-10. ,- Journal Merge Error Processing (IEFXB60 1) (part 1 of 2)
Job Journal to
SWAMerging
(IEFXB601l
Input
Output
N
j
i
Request Parameter
. List (RPL)
~
r-
r
r
G
w
-JSCB
I
V
Return Code
V
X'OS' JES Error
X'04' SWA Error
2
VAT
RCAREA
If JES return code while accessing
job journal is not equal to zero, or
indicates end of file. set the error
return code.
RPLERRCD
~
~
1
code.I]
If interpreter -created control block
is not found in SWA, set return
I,¥it
'<
f'-)
N
'a"
S!-
VATOVA
3
W&i
code.
I
-
If the virtual address being updated
is not found in the VAT, set return
w
:..a
4
For system restart processing, write
message.
5
Fornon-system-restart processing,
write message.
1&
Ftt
a/
'--------I
Console
. Message
JSCB
JSCBJNLE
6· .Set error indicator.
7
Free VAT and extension(s).
:
:
:)
VATX
Free
(tEFXB60U
,_
~
Diagram 17-10. Journal Merge Error Processing (IEFX8601) (part 2 of 2)
Extended Description
Module
Label
IEFXB601
ERRPROC
This processing handles errors that may be encountered
during SWA reconstruction or in accessing the job
journal. It issues an appropriate message and, for either
automatic step or automatic checkpoint restart, it informs
the operator that the job has been cancelled.
1
The return code is set to X '08' .
2
The return code is set to X'04'.
3
The return code is set to X'04'.
4
This message is intended for the programmer and is
written to the SYSOUT data set.
5
The message is written to the programmer via the
SYSOUT data set, and a message is written to the
operator via the WTO macro instruction.
rn
st<5.
~
N
a::
11
S
"""
~
w
u-
~
6
The journal error bit in the JSCB is turned on.
7
The routine releases the VAT resource, and returns a
code of X'24' in register 15.
jT
~~
-------------_ _~telface Processing (IEFXB602) (part I of 2)
I
)
I
...
Interpreter
(JEFVHO)
w
~
~'
fIl
~
a
l""
c2n·
.~a:
l""
R1
OMPA
~
,,
I
/
~
CD
w
<:
fIl
N
:=
~
a~
w
:....
i~EPA,
~
t
I.'.:",. J)
;.>~.
Subsequent entry:
~.~
Ii.".
2
.2.@
...: .':.
Determine
.
fun~::~o
requ
ested
and
make
in VAT.
~~
VAT
~«
A
number of en'"
:;';,?
3
Make initial entries in VAT.
;'~
4
Invoke SWA manager to perform
specified function.
1
l
r"-:>
r.~;~
....
pA
I
t.i,
*
';
""iI
VAT
r---
n:
\~ID
SWA Virtual
address
OMPCL
"1
Ge, storage for virtual address ,able.
0.->
0W
]
\
1
JSCB
....
!>
OMPOP
,,
I
Output
First time entry:
"
,
I
\
OMPCM OMPNC
<
a
,
Process
VATNVA
VATBLKID
~:£}
:. ~::
:::
A~%
2?
OMPOP
SWA
Update
SWA
Updated
EPA
D
VAT
_.1'\
I
SWA prefix for
BLOCK
I
y
5
D
.....
If the SWA manager function is
successful, place more information
in VAT for each entry handled.
y
)
o
R1
6
Pass information to interpreter.
:7:
:~,
1M
~
* If request is other than 'Write' or
'Write Assign', omit steps 3 and 5.
Interpreter
(lEFVHO)
:>
-IC3l-o
OMPA
~
Diagram 17-11. Restart Interface Processing (IEFXB602)
Extended Description
(part 2 of 2)
Module
Label
IEFXB602
VATBUILO
This routine builds a virtual address table (VAT) to be
used by the journal merge routine during SWA reconstruction processing.
1
The VAT is an 800-byte table. The JSCB pointer to
the V AT is constructed.
2
If either a 'write' or a 'write/assign' function is
requested, the routine determines the number of
entries to be made in the VAT after the SWA manager
performs its function.
3
The routine uses the external parameter area (EPA) to
get the SWA virtual address (used for the initial
VATNVA field in the VAT) and the block 10 if one exists.
4
The routine uses the IEFOMREO macro instruction to
give control to module IEFOB550. The operation field,
OMPQP, indicates whether the function is a 'write,' a 'write/
assign,' an 'assign,' or a 'read' operation. The EPA updating
occurs only for a 'write/assign' or an 'assign' operation.
5
The relative block number (RBN) is placed in the VAT
for each entry, and the block 10 field of the V AT is
filled in if not alreadY there.
6
The routine returns control to the interpreter. The
output to the interpreter is the same as the input from
the interpreter but with additional information that was
filled in by the SWA manager routine.
f'-l
g
g.
=
N
at:
~
6'
0S.
o
'C
;
g.
=
w
Q.
CN
U.
Diagram 17-12. Building Step Header Record for Job Journal (IEFXB604)
N
~
Initiator: Step
Initiation (lEFSD162)
Input
N
~
I
i
n
&:
Sf
(D
CN
Output
~ ~~,
JSCB
~
i
Process
-.
Cl)
~
(part 1 of 4)
.
)
,v
,
,- --
....
LCTJCTAD
i
JCTJSBAL
:...
'"")
/"
~ SCT
Step
Number
(SCTSNUMB)
I
.
~
b.
v
I
LCTSCTAD
......
..... -
- _..L_ -
3
restart for a step other than
the first step (step n):
Relative Byte
Address
(RPLRBAR)
'")
v
b.
c.
:«<
Write the JHR and the SHR
for step (n-U, and all blocks
from step 1 up to step n in
the journal.
11
JSCBJRBA
-
/
SHR
~
.--
15
~
"./
Job Journal
~
LJ\
~
Restart Job
Processing
~
~
SHR1\.-/
J
I
~.IJCT
.......".
'--
5
.-/
Job Journal
i'--
'"
-v'
~l
I
1
I
C
~I
Normal Job
Processing or
Deferred
Restart Job
~
Write the SH R for step n
in the journal.
,~
I
Job Journal
Save the RBA of the SHR
for step (n-1).
"",
I
JNLPARM
__h
RPL
V
I I
I
~
~»A:0~~.i•. JJ![.~,:r©{;i~. 'y'if~
Save the Relative Byte
Address (R BA) of the SH R
record.
If this step is a checkpoint
.'
JSCBJNLR
I
Write the Job Header Record
(JHR) and the Step Header
Record (SHR) in the journal.
I
a.
JSCB
I
If this step is the first step of a
normal job in process or the
first step of C! restart job:
a.
I
I
J
S·
CN
2
I
I
JCT
l!
18
"',%
I
~N
I
~SCB
"
m
'" v
LCT
v
SHR
I
Register 1
Register 1
L
1
'"
Check for no job journal or
journal error.
JHR
1- -
VA
.-/
~i,
.-/ ~n-1
'-
JHR-15
"-.
ISHR1/
~
n
""'-----"""
Diagram 17-12. Building Step Header Record for Job Journal (IEFXB604) (part 2 of 4)
Extended Description
Module
1
IEFXB604
Check the JSCBJNLF and JSCBJNLE bits in the
JSCBJJSB field to determine whether there is no
job journal or there is a journal error. Change job state
in the JSCB to "in allocation."
2
If the failing step is the first step of the job or if it
is the first step of a non-restart job, write the JHR
and the SHR in the journal. Set JCTJSBAL to indicate
that the job state is "in allocation", and write the job
control table (JGT) in the journal for all jobs except
automatic checkpoint restart jobs, to record the "in
allocation" status.
3
If the failing step (step n) is any step but the first
step of an automatic checkpoint job, write the
JHR and the SHR for step n-1 in the journal, and all the
control blocks of all previous steps up to but not
including the failing step. This information must be
saved to permit a possible subsequent restart. Finally,
write the SHR for step n in the journal.
~
sa.
5·
::s
~
a::
t
~
So
o
~
!o·
::s
w
c:,.
w
Label
t
•
-
Diagram 17-12. Building Step Header Record for Job Journal (IEFXB604) (part 3 of 4)
pr~~
~
~
N
Input
#.<,' .:~,,<, :6i:. >.<"
f
I
in·
r-
I
~
f
~-
~-----,~
Step
~N
Number
(SCTSNUMB)
i
~
~
I
___
DQ
4
14
Output
:~:
If this is a step restart for any
step but the first step (step n):
I"
...
VI
I
JSCB
JSCBJNLR
RPL
..
Relative Byte
f~:~R~AR)
I
I
...
I
I
I
I
n
I
a.
Write the SHR for step n
in the journal.
I
b.
Write the JHR and the SHR
for step (n-1), and all blocks
from step 1 up to step n in
the journal.
<4)
'\~
~
I
C. Save the RBA of the SHR
for step (n-H.
."
I I
I
L ... _
n-1
Job Journal
d.
5
Write the SHR for step n
in the journal.
~
If this is a non-restart job for
any step but the first step:
a.
Write the SHR for the
current step in the journal.
Register 1
I
Job Journal
I
LCTSCTAD
~
t--
, ". ': ",,' :; A\
~LCT
r--
....
....)
6
Turn off all restart bits in the
linkage control table (LCT).
...
....
~
Restart
Bits
(LCTRFB)
Restart
Bits
(LCTRFB)
Initiator: Step
Initiation (lEFSD162)
Diagram
17-12~
Building Step Header Record for Job Journal (IEFXB604) (Part 4 of 4)
Extended Description
Module
4
IEFXB604
tf the failing step is any step but the first step of a
step restart job, write the SHR for step n, and then
write the JHR and the SHR for step n-1 in the journal.
Write all the control blocks for steps 1 thru n-1, and
lastly write the SHR for step n in the journal once again.
As in step 3, this information is saved to permit a
possible restart.
5
If the failing step is any step but the first step of a
non-restart job, write the SHR of the C!Jrrent step
in the journal. Again, this information is saved to permit
a possible restart.
6
til
g
6'
::s
~
a:
(D
So
~
o
o"'"
'0
i5'
::s
w
-uc ,.
Turnoff all restart bits (lCTRFBSM, lCTRFBCR,
and lCTRFBDC) before exiting.
Label
...~
Diagram 17-13. Preparing an Abended Job Step for Restart (IEFRPREP) (part 1 of 4)
0\
~
<-rn
. Input
1I
R1
Unallocation
(IEFBB410)
Output
N
1
i
a . Is restart requested.
.' ro-
b.ls job restartable.
f
oS
c. Was a checkpoint taken.
~
e.g
d. Is abend code valid.
CD
W
.~
N
e.'s job journal available.
(For the (active)
Problem Program)
~
f. Did error occur on a previous
journal write.
f
-
Check for the-following to.determine
if restart can occur.
c::1
w
~
2
Check for-operator authorization.
Message
3
If "positive" response to 1 'and 2,
prepare for restart.
If restart denied. - '
I I· Step 7
Diagram 17-13. Preparing an Abended Job Step for Restart (IEFRPREP) (part 2 of 4)
Extended Description
Module
Label
IEFRPREP
IEFPREP
This routine determines if an .abended (abnormally
terminated) job step task can be restarted. If it can,
the routi ne prepares the task for a restart.
1
a) Test JCTNORST.
b) The job cannot restart if, after a checkpoint was
taken, dynamic allocation routines have scratched a
dynamically allocated data set that is used by the job.
c) Test JCTCKFT.
C'I)
a
~.
::I
~
a==
8'
Q.
o
o"""
"0
(D
i
~.
::I
w
IN
00
o
Value
QMPA address
External Parameter
Area (EPA) chain address
Linkage Control Table
(LCT) address
Extension Block Address
(In this case, a chain of control
blocks can exist. Each block
contains the address of the
block to be journaled. its
identifier, its length, and the
R BN (relative block number).)
'-l
~
Diagram 17-14. Writing Blocks to the Job Journal (IEFXBSOO) (Part 3 of 4)
N
N
oC'Il
~N
Process
Input
C'Il
!
'<
=~
£
(;.
~
I
JNLPARM
OMPA
I~GJ--'n".JNL£ I
OMPA
!>
I ....
EPA
~
fV
c
a
Output
Step
S;bOI
A,B
3
4
Check for "journal all"
indicator.
• If yes
I _
Determine if block(s) are
critical for restart.
I_
Step 8
Step 8
<:
C'Il
(D
N
o
1M
(".J
-
~N
o
00
o
1M
00
s
JNLPARM
i .....
IO-§
IY
C
QRBN
JCT
JFCB
o
JFCBX
Determine it'block to be
written is valid.
6
Non-SWA
Prefix
I_
Step 9
I .....
Build prefix for block
(similar to prefix for SWA
blocks).
~
RBN
....,
I-f I 1
~
1
Block Virtual
Address
...... B lock Length
Block 10
I ....
GDGNT
_
5
In~alid block
JNLPARM
LCT
C
C
7
GDGNT
~~~_
JFCBX
·0-----·0
Check relative block number
(RBN).
•
__--:>
I
A,B,
C,D
8
A,B,
C,D
9
If first time for this
block, assign a RBN.
:
:> I
lJ\.
Write all valid block(s) to
the job journal.
If journalling error occurs,
issue message and stop
journalling. If invalid
block is present, set
return code.
JNLPARM
!Y
II
-"
IV
:pCalle,
U
1-
New RBN
if Needed
Job Journal
JSCB
~JSCBJJSB
',-~
Diagram 17-14. Writing Blocks to the Job Journal (IEFXB500) (part 4 of 4)
Extended Description
3
Module
SWA Write (and Move):
IEFXB500
SWAWRT
SWAWRTL
The journal-write module contains a list of all
critical control blocks for the four main job states:
• I nterpreter state
• Allocation state
• Problem program execution state
• Termination state
This list (or template) also indicates critical non-SWA
('direct write') control blocks (e.g., step header record,
via data sets such as data set page control table header
and via data set control block).
SWA virtual address
31
o or t
4
For SWA move:
t Buffer to which block is read
or from which block is written
en
~
n
=
N
a::
~
S
o
....
Q.
o
~
a5'
~
=
(.H
~
N
(.H
t
SWA virtual address from which block
is read or to which block is written
1
4
BI
o
3\
7
IEFXB500
RUNCHAIN
oc
o
4
<
en
t-.J
o
(.H
00
o
For the allocation-time journalling, the pointer chain
beginning at the LCT gives block addresses.
When writing to the journal, the routine uses the request
parameter list (RPL) that was built by the SWA create
routine (lEFXB600)' It passes the RPL to the subsystem
routine (JES2) as a parameter in the PUT macro instruction that results in a JES2 routine putting the block on
the journal.
JOURNAL
9
ERRMSG
Error indicator in the JSCB is set, a WTP macro
instruction is used to issue a message, a return code
is placed in the parameter list JNLPARM, and control
returns to the caller.
kiD
For SWA assign:
SWA virtual address
(from SWA manager)
ORTWRT
1
4
next EPA
Label
The routine builds the prefix before it journals the
block.
Except when journalling control blocks at allocationtime, the order in which the blocks are journalled
depends on the order in which they are updated on SWA.
At allocation-time, the blocks are journalled in the following order: JCT, SCT (of current step), one or more GOGNT
(generation data group name table), one or more POI
(passed data set information), one or more VUT (volume
unload table), first SlOT plus JFCB plus JFCBX (one or
more) or JFCBE, additional SIOT-JFCB-JFCBXs chains
and SIOT-JFCB-JFCBE chains.
1
Length of block written or read
The parameter list contains the block ID. This lOis
matched against the template as in step 4.
8
4
Block 10
Module
Direct Write:
For the first journalling of the block, the RBN (in the
fourth word of the parameter list) is zero. This routine
assigns a unique RBN that will be used if subsequent
journalling of the block is required.
The 10 of each block that is scheduled to be journalled is
found in the SWA prefix for the block. The lOis matched
with the list in the template for the particular job state
involved, to determine if the block is critical for restart.
The format of the EPA appears below:
For SWA locate'
t Block to be written or read
SWAWRT
6
4
t
Extended Description
5
If this indicator (QMSJNL) is on, the routine journals the
control block regardless of the job state (see step 4). Only
the terminator modules use this indicator.
g.
Label
t
Diagram 17-15. Journal for Restarted Jobs (IEFXB500) (part 10f2)
t
~
N
fIl
1
J
From
IEFXB604
Input
o
t
LCT
1
i
l:
f~
For an automatic restart
job, rewrite all control
blocks up to but not
including the failing step
in the journal.
f
CD
w
~
N
JHR
Q
w
00
s
2
For an automatic step
restart, update the first Job
Header Record (JHR) with
the relative byte address
(RBA) pointing to the
proper journal record.
3
For a checkpoint restart,
after allocation of the
failing step, update the JHR
with the proper job-journal
repositioning information.
From
IEFSD162
JSCB
jSCBFRBA
JSCBJRBA
(I Ei=XB604)
Job Journal
Diagram 17-15. Journal for Restarted Jobs (IEFXBSOO)
Extended Description
Module
Label
1
IEFXB500
RUNCHAIN
RUNSIOT
For an automatic step restart or a checkpoint restart,
write all critical control blocks from step one up to
but not including the failing step in the journal. Blocks
are written as if they were all part of step n-1, where n is
the failing step's number. Critical control blocks are:
JCT, POI, GDGNT, VUT, SCT, SlOT, JFCB,JFCBX, and
JFCBE. VIO blocks are also written if SIOVAMDS is on.
2
For an automatic step restart, a GET macro with
update is issued, using the relative byte address (RBA)
saved in JSCBFRBA by the merge routine. The job header
record (JHR) is then updated by inserting an RBA which
was saved in JSCBJRBA by IEFXB604. This RBA points
to the SHR for step n-1 and will be used by the merge
routine after restart.
JHRUPDT
3
JHRUPDT
For a checkpoint restart, after allocation of the
failing step, update the JHR by inserting JSCBJRBA
and the RBA returned from the last PUT macro. This
RBA will be used at restart-time to reposition the journal
data set.
CIl
a
t5.
=
to.J
a::
[
o
~
o
'1:1
a
5"
=
~
to.J
VI
(part 2 of 2)
~
to.J
o
W
Oc
o
3-526
OS/VS2 System Loaic LibruyVolume 3 (VS2.03.810)
VS2.03.810
Index
ABDUMP initialization (See OS/VS2 System Initialization
Logic)
ABEND
in SWA manager move mode 3-265
ABENDed jobstep, preparing for restart 3-516
abnormal end of SMF writer function 3-460
abnormal termination of log task 3-476
ACB (access control block)
creation for eseudo access method 3-178
in converter/interpreter interface 3-178
in JFCB housekeeping control 3-318
in JLOCATE 3-333
in pseudo access method 3-184
in subsystem initiation message writer 3-186
in SWA create interface 3-216
access control block (see ACB)
access method, pseudo (see pseudo access method)
account tables (see ACT)
ACT (account tables)
in interpreter 3-254
in job deletion 3-208
in step deletion 3-208
action queue, deferred, in SRM 3-28
action/algorithm scheduling in SRM 3-23,3-23.2,3-23.3
(VS2.03.807)
active subsystem
notification 3-172
requests 3-172
addresses, virtual in SWA, updating 3-504
affinity (see CPU affinity)
affinity processor
function 3-304-3-305
affinity removed
function 3-304, 3-298, 3-368
affinity requests, allocating 3-300
ALCW A (allocation work area)
in allocate request to unit 3-304, 3-306
in allocating offline devices 3-376
in allocation via algorithm 3-348
in common allocation cleanup 3-378
in common allocation control 3-280
in demand allocation 3-355
in fixed device control 3-294
in generic allocation control 3-338
in nonspecific volume allocation control 3-308
in recovery allocation 3-358
in specific volume allocation 3-298
algorithm, allocating via 3-348
cover/reduce algorithm 3-349
interface to SRM 3-351
multi-unit requests 3-349
UCB candidates list 3-351
algorithm tables
in allocate request to unit 3-304-3-306
in allocating offline devices 3-366
in allocation via algorithm 3-339
in common allocation cleanup 3-378-3-379
in demand allocation 3-355
in generic allocation control 3-342, 3-344
in multi-unit request processing 3-366
in nonspecific volume allocation control 3-312
in recovery allocation 3-358
in specific volume allocation 3-298
algorithms, SRM 3-30
in periodic entry point scheduling 3-32
scheduling 3.23.2 (VS2.03.807)
alias-named data sets, processing 3-332-3-333
all active subsystem notification 3-172-3-173
allocate catalog control
function 3-336
allocate from groups picked by algorithm (see IEFAB478
object module)
allocate function control (see IEFDB410 object module)
allocate request to unit 3-302
allocate via the algorithm
function 3-348
allocate VIO data sets
function 3-280-3-281
allocate within a generic
function 3-342, 3-344, 3-346
allocating affinity requests
in allocating requests to units 3-304
in allocating requests to specify volumes 3-300
in allocation recovery 3-358
allocating direct-access request 3-294
allocating non-specific volume requests 3-308
allocating permanently resident volume requests 3-294
allocating reserved volume requests 3-294
allocating system log 3-472
allocating teleprocessing requests 3-286
allocating a unit
, building a VM & V request block 3-302
unloading a volume 3-302
allocating volumes and units to requests 3-280
,
allocation common EST AE exit routine (IEF AB4ED)
(VS2.03.804)
error processing 3-291-3-413 (VS2.03.804)
allocation environment, current, providing information
about 3-422
allocation message routine
function 3-380-3-381
allocation queue manager (see IEFAB4FA object module)
allocation queue manager request block (see AQMRB)
allocation/unallocation 3-269
. '
affinity request 3-300
catalog search 3-334
I
common allocation clean-up 3-378
common control (see also common allocation control)
3-280
common control for unallocation 3-430
common unalloaction functions 3-402
DD function control 3-322
ddname allocation
function 3-412, 3-428
demand allocation 3-355
device, offline, allocation of 3-366
disposition processing 3-440
dynamic allocation control 3-414
dynamic environment, current, providing information
about 3-423
dynamic information retrieval 3-422
dynamic unallocation control 3-416
fixed device control 3-294
function map, building (in initiator/unallocation
interface) 3-404
generic de vie type control 3-317
installation routine verification (in SVC 99 control)
3-412
interface to initiator
allocation 3-396
unallocation 3-402
introduction to allocation/unallocation 3-269
ISAM request error checking (in common allocation
cleanup) 3-380
JES2 notified of unallocation of data set and associated
resources 3-438-3-439
JFCB housekeeping control 3-314
JLOCATE, functions of 3-334
major functions of allocation/unallocation 3-271
mount equalization for MSS volumes 3-291, 3-350,
3-370
MSS interface to obtain preferred UCB list to update
UCB candidate list 3-371, 3-377
offline device allocation 3-366
overview of allocation/unallocation 3-269
passed data set information, obtaining 3-334
processing job step (SVC 99 control) 3-412
reattempted allocation, criteri'a for 3-378
recovery 3-358
remove in-use attribute 3-424
Index
I-I
VS2.03.810
remove in-use processing 3-424
to unit 3-302
retry 3-378
SRM interface
in common. allocation clean-up 3-382
in non-specific volume allocation 3-312
step allocation control
function 3;.398
step initiator
in initiator/allocation interface 3-396
in step initiation 3-200
SVC 99 control 3-412
termination error, processing 3-382
unit unallocation 3-444
via algorithm 3-348
volume list (in disposition processing, IEFAB4A2)
3-440
volume mount and verify (VM & V)
interface 3-386
processing 3-390
allocation work area (see ALCW A)
ALTCPREC SYSEVENT code (33)
processing -in SRM SYSEVENT code processor 3-18
alternate disposition message routine
function 3-443
alternation of SWA subpool 3-267
AMWA (access method work area)
in converter/interpreter interface 3-178
in pseudo access method 3-184
in subsystem initiation 3-176
analyzer, MF /1 syntax 3-86
APF (see authorized program facility)
APG (automatic priority group)
changing priorities in 3-62
in step initiation 3-205
AQMRB (allocation queue manager request block)
in generic allocation control 3.;338
ASCB (address space control block)
in CPU management (SRM) 3-62
in dynamic allocation control 3-414
in SMF cross~memory post error exit 3-460
in SRM interface 3-6
in SRM service routine (IRARMSRV) 3-9.2
(VS2.0l.807)
in step initiation 3-200
in storage management (IRARMSTM) 3-46
(VS2.03.807)
in storage management (SRM) 3-46
iri SVC 99 control 3-412
in swappable user evaluation (IRARMWM2) 3-70
(VS2.03.807)
in swap-io
control 3-40
in swap-out
control 3-42
in SYSEVENT processing in SRM SYSEVENT code
processor 3-11
in user evaluation (IRARMCVL) 3-43.4 (VS2.03.807)
ASCB priority
in step initiation 3-200
ASID (address space identifier)
in job unallocation 3-410
ASM (see auxiliary storage manager)
ASMCNSTS SYSEVENT code (27)
processing in SRM SYSEVENT code processor 3-17
ASMVT
in interval measurement gathering routine for paging
3-122
in resource monitor periodic monitoring (IRARMRM 1)
3-66 (VS2.03.807)
in storage management (IRARMSTM) 3-46
(VS2.03.807)
in storage management (SRM) 3-48
ASSIGN
processing 3-264
ASSIGN/LOCATE processing 3-266
ASSIGN/START processing 3-264
assignment of CPU task affinity
function 3-201, 3-199
ASXB (address space extension block)
r~quests
1-2
OS/VS2 System Logic Library Volume 3 (VS2.03.810)
in SMF cross memory post error exit 3-460
asynchronous exits (see exit asynchronous)
ATCA
in allocation/volume mount and verify (VM & V)
interface 3-388
in volume mount and verify (Vl\1& V) 3-394
attributes, user (see VAPS)
automatic checkpoint/restart
processing 3-498
SWA create interface 3-216
automatic priority group (see APG)
automatic step restart 3-500
auxiliary page shortage 3-48
auxiliary storage manager I/O request area (see AlA)
available queue element (see AQE)
AVQLOW SYSEVENT code (23)
processing in SRM storage management (IRARMSTM)
3-49
processing in SRM SYSEVENT code processor 3-16
A VQOK SYSEVENT code (24)
processing in SRM storage management (IRARMSTM)
3-49
processing in SRM SYSEVENT code processor 3-16
A VR (automatic volume recognition)
in generic allocation
function 3-340, 3-341
BASEA (see MSRDA)
batch allocation
in common allocation control 3-280
BRINGIN SYSEVENT (44)
processing in SRM SYSEVENT processor 3-21
broadcast data set (see SYS1.BRODCAST)
build eligible devices list (EDL)
function 3-282-3-283
building step header record for job journal 3-512
CAT (channel availablity table)
in MF/1 channel sampling module 3-140
catalog, allocating (see SVC 99) 3-337
catalog, implied by data set names 3-334
catalog, master 3-335
catalog, private, searching 3-334
catalog processing 3-204
catalog searching 3-334
catalog unallocation control
function 3-336, 3-318, 3-432
cataloged procedures 3-232
CCT
in CPU load balancin~ swap analysis 3-66
in CPU management (lRARMCPM) 3-62 (VS2.03.807)
in CPU management (SRM) 3-62
in reSource monitor periodic monitoring (IRARMRM 1)
3-66 (VS2.03.807)
in storage management (SRM) 3-48
change ddname/JES3 exit (IEFDB4FB)
function 3-418-3-419
channel, logical
analysis of I/O load 3-56
imbalance 3-54
in I/O mangement 3-54
channel, measurement
MF/l initialization for 3-100
channel availability table (see CAT)
channel data collected by MF/l
interval 3-130
sampling 3-140
se.cond CPU 3-142
checkpoint data set 3-486
checkpoint/restart 3-202, 3-483
ABENDed job step, preparing for restart 3-516
automatic
in SWA create interface 3-216
processing 3-498
data set descriptor records processing 3-486, 3-483
deferred 3-216
dynamic allocation interface 3-486
header record 3-489
VS2.03.810
;:)L~P mitiation
3-202
job journal writing 3-520
CIB (command input block)
in measurement facility control 3-80
CIB (command input buffer)
in job initiation 3-196
clean-up processing
in common allocation 3-378
in volume mount & verify (VM & V) 3-394
clock, TOD (see TOD clock)
coefficients, resource (see resource factor coefficient)
collect data for MP/l (IRARMWR3) 3-73.8 (VS2.03.807)
command, reconfiguration (see reconfiguration commands)
command. processing
in the input stream 3-230
commands
in the input stream 3-230
WRITELOG START 3-466
comment or continuation statement processing . 3-226
common allocation clean-up
called by 3-378
common allocation parameter list, building 3-378
functions 3-378
requests excluded (see also requests, allocation) 3-378
common allocation control
called by 3-280
fixed device control 3-290
function 3-280
function map 3-430
generic allocation control, use with 3-288
order of allocation 3-280
parameter list, function map 3-280
recovery, occasions for use 3-288
serialization of 3-282
waiting for devices 3-280
common allocation parameter list
building 3-378
common request router
processing
function 3-172
request block construction 3-412
common unallocation functions 3-430
comparator, clock (sec clock comparator)
COMW A (converter/interpreter common work area)
converter usc of in
identifying verbs or JCL statements 3-226
initialization 3-224
processing commands in the input stream 3-230
processing in-stream and cataloged procedures
3-232
termination 3-242
.
interpreter use of in initialization 3-246
concatenation, dynamic
function 3-418
CONFIGCH SYSEVENT code (29)
processing in SRM SYSEVENT code processor 3-17
continuation statement processing 3-226-3-229
control, common allocation (see common allocation
control)
control blocks (see data areas)
conversion of bit mask
function 3-200-3-201
converter (see also interpreter)
command verb validation routine
function 3-230, 3-228
comment or continuation validation routine
function 3-226
converting statements to internal text 3-236-3-239
entering defaults'into internal text 3-240-3-241
error messages
processing by subsystem initiation message writer
3-186-3-187
get routine
function 3-226
identifying verbs on J CL statements 3-226-3-229
initialization
function 3-224-3-225
instream procedure routines
function 3-232
pre-scan routine
...
function 3-228
processing commands in the input stream 3-230-3-23
processing in-stream and cataloged procedures
3-232-3-233
processing symbolic parameters 3-234-3-235
pseudo-access method 3-182-3-185
scan routine
3~236, 3-240, 3-234, 3-226
function
SW A manager interface routine
function 3-233
symbolic parameter routine
function
3-234
termination routine
function 3-242-3-243
test and store utility routine
function 3-252
use by master subsystem 3-178-3-181
verb identifier routine
function
3-226, 3-228, 3-232, 3-238
con verter / interpreter
interface 3-178-3-181
operator message module
function 3-258-3-259
converting an allocation in dynamic allocation control
3-414
COPYDMDT SYSEVENT code (VS2.03.807)
code processor 3-11 (VS2.03.807)
processing in SRM SYSEVENT 3-22 (VS2.03.807)
corequisite publications iv (preface)
count table
in allocation via algorithm 3-350
in common allocation control 3-280
in demand allocation 3-355
in fixed device control 3-294
in nonspecific volume allocation control 3-312
in specific volume allocation
3-300
cover/reduce algorithm
function 3-366, 3-348, 3-374, 3-280
CPU activity initialization in MF/1
3-96
CPU affinity
in job initiation 3.;.199
in step initiation 3-20 I
CPU load balancin~ swap analysis 3-66
CPU management III SRM
3-62
CPU measurements in MF/J
in interval MG routine 3-118-3-121
CPU tltililation (VS2.03.807)
in CPU management (IRARMCPM) 3-63,3-64
(VS2.03.807)
CRI (catalog return information)
in DD function control 3-322-3-330
in JLOCATE 3-334
cross-memory posting of SMFerror exit .-460
CSCB (command scheduling control blo )
in allocation/initiator interface ~98R
in initiator/allocation interface '
in job initiation 3-196
6
in step initiation 3-200
in SWA create interface 3-'
CSJ? (common syste~ data aTe'{ 3-282
m common allocatIOn contttCPM) 3
in CPU management (IRflP
3
-62 (VS2.03.807)
in MP/I channel jnitiali~'t<>nrovjd~OO.
.
current allocation environ,..' , P
ng informatIOn
about 3-42~ .
.,e" table)
CV:r (comm~ntc~t~~n . Ulterface 3-396
!n allocat!on/tntt~ IJlOunt and verif (VM & V)
tn allocahon/v6
y
interface .p header record for th . b .
in building .
e JO Journal
3-512 equest router 3-172
in compilame assignment 3-188
!n ~~tri/al1ocation interface 3-396
~n ~~"or/unaJ1ocation interface 3-404
tn • vaJ measurement
th .
i,..6
ga ermg routine for workload
.Ierging job journal to SWA 3-492
.J ~~/J channel ~n!tia!i~a!ion
3-100
/ I CPU actIVIty lUltlalization 3-96
Index
1-3
VS1.03.8Iu
n MF/1 device initialization
3-104
m MF/l paging activity initialization
3-96
in MF/l second CPU test channel sampling module
3-142
in MF/l termination processor 3-110
in STAE exit processing for SMF 3-458
in subsystem determination 3-174
in subsystem interface 3-164
in switching SMF data sets 3-454
in unallocation/initiator interface 3-404
in volume mount and verify (VM&V) 3-394
in writing blocks to the job journal 3-520
in writing SMF records 3-450
DADSM'
allocation interface 3-304
parameter list in allocate request to unit 3-304
VM & V interface 3~386
;DAIRFAIL (IKJEFFI8) failure in dynamic allocation
• 3-486 (VS2.03.810)
Data Area section 7-1855
data control (IRBMFDTA) in MF/l 3-106
data set assignment 3-188
data set descriptor record processor (see also
checkpoint/ restart)
in SWA create interface
function 3-486, 3-216, 3-217
data set enqueue parameter list building
function 3-198-3-199
data set name (see also DSN resolution)
in data set tree processing 3-198-3-199
data set name assignment
function 3-188
data set name resolution
function 3~324
data set tree structure processing in job and step initiation
function 3-198-3-199
data sets, releasing
in common unallocation control 3-432-3-433
data sets, SMF 3-454
.
DCB (data control block)
in converter/interpreter interface 3-178
in data set descriptor records processing 3-486
in switching SMF data sets 3-454
in writing SMF records 3-450
resolution in DD function control
function 3-330-3-331
DD function control (IEFAB454)
DCB res<-tution 3-331
DISP reso1ltion 3-332-3-333
GDG (~enelltion data group) processing 3-324-3-325
processmg
functio": -322
volume/u!llt re~'ution 3~328-3-331
DD preparation
function 3-314-3"'\5
DD processing control
function 3-324, 3-3tddname allocatio~ 3-4~~"-412
ddname and relative posltlCt}'lumber
informing the JE~3 subS'ttm 3-418-3-419
ddname search routme
function 3-416, 3-418, 3"""
DEB (data extent block) .
.~
deconcatenatioI}, dyna2~
,
step initiation, In. 3deconcatenation routme
. into JCL'~
function 3-420
defaults, converter, entertn(fRARMCEN)\al text 3-240
7)
"'RM 3-28
deferred action processor
deferred actic:i q(eue ::!!~~3'~_28 (VS1.&,
in deferre rta~ lb°'determination (in SW A l~
deferred resta ]0
'\
interface) ~-2h17. SRM 3-23 (VS1.03.8tft\
deferring algont ~s m
\
DELETE subrouttne
d
3-265
\,
v
in SW A manager fmo m~neSWA manager loc~
DELETE/LOCATE unc ion 1
\:le
3-266-3-267
f
I
1-4
~ Lib-- Volume 3 (VS1.03.810)
OS/VSl System ........'"
.-J
demand allocation
processing
function 3-355
use with generic allocation 3-407
demand requests
definition 3-355
operator replies 3-375
processing 3-375, 3-377
volunit entry, updating 3-372, 3-373
DEQ macro instruction (see ENQ/DEQ/RESERVE
routine)
determination of subsystem name 3-175
determine device requirements
function 3-282-3-283
determining device requests
for request not yet allocated 3-289
DEVALLOC SYSEVENT code (28)
processing in SRM. SYSEVENT code processor 3-17
device allocation/unallocation (see allocation/unallocation)
device data collected by MF/1 3-145
device end post handler
function 3-394.
device groups no longer needed, determining 3-372
device groups that must remain serialized 3-373
device sampling in MF/l
initialization 3-104
processing 3-145
device selections from lES3 3-284-3-285
devices, generic (see generic allocation control)
.
devices, waiting for
in common allocation control 3-289
direct access data set (see DADSM)
direct access label read
function 3-340, 3-394
direct read
in pseudo access method 3-182
direct write
in pseudo access method 3-182
OISP (disposition) information (see also disposition
processing)
completing in JFCB R IN SlOT 3-322
DISP (disposition) resolution (see also disposition
processing)
associated with commands in the input stream 3-231
in DD function control 3-333
dispatching
priority, changing
iIi CPU management 3~62
disposition message routine
function 3-443
disposition processing control
function 3-440
disposition processing in IEFAB4A2 (see also OISP
resolution, DISP information) 3-440
in common unallocation control (IEFAB4AO) 3-430
in DO function control (IEFAB454)
function 3-332-3~333
OMDT (domain descriptor table) (VS2.03.807)
in resource monitor MPL adjustment processing
(IRARMRM2) 3-67.0 (VS2.03.807)
in resource monitor periodic monitoring (lRARMRM 1)
3-66 (VS2.03.807)
in swap analysis (IRARMCAP) 3-36 (VS2.03.807)
DOM count in VM&V (volume mount and verify) tables
3-391
DOM (delete operator message) 10 entries
in allocation/volume mount and verify (VM & V)
interface 3-388
in volume mount and verify (VM & V) 3-392-3-393
domains (VS2.03.807)
definition/description 3-3 (VS2.03.807)
of work indicated in IPS 3-3 (VS1.03.807)
DONTSWAP SYSEVENT code (code 41)
exception to authorization 3-5
in SYSEVENT processor 3-20
in workload manager 3-71
DSAB (data set association block)
in allocate request to unit 3-302
in allocating offline devices (IEFAB486) 3-368
in allocation via algorithm 3-348
o
VS2.03.810
function 3-228
processing commands in the input stream 3-230-3-231
processing in-stream and cataloged procedures
3-232-3-233
processing symbolic parameters 3-234-3-235
pseudo-access method 3-182-3-185
scan routine
function 3:"236, 3-240, 3-234, 3-226
SWA manager interface routine
function 3-233
symbolic parameter routine
function 3-234
termination routine
function 3-242-3-243
test and store utility routine
function 3-252
use by master subsystem 3-178-3-181
verb identifier routine
function 3-226, 3-228, 3-232, 3-238
converter/interpreter
interface 3-178-3-181
operator message module
function 3-258-3-259
converting an allocation in dynamic allocation control
3-414
COPYDMDT SYSEVENT code (VS2.03.807)
code processor 3-11 (VS2.03.807)
processing in SRM SYSEVENT 3-22 (VS2.03.807)
corequisite publications iv (preface)
count table
in allocation via algorithm 3-350
in common allocation control 3-280
in demand allocation 3-355
in fixed device control 3-294
in nonspecific volume allocation control 3-312
in specific volume allocation 3-300
cover/reduce algorithm
function 3-366, 3-348, 3-374, 3-280
CPU activity initialization in MF /1
3-96
CPU affinity
.
in job initiation 3-199
in step initiation 3-201
CPU load balancing swap analysis 3-66
CPU management in SRM 3-62
CPU measurements in MF/l
in interval MG routine 3-118-3-121
CPU utilization (VS2.03.807)
in CPU management (IRARMCPM) 3-63,3-64
(VS2.03.807)
CRI (catalog return information)
in DO function control 3-322-3-330
in JLOCATE 3-334
cross-memory posting of SMF error exit 3-460
CSCB (command scheduling control block)
in allocation/initiator interface 3-398
in initiator/allocation interface 3-398
in job initiation 3-196
in step initiation 3-200
in SWA create interface 3-216
CSD (common system data area)
in common allocation control 3-282
in CPU management (IRARMCPM) 3-62 (VS2.03.807)
in MF /1 channel initialization 3-100
current allocation environment, providing information
about 3-422
CVT (communication vector table)
in allocation/initiator interface 3-396
in allocation/volume mount and verify (VM & V)
interlace 3-388
in building a step header record for the job journal
3-512
in common request router 3-172
in data set name assignment 3-188
in initiator/allocation interface 3-396
in initiator/unallocation interface 3-404
in interval measurement gathering routine for workload
3-126
in merging job journal to SW A 3-492
in MF/1 channel initialization 3-100
in MF/l CPU activity initialization 3-96
in step initiation 3-202
job journal writing 3-520
CIB (command input block)
in measurement facility control 3-80
CIB (command input buffer)
in job initiation 3-196
clean-up processing
in common allocation 3-378
in volume mount & verify (VM & V) 3-394
clock, TOD (see TOD clock)
coefficients, resource (see resource factor coefficient)
collect data for MF/l (IRARMWR3) 3-73.8 (VS2.03.807)
command, reconfiguration (see reconfiguration commands)
command. processing
in the input stream 3-230
commands
in the input stream 3-230
WRITELOG START 3-466
comment or continuation statement processing . 3-226
common allocation clean-up
called by 3-378
common allocation parameter list, building 3-378
functions 3-378
requests excluded (see also requests, allocation) 3-378
common allocation control
called by 3-280
fixed device control 3-290
function 3-280
function map 3-430
generic allocation control, use with 3-288
order of allocation 3-280
parameter list, function map 3-280
recovery, occasions for use 3-288
serialization of 3-282
waiting for devices 3-280
common allocation parameter list
building 3-378
common request router
processing
function 3-172
request block construction 3-412
common unallocation functions 3-430
comparator, clock (see clock comparator)
COMWA (converter/interpreter common work area)
converter use of in
identifying verbs or JCL statements 3-226
initialization 3-224
processing commands in the input stream 3-230
processing in-stream and cataloged procedures
3-232
termination 3-:-242'
interpreter use of in initialization 3-246
concatenation, dynamic
function 3-418
CONFIGCH SYSEVENT code (29)
processing in SRM SYSEVENT code processor 3-17
continuation statement processing 3-226-3-229
control, common allocation (see common allocation
control)
control blocks (see data areas)
conversion of bit mask
function 3-200-3-201
converter (see also interpreter)
command verb validation routine
function 3-230, 3-228
comment or continuation validation routine
function 3-226
converting statements to internal text 3-236-3-239
entering defaults'into internal text 3-240-3-241
error messages
processing by subsystem initiation message writer
3-186-3-187
get routine
function 3-226
identifying verbs on JCL statements 3-226-3-229
initialization
function 3-224-3-225
instream procedure routines
function 3-232
pre-scan routine
)
Index
_ iif@ •.• ~" £
,~
,,¥
4P
("i·fijJ£tE;f\i\ii)iM4I\;';;
;**",*""'*44.£4.\.$.4;;'. 6, ...44$
.\$ @lUlU
n4A;
;;
4T4;J.$Ib£
44.'(',·,;
'I
,'r;
I
'*'
a
1-3
VS2.03.810
in MF/1 device initialization 3-104
in MF /1 paging activity initialization 3-96
in MF/1 second CPU test channel sampling module
3-142
in MF/1 termination processor 3-110
in STAE exit processing for SMF 3-458
in subsystem determination 3-174
in subsystem interface 3-164
in switching SMF data sets 3-454
in unallocation/initiator interface 3-404
in volume mount and verify (VM & V) 3-394
in writing blocks to the job journal 3~520
in writing SMF records 3-450
DADSM
allocation interface 3-304
parameter list in allocate request to unit 3-304
VM&V interface 3-386
!DAIRFAIL (IKJEFFI8) failure in dynamic allocation
! 3-486 (VS2.03.8tO)
Data Area section 7-1855
data control (IRBMFDTA) in MF/l 3-106
data set assignment 3-188
data set descriptor record processor (see also
checkpoint/restart)
in SWA create interface
function 3-486, 3-216, 3-217
data set enqueue parameter list building
function 3-198-3-199
data set name (see also DSN resolution)
in data set tree processing 3-198-3-199
data set name assignment
function 3-188
data set name resolution
function 3-324
data set tree structure processing in job and step initiation
function 3-198-3-199
data sets, releasing
in common unallocation co.ntrol 3-432-3-433
data sets, SMF 3-454
DCB (data control block)
in converter/interpreter interface 3-178
in data set descriptor records processing 3-486
in switching SMF data sets 3-454
in writing SMF records 3-450
resolution in DD function control
function 3-330-3-331
DD function control (IEFAB454)
DCB resolution 3-331
DISP resolution 3-332-3-333
GDG (generation data group) processing 3-324-3-325
processing
function 3·322
volume/unit resolution 3-328-3-331
DD preparation
'
function 3-314-3-315
DO processing control
function 3-324, 3-314
ddname allocation 3-428, 3-412
ddname and relative position number
informing the JES3 subsystem 3-418-3-419
ddname search routine
function 3-416, 3-418, 3-420
DEB (data extent block)
deconcatenation, dynamic 3-420
step initiation, in 3-204
deconcatenation routine
function 3-420
defaults, converter, entering intoJCL internal text 3-240
deferred action processor (IRARMCEN) in SRM 3-28
deferred action queue (VS2.03.807)
in deferred action process 3-28 (VS2.03.807)
deferred restart job determination (in SWA create
interface) 3-217
deferring algorithms in SRM 3-23 (VS2.03.807)
DELETE subroutine
in SWA manager move mode 3-265
DELETE/LOCATE function in SWA manager locate mode
3-266-3-267
1-4
OS/VSl System Logic Ubrary Volume 3 (VS2.03.810)
demand allocation
processing
function 3-355
use with generic allocation 3-407
demand requests
definition 3-355
operator replies 3-375
processing 3-375, 3-377
volunit entry, updating 3-372, 3-373
DEQ macro instruction (see ENQ/DEQ/RESERVE
routine)
determination of subsystem name 3-175
determine device requirements
function 3-282-3-283
determining device requests
for request not yet allocated 3-289
DEVALLOC SYSEVENT code (28)
processing in SRM. SYSEVENT code processor 3-17
device allocation/unallocation (see allocation/unallocation)
device data collected by MF/l 3-145
device end post handler
function 3-394
device groups no longer needed, determining 3-372
device groups that must remain serialized 3-373
device sampling in MF/l
initialization 3-104
processing 3-145
device selections from JES3 3-284-3-285
devices, generic (see generic allocation control)
devices, waiting for
in common allocation control 3-289
direct access data set (see DADSM)
direct access label read
function 3-340, 3-394
direct read
in pseudo access method 3-182
direct write
in pseudo access method 3-182
DISP (disposition) information (see also disposition
processing)
completing in JFCB R IN SlOT 3-322
DISP (disposition) resolution (see also disposition
processing)
associated with commands in the input stream 3-231
in DD function control 3-333
dispatching
priority, changing
in CPU management 3-62
disposition message routine
function 3-443
disposition processing control
function 3-440
disposition processing in IEFAB4A2 (see also DISP
resolution, DISP information) 3-440
in common unallocation control (IEFAB4AO) 3-430
in DD function control (IEFAB454)
function 3-332-3-333
DMDT (domain descriptor table) (VS1.03.807)
in resource monitor MPL adjustment processing
(IRARMRM2) 3-67.0 (VS2.03.807)
in resource monitor periodic monitoring (IRARMRM 1)
3-66 (VS2.03.807)
in swap analysis (IRARMCAP) 3-36 (VS2.03.807)
DOM count in VM&V (volume mount and verify) tables
3-391
DOM (delete operator message) ID entries
in allocation/volume mount and verify (VM & V)
interface 3-388
in volume mount and verify (VM & V) 3-392-3-393
domains (VS2.03.807)
definition/description 3-3 (VS2.03.807)
of work indicated in IPS 3-3 (VS2.03.807)
DONTSWAP SYSEVENT code (code 41)
exception to authorization 3-5
in SYSEVENT processor 3-20
in workload manager 3-71
DSAB (data set association block)
in allocate request to unit 3-302
in allocating offline devices (IEFAB486) 3-368
in allocation via algorithm 3-348
(
VS2.03.8tO
in allocation/initiator interface 3-396
in common allocation cleanup 3-378
in common allocation control 3-280
in common unallocation control 3-434
in ddname allocation 3-428
in demand allocation 3-355
in dynamic allocation control 3-414
in dynamic concatenation 3-418
in dynamic deconcatenation 3-420
in dynamic information retrieval 3-422
in dynamic unallocation control 3-416
in fixed device control (IEFAB430) 3-294
in generic allocation control (IEFAB47t) 3-342
in initiator/allocation interface 3-396
in initiator/unallocation interface 3-402
in recovery allocation (IEFAB485) 3-360
in remove in-use attribute routine (IEFDB480) 3-424
in SVC 99 control (IEFDB400) 3-412
in unit unallocation processing (IEFAB4A4) 3-446
DSAB entry checks made (in ddname allocation) 3-428
DSAB QDB (data set association block queue descriptor
block)
in allocation/initiator interface 3-396
in common allocation cleanup 3-380
in ddname allocation 3-428
in dynamic allocation control 3-414
in dynamic concatenation 3-418
in dynamic deconcatenation 3-420
in dynamic information retrieval 3-422
in dynamic unallocation control 3-416
in initiator/allocation interface 3-396
in initiator/unallocation interface 3-402
in nonspecific volume allocation control 3-310
in remove in-use attribute routine 3-424
in SVC 99 control (IEFDB400) 3-412
in unallocation/initiator interface 3-402
in unit un allocation processing 3-446
DSCB (data set control block)
iiI switching SMF data sets 3-454
DSDR (data set descriptor record)
checkpoint/restart, processing of 3-483
DSENQT (data set enqueue table)
in DD function control (IEFAB454) 3-332
in interpreter
creating and chaining tables 3-254
initialization 3-246
in step initiation 3-200
DSN resolution in data set tree processing 3-198-3-199
dsname search routine
function 3-416
DSNT (data set name table)
in DD function control 3-326
DTMVT (measurement vector table for trace and report
data, see also INMVT, MFMVT, STMVT, TMMVT)
in MFDATA SVC mainline 3-114
in MF/l report generator control (IRBMFRGM) 3-148
DWWIN
in interval measurement gathering routine for workload
3-126
in MF/1 workload initialization 3-98
dynamic allocation
convert routine
function 3-414
DAIRFAIL processing 3-486 (VS2.03.810)
ESTAE exit
function 3-413
function validity checker
function 3-414
processing 3-414
SVC 99 control (IEFDB400) 3-412
dynamic allocation request for unit and volume, processing
3-280
dynamic concatenation
criteria for 3-418
processing 3-418
dynamic deconcatenation
criteria for 3-420
processing 3-420
dynamic information retrieval
function 3-422
dynamic support system (see DSS)
dynamic unallocation 3-416
ECB (event control block)
in converter/interpreter interface 3-180
in swap-out control 3-43
ECCDB
in MF/1 channel interval measurement gathering routine
3-130
in MF/l channel initialization 3-100
in MF/1 channel sampling module 3-140
in MF/1 second CPU test channel sampling module
3-142
ECCED
in MF/1 channel interval measurement gathering routine
3-130
in MF/1 channel initialization 3-100
in MF/1 channel sampling module 3-140
ECCPE
in MF/l channel initialization 3-100
in MF/1 channel sampling module 3-140
EDDCD
in interval measurement gathering routine for devices
3.. 134
in MF/1 device initialization 3-104
EDDDB
in interval measurement gathering routine for devices
3-134
in MF/1 device initialization 3-104
EDDED
in interval measurement gathering routine for devices
3-134
in MF/l device initialization 3-104
in MF/1 device sampling module 3-144
EDL (eligible device list)
building 3-122, 3-283
contents 3-283
in allocating offline devices 3-366
in allocation via algorithm 3-348
in common allocation cleanup 3-382
in common allocation control 3-282
in demand allocation 3-355
in fixed device control 3-294
in generic allocation control 3-338
in nonspecific volume allocation control 3-312
in recovery allocation 3-358
in specific volume allocation 3-298
EDT
in allocate request to unit 3-302
in allocating offline device 3-366
in common allocation control 3-280
in generic allocation control 3-338
in JFCB housekeeping control 3-316
in recovery allocation 3-360
eligible units, determining
in specific volume allocation control 3-298-3-299
eliminate ineligible groups and generics
function 3-348, 3-362, 3-366
end of task (see EOT)
ENQ/DEQ routine for allocation
function 3-386, 3-357, 3-312
ENQ macro instruction (see ENQ/DEQ/RESERVE
routine)
ENQRLSE SYSEVENT code (21)
processing in SRM SYSEVENT code processor 3-16
enqueue parameter list, use of in job initiation
3-198-3-199
enqueueing on volume serial number 3-312
entry point scheduling in SRM, periodic 3-32
entry point summary for SRM (VS2.03.807)
control function (IRARMCTL) 3-43.6 (VS2.03.807)
CPU management (IRARMCPM) 3-65.0 (VS2.03.807)
functional recovery routine (IRARMERR) 3-9.13
(VS2.03.807)
interface function (IRARMINT) 3-9.0 (VS2.03.807)
I/O management (IRARMIOM) 3-61.0 (VS2.03.807)
MF/l interface (IRARMWAR) 3-73.10 (VS2.03.807)
resource monitor (IRARMRMR) 3-67.2 (VS2.03.807)
service routine (IRARMSRV) 3-9.13 (VS2.03.807)
Index
1-5
J
VS2.03.810
storage management (IRARMSTM)
3-51.2
(VS2.03.807)
sysevent processor (IRARMEVT) 3-22.6 (VS2.03.807)
workload manager (IRARMWLM) 3-73.4 (VS2.03.807)
environment current allocation, providing information
about (IEFDB470) 3-422
EPA (external parameter area)
format 3-523
in allocation/initiator interface 3-396
in dynamic allocation control 3-414
in dynamic unallocation ~ontrol 3-416
in initiator/allocation interface 3.;.396
in JFCB housekeeping control 3-318
in remove in-use attribute routine 3-426
in SWA manager locate mode 3-266
in SWA manager move mode 3-264
EPAL (external parameter area locate mode, see EPA)
EPAM (external parameter area move mode, see EPA)
EPFA
in full analysis (IRARMCAS) 3-34
error codes
set in dynamic concatenation (IEFDB450) 3-418
error messages
processing by subsystem initiation message writer
3-186-3-187
error processing (see also error recovery ESTAE processing)
in allocation via algorithm 3-351
in allocation recovery 3-365
in common allocation clean-up 3-378
in common allocation control 3-307
in DD function control 3-333
in demand allocation 3-355
in fixed device allocation control 3-297
in generic allocation control 3-341
in initiator/allocation interface 3-399
in JFCB housekeeping control 3-317, 3-319
in JLOCATE (IEFAB469) 3-337, 3-335
in job journal merge 3-508
in non-specific volume allocation control 3-313, 3-377
in offline/allocated device allocation 3-369
in specific volume allocation control 3-301
in subsystem initiation
IEFJCNTL 3-177
IEFJJOBS 3-177
in volume mount and verify 3-395
error recursion (see recursion processing of errors)
error, syntax, detecting in converter (IEFVFA) 3-234
ESTAE
for SWA create interface 3-217
in converter initialization 3-224
in interpreter initialization 3-246
in job initiation 3-196
event-driven MF/1 functions
in MFROUTER 3-138
in MF/l termination processor (IRBMFTMA) 3-110
exchange swap 3-23.0,3-36 (VS2.03.807)
exclusive control (see XCTL routine)
exclusive data set attribute
handling in initiator 3-199
EXEC statement
in interpreter 3-257
exit, attention (see attention exit)
exit handling (see EXIT routine)
exit, initiator 3-200-3-201
expressswap-in 3-23.0,3-36 (VS2.03.807)
external parameter area (see EPA)
external parameter area locate mode (see EPA)
external parameter area move mode (see EPA)
faults (see page faults)
fetch (see program fetch)
FETCHLIB 3-204
five functional groups in SRM 3-3 (VS2.03.807)
fixed device control (IEFAB430)
count fields updated 3-294
direct access UCB use 3-294
processing
function 3-294
use with common allocation control 3-283
·1-6
OS/VS2 System Logic Ubrary Volume 3 (VS2.03.810)
use with nonspecific volume allocation control 3-297
frame (see page frame)
FRR (see functional recovery' routine)
full analysis (see system resources manager)
function codes
in subsystem interface 3-161
in SWA manager move mode 3-264
in SWA manager locate mode 3-266
used by JES2 and JES3 3-161
functional recovery routine (see also termination conditions)
'for SRM 3-9, 3-7
GDG (generation data group) processing
function 3-323-3-325
GDGALL requests, processing 3-325
GDGNT (generation data group name table)
in DD function control 3-324
in JLOCATE 3-334
generation data group (see GDG)
generic allocation control (IEFAB471)
AVR 3-341
function 3-338
generic processing, build tables for
function 3-338-3-339
generic table build processing 3-338
GET
in pseudo access method 3-184
group ID list
in allocation via algorithm 3-348
group lock/unlock ESTAE exit (IEFAB4E7) (VS2.03.804)
function 3-411 (VS2.03.804)
group lock/unlock interface (IEFAB4EC) (VS2.03.804)
function 3-411 (VS2.03.804)
GWT
in step initiation 3-200
header record for job journal; step, building
HIPO (see Method-of.;.Operation section)
housekeeping (see JFCB housekeeping)
HSKPW A (JFCB housekeeping work area)
in DD function control 3-322
in JFCB housekeeping control 3-314
in JLOCATE 3-334
ICBME object module
function 3-350-3-351, 3-377
ICT
in I/O load balancing swap analysis (SRM)
in I/O management (SRM) 3-54
in storage management (SRM) 3-48
IDACATll object module
function in JLOCATE 3-337
lEAVPFTE object module
IEEMB803 object module
function 3-466, 3-470, 3-474, 3-472
IEEMB804 object module
function 3-480
IEEMB806 object module
function 3-476
IEEMB807 object module
function 3-472, 3-468
IEEMB825 object module
function 3-458
IEEMB827 object module
function 3-460
IEEMB829 object module
function 3-450-3-451, 3-456, 3-452, 3-454
IEEMB830 object module
function 3-452, 3-450-3-451
IEEMSER (see MSRDA)
IEF AB4AO object· module
function 3-430
function map for 3-430
IEFAB4A2 object module
function 3-440
IEFAB4A4 object module
function 3-444
3-512
3-56
VS2.03.8tO
')
/
IEFAB4A6 object module
function 3-396-3-397
IEFAB4A8 object module
function 3-436-3-437
IEFAB4BO object module
function 3-443
IEFAB4B2 object module
function 3-443'
IEFAB4EB object module
function 3-334-3-335
IEFAB4EC object module (VS2.03.804)
function 3-411 (VS2.03.804)
IEFAB4ED object module (VS2.03.804)
function 3-291-3-413 (VS2.03.804)
IEF AB4EE object module
function 3-380-3-381
IEFAB4EF object module
function 3-336-3-337, 3-314-3-315
IEFAB4EO object module
function 3-340-3-341
IEF AB4E7 object module (VS2.03.804)
function 3-411 (VS2.03.804)
IEF AB4FA object module
function 3-341, 3-346, 3-388, 3-290, 3-378, 3-435, 3-372
IEFAB4FC object module
function 3-396, 3-398, 3-418, 3-436
IEF AB4FD object module
function 3-380, 3-398, 3-400
IEFAB4FE object module
function 3-396, 3-412
IEFAB4FO object module
function 3-386, 3-357, 3-312
IEFAB4F2 object module
function 3-368-3-369
IEFAB4F4 object module
function 3-336, 3-318, 3-432
IEFAB4F5 object module
function 3-336
IEFAB4F7 object module
function 3-316, 3-412, 3-418, 3-400, 3-322
IEFAB4F8 object module
function 3-340, 3-394
IEF AB4F9 object module
function 3-340, 3-418
IEFAB421 object module
function 3-280
IEFAB422 object module
function 3-282-3-283
IEFAB423 object module
function 3-282-3-283
IEFAB424 object module
function 3-282-3-283
IEFAB425 object module
function 3-286-3-287
IEFAB426 object module
function 3-282-3-283
IEFAB428 object module
function 3-280-3-281, 3-302-3-303
IEFAB430 object module
function 3-294
IEFAB431 object module'
function 3-280-3-281
IEFAB432 object module
function 3-304-3-305
IEFAB433 object module
function 3-298
IEFAB434 object module
function 3-302
IEFAB435 object module
function 3-302
IEFAB436 object module
function 3-308
IEFAB438 object module
function 3-282-3-283
IEFAB440 object module
function 3-350, 3-310
IEFAB441 object module
function 3-368, 3-302
IEFAB442 object module
function 3-304, 3-298, 3-368
IEF AB451 object module
function 3-314
IEFAB452 object module
function 3-324, 3-314
IEFAB453 object rnodule
function 3-314-3-315
IEFAB454 object module
function 3-322
IEFAB455 object module
function 3-334
IEFAB456 object module
function 3-324
IEFAB457 object module
function 3-326
IEFAB458 object module
function 3-330-3-331
IEFAB459 object module
function 3-332-3-333
IEFAB461 object module
function 3-323-3-325
IEFAB463 object module
function 3-326, 3-328
IEFAB464 object module
function 3-328, 3-330
IEFAB466 object module
function 3-326, 3-334
IEF AB469 object module
function 3-334
IEF AB470 object module
function 3-316-3-317
IEFAB471 object module
function 3-338
IEF AB472 object module
function 3-338-3-339
IEFAB473 object module
function 3-340, 3-341
IEFAB474 object module
function 3-348, 3-366
IEFAB475 object module
function 3-342, 3-344,
IEF AB476 object module
function 3-348
IEFAB477 object module
function 3-360, 3-348,
IEFAB478 object module
function 3-370, 3-350,
IEF AB479 object module
function 3-355
IEFAB48A object module
function 3-374-3-375
IEFAB480 object module
function 3-366, 3-348,
IEF AB481 object module
function 3-348, 3-362,
IEFAB485 object module
function 3-358
IEFAB486 object module
function 3-366
IEFAB487 object module
function 3-374, 3-364
IEFAB488 object module
function 3-374, 3-376
IEFAB489 object module
function 3-377
IEFAB49A object module
function 3-394, 3-388
IEFAB49B object module
function 3-394
IEFAB490 object module
function 3-378
IEFAB491 object module
function 3-280, 3-366
IEFAB492 object module
function 3-386
IEFAB493 object module
function 3-390
IEFAB494 object module
function 3-390
IEFAB495 object module
function 3-392
3-346
3-368
3-290
3-374, 3-280
3-366
Index
1-7
I
VS2.03.810
IEFAB496 object module
function 3-394
IEF AB498 object module
function 3-390, 3-388, 3-394
IEFAB499 object module
function 3-392
IEFAB820 object module
function 3-206
IEFBB401 object module
function 3-396
IEFBB402 object module
function 3-396
IEFBB404 object module
function 3-398
IEFBB410 object module
function 3-402, 3-404
IEFBB412 object module
function 3-406, 3-414
IEFBB414 object module
function 3-404-3-405
IEFBB416 object module
function 3-410
IEFDB4AO object module
function 3-416
IEFDB4Al object module
function 3-416, 3-426
IEFDB4FA object module
function 3-416
IEFDB4FB object module
function 3-418-3-419
IEFDB4FC object module
function 3-416, 3-418, 3-420
IEFDB4FF object module
function 3-424, 3-420, 3-422, 3-428, 3-418, 3-416
IEFDB4F9 object module
function 3-418
IEFDB400 object module
function 3-412
IEFDB402 object module
function 3-413
IEFDB"41O object module
function 3-414, 3-412
IEFDB411 object module
function 3-414
IEFDB412 object module
function 3-414
IEFDB413 object module
function 3-414
IEFDB450 object module
function 3-418
IEFDB460 object module
function 3-420
IEFDB470 object module
function 3-422
IEFDB480 object module
function 3-424
IEFDB481 object module
function 3-416, 3-426
IEFDB490 object module
function 3-412
IEFDSLST object module
function 3-198-3-199
IEFDSTBL object module
function 3-198-3-199
IEFIB600 object module
function 3-216
IEFIB605 object module
function 3-216
IEFIB645 object module
function 3-216-3-217
IEFICPUA object module
function 3-201, 3-199
IEFIIC object module
function 3-196
IEFIMASK object module
function 3-200-3-201
IEFJACTL object module
function 3-182, 3-184
IEFJCDLT object module
function 3-176-3-177
1-8
OS/VS2 System Logic Library Volume 3 (VS2.03.810)
IEFJCNTL object module
function 3-177, 3-179
IEFJDIRD object module
function 3-182-3-183
IEFJDSNA object module
function 3-188
IEFJDWRT object module
function 3-182-3-183
IEFJJCLS object module
function 3-176-3-177
IEFJJOBS object module
function 3-176
IEFJJTRM object module
function 3-190
IEFJRASP object module
function 3-172
IEFJREAD object module
function 3-184-3-185
IEFJSDTN object module
function 3-174
IEFJSREQ object module
function 3-161-3-167
IEFJWRTE object module
function 3-184-3-185
IEFJWTOM object module
function 3-186
IEFNB903 object module
function 3-246
IEFP ARAM {initiation parameter list)
in step initiation 3-202
IEFQB550 object module
function 3-264
IEFQB555 object module
function 3-266
IEFQB580 object module
function 3-264
IEFQB585 object module
function 3~264
IEFRPREP object module
function 3-516
IEFSD101 object module
function 3-200-3-201
IEFSD 102 object module
function 3-200-3-201
IEFSD160 object module
function 3-196
IEFSD 161 object module
function 3-196, 3-198
IEFSD 162 object module
function 3-200
IEFSD164 object module
function 3-208
IEFSD 166 object module
function 3-210
IEFSD263 object module
function 3-206
IEFSMFIE object module
function 3-200-3-201
IEFVDA object module
function 3-248-3-249
IEFVEA object module
function 3-248-3-249
IEFVF A object module
function 3-236, 3-238, 3-240, 3-234, 3-226
IEFVFB object module
function 3-234
IEFVGK object module
function 3-250
IEFVGT object module
function 3-252
IEFVHA object module
function 3-226
IEFVHC object module
function 3-226
IEFVHCB object module
function 3-226, 3-228, 3-232, 3-238
IEFVHE object module
function 3-248
IEFVHEB object module
function 3-228
VS2.03.810
IEFVHF object module
function 3-242-3-243
IEFVHH object module
function 3-256
IEFVHM object module
function 3-230, 3-228
IEFVHN object module
function 3-258
IEFVHQ object module
function 3-233
IEFVHR object module
function 3-258-3-259
IEFVHl object module
function 3-224-3-225
IEFVINA object module
function 3-232
IEFVINB object module
function 3-232
IEFVINC object module
function 3-232
IEFVJA object module
function 3-248
IEFXB500 object module
function 3-521, 3-202, 3-524, 3-520, 3-512, 3-518
IEFXB590 object module
function 3-525
IEFXB601 object module
function 3-492, 3-496, 3-498-3-509, 3-216, 3-494
IEFXB602 object module
function 3-510-3-511
IEFXB604 object module
function 3-512, 3-514, 3-202
IEFXB609 object module
function 3-486, 3-216
IEFXB610 object module
function 3-487
IEL (initiator entrance list)
in job initiation 3-196
IGXOOO13 object module
function 3-82, 3-80, 3-91
IGXOOO14 object module
function 3-114
IKJEFFl8 object module 3-486 (VS2.03.810)
IMCB (SRM user I/O measurement control table)
in I/O management (SRM) 3-54
in SYSVENT processing in SRM SYSEVENT code
processor 3-13
INCOA (common option area for input source options, see
also MFCOA, STCOA, TMCOA)
in MF/1 input merge control 3-84
in MF/l list option module 3-88
in MF/1 syntax analyzer 3-86
INITATT SYSEVENT code (0)
in work load manager 3-73
processing in SRM SYSEVENT code processor 3-13
INITDET (SYSEVENT code 11)
in I/O management 3-54-3-55
in workload manager 3-70-3-71
processing in SRM SYSEVENT code processor 3-13
initialize for MF/l (IRARMWR1) 3-73.6 (VS2.03.807)
initiation
of the master scheduler 3-176-3-177
data set name assignment 3-188-3-189
of a subsystem 3-176-3-177
data set name assignment 3-188-3-189
step 3-200
notify subsystem of step initiation 3-202
initiator attach module
function 3-206
initiator builder of completion code interface 3-458
initiator control initialization
function 3-196
initiator data set enqueue
function 3-200-3-201
initiator device allocation interface routine
function 3-200
initiator interface control and interface to allocate catalog
function 3-196
initiator job initiation 3-196
initiator job select routine
function 3-196, 3-198
initiator recovery processing 3-212
initiator SMF exit 3-200-3-201
initiator/terminator
processing 3-193
SW A sub pool for 3-267
initiator/unallocation interface
functions 3-402
when called 3-402
input stream (see converter)
INMVT (measurement vector table for temporary input
options, see also DTMVT, MFMVT, STMVT, TMMVT)
in MF /1 input merge control 3-84
in MF /1 syntax analyzer 3-86
input to MF/l, analyzing 3-86
input options for MF/l (see options, MF/I)
IN queue for SRM (VS2.03.807)
definition 3-23 (VS2.03.807)
in CPU management (IRARMCPM) 3-62 (VS2.03.807)
in resource monitor periodic monitoring (IRARMRMI)
3-67 (VS2.03.807)
in select user for swap-out (IRARMCPO) 3-43.2
(VS2.03.807)
in storage management (IRARMSTM) 3-46
(VS2.03.807)
in swap analysis (IRARMCAP) 3-36 (VS2.03.807)
in swappable user evaluation (IRARMWM2) 3-70
(VS2.03.807)
installation performance specifications (see IPS values)
in-stream procedures (see JCL statements)
director entry build, directory search, processing
3-232-3-233
instructions (see also macro instructions)
integrity (see data set integrity processing)
interface, subsystem 3-159
internal text
converting JCL to 3-236
data set, getting JCL statement from 3-249
entering defaults into 3-240
interpreter (see also converter/interpreter)
creating and chaining tables 3-252
enqueue routine
function 3-256
error messages
processing by subsystem initiation message writer
3-186-3-187
EST AE, setting up 3-246
EXEC statement processor
function 3-248-3-249
get and route routine
function 3-248
get key/positional utility routine
function 3-250
initialization 3-246
function 3-246
interface to SW A create 3-216
job statement processor
function 3-248
parameter values, analyzing 3-248
pseudo access method 3-182-3-185
termination
function 3-258
use by master subsystem 3-178-3-181
writing tables into SWA 3-256
interval, MF /1
in MFDATA SVC mainline 3-114
timed (in MFSTART mainline) 3-82
interval-driven MF /1 routines
for data (IRBMFDTA) 3-106
for CPU (IRBMFDCP) 3-118
for devices 3-134
for paging (IRBMFDPP) 3-126
for workload (IRBMFDWP) 3-126
initialization of in MFIMAINL 3-90
termination processor (IRBMFTMA) 3-110
I/O load balancing in SRM
swap analysis (IRARMIL2) 3-56
user I/O monitoring (IRARMILO) 3-58
I/O management in SRM (IRARMIOM) 3-54
Index
1-9
I
YS2.03.810
lOS UCB LUT (I/O supervisor unit control block logical
unit table)
in allocating offline devices 3-374
in common allocation control 3-282
in fixed device control 3-294
in generic allocation control 3-340
in JFCB housekeeping control 3-316
in job unallocation 3-410
in recovery allocation 3-358
IRARMCAP
function 3-36
IRARMCAP entry point in IRARMCTL (YS2.03.807)
function 3-36,3-43.6 (YS2.03.807)
IRARMCAS
function 3-34
IRARMCAT
function 3-26
IRARMCEL
function 3-30
IRARMCEL entry point in IRARMCTL (VS2.03.807)
function 3-30,3-43.6 (YS2.03.807)
IRARMCEN
function 3-28
IRARMCEN entry point in IRARMCTL (VS2.03.807)
function 3-28,3-43.6 (YS2.03.807)
IRARMCET
function 3-32
IRARMCET entry point in IRARMCTL (VS2.03.807)
function 3-32,3-43.6 (VS2.03.807)
IRARMCL2
function 3-66
IRARMCPI entry point in IRARMCTL (VS2.03.807)
function 3-43.0,3-43.6 (VS2.03.807)
IRARMCPM object module
function 3-62
IRARMCPM object module (VS2.03.807)
entry point summary 3-65.0 (VS2.03.807)
function 3-62 (VS2.03.807)
IRARMCPO entry point in IRARMCTL (VS2.03.807)
function 3-43.2,3-43.7 (VS2.03.807)
IRARMCSI
function 3-40
IRARMCSI entry point in IRARMCTL (VS2.03.807)
function 3-40,3-43.6 (YS2.03.807)
IRARMCSO
)
function 3-42
IRARMCSO entry point in IRARMCTL (VS2.03.807)
function 3-42,3-43.6 (VS2.03.807)
IRARMCTL object module
function 3-24
IRARMCTL object module (VS2.03.807)
entry point summary 3-43.6 (YS2.03.807)
function 3-24,3-43.6 (VS2.03.807)
IRARMCVL entry point in IRARMCTL (VS2.03.807)
function 3-43.4,3-43.7 (VS2.03.807)
IRARMERR object module
function 3-9
IRARMERR object module (YS2.03.807)
entry point summary 3-9.13 (VS2.03.807)
function 3-5 (VS2.03.807)
IRARMEVT object module
function 3-12
overview of functions 3-11
IRARMEVT object module (YS2.03.807)
entry point summary 3-22.6 (VS2.03.807)
function 3-12 (VS2.03.807)
IRARMHIT entry point in IRARMWLM (VS2.03.807)
function 3-73.2,3-73.4 (VS2.03.807)
IRARMILO entry point in IRARMIOM (YS2.03.807)
function 3-58,3-61.0 (VS2.03.807)
IRARMIL2
function 3-56
IRARMINT object module
function 3-6
IRARMINT object module (VS2.03.807)
entry point summary 3-9.0 (VS2.03.807)
function 3-6 (YS2.03.807)
(IRARMIOM object module
function 3-54
IRARMIOM object module (YS2.03.807)
I-tO
OS/VS2 System Logic Library Yolume 3 (VS2.03.8tO)
entry point summary 3-61.0 (VS2.03.807)
function 3-54 (VS2.03.807)
IRARMIPS entry point in IRARMEVT (YS2.03.807)
entry point description 3-22.6 (VS2.03.807)
IRARMI04 entry point in IRARMSRV (VS2.03.807)
function 3-9.6,3-9.13 (VS2.03.807)
IRARMI05 entry point in IRARMSRV (VS2.03.807)
function 3-9.8,3-9.13 (VS2.03.807)
IRARMMS2
function 3-52
IRARMRMR object module (VS2.03.807)
entry point summary 3-67.2 (VS2.03.807)
function 3-45.1 (YS2.03.807)
IRARMRM 1 entry point in IRARMRMR (YS2.03.807)
function 3-66,3-67.2 (VS2.03.807)
IRARMRM2 entry point in IRARMRMR (YS2.03.807)
function 3-67.0,3-67.2 (YS2.03.807)
IRARMSET object module
function 3-32
IRARMSRV object module
function 3-48, 3-32, 3-42, 3-40, 3-6
IRARMSRV object module (YS2.03.807)
entry point summary 3-9.13 (YS2.03.807)
function 3-9.2 (VS2.03.807)
IRARMSTM object module
function 3-46
IRARMSTM object module (YS2.03.807)
entry point summary 3-51.2 (VS2.03.807)
function 3-46 (VS2.03.807)
IRARMWAR object module
function 3-70
IRARMWAR object module (VS2.03.807)
entry point summary 3-73.10 (VS2.03.807)
function 3-69 (VS2.03.807)
IRARMWLM object module
function 3-70
IRARMWM2 entry point in IRARMWLM (YS2.03.807)
function 3-70,3-73.4 (VS2.03.807)
IRARMWM3 entry point in IRARMWLM (VS2.03.807)
function 3-73.0,3-73.4 (VS2.03.807)
IRARMWR 1 entry point in IRARMWAR (YS2.03.807)
function 3-73.6,3-73.10 (VS2.03.807)
IRARMWR3 entry point in IRARMWAR (VS2.03.807)
function 3-73.8,3-73.10 (VS2.03.807)
IRBMF ALL object module
function 3-80-3-81
IRBMFANL object module
function 3-86
IRBMFCNV object module
function 3-147, 3-151
IRBMFDCP object module
function 3-118
IRBMFDDP object module
function 3-134
IRBMFDEA object module
function 3-106-3-107
IRBMFDHP object module
function 3-130
IRBMFDPP object module
function 3-122
IRBMFDTA object module
function 3-106
IRBMFDWP object module
function 3-126
IRBMFECH object module
function 3-140
IRBMFEDV object module
function 3-144
IRBMFEVT object module
function 3-138
IRBMFICP object module
function 3-96
IRBMFIDV object module
function 3-104
IRBMFIHA object module
function 3-100
IRBMFINP object module
function 3-84
use of 3-80, 3-86
IRBMFIOI object module
VS2.03.810
function 3-95, 3-111
IRBMFIPG object module
function 3-96
IRBMFIPP
function 3-96
IRBMFIWK object module
function 3-98
IRBMFMFC object.module
function 3-80
IRBMFMPR object module
function 3-112
IRBMFRCR object module
function 3-150
IRBMFRDR object module
function 3-150
IRBMFRGM object module
function 3-146
IRBMFRHR object module
function 3-150
IRBMFRPR object module
function 3-150
IRBMFRWR object module
function 3-150
IRBMFSAR object module
function 3-147
IRBMFSDE object module
function 3-82-3-83
IRBMFTCH object module
function 3-142
IRBMFTMA object module
function 3-110
IRBMFTRM object module
function 3-111
ISV (internal service value) (VS2.03.807)
in individual user evaluation (IRARMWM3)
(VS2.03.807)
in swappable user evaluation (IRARMWM2)
(VS2.03.807)
item, defined in MF/l syntax analyzer 3-86
3-73.0
3-70
JCL data set reading from 3-226
JCL statement (see also converter)
comment, checking for 3-226
continuation, checking for 3-226
converting statements to internal text 3-236
DD processing 3-229
EXEC processing 3-229
identifying verbs on 3-226-3-229
merging from JCL data set and procedure library
3-229
null processing 3-229
JCL to JCLS conversion
function 3-176-3-177
JCLS to SWA conversion
function 3-177, 3-179
JCT (job control table)
in ABENDed job restart preparation 3-516
in allocation/initiator interface 3-396
in automatic checkpoint/restart 3-498.
in building a step header record for the job journal
3-512
in DD function control 3-322
in dynamic allocation control 3-414
in dynamic unallocation 3-416
in initiator/al1ocation interface 3-396
in initiator/unallocation interface 3-402
in interpreter
creating and chaining tables 3-252
writing tables into SWA 3-256
in JLOCATE 3-334
in job deletion 3-208
in job initiation 3-196
in job unallocation 3-410
in merge cleanup 3-502
in step continue processing 3-494
in step deletion 3-208
in step initiation 3-200
in SVC 99 control 3-412
in unallocation/initiator interface 3-402
JCTX (job control table extension) (VS2.03.804)
SWA manager id 3-261 (VS2.03.804)
writing tables into SW A 3-256,3-257 (VS2.03.804)
JES exit in converting JCL statements to internal text
3-238-3-239
JESCT (job entry subsystem control table)
in common request router 3-172
in data set name assignment 3-188
in subsystem determination 3-174
in subsystem interface 3-159
JES2/3
function codes 3-161
notified of step initiation 3-202
system interface 3-171-3-191
JES3
flags used by common unallocation control 3-430
interf ace routine
function 3-282-3-283
multi-unit, nonspecific volume requests, checking 3-382
JFCB (job file control block)
DCB information in, completion 3-322
DISP information in, completing 3-322
in allocate request to unit 3-302
in allocating offline devices 3-366
in allocation via algorithm 3-348
in allocation/initiator interface 3-396
in allocation/volume mount and verfiy (VM & V)
interface 3-386
in common allocation cleanup 3-378
in common allocation control 3-280
in common un allocation 3-432
in data set descriptor records, processing 3-486
in data set name assignment 3-188
in DD function control 3-322
in demand allocation 3-355
in disposition processing 3-440
in dynamic allocation control 3-414
in dynamic information retrieval 3-422
in fixed device control 3-294
in generic allocation control 3-338
in initiator/allocation interface 3-396
in initiator/unallocation interface 3-402
in interpreter 3-252
in JFCB housekeeping control 3-314
in JLOCATE 3-334
in job unallocation 3-410
in nonspecific volume allocation control 3-308
in recvery allocation 3-358
in SVC 99 control 3-414
in switching SMF data sets 3-454
in unallocation/initiator interface 3-402
in volume mount and verify (VM & V)/allocation
interface 3-386
in writing SMF records 3-450
JFCB housekeeping
functions 3-314
STEPCA T request processing 3-314
JFCBE (job file control block extension for 3800 printer)
(VS2.03.810)
in checkpoint/restart 3-483, 3-499, 3-501, 3-522, 3-523,
3-525 (VS2.03.810)
in interpreter 3-245, 3-249, 3-255 (VS2.03.810)
JFCBX (job file control block extension)
in allocation/initiator interface 3-396
in checkpoint/restart 3-483 (VS2.03.810)
in common allocation control 3-280
in disposition processing 3-440
in dynamic allocation control 3-414
in initiator/allocation interface 3-396
in initiator/unallocation interface 3-402
in interpreter 3-245 (VS2.03.810)
in SVC 99 control 3-412
in unallocation/initiator interface 3-402
JLOCATE (IEFAB469) processing 3-334
JMR (job management record)
in converter initialization 3-224
in converter termination 3-242
in interpreter, initialization 3-246
in interpreter, writing tables into SWA 3-256
in SWA create interface 3-216
Index
1-11
j
VS2.03.810
JNLPARM
in writing blocks to the job journal 3-520
job account table, use in step and job deletion (initiator)
3-208
job control language (see JCL)
job entry subsystem (JES)
interface 3-159
job initiation 3-196
job journal
building step header record for 3-512
changes for VS2 Release 3 3-483
errors during reconstruction 3-508
in step initiation 3-202-3-203
journal for restarted jobs 3-524
journal merge error processing 3-508
journal merge reading 3-506
merge cleanup 3-502-3-503
merging job step entries onto the SWA 3':'494, 3-492
overview 3-483
step header record, building 3-512
writing
blocks to 3-520-3-523
in preparing ABENDed job for restart 3-518-3-519
JOB statement, checking 3-249
JOBCAT DD statement, processing 3-249
JOBLIB
in interpreter 3-249
in step initiation 3-204
job delete routine
function 3-210
job scheduler
overview 3-153
job select routine
function 3-196, 3-198
job status indicators
in SWA create interface 3-216-3-217
setting in JSCB and JCT by step initiator 3-203
job step, ABENDed, preparing for restart 3-516
job, step allocation (see step allocation)
job termination
for a subsystem 3-190
job time limit, calculating in step initiator 3-202
job unallocation
functions 3-410
interface with initiator 3-402
parameter list for initiator interface 3-402
JOBSELCT SYSEVENT code (8)
in workload manager 3-71
processing in SRM SYSEVENT code processor 3-13
JOBTERM SYSEVENT code (9)
in workload manager 3-71
processing in SRM SYSEVENT code processor 3-13
journal (see job journal)
journal merge
loading journal merge routine 3-246
processing 3-492
journal merge routine
function 3-492, 3-496, 3-498!3-509, 3-216, 3-494
journal write routine
function 3-520, 3-202, 3-524, 3-512, 3-518
JSCB (job step control block)
in ABENDed job restart preparation 3-516
in allocation/initiator interface 3-396
in automatic step restart 3-500
in building a step header record for the job journal
3-512
in common allocation cleanup 3-378
in common allocation control 3-280
in data set descriptor records processing 3-486, 3-492
in ddname allocation control 3-428
in dynamic allocation 3-414
in dynamic concatenation 3-418
in dynamic deconcatenation 3-420
in dynamic information retrieval 3-422
in dynamic unallocation control 3-416
in initiator/allocation interface 3-396
in initiator/unallocation interface 3-402
in JFCB housekeeping control 3-314
in JLOCATE 3-334
in job initiation 3-196
1-12
OS/VS2 System Logic Library Volume 3 (VS2.03.810)
in journal merge error processing 3-508
in log initialization 3-466
in merge cleanup 3-502
in merging job journal to SWA 3-492
in nonspecific volume allocation control 3-308
in remove in-use control routine 3-424
in remove in-use attribute 3-424
in restart interface processing 3-510
in subsystem interface 3-159
in SVC 99 control 3-412
in SWA create interface 3-216
in SWA manager locate mode 3-266
in system restart processing 3-496
in unallocation/initiator interface 3-402
in updating virtual addresses in SWA 3-504
in writing blocks to the job journal 3-520
in writing SMF records 3-450
keyword processing
in converting JCL statements to internal text
in parameter value analysis 3-248-3-249
3-236
LCA (log control area)
in log initialization 3-466
in terminating the system log 3-470
in writing data on the system log 3-480
LCCA (logical communications configuration area)
in CPU load balancing swap analysis 3-66
in CPU management (SRM) 3-62
in interval measurement gathering routine for CPU
3-118
in MFD ATA mainline 3-114
LCH
in I/O load balancing swap analysis 3-56
in I/O management (SRM) 3-54
LCT (linkage control table)'
in ABENDed job restart preparation 3-516
in allocation/initiator interface 3-396
in building a step header record for the job journal
3-512
in converter/interpreter interface 3-178
in initiator/allocation interface 3-396
in initiator/unallocation interface 3-402
in job initiation 3-196
in job deletion 3-208
in step continue processing 3-494
in step deletion 3-208
in step initiation 3-200
in subsystem initiation 3-176
in SWA create interface 3-216
in SWA manager locate mode 3-266
in unallocation/initiator interface 3-402
link pack area (see LPA)
listing MF/1 options 3-88
load balancing in SRM swap analysis
CPU 3-62
I/O 3-56
locating specific volume request 3-298
lock manager (see SETLOCK)
lock, SRM 3-25
locking services/considerations
in SRM 3-5
log data set (see system log)
log hardcopy (see hardcopy of system log)
log, system (see system log)
log task abnormal termination, processing
function 3-476
logical reconfiguration (see reconfiguration commands)
long wait processing in the SRM 3-49
main storage occupancy analysis (IRARMMS2) 3-52
mainline, initialization MFI 3-90
major name
in job initiation 3-198-3-199
master catalog, searching in JLOCATE (IEFAB469)
3-334-3-335
master JCL
VS2.03.810
conversion to SWA control blocks in
converter/interpreter interface 3-178
in data set name assignment 3-188-3-189
in sybsystem initiation 3-176-3-177
master subsystem
common request router 3-172
converter/interpreter interface 3-178
in data set name'assignment 3-188
in subsystem determination 3-174
in subsystem initiation 3-176
in subsystem initiation message writer 3-186
in subsystem job termination 3-190
interface overview 3-159
pseudo access method 3-182
MCT
in main storage occupancy analysis 3-52
in resource monitor MPL adjustment processing
(IRARMRM2) 3-67.0 (VS2.03.807)
in resource monitor periodic monitoring (IRARMRM 1)
3-66 (VS2.03.807)
in storage management (IRARMSTM) 3-46
(VS2.03.807)
in storage management (SRM) 3-46
in swap-in control 3-40
in timer action analysis 3-26
MEL (merge entrance list)
in automatic checkpoint/restart 3-498
in automatic step restart 3-500
in merging job journal to SWA 3-492
in step continue processing 3-494
in SWA create interface 3-216
MEMCREAT SYSEVENT code (6)
in SRM interface 3-7
processing in SRM SYSEVENT code processor 3-12
MEMDEL SYSEVENT code (7)
processing in SRM SYSEVENT code processor 3-12
merge of MF/1 options (see also options, MF/1)
in MF/1 control 3-80
merge cleanup for restart or step continue processing
3':502
merging job step entries in job journal 3-494
message processor for MF/l (IRBMFMPR) 3-112
MF/l
binary to channel conversion routine
function 3-147
channel event data sampling module
function 3-140
channel interval measurement gathering routine
function 3-130
channel measurements
initialization
function 3-100
sampling 3-140, 3-142
channel report generator
function 3-150
CPU measurement
initialization
function· 3-96
gathering
function 3-118
interval 3-118-3-121
CPU report generator
function 3-150
data control routine
function 3-106
data control ESTAE recovery routine
function 3-106-3-107
device event data sampling module
function 3-144
device interval measurement gathering routine
function 3-134
device measurements
initialization routine
function 3-104
interval 3-134
sampling 3-144
device report generator
function 3-150
dynamic allocation
function 3-80-3-81
event driven measurement routines
calling from MFROUTER 3-139
flowchart, inter-module 6-1577
function 3-111
general resource resource release routine
function 3-111
initialization (mainline) 3-90
initialization
for channel measurement 3-100
for CPU activity 3-96
for device measurement 3-104
for paging activity measurement 3-96
for workload measurement 3-98
input merge control
function 3-84
lOS initialization/termination routine
function 3-95, 3-111
list option module 3-88
mainline initialization 3-90
measurement facility control module
function 3-80
merge of options 3-84, 3-80
message processor
function 3-112
MFC (measurement facility control) module 3-80
MFDATA SVC mainline 3-114
MFROUTER SVC processor
function 3-138
MFST ART mainline processor
ESTAE routine
function 3-82-3-83
options, listing 3-88
options, merging 3-84, 3-80
overview of MF/l
3-75
paging activity initialization 3-96
paging measurements
initialization
function 3-96, 3-92
interval measurement gathering routine
function 3-122
paging report generator
function 3-150
recovery routine, EST AE 3-83
report generation
control EST AE routine
function 3-147
control module
function 3-146
modules for CPU, paging, workload, channels, and
devices 3-150
SARG function 3-77, 3-75
second CPU test channel sampling module
function 3-142
SMF-related records
for channels 3-133
for CPU 3-119
for devices 3-135
for paging 3-123
START parameters, processing of 3-81
stopping MF /1
3-81
syntax analyzer
function 3-86
SYSEVENT code (WKLDINIT) issued 3-99
termination
in measurement facility control 3-81
processing
function 3-110
visual table of contents 3-79
workload measurement
initialization 3-98
interval measurement gathering routine
function 3-126
report generator
function 3-150
MFC (measurement facility control), IRBMFMFC in MF/l
3-80
MFCOA (measurement facilities common options area, see
also INCOA, STCOA, and TMCOA)
in input merge control 3-84
in mainline initialization of MF/l 3-90
Index
1-13
VS2.03.8tO
in measurement facility control 3-80
in MFST ART mainline 3-82
in MF/1 data control 3-106
in MF/1 report generator control 3-146
MFDATA SVC routine (MF/l)
function 3-114
processing 3-114
MFIMAINL
function 3-90
MFLISTOP
function 3-88
MFMVT (measurement vector table for problem state
options, see also DTMVT, INMVT, STMVT, TMMVT)
in input merge control 3-84
in mainline initialization of MF/l 3-90
in measurement facility control 3-80
in MFST ART mainline 3-82
in MF/l report generator control 3-146
MFPCT (problem control table)
in measurement facility control 3-80
in MF /1 data control 3-106
MFPMA (problem measurement area, see also TMPMA)
in input merge control 3-84
in mainline initialization of MF/l 3-90
in MF/l rep rot generator control 3-146
MFROUTER service routine (IRBMFEVT) 3-138
MF/l channel initialization 3-100
MFSEL (subtask elements table)
in MF/l report generator control 3-146
MFST ART mainline (MF /1)
function 3-82, 3-80, 3-91
minor name (rname)
in job initiation enqueue parameter list 3-198-3-199
mount control blocks
building and contents
function 3-392-3-393
mount equalization for MSS volumes 3-291, 3-350, 3-370
mount failure for MSS volume 3-387
mount message, building, issuing; and verifying volumes
3-392-3-395
mounting a volume (see volume mount & verify)
MP (see multi-processor system)
MSRDA or BASEA (master scheduler resident data area)
in aUocation/initiator interface 3-398
in common allocation control 3-280
in initiator/allocation interface 3-398
in log initialization 3-466
in log task abnormal termination 3-478
in terminating the system log 3-470
in writing data on the system log 3-480
MSS
mount equalization 3-291, 3-350, 3-370
no A VR processing 3-341
MUG (multi-unit generic)
ensuring each request is allocated to a single generic
3-366
not successfully handled by algorithm 3-367
multiprogramming level (VS2.03.807)
definition/description 3-3 (VS2.03.807)
management to 3-3,3-23 (VS2.03.807)
in resource monitor periodic monitoring 3-66
(VS2.03.807)
in resource monitor MPL adjustment processing 3-67.0
sampling and adjusting 3-66,3-67.0 (VS2.03.807)
multi-unit generic (see MUG)
multi-unitlmulti-generic requests processing
function 3-348, 3-366
multi-unit requests
tape data sets, processing 3-380
unsuccessful processing 3-379
within a generic 3-317
multiple device type determination
function 3-326, 3-328
multiple request for the same unit
processing in fixed device control 3-299
MVCA
in allocation/volume mount and verify (VM & V)
interface 3-388
in volume mount and verify (VM & V) 3-392
MVCA chain processor
1-14
OS/VS2 System Logic Library Volume 3 (VS2.03.810)
function 3-390, 3-388, 3-394
MVCAX
in allocation/volume mount and, verify (VM & V)
interface 3-394
NEL (interpreter entrance list)
creation by master subsystem 3-178
in converter
initialization 3-224
processing commands in the input stream 3-230
termination 3-242
in SWA create interface 3-216
new address space (see address space)
NEWIPS SYSEVENT code (32)
in workload manager 3-71
processing in SRM SYSEVENT code processor 3-18
NIOW AIT SYSEVENT code (3)
in SRM storage management 3-47
processing in SRM SYSEVENT code processor 3-12
non-cancellable property as indicated in PPT 3-201
nonshareable device allocation 3-359
nonspecific volume allocation
allocation recovery 3-358
processing (IEFAB436) 3-308
types of requests
public volumes 3-308, 3-356
storage volumes 3-308
use with fixed device control in allocating to
permanently resident or reserved volumes
3-296-3-297
use with generic allocation in allocating to private
volume or public volume 3-344-3-345
non-swapable property as indicated in PPT 3-200
normal dynamic allocation control
function 3-414
"not ready" devices (in recovery allocation) 3-364-3-365
notification
to active subsystem (function codes) 3-161
occupancy analysis of main storage in SRM 3-52
offline/allocated device allocation 3-366
operator interface 3-374
processing
function 3-366
offline allocation requests 3-366
offlines/ allocateds, processing
function 3-374-3-375
OKSW AP SYSEVENT code (42)
in SRM interface 3-7
in workload manager 3-71
.processing in SRM SYSEVENT code processor 3-20
open checkpoint data set routine
function 3-487
OPEN processing 3-204
Operation (see Method of Operation Section)
operator cancelled jobs
processing in common allocation cleanup 3-382
operator console (see console)
options for MF/l
in. channel initialization 3-100
in CPU initialization 3-96
in device initialization 3-104
in the MFDATA SVC Mainline 3-114
in paging initialization 3-96
in workload initialization 3-98
listing 3-88
merging on input 3-84
validity checking 3-86
Organization (see Program Organization Section)
OUCB (system resources manager use control block)
in control swap-in (IRARMCSI) 3-40 (VS2.03.807)
in CPU management (IRARMCPM) 3-64 (VS2.03.807)
in CPU load balancing swap analysis 3-66
in deferred action processing 3-28
in individual user evaluation (IRARMWM3) 3-73.0
(VS2.03.807)
in partial analysis 3-36
in SRM interface 3-9
VS2.03.810
in storage management (IRARMSTM) 3-46
(VS2.03.807)
in swapp able user evaluation (IRARMWM2) 3-70
(VS2;03.807)
in swap-in control 3-40
in swap-out control 3-42
in timer action analysis 3-26
in user evaluation (IRARMCVL) 3-43.4 (VS2.03.807)
in user ready processing (IRARMHIT) 3-73.2
(VS2.03.807)
in workload management 3-70
OUT queue for SRM (VS2.03.807)
definition 3-23.0 (VS2.03.807)
in resource monitor periodic monitoring (IRARMRM 1)
3-67 (VS2.03.807)
in select user for swap-in (IRARMCPI) 3-43.0
(VS2.03.807)
in swap analysis (IRARMCAP) 3-36 (VS2.03.807)
in swappable user evaluation (lRARMWM2) 3-70
(VS2.03.807)
in user ready processing (IRARMHIT) 3-73.2
(VS2.03.807)
OUXB (system resources manager user extension block)
in control swap-in (lRARMCSI) 3-40 (VS2.03.807)
in CPU management (SRM) 3-62
in individual user evaluation (IRARMWM3) 3-73.0
(VS2.03.807)
in I/O management (IRARMIOM) 3-54 (VS2.03.807)
in storage management (IRARMSTM) 3-46
(VS2.03.807)
in SRM interface 3-9
in Swappable User evaluation (IRARMWMZ) 3-70
in user evaluation (IRARMCVL) 3-43.4 (VS2.03.807)
in user ready processing (IRARMHIT)
3-73.2
(VS2.03.807)
in control swap-in 3-41
in SYSEVENT processing in SRM SYSEVENT code
processor 3-12
in workload management 3-70
override processing in interpreter
in creating and chaining tables 3-254
in writing tables into SWA 3-257
packaging of SRM 3-3.2 (VS2.03.807)
page free request (see PGFREE)
page load (see PGLOAD)
page stealing 3-46-3-47
paging measurements for MF/l
initialization 3-97
parameter value analysis in interpreter 3-248
parse (see IKJP ARSE)
. parse of MF11 syntax 3-86
passed data set information scan
function 3-334
path, device (see device path)
PCCA (physical communications configuration area)
in interval measurement gathering routine for CPU
3-118
in MF/l channel initialization 3-101
in MF/l channel sampling module 3-140
PCCB (private catalog control block)
in JFCB housekeeping control 3-314
in JLOCATE 3-336
in step initiation 3-204
PCCB routine
function 3-336-3-337,3-314-3-315
PDI (passed data set information)
in DD function control 3-322
in JLOCATE 3-334
in job unallocation 3-410
searching 3-334
PD I read and chain
function 3-334-3-335
performance group descriptor (see WPGD) (VS2.03.807)
performance group period change
by workload manager 3-70, 3-72
performance objective
use by workload manager 3-71
permanently resident volumes
allocating request for 3-294
PFK (see program function key)
pool (see quick cell)
posting SMF
error exit 3-460
PPT (program properties table)
in step initiation 3-200
scan
function 3-200-3-20 I
r,rimary job entry subsystem initialization 3-176
'privileged" property (as indicated in program properties
table) 3-200-3-201
PRLIST 3-294
PROC statement 3-233
procedure, cataloged, processing 3-232
procedure, in-stream, processing 3-232
process job condition codes
function 3-406, 3-414
process TP requests
function 3-286-3-287
processors, command (see command processing)
PROCSTEP (procedure step) 3-226
program properties table
function 3-200-3-201
programmer, writing to (see WTP)
prompting exit (see pre-prompt exit, LOGON)
PSA (prefixed save area)
in MF11 channel sampling module 3-140
in MFII second CPU test channel sampling module
3-142
PSCB (protected step control block)
in dynamic allocation control 3-414
pseudo access method in subsystem initiation
control
function 3-182, 3-184
direct read and write
function 3-182-3-183
sequential read and write
function 3-184-3-185
PSLIST (public storage list)
in nonspecific volume allocation control 3-308
public volume allocation requests
in allocating nonspecific volume requests 3-308
in demand allocation 3-356
processing in fixed device control 3-294
PVT (page vector table)
.
in interval measurement gathering routine for paging
3-122
in main storage occupancy analysis 3-52
in resource monitor MPL adjustment processing
(IRARMRM2) 3-67.0 (VS2.03.807)
in storage management (lRARMSTM) 3-46
(VS2.03.807)
in swap-in control 3-40
QDB (queue descriptor block)
in dynamic allocation 3-414
in dynamic unallocation 3-416
in SVC 99 control 3-412
QMNGRIO macro interface handler
function 3-264
QMPA (queue management parameter area)
in converter
initialization 3-225
processing in-stream and cataloged procedures
3-232
in converterlinterpreter interface 3-178
in job deletion 3-210-3-211
in job initiation 3-196
in restart interface processing 3-510
in step deletion 3-210-3-211
in SW A create interface 3-216
in SW A manager locate mode 3-266
in SW A manager move mode 3-264
in writing blocks to the job journal 3-520
QSCEFL SYSEVENT code (18)
processing in SRM SYSEVENT code processor 3-15
QSCECMP SYSEVENT code (13)
in SRM CPU load balancing swap analysis 3-67
Index
1-15
YS2.03.810
in SRM CPU management 3-63
in SRM SYSEVENT code processor 3-14
in SRM workload manager 3-71
QSCEST SYSEVENT code (12)
in SRM I/O management (IRARMIOM) 3-54-3-55
in SRM SYSEVENT code processor 3-14
queue manager processing
in SWA manager move mode 3-264
quiesce processing
in SRM swap-out control 3-42
RACF accessor environment (YS2.03.804)
deleting 3-193,3-197 (YS2.03.804)
initializing 3-216,3-217 (YS2.03.804)
writing JCTX into SWA 3-256,3-257 (YS2.03.804)
RCT (YS2.03.807)
in resource monitor MPL adjustment processing
(IRARMRM2) 3-67.0 (YS2.03.807)
in resource monitor periodic monitoring (IRARMRM 1)
3-66 (YS2.03.807)
read
in pseudo access method 3-182
READ macro instruction
in SWA manager move mode 3-264-3-265
READ/LOCATE commands 3-266
real frame (see page frame)
real page shortage in SRM 3-52-3-53
real timer interval requests 3-508
recording, error (see error recording) .
recovery allocation (IEFAB485) (see also allocation)
conditions that cause execution of 3-289
interface with operator
function 3-374, 3-364
online devices
function 3-377
processing
function 3-358
type requests that need recovery or retry 3-305
recovery, error (see error recovery EST AI)
recovery, FRR (see functional recovery routine)
recovery reply options processor
function 3-374, 3-376
recovery routine (see also functional recovery routine)
3-83
for MF/l
REGION parameter 3-201
release data set
function 3-396-3-397
remove in-use attribute routine (IEFDB480)
functions 3-424
remove in-use control routine
function 3-424
remove in-use processor
function 3-416, 3-426
report generators, MF /1, calling
in data control 3-109
in report generation control 3-146-3-147
REQSERVC sysevent code, processing 3-19
REQSVDAT SYSEVENT code (YS2.03.807)
processing in SRM SYSEVENT code processor 3-22.5
(YS2.03.807)
request router, common 3-172
request subsystem services function codes 3-161
requests, allocation
not satisfied
processing in common allocation clean-up
(IEFAB490) 3-378
retry criteria 3-379
satisfied
processing in common allocation clean-up 3-378
multi-unit tape data sets, processing 3-380
volume mount & verify interface 3-380
requests, region (see region requests)
reserved volume allocation requests
processing in fixed device control (IEFAB430) 3-294
RESETPG SYSEVENT code (31)
processing in SRM SYSEVENT code processor 3-17
use by workload manager 3-71
resource factor coefficient, use of (RFC)
in SRM CPU management 3-65
1-16
OS/VS2 System Logic Library Yolume 3 (VS2.03.810)
in SRM I/O management 3-55
resources manager (see system resources manager)
resource monitor MPL adjustment (YS2.03.807)
processing (IRARMRM2) 3-67.0,3-67.3 (YS2.03.807)
resource monitor periodic monitoring (YS2.03.807)
(IRARMRMl) 3-66,3-67.3 (YS2.03.807)
restart (see also checkpoint/restart, DSS)
automatic step 3-500
interface routine
function 3-510-3-511
system
processing 3-496
restart preparation routine
function 3-516
restarting (see restart)
retry
overview 3-273
processing in common allocation clean-up 3-379
rewinding requests, processing in volume mount and verify
3-390
RLCT
in I/O load balancing swap analysis 3-56
in I/O management (SRM) 3-54
RMCA
in CPU load balancing swap analysis 3-66
in CPU management (SRM) 3-62
in I/O load balancing swap analysis 3-56
in I/O management (SRM) 3-54
in partial analysis 3-36
in workload management 3-72
RMCT (system resources manager control table)
in algorithm request 3-30
in CPU load balancing swap analysis 3-66
in deferred action processing 3-28
in full analysis 3-34
in I/O load balancing swap analysis 3-56
in I/O management (SRM) 3-54
in main storage occupancy analysis 3-52
in partial analysis 3-36
in periodic entry point scheduling 3-32
in select user for swap-in (IRARMCPI) 3-43.0
(YS2.03;807)
in select user for swap-out (IRARMCPO) 3-43.2
(YS2.03.807)
in SRM control 3-23
in SRM interface 3-5
in SRM service routine (IRARMSRV) 3-9.8
(YS2.03.807)
in storage management (IRARMSTM) 3-46
(YS2.03.807)
in swap analysis (IRARMCAP) 3-36 (YS2.03.807)
in swappable user evaluation (IRARMWM2) 3-70
(YS2.03.807)
in swap-in control 3-40
in timer action analysis 3-26
in user ready processing (IRARMHIT) 3-73.2
(YS2.03.807)
in workload management 3-69
RMEP
in periodic entry point scheduling 3-32
in storage management (IRARMSTM) 3-46
(YS2.03.807)
used in processing actions/algorithms 3-23.2,3-23.3
(YS2.03.807)
RMPT
in CPU management (SRM) 3-62
in partial analysis 3-36
in periodic entry point scheduling 3-32
route requests to active subsystems 3-172
RPL (request parameter list)
in log writer processing 3-474
in pseudo access method 3-182
in subsystem initiation message writer 3-186
RPL/ ACB interface
in subsystem initiation message writer 3-186
in pseudo access method 3-182
RRPA
in collect data for MF/l (IRARMWR3) 3-78.8
(YS2.03.807)
in full analysis 3-34
VS2.03.810
in user evaluation (IRARMCVL) 3-43.4 (VS2.03.807)
RSM (see real storage manager)
RSMCNSTS SYSEVENT code (22)
processing in SRM SYSEVENT code processor 3-16
RSTORCMP SYSEVENT code (19)
processing in SRM SYSEVENT code processor 3-15
use by SRM workload manager 3-71
RTB (response/throughput bias) (VS2.03.807)
in user evaluation (IRARMCVL) 3-43.4 (VS2.03.807)
R/TM (see recovery termination)
RV (recommendation value) (VS2.03.807)
in CPU management (IRARMCPM) 3-63 (VS2.03.807)
in select user for swap-in 3-43.0 (VS2.03.807)
in select user for swap-out 3-43.2 (VS2.03.807)
in swap analysis 3-37 (VS2.03.807)
in user evaluation 3-43.5 (VS2.03.807)
)
.'
scan dictionary
in converting statements to internal text 3-236
scheduler (see job scheduler)
scheduling, SRM periodic entry point IRARMCET 3-32
scratch requests 3-358
screen image buffer (see SIB)
SCT (step control table)
in ABENDed job restart preparation 3-518
in allocation/initiator interface 3-396
in data set descriptor records, processing 3-486
in DD function control 3-322
in dynamic allocation 3-414
in dynamic information retrieval 3-422
in dynamic unallocation control 3-416
in initiator/allocation interface 3-396
in interpreter
creating and chaining tables 3-252
writing tables into SWA 3-256
in JFCB housekeeping control 3-314
in job deletion 3-208
in step continue processing 3-494
in step deletion 3-208
in step initiation 3-200
in SVC 99 control 3-412
searching for volser in UCBs (in job unallocation) 3-411
SECHT
in SRM interface 3-5
second CPU test channel sampling module (IRBMFTCH),
function 3-142
second level interrupt handler (see SLIH)
security environment (RACF) (VS2.03.804)
deleting 3-193,3-197 (VS2.03.804)
initializing 3-216,3-217 (VS2.03.804)
writing JCTX into SWA 3-256,3-257 (VS2.03.804)
select user for swap-in (IRARMCPI) 3-43.0 (VS2.03.807)
select user for swap-in (IRARMCPO) 3-43.2 (VS2.03.807)
SETDMN SYSEVENT code (VS2.03.807)
processing in SRM SYSEVENT code processor 3-20
(VS2.03.807)
setting domains 3-20 (VS2.03.807)
sequential read
in pseudo access method 3-182
sequential write
in pseudo access method 3-182
serialization
in common allocation control 3-282
service rate
explanation of use by SRM workload manager 3-69
shared data set attributes, replacing in job initiation 3-199
SIB (screen image buffer)
signal processor (see SIGP instruction)
single line message (see WTO)
SlOT (step I/O table)
completing DCB information in 3-329
completing DISP information in 3-333
copying unit information into 3-331
in allocate request to unit 3-302
in allocating offline devices 3-366
in allocation/initiator interface 3-396
in allocation/volume mount and verify (VM & V)
interface 3-386
in allocation via algorithm 3-348
in common allocation cleanup 3-378
in common allocation control 3-280
in common unallocation 3-432
in data set descriptor records processing 3-486
in DD function control 3-322
in demand allocation 3-355
in disposition processing 3-440
in dynamic allocation control 3-414
in dynamic concatenation 3-418
in dynamic information retrieval 3-422
in dynamic deconcatenation 3-420
in dynamic unallocation control 3-416
in fixed device control 3-294
in generic allocation control 3-338
in initiator/allocation interface 3-396
in initiator/unallocation interface 3-402
in interpreter 3-252
in JFCB housekeeping control 3-314
in JLOCATE 3-334
in job unallocation 3-410
in nonspecific volume allocation control 3-308
in recovery allocation 3-358
in remove in-use processor 3-424
in specific volume allocation 3-298
in SVC 99 control 3-412
in unallocation/initiator interface 3-402
in unit unallocation processing 3-444
selecting in non-specific allocation control 3-308
SMCA (system management control area)
in SMF cross-memory post error exit 3-460
in ST AE exit processing for SMF 3-458
in switching SMF data sets 3-454, 3-456
in volume mount and verify (VM & V) / allocation
interface 3-386
in writing SMF records 3-450
SMF (System Measurement Facility)
cross-memory post error exit routine
function 3-460
in converter
initialization 3-224
dynamic dd routine
function 3-418
exit in step initiation 3-200
initialization exit support module
function 3-200-3-201
interface to interpreter 3-256
record manager
function 3-452, 3-450-3-451
record writing
function 3-450-3-451, 3-456, 3-452, 3-454
records, writing
in MF /1 routine for channels 3-131
in MF/l routine for CPU 3-119
in MF/l routine for devices 3-135
in MF/l routine for paging 3-123
in MF/l routine for workload 3-127-3-129
in step initiation 3-200
STAE exit processing
function 3-458
SYSEVENT REQPGDAT (39) issued to obtain paging
data 3-20
TCTIOT construction interface
function 3-206
SMF data set
in MFDATA mainline 3-115
opening of 3-450
opening of alternate 3-454
splitting 3-454, 3-453
switching 3-454, 3-452, 2-303
SMF records
count of, updating 3-456
splitting 3-452
space, address (see address space)
special protect key 3-200
specific volume allocation control
processing
function 3-298
use with fixed device control 3-295
use with generic allocation 3-344
SQA
Index
1-17
YS2.03.810
in MF /1 device initialization 3-46
SQALOW SYSEVENT code (25)
processing in SRM SYSEVENT code processor 3-16
in SRM storage management 3-50-3-51
SRM (see also system resources manager)
algorithm processor 3-23, 3-23.2, 3-23.3, 3-24
(YS2.03.807)
3-73.8 (YS2.03.807)
collect data for MF/1
control algorithm 3-23
control swapin routine 3-40
control swapout routine 3-42
CPU load balancing swap analysis 3-66
CPU management routines 3-62
deferred action processor 3-28
FRR 3-9
full analysis retry function 3-34
individual user evaluation 3-73.0 (YS2.03.807)
3-73.6 (YS2.03.807)
initialize for MF/1
interface module 3-6
I/O load balancing swap analysis routine 3-56
I/O management routines 3-54
I/O load balancing user I/O monitoring 3-58
. (YS2.03.807)
main storage occupancy routine 3-52
module/entry point cross reference 3-3.2, 3-3.3
(YS2.03.807)
nonresident set to new IPS routine 3-32
obtain/free SQA storage 3-9.6 (YS2.03.807)
partial analysis routine 3-36
periodic entry point scheduling routine 3-32
processing algorithms and actions 3-23, 3-23.2, 3-23.3
(YS2.03.807)
requeue SRM TQE 3-9.8 (YS2.03.807)
resource monitor MPL adjustment processing 3-67.0
(YS2.03.807)
resource use algorithms, overview 3-45
resource monitor periodic monitoring 3-66
(YS2.03.807)
RMEP algorithm and action invocation flags 3-23.3
(YS2.03.807)
select user for swap-in 3-43.0 (YS2.03.807)
select user for swap-out 3-43.2 (YS2.03.807)
service routine 3-9.2 (YS2.03.807)
storage management routines 3-46
supervisor service request routine 3-48, 3-32, 3-42, 3-40
swap analysis 3-36 (YS2.03.807)
swappable user evaluation 3-70 (YS2.03.807)
sysevent processor 3-11
sysevent routers and processors 3-12
timer action analysis 3-26
user evaluation 3-43.4 (YS2.03.807)
user ready processing 3-73.2 (YS2.03.807)
uses ASM and RSM 3-3 (YS2.03.807)
workload activity recording routine 3-70
workload management function, overview 3-69
workload manager algorithm module 3-70
SSCVT (subsystem communications vector table)
in common request router 3-172
in subsystem determination 3-174
in subsystem interface 3-159
SSIB (subsystem identification block)
in common request router 3-172
in data set name assignment 3-188
in job initiation 3-196
in log initialization 3-466
in subsystem determination 3-174
in subsystem initiation 3-176
in subsystem interface 3-159
in switching log data sets 3-472
in terminating the system log 3-470
SSOB (subsystem options block)
in common request router 3-172
in converter/interpreter interface 3-178
in data set name assignment 3-188
in job initiation 3-196
in log initialization 3-466
in subsystem determination 3-174
in subsystem initiation 3-176
in subsystem interface 3-159
in subsystem job termination 3-190
1-18
OS/YS2 System Logic Library Yolume 3 (VS2.03.810)
SSVT (subsystem vector table)
in subsystem interface 3-159
stack, FRR ( see FRR stack)
STAE (set task asynchronous exit)
for SMF 3-458
START command (see also START/LOGON/MOUNT
overview) .
parameters used by MF / 1 START command 3-84,
3-80
statement (see JCL statement)
status, console (see console status)
STC (started task control)
SWA sub pool for 3-267
step allocation processing in initiator/allocation interface
3-396
step continue processing (IEFXB60l) 3-494
step delete routine
function 3-208
step header reocrd, for job journal, building
function 3-512, 3-514, 3-202
step initiation 3-200
step, preparing for allocation 3-396
step restart
automatic, job journal processing for 3-500
reconstructing SWA for 3-216
step time processing if job step is canceled 3-207
step unallocation 3-402
STEPCAT requests 3-314
STEPL (ST AE exit parameter list)
in job initiation 3-196
STCOA (common option area for supervisor state options,
see also INCOA, MPCOA, TMCOA)
in mainline initialization of MF/l 3-90
STGST (global supervisor table)
in mainline initialization of MF/l 3-90
in MF /1 workload initialization 3-98
STMMV
in MFROUTER processor 3-138
in MF/1 channel initialization 3-100
in MF /1 device initialization 3-104
STMVT (measurement vector table for supervisor state
options, see also DTMVT, INMVT, MFMVT, TMMVT)
in mainline initialization of MF/l 3-90
STOP command
MF /1 enabling use of 3-80
STOP command for MF/l
in data control routine 3-108, 3-106
in measurement facility control 3-80
STOP processing 3-196-3-197
STOP MONITOR command
storage deletion routine
function 3-176-3-177
storage volume allocation requests
in fixed device allocation (IEFAB430) 3-295
in nonspecific volume allocation control 3-309
storage management (see real storage manager, virtual
storage management, system resources manager)
STPRT
in MF/1 channel initialization 3-100
in MF /1 CPU initialization 3-96
in MF /1 device initialization 3-104
in MF/l l'aging initialization 3-96
in MF/l workload initialization 3-98
stream, input (see converter)
structure, examining alternatives in MF/1 syntax analyzer
3-86
STRVT (resource vector table)
in mainline initialization of MF /1 3-90
STSCT (supervisor control table)
in mainline intialization of MF /1
3-90
in MF/1 termination processor 3-110
STSGT
in channel interval measurement gathering routine
3-130
in interval measurement gathering routine for CPU
3-118
in interval measurement gathering routine for devices
3-134
in interval measurement gathering routine for paging
3-122
VS2.03.810
in interval measurement gathering routine for workload
3-126
in MFDATA mainline 3-114
in MFROUTER processor 3-138
in MF /1 channel initialization 3-100
in MF/l CPU initialization 3-96
in MF /1 device initialization 3-104
in MF /1 paging. initialization 3-96
in MF/1 termination processor 3-110
STSMA (supervisor measurement table)
in channel interval measurement gathering routine
3-130
in interval measurement gathering routine for CPU
3-118
in interval measurement gathering routine for devices
3-134
in interval measurement gathering routine for paging
3-122
3-90
in mainline initialization of MF/1
in MFDATA mainline 3-114
in MF/1 channel initialization 3-100
in MF/1 CPU initialization 3-96
in MF/1 device initialization 3-104
in MF/1 paging initialization 3-96
in MF/1 workload initialization 3-98
subsystem allocation requests, processing in common
allocation control 3-281
subsystem determination
function 3-174
subsystem initiation 3-176
in converter/interpreter interface 3-178
in data set name assignment 3-188
in pseudo access method 3-182
message writer
function 3-186
processing
function 3-176
subsystem/initiator SWA interface
function 3-216
subsystem interface
function codes 3-161
introduction 3-159
subsystem job termination
function 3-190
subsytem name, determination of 638
subsystem, routing request to 3-172
supervisor state, putting initiator task into 3-197
SVC interruptions (see supervisor interruptions handler)
SVC 34
commands in the input stream, processing 3-230
SVC 99 control (IEFDB400) 3-412
in JLOCATE 3-337
SVC 109 (see extended SVC routing)
SVC 116 (see extended SVC routing)
SVC 122 (see extended SVC routing)
SVCIH (see supervisor interruption handler)
SWA (scheduler work area)
block length 3-265
in automatic checkpoint/restart 3-498
in automatic step restart 3-500
in converter/interpreter interface 3-180
in data set descriptor records processing 3-486
in job initiation 3-196
in merge cleanup 3-502
in SWA manager locate mode 3-266
in SWA manager move mode 3-264
in system restart processing 3-496
interface to in-stream and cataloged procedures 3-233
interpreter writing tables into SWA 3-256
merging from job journal 3-492
virtual address in SWA, updating 3-504
SWA conversion from JCLS
function 3-177, 3-179
SWA create interface
function 3-216-3-217
SWA manager
function code 3-264
interface to in-stream and cataloged procedure
processing 3-233
interface to interpreter 3-256
interface to job step allocation 3-397
interface to job unallocation 3-411
interface module
function 3-264
locate mode
function 3-266
move mode
function 3-264
SW A merge processing 3-492, 3-503
SWA prefix
in SWA manager move mode 3-265
in SWA manager locate mode 3-267
SWA reader routine
function 3-396, 3-412
SWA reconstruction processing
in journal merge error processing 3-509
in restart processing 3-511
SWA subpool
alternation 3-267
SWA virtual address
in SW A manager move mode 3-265
in SW A manager locate mode 3-267
swap (VS2.03.807)
in SRM exchange swap 3-23.0 (VS2.03.807)
swap analysis 3-36 (VS2.03.807)
swap analysis in SRM
CPU 3-62
in partial analysis routine (IRARMCAP) 3-36
I/O load 3-56
"swap package", definition of 3-37
swap-in (VS2.03.807)
in SRM express swap-in 3-23.0 (VS2.03.807)
in SRM select use for swap-in (IRARMCPI) 3-43.0
(VS2.03.807)
in SRM unilateral swap-in 3-23.0, 3-40 (VS2.03.807)
swap-in, address space
in SRM control swap-in (IRARMCSI) 3-40
in SRM I/O management routine (IRARMIOM) 3-54,
3-57
storage evaluation for in SRM partial analysis 3-36
swap-in, timer dependent, in SRM timer action analysis
(IRARMCAT)
3-26
swap-out (VS2.03.807)
in SRM select use for swap-out (IRARMCPO) 3-43.2
(VS2.03.807)
in SRM unilateral swap-out 3-23.0, 3-42 (VS2.03.807)
swap-out, address space
in SRM control swap-out 3-42
in SRM I/O load balancing swap analysis 3-56
in SRM partial analysis 3-36
timer dependent, in SRM timer action analysis
(IRARMCAT) 3-26
SWINFL SYSEVENT code (17)
processing in SRM SYSEVENT code processor 3-15
switching SMF data sets 3-454, 3-452, 2-303
switching system log data sets (IEEMB803) 3-472
SWOUTCMP SYSEVENT code (15), processing in SRM
SYSEVENT code processor 3-15
SWPINST SYSEVENT code (VS2.03.807)
processing in SRM SYSEVENT code processor 3-16
(VS2.03.807)
symbolic parameters, processing in the converter 3-234
syntax analyzer of MF/l input (IRBMFANL) 3-86
syntax checker for allocation
function 3-424, 3-420, 3-422, 3-428, 3-418, 3-416
syntax errors in JCL symbolic parameters, scanning for in
converter 3-235
SYQSCCMP SYSEVENT code (36)
processing in SRM SYSEVENT code processor 3-18
SYQSCST SYSEVENT code (35)
processing in SRM SYSEVENT code processor 3-18
SYSCHK DD statement processing in converter 3-229
SYSEVENT codes
MF/1 related 3-98
processing 3-12-3-22
in SRM CPU management 3-63
in SRM CPU swap load balancing analysis 3-67
in SRM interface 3-5-3-9
in SRM workload manager 3-71
tracing 3-6
Index
1-19
VS2.03.810
SYSEVENT List 3-11 (YS2.03.807)
SYSOUT data set name
assigning for subsystem initiation 3-188
System Activities Measurement Facility (see MF/t)
system log
allocating new 3-472
ESTAE processor
function 3-476
initialization 3-466
initializing log data set 3-466
message module
function 3-472, 3-468
switching 3-472
terminating 3-470
abnormally 3-476
unallocating
current 3-472
during termination 3-470
writer processing 3-474
writing 3-480, 2-306
system log data set (see system log)
system log initialization
writer module
function 3-466, 3-470, 3-474, 3-472
System Measurement Facility (see SMF)
system message interface routine
function 3-380, 3-398, 3-400
system parameter library (see SYS1.PARMLIB)
system reconfiguration (see reconfiguration commands)
system resources manager (SRM) (see also workload
manager) 3-3
algorithms
in periodic entry point scheduling 3-32
resource use algorithms, introduction to 3-45
algorithm request routine 3-30
allocated UCB list, use of 3-310-3-311
analysis routines
full 3-34
partial 3-36
automatic priority group (APG) management 3-45.1
(YS2.03.807)
auxiliary slot shortage prevention 3-45 (YS2.03.807)
consists of five functional groups (YS2.03.807)
control function 3-3 (YS2.03.807)
interface function 3-3 (YS2.03.807)
resource use algorithm 3-3 (YS2.03.807)
sysevent processor 3-3 (YS2.03.807)
workload manager 3-3 (YS2.03.807)
control routine 3-23,3-25
control swap-in routine 3-40
control swap-out routine 3-42
CPU management 3-62
CPU load balancing swap analysis 3-66
deferred action processor 3-28
domain MPL adjustment routine 3-67.0 (YS2.03.807)
ENQ/DEQ algorithm 3-9.8 (YS2.03.807)
error processing 3-9
functional recovery routine 3-9, 3-7
how packaged 3-3.2 (YS2.03.807)
interface, general 3-5
interface
to UCB cnadidates list in offline/allocated device
allocation 3-371
interface routine (IRARMINT) 3-6, 3-5
in non-specific volume allocation control
3-312-3-313
with allocation in common allocation cleanup 3-382
introduction, general 3-3
I/O load balancing swap analysis 3-56
I/O management routine 3-54
lock, obtaining and releasing in full analysis routine
3-34
locking considerations for SYSEVENTs 3-5
main storage occupancy analysis 3-52
page replacement 3-45 (YS2.03.807)
pageable real storage shortage prevention 3-45
(YS2.03.807)
periodic entry point scheduling routine 3-32
PSLIST use 3-311
real page shortage prevention 3-45 (YS2.03.807)
1-20
OS!VS2 System Logic Library Yolume 3 (VS2.03.810)
resource monitor 3-45.1 (YS2.03.807)
resource use algorithms, introduction to 3-45
SQA shortage prevention 3-45 (YS2.03.807)
SRB analysis processing 3-34
SRB scheduling 3-23 (YS2.03.807)
storage management routine 3-46
swap evaluation 3-37
swap-in control routine 3-40
swap-out control 3-42
SYSEVENT code
locking considerations 3-5
MF/l related (WKLDINIT) 3-99
processing 3-11-3-22
time-driven queue
defintion of 3-3
timer action analysis 3-26
TQE
in periodic entry point scheduling 3-33
visual contents for HIPO diagrams 3-4
visual table of contents 3-4 (YS2.03.807)
workload manager
introduction to 3-69
routine 3-70
system restart
processing to cause restart at the next step 3-494
system, stopping (see stopping)
system trace (see trace, system)
system trace termination (see trace termination)
SYS1.LINKLIB, obtaining master JCL from in subsystem
initiation 3-176
SYS 1.PROCLIB
not opened successfully in subsystem initiation 3-177
tape label read
function 3-340, 3-418
tape unloading (YS2.03.804)
in unit allocation 3-445,3-446 (YS2.03.804)
TCB (task control block)
in allocation/initiator interface 3-396
in ABENDed job restart preparation 3-516
in common unallocation 3-430
in dynamic allocation control 3-414
in initiator/allocation interface 3-396
in initiator/unallocation interface 3-402
in job deletion 3-208
in log initialization 3-466
in merging job journal to SWA 3-492
in MFDAT A mainline 3-114
in remove in-use attribute 3-424
in step deletion 3-208
in step initiation 3-200
in subsystem interface 3-159
in SVC 99 control 3-412
in unallocation/initiator interface 3-402
in writing blocks to the job journal 3-520
TCT (timing control table)
in initiator/allocation interface 3-396
TCTIOT (timing control table I/O table)
in allocate request to unit 3-302
in dynamic allocation control 3-414
in step initiation 3-200
teleprocessing
allocation of device requests 3-286
terminal recognizer, calling in MF/l syntax analyzer 3-86
terinating allocation error processing (common allocation
cleanup) 3-378
termination, abnormal, log task 3-476
termination, system activities measurement 3-110
terminator (see initiator/terminator)
TERMWAIT SYSEVENT code (2)
processing in SRM SYSEVNET code processor 3-12
use by workload manager 3-69
text EXEC statement condition codes
function 3-500
test if device is ready
function 3-340-3-341
text, internal (see converter, internal text)
text keys, in ddname allocation 3-429
TGETTPUT SYSEVENT code (34)
VS2.03.810
\
!
I
processing in SRM SYSEVENT code processor 3-18
use by workload manager 3-71
time dependent swap-in processing 3-26
time driven queue (in SRM), definition of 3-3
time limit, step 3-202
timer action analysis in SRM 3-26
timer second level interrupt handler (see timer SLIH)
TIMEREXP SYSEVENT code (1)
processing in SRM SYSEVENT code processor 3-12
in periodic entry point scheduling 3-32-3-33
timing control in step initiation 3-202
TIOT (task input/output table)
in allocating offline devices 3-366
in allocation via algorithm 3-348
in common allocation cleanup 3-378
in common allocation control 3-280
in ddname allocation control 3-428
in demand allocation 3-355
in dynamic allocation control 3-414
in dynamic concatenation 3-418
in dynamic deconcatenation 3-420
in dynamic unallocation control 3-416
in dynamic information retrieval 3-422
in generic allocation control 3-338
in nonspecific volume allocation control 3-308
in recovery allocation 3-358
in remove in-use processor 3-426
in specific volume allocation 3-298
in step initiation 3-200
TIOT, expandable, build, update, rebuild
function 3-280-3-281, 3-302-3-303
TIOT manager control routine
function 3-396, 3-398, 3-418, 3-436
TPCA (see TPC)
TQE (timer queue element)
in MFROUTER processor 3-139
in requeue SRM TQE (IRARMI05) 3-9.8 (VS2.03.807)
in SRM periodic entry point scheduling 3-33
TSB (terminal status block)
in dynamic allocation control 3-414
TSO LOGON (see LOGON)
UCB (unit control block)
in allocate request to unit 3-302
in allocating offline devices 3-366
in allocation/initiator interface 3-396
in allocation/volume mount and verify (VM & V)
interface 3-386
in allocation via algorithm 3-348
in common allocation cleanup 3-378
in common allocation control 3-280
in common unallocation 3-430
in demand allocation 3-355
in dynamic allocation control 3-414
in dynamic unallocation control 3-416
in fixed device control 3-294
in generic allocation control 3-338
in initiator/allocation interface 3-396
in initiator/unallocation interface 3-402
in job unallocation 3-410
in MF/l device initialization 3-104
in MF /1 device sampling module 3-144
in nonspecific volume allocation control 3-308
in recovery allocation 3-358
in specific volume allocation 3-298
in unallocation/initiator interface 3-402
in volume mount and verify (VM&V)/allocation
interface 3-386
UCB candidate list in offline/allocated device allocation
building, and interfacing with SRM 3-371
UCB list in nonspecific volume allocation control
building
function 3-350, 3-310
interfacing with SRM 3-312
releasing 3-312
UCB update routne
use in allocate request to unit 3-303
UCM (unit control module)
in communications task overview 3-418
in unit unallocation processing 3-444
UCME (unit control module entry)
in communications task overview 3-418
UIC (in referenced internal count) (VS2.03.807)
in resource monitor periodic monitoring 3-67.1
(VS2.03.807)
in SRM service routine 3-9.3 (VS2.03.807)
in storage management (IRARMSTM) 3-46
(VS2.03.807)
unallocate requests to be rearranged
function 3-360, 3-348, 3-368
unallocated volunit entries, processing 3-371
unallocating current system log 3-472
unallocation (see also allocation/unallocation)
control, common
function 3-430
dynamic unallocation control and processor
function 3-416, 3-426
job unallocation
function 3-410
step unallocation control
function 3-404-3-405
unallocation deserialization (VS2.03.804)
in common allocation cleanup 3-381 (VS2.03.804)
in job unallocation 3-411 (VS2.03.804)
unallocation/initiator interface
function 3-402, 3-404
unilateral swap-out/swap-in 3-23.0, 3-36 (VS2.03.807)
unit affinity (see allocating affinity requests)
unit, allocating request to (see allocating requests to units)
unit allocation
in offline/allocated device allocation 3-369
unit, eligible
in specific volume allocation control 3-299
unit information
copying in dd function control 3-323
retrieving in dd function control 3-323
in JFCB housekeeping 3-316
unit name conversion
function 3-316-3-317
unit unallocation (IEFAB4A4)
direct access device processing 3-446
in common unallocation 3-434
non-direct access device processing 3-446
tape processing 3-446
units code
in workload manager 3-71
unload requests, processing in volume mount and verify
3-390
for an MSS volume 3-391
unmounted volumes, processing in demand allocation
3-357
update algorithm tables
function 3-368-3-369
update DDR count routine
function 3-282-3-283
update UCB routine
function 3-302
user evaluation (IRARMCVL) 3-43.4 (VS2.03.807)
user ready processing (IRARMHIT) 3-73.2 (VS2.03.807)
user, swapping (see swap-in, swap-out)
USERRDY SYSEVENT code (4)
processing in SRM SYSEVENT code processor 3-12
use by workload manager 3-71
validity checking unallocated device or data set requests
that need a specific volume 3-368
values, IPS (see IPS values)
VA T (virual address table)
in automatic step restart 3-500
in journal merge error processing 3-508
in merge cleanup 3-502
in merging job journal to SWA 3492
in restart interface processing 3-510
in system restart processing 3-496
in updating virtual addresses in SWA 3-504
verbs, converter identifying on JCL statement 3-226
verify control routine
function 3-394
Index
1-21
VS2.03.810
VERIFYPG SYSEVENT code (30)
processing in SRM SYSEVENT code processor 3-17
VIO allocation requests
processing in common allocation control 3-280
VIO eligible requests, processing in dd function control
3-328
virtual address in SWA, updating 3-504
VM & V count tables, contents 3-391
VM & V request block
building in allocate request to unit 3-302
in allocation/volume mount and verify (VM & V)
interface 3-386
in common allocation cleanu~ 3-378
in volume mount and verify (VM & V) 3-390
VOLSER searching in job unallocation 3-411
volume allocation control, nonspecific
function 3-308
volume demounting for an MSS volume 3-391
volume, determining if it is on an eligible unit 3-298
volume, enqueueing on in nonspecific volume allocation
control 3-312
volume information
copying and retrieving in dd function control 3-327
volume list
building
in common unallocation control 3-434
in disposition processing 3-440
obtaining new 3-336
volume mount and verify (VM & V)
conditions under which a volume cannot be used 3-395
control
function 3-390
determining fu"nctions to be performed 3-390
DOMR and cleanup routine
function 3-394, 3-388
functions 3-390
interface with allocation
function 3-386
interface to common allocation cleanup 3-395
MSS mount request, handling 3-392
routines used 3-390
WTO/WTOR format routine
function 3-392
volume, releasing
function 3-434, 3-436-3-437
volume serial number (see VOLSER)
volume, specific allocation (see specific volume allocation
control)
volume/unit resolution
function 3-326
volume validity checker
function 3~368, 3-302
volume, requests for
permanently resident or reserved
processing in fixed device allocation 3-294
specific 3-298
volume unload control (see IEFAB494 object module)
volume unload for an MSS volume 3-391
volumes, verifying 3-394-3-395
volunit affinity processing
function 3-282-3-283
volunit table
eligible entries, locating in nonspecific volume allocation
control
3-308
in allocate request to unit 3-302
in allocating offline devices 3-366
in allocation/volume mount and verify (VM & V)
interface 3-386
in allocation via algorithm 3-348
in common allocation cleanup 3-378
in common allocation control 3-280
in demand allocation 3-356
in fixed device control 3-294
in generic allocation control 3-338
in nonspecific volume allocation control 3-308
in recovery allocation 3-358
in specific volume allocation 3-298
in volume mount and verify (VM&V)/allocation
interface 3-386
obtaining space for 3-282-3-283
1-22
OS/VS2 System Logic Library Volume 3 (VS2.03.810)
VSM (see virtual storage management)
VUT (volume unit table)
in job unallocation 3-410
in unit unallocation processing 3-444
wait holding resources
function 3-280, 3-366
wait queue (deferred action queue) in SRM 3-28
WAIT queue for SRM (VS2.03.807)
definition 3-23.0 (VS2.03.807)
in user ready processing (IRARMHIT) 3-73.2
(VS2.03.807)
WAMT
in collect data for MF/l (IRARMWR3) 3-73.8
(VS2.03.807)
in initialize for MF/l (IRARMWRl) 3-73.6
(VS2.03.807)
in interval measurements gathering routine for workload
3-126
is SYSEVENT processing in SRM SYSEVENT code
processor 3-11
warmstart
in SWA create interface 3-217
locating JFCBs and JFCBXs in initiator /unallocation
interface 3-403
WKLDCOLL SYSEVENT code (46)
processing in SRM SYSEVENT code processor 3-21
use by workload manger 3-71
WKLDTERM SYSEVENT code (47)
processing in SRM SYSEVENT code processor 3-21
WLLDINIT SYSEVENT code (45)
processing in SRM SYSEVENT code processor 3-21
use by workload manager 3-71
WMST (workload manager specification table)
in individual user evaluation (IRARMWM3) 3-73.0
(VS2.03.807)
in swappable user evaluation (IRARMWM2) 3-70
(VS2.03.807)
in user evaluation (IRARMCVL) 3-43.4 (VS2.03.807)
in workload management 3-69
initialize for MF/l (IRARMWRl) 3-73.6 (VS2.03.807)
work masks (group masks) in device allocation
definition 3-272
use of 3-339
workload level, introduction 3-69
workload manager
function 3-69-3-73
workload measurement in MF /1
initialization 3-98
interval routine (RBMFDWP) 3-126
WPGD (performance group descriptor) (VS2.03.807)
in individual user evaluation (IRARMWM3) 3-73.0
(VS2.03.807)
in swapp able user evaluation (IRARMWM2) 3-70
(VS2.03.807)
in user evaluation (IRARMCVL) 3-43.4 (VS2.03.807)
in user ready processing (IRARMHIT) 3-73.2
(VS2.03.807)
WPGDT
in workload mangement 3-69
wrap-around CPU values in MF/l, adjusting for 3-119
write
in pseudo access method 3-184
WRITE/ ASSIGN function
in SWA manager move mode 3-264-3-265
WRITE/LOCATE function
in SWA manager locate mode 3-267
WRITE request
in SWA manager move mode 3-264-3-265
WRITELOG command
in switching system log data sets 3-473
write-to-log
writing data to system log
function 3-480
write-to-programmer (see WTP)
WTL (write to log) 3-480
WTO (write-to-operator) macro instruction
in subsystem initiation message writer 3-186
VS2.03.810
3800 printing subsystem (VS2.03.810)
in interpreter 3-245 (VS2.03.810)
related JCL parameters 3-249 (VS2.03.810)
(see also .JFCBE and JFCBX) (VS2.03.810)
Index
1-23
1-24
OS/VS2 System Logic library Volume 3 (VS2.03.810)
OS/VS2
System Logic Library
READER'S
COMMENT
FORM
Volume 3
SY28-0763-0
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
n
S.
~
."
o
a:
»
0'
::l
OQ
r-
:i"
(I)
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.
SY28-0763-0
Your comments, please ...
This manual is part of a library that serves as a reference source fLiT 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
Fold
-
- - -' - - - - - - - - - - - - - - First Class
Permit 81
.Poughkeepsie
New York
I
-~
I
I
I
I
'W
•
Business Reply Mail
No postage stamp necessary if mailed in the U.S.A.
I
I
I
I
I
I
Postage will be paid by:
International Business Machines Corporation
Department D58, Building 706-2
PO Box 390
Poughkeepsie, New York 12602
I
I
I
----------~------------~
Fold
Fold
I
I
I
I
I
I
I
I
~J]j~
·1
International BUsiness Machines Corporation
Data Processing Division
1133 Westchester Avenue, White Plains, New York 10604
(U.S.A. only)
I
I
I
(!)
IBM World Trade Corporation
821 United Nations Plaza, New York, New York 10017
(International)
I
I
I
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 19:58:36-08:00 Modify Date : 2012:06:10 01:21:21-07:00 Metadata Date : 2012:06:10 01:21:21-07:00 Producer : Adobe Acrobat 9.51 Paper Capture Plug-in Format : application/pdf Document ID : uuid:03eaf80a-cf8a-49cb-8a14-b2f8825a03c5 Instance ID : uuid:ffab5024-14c7-46cb-b67a-17654384f9af Page Layout : SinglePage Page Mode : UseNone Page Count : 632EXIF Metadata provided by EXIF.tools