C28 6646 0_Supervisor_and_Data_Management_Services_Feb67 0 Supervisor And Data Management Services Feb67
C28-6646-0_Supervisor_and_Data_Management_Services_Feb67 C28-6646-0_Supervisor_and_Data_Management_Services_Feb67
User Manual: C28-6646-0_Supervisor_and_Data_Management_Services_Feb67
Open the PDF directly: View PDF 
.
Page Count: 158
| Download | |
| Open PDF In Browser | View PDF |
File No. S360-36
Form C28-6646-0
Systems Reference Library
IBlM System/360 Operating System
Supervisor and Data Management Services
This publication describes the services and faciliavailable in the IBM System/360 Operating System
when using supervisor ahd data management
macro~
instructions.
It
also
describes
the
linkage
conventions established for use in the operating system.
tiE~s
This publication covers the three main configuiat:ions of the operating system: systems with the
primary c.ontrol program; systems that provide multiprogramming with a fixed number of tasks (MFT or
Option 2); systems that provide multiprogramming with a
variable number of tasks (MVT or Option 4).
Information
purposes.
on MVT contained herein is for planning
OS
First Edition (February 1967)
This publication is one of a set of publications which entirely replace
and ol.:solete the publications IBl"j System/360 Operating System: Data
Management, Form C28-6537, and IBM System/360 OBerating System: Control
Program Services, Form C28-6541. The facilities and services available
through the use of supervisor and data macro-instructions are now
described herein.
The descriptions and definitions of the supervisor
and data management macro-instructions are contained in the publication
IBM Systerrv360 Operating System: Supervisor and Data Management MacroInstructions, Form C28-6647. The facilities available through the use
of the TESTRAN macro-instructions, as well as the descriptions and
definitions of the TESTRAN macro-instructions, are contained in the
publication IBM System/360 Operating System: TESTRAN, Form C28-6648.
Specifications contained herein are subject to change from time to time.
Any such change will be reported in subsequent revisions or Technical
Newsletters.
This publication was prepared for production using an IBM computer to
update the text and to control the page and line format.
Page
impressions for photo-offset printing were obtained from an IBM 1403
Printer using a special print chain.
Requests for copies of IBM publications should be made to your
representative or to the IBM branch office serving your locality.
IBM
A form is provided at the back of this publication for reader's
comments. If the form has been removed, comments may be addressed to
IBM Corporation, programming Systems Publications, Department D58,
PO Box 390, Poughkeepsie, N.Y.
12602
©
International Business Machines corporation 1967
PREFACE
This
publication
describes
the
supervisor services and data management
facilities of the IBM System/360 Operating
System. It provides applications programmers coding in the assembler language with
the information necessary to design programs using these services and facilities.
The publication is divided into three
principal parts. Each section has a format
designed to fit the illustrations and examples required to explain the subject.
• Supervisor Services
This section
covers the supervisor services available through the use of assembler language macro-instructions, and describes
linkage conventions, requirements for
program and main storage management,
the program management services available, and task creation and management.
• Data Management Services -- This section covers the data management services available through the use of assembler language macro-instructions, and
describes the data organization and
access features of the operating system, along with cataloging and space
allocation facilities.
• Appendix -- Information is presented on
the format and use of data set labels.
?REREQUISITE PUBLICATIONS
IBM System/360 Operating system: Conand Facilities, ForU! C28-6535
2~pts
IBM System/360 Operating System: Assembler Language, Form C28-65l4
PUBLICATIONS TO WHICH THE TEXT REFERS
IBM System/360 Principles of
Form A22-682l
Operation,
IBM System/360 Operating System: Linkage
Editor, Form C28-6538
IBM System/360 Operating System: Storage
Estimates, Form C28-655l
IBM System/360 Operating System:
Control Language, Form C28-6539
Job
IBM System/360 Operating System: Nessages, Completion Codes,
and
Storage
Dumps, Form C28-663l
IBM System/360 Operating System: Supervisor
and
Data
Nanagement
MacroInstructions, Form C28-6647
IBM System/360 Operating System: system
Programmer's Guide, Form C28-6550
IBM System/360 Operating system: System
Generation, Form C28-6554
CONTENTS
SECTION I:
SUPERVISOR SERVICES
9
Introduction • • •
9
Program Management • •
Initial Requirements • •
• • •
providing an Initial Base
Register. . • • • •
• • • •
Saving Registers • •
· • •
Establishing a Permanent Base
Register. • • • • • • •
Linkage Registers. • • •
• • •
Acquiring the Information in the
PARM Field of the EXEC
Statement • • • •
Load Module structure Types
• .
Simple Structure •
Planned Overlay Structure.
. •
Dynamic Structure. • • •
• • •
Load .Module Execution • • • •
•
passing Control in a Simple
Structure. • • • • • • • •
•
Passing control Without Return • •
Passing Control With Return. • • •
Hmv Control Is Returned. • • • • •
Return to the Control Program. • •
passing Control in a Planned
Overlay Structure. • • • • • • • • .
Passing Control in a Dynamic
Structure. . • . • . • • • • • • • •
Bringing the Load Module Into
Main Storage. • • • • • • . • • •
Passing Control With Return. • • •
HOVi Contr()l Is Returned.
• ••
Passing Control without Return • •
9
Task Creation. • • • •
Creating the Task •
Subtask Priority. •
10
10
10
12
12
12
13
13
13
13
13
14
14
15
17
19
19
19
19
23
26
26
• • • 27
• • • 28
• • • 28
Task Management. • • •
• . 29
Task and suttask Communications • • . 29
Task Synchronization. • • •
• . • 30
Program Management Services~ •
• ••
Additional Entry Points •
• • •
Entry Point and Calling Sequence
Identifiers. • • • • . . • • • • . •
Using a Serially Reusable Resource. •
Naming the Resource. • • • • . . •
Exclusive and Shared Requests..
processing the Request • • • • • •
Proper Use of ENQ and DEQ. • • • •
Obtaining Information From the Task
Control Block. . •
. • • . . • .
Timing Services • •
• . .
Date and Time of Day .
•
Interval Timing.
• • •
Writing to Operator or System Log • •
Program Interruption Processing .
Abnormal Condition Handling
•
The Dump. • . • . • • • • • • •
31
31
31
32
32
32
33
34
36
36
36
37
38
38
40
42
ReqUirements • .
Indicative Dump.
Main Storage Management.
· •
Explicit Requests • . •
Specifying Lengths •
Types of Explicit Requests
Subpool Handling • . •
Implicit Request. • • • . • •
Load Module Management
Releasing Main Storage
SECTION II:
• • 42
• . 43
• • • • 43
43
• • 44
• • • • 44
•
•
•
Data Set Characteristics
• •
Data Set Identification • • •
Data Set Storage. • • • •
Direct-Access Volumes • •
Magnetic Tape Volumes.
Data set Record Formats • • .
Fixed-Length Records •
Variable-Length Records • .
Undefined-Length Records .
Control Character. • • • .
45
• 49
• 51
DATA MANAGEMENT SERVICES
PART 1:
INTRODUCTION TO DATA
MANAGEMENT. • • • • • • .
•
.... • • 47
• • • • 47
• • • • 53
• • • • 53
•
•
•
• 55
• 56
• • • 56
• • • • 57
• • • • 58
• • 58
•
• 59
• • 60
• • • • 60
Direct-Access Device Characteristics
Track Format. • •
Track Addressing.
· •
Track Overflow. • • • • .
• •
Write Validity Check ••
• • 60
· 61
• • 62
Interface With the Operating System.
Data Set Description. • • • • • •
Processing Program Description. •
Modifying the Data Control Block.
•
•
.
•
•
• 62
• • 63
•
•
.
.
63
65
66
70
PART 2: DATA MANAGEMENT PROCESSING
• • • . 71
PROCEDURES. • • . . . • •
Data Processing Techniques .
..• .
Queued Access Technique •
. . •
GET -- Retrieve a Record •
..
PUT -- Write a Record. • •
.•
PUTX -- Write an Updated Record. .
Basic Access Technique. • •
READ -- Read a Block • •
. .
WRITE -- Write a Block •
• •
CHECK -- Test Completion of
Read/Write Operation. .
. .
WAIT -- Wait for Completion of a
Read/Write Operation. • • . . • .
Data Event Control Block (DECB) • .
Selecting an Access Method. • . • • •
Opening and Closing a Data Set . . . •
OPEN -- Initiate Processing of a
Data Set. • • . • . . • . . . . .
CLOSE -- Terminate Processing of
a Data Set. . . • • . . •
. .
End-of-Volume Processing . . • • .
71
71
71
71
72
72
72
73
74
74
74
74
75
76
77
78
FEOV -- Force End of Volume. • . • 78
Buffer Acquisition and Control • • . • •
Buffer Pool Construction. • . • . . .
BUILD -- Construct a Buffer Pool •
GE'rpOOL -- Get a Buffer Pool . . .
Automatic Buffer Pool
Construction. • • • • . . • .
FREEPOOL -- Free a Buffer Pool . .
Buffer Control. . •
. • . .
Simple Buffering • • • • • • • • .
Exchange Buffering • • • • • . . .
RELSE -- Release an Input Buffer .
TRUNC -- Truncate an output
Buffer. • • . . . • . • . • • • .
GETBUF -- Get a Buffer From a
Pool. • . • . • . • . ~.
..
FREEBUF -- Return a Buffer to a
Pool. • • • • • • • • • • . • . .
FREEDBUF -- Return a Dynamic
Buffer toa Pool • • • • . . • • .
78
79
79
80
Processing a Sequential Data Set •
Data Format -- Device Type
Considerations . • • • •
Magnetic Tape (TA) • • •
Paper Tape Reader (PT) •
Card Reader and Punch (RD/PC) . • .
Printer (PR) • • . • • • • • . • .
Direct Access (DA) • • • • • • • •
Sequential Data sets -- Device
Control. • • • • • • • • • • • . . .
CNTRL -- control an I/O Device • •
PRTOV -- Test for Printer
Overflow • • • • . • • • • . . . •
BSP -- Backspace a Magnetic Tape
or Direct-Access Volume • • • • •
NOTE -- Return the Relative
Address of a Block. • • • • . • •
POINT -- Position to a BloCK • • •
sequential Data sets -- Device
Independence • . • • • . • • • . • •
System Generation Considerations •
Programming Considerations • . • •
Chained Scheduling for I/O
Operations • • • • • • • • • • • • •
Creating a Sequential Data Set. • • •
88
80
80
81
82
84
87
88
88
Additional Records in an Indexed
Sequential Data Set. • . • •
• .106
Indexed Sequential Data Set
Maintenance. • • • . . •
.107
Indexed Sequential Buffer and Work
Area Requirements. . • • . .
• .109
Controlling an Indexed Sequential
Data Set Device. • . . • .
. . . 110
SETL -- Specify Start of
Sequential Retrieval. . .
. .110
ESETL -- End sequential
Retrieval. . . . . • . •
. .110
Creating an Indexed Sequential Data
Set. . . • • • • • . . . . • • • • . 110
Updating an Indexed Sequential Data
Set. . . . • • . . • . • . • • • . .112
Direct Retrieval and Update of an
Indexed Sequential Data Set.
• .113
88
88
89
89
90
90
91
91
91
91
92
92
92
92
92
93
93
94
95
Processing a Partitioned Data Set.
96
Partitioned Data Set Directory.
• 97
processing a Member of a
Partitioned Data Set. • • • •
.100
BLDL -- Construct a Directory
Entry List • • • • • • • • • • • • 100
FIND -- Position to a Member • • • 100
STOW -- Alter a Directory Entry • • 101
creating a Partitioned Data Set • • • 101
Retrieving a Member • • • • • • • • • 103
Updating Members of a Partitioned
Data Set. . • . • • • • • •
• .104
processing an Indexed Sequential Data
Set • • • • • .• • • • • •
• •• 104
Indexed Sequential Data Set
•• 104
organization • • • • •
Prime Data Area.
.105
Index Areas. • • • • • •
• • • 105
Overflow Areas • • •
• • • 106
Processing a Direct Data S e t . .
• .114
Organizing a Direct Data Set.
• .114
Referring to a Record in a Direct
.Data Set • • . . • . . • . . . • • .115
Creating a Direct Data Set . • • . • . 115
Addirtg/Updating Records on a Direct
Data Set. • • . • . • • • • .
.116
PART 3: DATA SET DISPOSITION AND
SPACE ALLOCATION • • • • • . • • . . • . 119
Allocating Space on Direct-Access
Volu~es • • . . • • . . • . • • . . . • 119
Specifying Space Requirements •
.119
Estimating space Requirements • • • • 120
Allocating Space for a Partitioned
Data Set • • • • • . • • • . • • • • 121
Allocating Space for an Indexed
sequential Data Set • • . • . • . • . 122
Specifying a Prime Data Area • . • 124
Specifying a Separate Index Area .124
Specifying an Independent
Overflow Area ~ . • . • • • • • • 124
Calculating Space Requirements
for an Indexed Sequential Data
Set . • • • • . • • • • • . . . . 124
Control and Disposition of Data Sets • . 128
Concatenating Sequential and
Partitioned Data Sets. • •
• .129
Cataloging Data Sets. . • •
• .130
Entering a Data Set Name in the
Catalog. • • • • • • • •
.131
Entering a Generation Data Group
in the Catalog • • • • • • • • • • 132
Control of Confidential Data -Password Protection • • • • • • • . . 132
APPENDIX A:
VOLUME LABELING • .
• .133
Magnetic Tape Labels. •
• • • . 133
Standard Tape Labels.
• .133
Tape/Direct-Access Volume Labels
Format • . • • • • • . • • • • • . 135
Additional Volume Labels Format •• 136
Data Set Header and Trailer
Label 1 Format. • • • • • • . • .137
Data Set Header and Trailer
Label 2 Format. • • • • • •
.139
User Header and Trailer Label
Format. • • • • • •
• • • 141
Nonstandard ~rape Labels • • • • • • .141
APPENDIX B: CONTROL CHARACTERS AND
SYSOUT WRITER • • • . • • •
• .147
Control Characters • •
• .147
Machine Code
• .147
Extended ASA Code. .
· .147
SYSOUT Writers .
• .148
INDEX
• .149
Magnetic Tape Volume Organization • • • • 142
• • • 144
Direct-Access Labels •
• • • 144
Volume Label Group • •
Da"ta. Set Control Block (DSCB)
• .145
G:r-oup • "
• .145
User Label Group
n
•
•
EXAMPLES
Example 1. Control Section
Addressability. • • • • • • • • • • • •
Example 2.
Int:ernal Entry Point
Addressability • • • • • • • • • '.
Example 3. saving A Range of
Registers . • • • . • • • • • • •
.
Example 4. Saving Registers 5-10,
14, and 15 • • • • • • • • • • • • • • .
Example 5. Non-reenterable Save Area
Chaining. • • • • • • • • • • • .
.
Example 6. ReE~nterable Save Area
Chaining. • • • • • • . . • • • • • • •
Example 7. Passing Control in a
Simple Structure. • • . • •
•
Example 8. Passing Control With a
Parameter List. • • . • • •
• • •
Example 9. Passing Control with
Return. • • • • • • • • • •
. • •
Example 10. Passing Control With CALL •
Example 11. Test for Normal Return. . •
Example 12. Return Code Test Using
Branching Table • • . • • • • • • • . .
Example 13. Establishing a Return
Code. • • • • • • • • • • • • . • . • •
10
10
11
11
11
12
14
15
16
16
17
17
18
Example 14. Use of the RETURN
Macro-Instruction • • • . • • . • • . •
Example 15. RETURN Macro-Instruction
With Flag • . • • • . • • •
• •
Example 16. Use of the LINK
Macro-Instruction • • . • . • •
· •
Example 17. Use of the BLDL
Macro-Instruction • • • • •
• .
Example 18. The LINK
Macro-Instruction With a DE Operand
•
Example 19. Two Requests for Two
Resources •
•.••
••.•
Example 20. One Request for Two
Resources •
••••••••••••
Examole 21. Day of Year Processing • • •
Exam~le 22.
Interval Timing • . • • • .
Example 23. Writing to the Operator • .
Example 24. Writing to the Operator
With a Reply. • • . • . . .
Example 25. Use of the SPIE
Macro-Instruction . • • . •
• •
Example 26. Use of the GETMAIN
Macro-Instruction • . •
• .
Example 27. Use of List and Execute
Forms . . • • • . • • •
· •
18
18
24
24
24
35
35
37
38
38
39
40
45
49
FIGURES
Figure 1. Save Area Format • •
· •
Figure 2. Acquiring FARM Field
Informa- tion . . . . . . .
·
Figure 3. Misusing Control Prograrr.
Facilities. . . • • • . . . • •
. .
Figure 4. Task Hierarchy • • . . . . •
Figure 5. Event Control Block • . • . .
Figure 6. ENQ Macro-Instruction
Processing. . • . . • • • • • . .
Figure 7. Interlock Condition • .
•
Figure 8. Program Interruption
Control Area • . • • • • • • • •
· •
Figure 9. Program Interruption
Element • • • • • . • • • • • .
Figure 10. Abnormal Condition
Detection • • . • • • • • . .
•
Figure 11. Main Storage Control.
·
Figure 12. Format F Records .
•
Figure 13. Format V Records •
• .
Figure 14. Format U Records •
Figure 15. 2311 Disk Drive ••
•
Figure 16. Direct-Access Volume Track
Formats • . • . • . •
• •
Figure 17. Completing the Data
Control Block • . • • • . • • . •
·
Figure 18. Source and Sequence for
Completing the Data Control Block • • .
Figure 19. A Partitioned Data Set • • •
10
12
21
29
30
33
35
39
39
41
46
58
59
60
61
61
63
64
91
Figure 20. A Partitioned Data Set
Directory Block . . . . • • •
98
Figure 21. A Partitioned Data Set
Directory Entry • . . . . . .
98
Figure 22. Build List Format.
• .101
Figure 23. Indexed Sequential Data
Set organization. • • • . . • .
. .105
Figure 24. Adding Records to an
Indexed Sequential Data Set
. . 107
Figure 25. Deleting Records From an
Indexed Sequential Data Set
. . 108
Figure 26. Reissuing a READ for
"Unlike" Concatenated Data Sets • . • • 129
Figure 21. Catalog Structure on Two
Volumes • . • • . • . . . . . •
• .131
Figure 28. Organization of Standard
Tape Labels • • • . . . • . • • • • • • 134
Figure 29. Initial Volume Label • . . . 135
Figure 30. Addir.ional Volume Labels . .136
Figure 31. Tape Header and Trailer
Labell.
. . • . • • . • . • • • 131
Figure 32. Tape Header and Trailer
Label 2 .
. . . • . •
• .139
Figure 33. Tape User Header and
Trailer labels.
. .141
Figure 34. Standard Label Formats for
Magnetic Tape . • . . • • • • . • . • . 143
Figure 35. Direct-Access Labeling
.144
TABLES
Table 1. Summary of Characteristics
and Available Options • • • • • • . • .
Table 2. Load Module Characteristics •
Table 3. Search for Module, EP or
EPLOC Operands With DCB=O or DCB
Operand Omitted • • • • • • • •
• •
Table 4. Search for Module, EP or
EPLOC Operands With DCB Operand
Specifying Private Library • • • . • • •
Table 5. Search for Module Using DE
Operand • • • . • • • • • • • ••
•
Table 6. Data Management Exit
Routines. • • • • . • . • • •
• ••
Table 1. Format and Contents of an
Exit Routine. • • • • • • • •
• •
9
13
20
20
21
61
68
Table 8. System Response to an Exit
Routine Return Code • . . . • . • . . • 69
Table 9. Data Access Methods
15
Table 10. Buffering Technique and
GET/PUT Processing Modes. . •
. 81
Table 11. Tape Density (DEN) Values •• 90
Table 12. Direct-Access Storage
Device capacities • • . • • • • • • . • 120
Table 13. Direct-Access Device
Overhead Formulas • • • • . • • • • . • 121
Table 14. Space Requests for Indexed
Sequential Data Sets • . • . • • • • • • 123
Table 15. Tape Density (DEN) Values •• 140
SECTION I:
INTRODUCTION
able in the operating system; it only
summarizes the options that affect the
material covered in this manual.
The supervisor services section of this
publica-t:.ion
provides
a
tutorial
presentation of the supervisor services
available from the IBM System/360 operating
system 1:hrough the use of the supervisor
macro-instructions supplied by IBM. The
information in this section includes a
discussion of the standard linkage conventions to be used with the operating system,
as well as a discussion of the requirements
for using the macro-instructions.
This
publicat.ion is to be used when designing a
program; the information required to code
the macro-instructions is presented in the
companion publication IEM System/360 Oper-ating System: Supervisor and Data Manage-.
ment Macro-Inst:ructions.
PROGRAM MANAGEMENT
The following discussion provides the
requirements for the design of programs to
be processed using the IBM System/360 Operating System.
Included here are the procedures required when receiving control from
the control program, the program design
facilities available" and the conventions
established for use in program management.
This discussion presents the conventions
and procedures in terms of called and
calling programs. Each program given control during the job step is initially a
called program.
During the execution of
that program, the services of another program may be required, at which time the
first program becomes a calling program.
For example, the control program passes
control to program A which is, at that
point, a called program. During the execution of program A, control is passed to
program B. Program A is now a calling
program, program B a called program. Program B eventually returns control to program A, which eventually returns control to
the control program.
This is one of the
simpler cases, of course. Program B could
pass control to program C, which passes
control to program D, which ret.urns control
to program C, etc. Each of these programs
has the characteristics of either a called
This
section covers the three major
of the operating system: the
opera ting sys1:em with the primary control
program; the ope:r:ating system that provides
multiprogramming with a fixed number of
tasks
(MFT); and the operating system that
provides multiprogramming with a variable
number of tasks
(MVT). Unless otherwise
indicated in the text, the descriptions in
this section apply to all configurations of
the operating system; when
differences
aris e because of operating system options"
these differences are explained.
configu~("ations
A brief description of the three configurations of the operating system is
given in Table 1.
This table does not
attempt to cover all of the options availTable
1.
SUPERVISOR SERVICES
Surnroary of Characteristics and Available Options
r-------------·--------T---------------------T---------------------T---------------------,
I
I primary Control
I
I
I
I
I Program
I MFT
I MVT
I
~---------------------+---------------------+---------------------+---------------------~
IBrief Description
I
I
I
I
ISequential Scheduler,
lone task per job
Istep, one job
Iprocessed at a time
I
I Sequential Scheduler,IPriority Scheduler,
I
lone task per job
lone or more tasks perl
Istep, one to four
Ijob step, more than I
I jobs processed
lone job processed
I
I concurrently
I concurrently
I
~----------------------+---------------------+---------------------+---------------------~
IMultiple wait Option IOptional
I Standard
I Standard
I
~---------------------+---------------------+---------------------+---------------------~
IIdentify Option
I Optional
I Standard
IOptional
I
~-------~-------------+---------------------+---------------------+---------------------~
ITime option
I Optional
I Optional
I Standard
I
~-------------,--------+---------------------+---------------------+---------------------~
IInterval Timing
I Optional
I Option
I
I Optional
I
I Standard
I
I
I
~---------------------+---------------------+---------------------+---------------------~
ISystem
Log Option
INot
Available
INot
Available
I Standard
L_____________________
_____________________
_____________________
_____________________ JI
~
~
~
Section I:
Supervisor Services
9
or calling program., regardless of whether
it is the first, fifth or twentieth program
given control during a job step.
The conventions and requirements that
follow are presented in terms of one called
and one calling program; these conventions
and requirements apply to all called and
calling programs in the system.
INITIAL REQUIREMENTS
The following paragraphs discuss the
procedures and conventions to be used when
a program receives control from another
program.
Although the discussion is presented in terms of receiving control from
the control program, the procedures and
conventions apply as well when control is
passed directly from another processing
program.
If the requirements presented
here are followed in each of the programs
used in a job step, the called program is
not affected by the method used to pass
control or by the identity of the program
passing control.
13, 14, and 15. The latter registers may
be modified, along with the condition code,
when system macro-instructions are used to
request data management or supervisor services.
The general registers are saved in an
18-word area provided by the control program; the format of this area is shown in
Figure 1.
When control is passed to your
program
from the control program"
the
address of the save area is contained in
register 13. As indicated in Figure 1, the
contents of each of the registers must be
saved at a predetermined location within
the save area; for example, register 0 is
always stored at word 6 of the save area,
register 9 at word 15. The safest procedure is to save all of the registers; this
insures that later changes to your program
will not result in the modification of the
contents of a register which has not been
saved.
r----T------------------------------------,
Contents
I
I Word I
~----+------------------------------------i
I
Eroviding an Initial Base Register
When control is passed to your program
from the control program, the address of
the entry point in your program is contained in register 15. This address can be
used to establish an initial base register,
as shown in Example 1 and Example 2.
In
Example 1, the entry point address is
assumed to be the address of the first byte
of the control section; an internal entry
point is assumed in Example 2.
Since
register 15 already contains the entry
point address in both examples, no register
loading is required.
I
I
I
2 IAddress
of
previous
save
I (stored by calling program)
areal
I
~----+------------------------------------i
I
I
3 IAddress of next save area (stored byl
Icurrent program)
I
~----+------------------------------------i
I
4 IRegister 14 (Return address)
I
~----+------------------------------------i
I
5 IRegister 15 (Entry Point address>
I
~----+------------------------------------i
I
6 IRegister 0
I
~----+------------------------------------i
I
7 IRegister 1
I
~----+------------------------------------i
I
CSECT
USING *,15
PROGNAME
1 IUsed by PL/l language program
~----+------------------------------------i
8 IRegister 2
I
~----+------------------------------------i
1
9 IRegister 3
I
~----+------------------------------------i
I 10 IRegister 4
Example
1.
Control Section Addressability
I
~----+------------------------------------i
I 11 IRegister 5
I
~----+------------------------------------i
I 12 IRegister 6
PROGNAME
DS
OH
USING *,15
I
~----+------------------------------------i
I 13 IRegister 7
I
~----+------------------------------------i
I 14 IRegister
Example
2.
Internal Entry Point Addressability
saving Registers
The first action your program should
take is to save the contents of the general
registers. The contents of any register
your program will modify ·must be saved,
along with the contents of registers 0, 1,
10
8
I
~----+------------------------------------i
I 15 IRegister
9
I
~----+------------------------------------i
I 16 IRegister 10
I
~----+------------------------------------i
I 17 IRegister 11
I
~----+------------------------------------i
IL ____
18 IRegister
12
____________________________________
JI
~
Figure
1.
Save Area Format
To save the contents of the general
registers, a store-multiple instruction,
such as STM 14,12,12(13), can be written.
This instruction places the contents of all
the registers except register 13 in the
proper words of the save area.
(Saving the
contents of register 13 is covered later.)
If the contents of only registers 14, 15,
and 0-6 are to be saved, the instruction
would be STM 14,6,12(13).
THE SAVE MACRO-INSTRUCTION:
The
SAVE
macro-instruction, provided to save you
coding time, results in the instructions
necessa~y
to store a designated range of
registers. An example of the use of the
SAVE
macro-instruction
is
shown
in
Example 3. The registers to be saved are
coded in the same order as they would have
been designated had an STM instruction been
coded. A further use of the SAVE macroinstruction is shown in Example 4. The
operand T specifies that the contents of
registers 14 and 15 are to be saved in
words 4 and 5 of the save area.
The
expansion of this SAVE macro-instruction
results in the instructions necessary to
store registers 5-10, 14 and 15.
SAVE (14,12)
USING PROGNAME,15
PROGNAME
Example
3.
Example
4.
Whether or not your program is going to
provide a save area, the address of the
save area you used must be saved. You will
need this address to restore the registers
before you return to the program that
called your program. If you are not pro~
viding a save area, you can keep the save
area address in register 13, or save it in
a fullword in your program. If you are
providing another save area, the following
procedure should be followed:
• Store the address of the save area you
used (that is, the address passed to
you in register 13) in the second word
of the new save area.
• Store the address of the new save area
(that is, the address you will pass in
register 13) in the third word of the
save area you used.
The reason for saving both addresses is
discussed more fully under the heading "The
Dump." Briefly, save the address of the
save area you used so you can find the save
area when you need it to restore the
registers; save the address of the new save
area so a trace from save area to save area
is possible.
Saving A Range of Registers
SAVE (5,10),T
USING PROGNAME,15
PROGNAME:
save area is not necessary, but this is
poor practice unless you are writing very
simple routines.
Saving Registers 5-10, 14, and
15
The SAVE ma.cro-instruction can be coded
only at: the entry point of a program
because the code resulting froro the macroexpansion requires that register 15 contain
the address of the SAVE macro-instruction.
PROVIDING A SAVE AREA: If your program is
going to use any system macro-instructions
(other than SAVE, RETURN, or the register
forms of GETMAIN and FREEMAIN), or if any
control section in your program is going to
pass control to another control section and
receive control back, your program is going
to be a calling program and must provide
another sa ve al~ea. Providing a save area
allows the program you call
to
save
registeJes without regard to whether it was
balled by your program, another processing
program"
or by the control program. If
your program does not use system macroinstructions
and
if
you
establish
beforehand what. registers are available to
the called program or control section, a
Example 5 and Example 6 show two methods
of obtaining a new save area and of saving
the save area addresses. In Example 5, the
registers are stored in the save area
provided by the calling program (the control program).
The address of this save
area is then saved at the second word of
the new save area"
an 18 fullword area
established through a DC instruction. Register 12 (any register could have been
used) is loaded with the address of the
previous save area. The address of the new
save area is loaded into register 13, then
stored at the third word of the old save
area.
SAVEAREA
Example
5.
STM
ST
LR
LA
ST
14,12,12(13)
13,SAVEAREA+4
12,13
13, SAVEAREA
13,8 (12)
DC
18A(O)
Non-reenterable
Chaining
Save
Area
In Example 6, the registers are again
stored in the save area provided by the
calling program. The contents of register
1 are saved in another register, and a
GETMAIN macro-instruction is issued.
The
Section I:
Supervisor Services
11
GETMAIN macro-instruction (discussed
in
greater detail under the heading "Main
Storage Management") requests the control
program to allocate 12 bytes of main storage from an area outside your progrant, and
to return the address of the area in
register 1. The addresses of the new and
old save areas are saved in the established
locations, and the address of the new save
area is loaded into register 13.
PROGNAME.
Example
SAVE
USING
LR
GETMAIN
ST
ST
LR
6.
(14,12)
PROGNAME,15
2,1
R,LV=12
13,4(1)
1,8(13)
13,1
Reenterable Save Area Chaining
Establishing a Permanent Base Register
If your program does not use system
macro-instructions and does not pass control to another program, the base register
established using the entry point address
in register 15 is adequate.
Otherwise,
after you have saved your registers, establish base registers using one or more of
registers 2-12. Register 15 is used by
both the control program and your program
for other purposes.
Linkage Registers
It was indicated earlier that registers
1, 13, 14, and 15 may be modified when
system macro-instructions are use~.
These
registers are known as the linkage registers and are used in an established
manner by the control program. It is good
practice to use these registers in t.he same
way in your program. Note that the contents of registers 2-12 are never altered
by the control program.
0,
REGISTERS 0 AND 1: Registers 0 and 1 are
used to pass parameters to the control
program or to a called program. The expansion of a system macro-instruction results
in instructions required to load a value
into register 0 or 1 or both, or to load
the address of a parameter list into register 1. The control prograro also uses
register 1 to pass parameters to your
program or to the program you call.
This
is why the contents of register 1 were
loaded into register 2 in Example 6.
REGISTER 13:
Register 13 contains the
address of the save area you have provided.
The control program may 'use this save area
when processing requests you have made
using system macro-instructions. A program
you call can also use this save area when
it issues a SAVE macro-instruction.
12
REGISTER 14:
Register 14 contains the
return address of the program that called
you, or an address within the control
program to which you are to return when you
have completed processing. The expansion
of most system macro-instructions results
in an instruction to load register 14 with
the
address
of
your next sequential
instruction. A BR 14 instruction at the
end of any program will return control to
the calling program as long as the contents
of register 14 have not been altered.
REGISTER 15:
Register 15, as you have
seen, contains an entry point address when
control is passed to a program from the
control program.
The entry point address
should also be contained in register 15
when you pass control to another program.
In addition, the expansions of some system
macro-instructions result in the instructions to load into register 15 the address
of a pazameter list to be passed to the
control program. Register 15 can contain a
return code when control is returned to a
calling progran t•
ACquiring the Information in the PARM Field
of the EXEC Statement
The manner in which the control program
passes the information in the PARM field of
your EXEC statement is a good example of
how the control program uses a parameter
register to pass information. When control
is passed to your program from the control
program, register 1 contains the address of
a fullword on a fullword boundary in your
area of main storage (refer to Figure 2).
The high order bit (bit 0) of this word is
set to 1. This is a convention used by the
control prograI" to indicate the last word
in a variable-length parameter list; you
must use the same convention when making
requests to the control program. The loworder three bytes of the fullword contain
Register
1
Full-Word
Boundary
2 Bytes
0 to 40 Bytes
Half-Word
Boundary
Figure
2.
Acquiring PARM
tion
Field
Informa-
the add]~ess of a two-byte length field on a
half word boundary.
The
length
field
contains a count of the number of bytes of
informat~ion in the PARM field, and
is set
to zero if the PARM field was omitted.
Immediately following the length field is
the information in the PARM field.
If your
program is not going to use this information
immediately, you should load the
address from register 1 into one of registers 2-i2 or store the address in a
fullword in your program.
•
LOAD MODULE STRUCTURE TYPES
Each load module uSed during a job step
can be designed in one of three load module
structures: simple, planned overlay, or
dynamic. A simple structure does not pass
control to any other load modules during
its execution, and is brought into main
storage all at one time. A planned overlay
structure does not pass control to any
other load modules during its execution,
and it i.s not brought into main storage all
at one t.ime.
Instead, segments of the load
module reuse the same area of main storage.
A dynamic structure is brought into main
storage all at one time, and passes control
to other' load modules during its execution.
Each of the load modules to which control
is passed can be one of the three structure
types.
Table 2 summarizes the characteristics
of these load module structures.
Table
2.
Load Module Characteristics
r-------------T-------------T-------------,
I
I
I
Passes
I
I
I
I
structure
Type
I
I Control to
ILoaded All atl Other Load
lOne Time
I
Modules
I
I
I
•I -------------+-------------+-------------i
Simple
I
Yes
I
No
I
program intervention. However, when a program is very large or complex, the main
storage area required for the load module
may exceed that which can be reasonably
requested.
(Main storage considerations
are discussed under the heading "Main Storage Management.")
Planned Overlay Structure
A planned overlay structure consists of
a single load module produced by the linkage editor. The entire load module is not
brought into main storage at once; different segments of the load module reuse use
the same area of main storage. The planned
overlay structure, while not as efficient
as a simple structure in terms of execution
speed, is more efficient than a dynamic
structure. When using a planned overlay
structure, control program assistance is
required to locate and load portions of a
single load module in a library; in a
dynamic structure, many load modules in
different libraries may need to be located
and loaded in order to execute an equivalent program.
Dynamic Structure
A dynamic structure requires more than
one load module during execution.
Each
load module required can operate as either
a
simple structure, a planned overlay
structure, or another dynamic structure.
The advantages of a dynamic structure over
a planned overlay structure increase as the
program becomes more complex, particularly
when the logical path of the
program
depends on the data being processed. The
load modules required in a dynamic structure are brought into main storage when
required, and can be deleted from main
storage when their use is completed •
~-----------~-+-------------+-------------i
I
I
Planned
Overlay
I
I
No
I
I
No
I
I
~-------------+-------------+-------------i
I
Dynamic
L _____________
I _____________
Yes
I _____________
Yes
JI
~
~
The
following
paragraphs cover the
advantages and disadvan'tages of each type
of structure, and discuss the use of each.
Simple Structure
•
A simple structure consists of a single
load module produced by the linkage editor.
The single load module contains all of the
instructions required, and is brought into
the main storage all at one time by the
control program. The simple structure can
be the most efficient of the three structure types because the instructions it uses
to pass control do not require control
LOAD MODULE EXECUTION
Depending on the configuration of the
operating system and the macro-instructions
used to pass control, execution of the load
modules is serial or in parallel. Execution of the load modules is always serial
in an operating system with the primary
control program or with' MFT; there is only
one task in the job step.
Execution is
also serial in an operating system with MVT
unless an ATTACH macro-instruction is used
to create a new task. The new task competes for control independently with all
other tasks in the system. The load module
named in the ATTACH macro-instruction is
executed in parallel with the load module
containing the ATTACH macro-instruction.
The execution of the load modules is serial
within each task.
.
Section I:
Supervisor Services
13
The discussion of passing control for
serial execution of a load module is discussed in the following paragraphs. The
discussion of creation and management of
new tasks is found under the headings "Task
Creation" and "Task Management."
PASSING CONTROL IN A SIMPLE STRUCTURE
The following paragraphs discuss the
procedures to follow when passing control
to an entry point in the same load ~odule.
The established conventions for use when
passing control are also discussed. These
procedures
and conventions provide the
framework around which all program interface is built. Knowledge of the information contained in the section "Addressing
Program sectioning and Linking" in the
publication IBM System/360 Operating System: Assembler Language, is required.
Passing Control Without Return
A control section is usually written to
perform a specific logical function within
the load module. Therefore, there will be
occasions when control is to be passed to
another control section in the same load
module,
and
no return of control is
required.
An example of this type of
control section is a "housekeeping" routine
at the beginning of a program which establishes values, initializes switches~ and
acquires buffers for the other control
sections in the program.
The following
procedures should be used when passing
control without return.
INITIAL REQUIREMENTS: Because control will
not be l:e:.tur:ned to this control section,
you must restore the contents of register
14. Register 14 originally contained the
address of the location in the calling
program (for example, the control program)
to which control is to be passed when your
program is finished.
Since the current
control section will not make the return to
the calling program~ the return address
must be passed to the control section that
will make the return.
In addition, the
contents
of
registers
2-12
must be
unchanged
when your program eventually
returns control, so these registers must
also be restored.
If control were being passed to the next
entry pOint from the control prograni, register 15 would contain the entry point
address. You should use register 15 in the
same way, so that the called
routine
remains independent of which program passed
control to it.
Register 1 should be used 'to pass parameters.
A parameter list should be estab-
lished, and the address of the list placed
in register 1. The parameter list should
consist of consecutive full words starting
on a fullword boundary, each fullword containing an address to be passed to the
called control section in the three low
order bytes of the word.
The high-order
bit of the last word should be set to 1 to
indicate the last word of the list.
The
system convention is that the list contain
addresses only. You may, Qf course, deviate from this convention; however, when you
deviate from any system convention, you
restrict the use of your programs to those
programmers who are aware of your special
conventions.
•
Since you have reloaded all the necessary registers, the save area that you used
is now available, and can be reused by the
called
control section.
You pass the
address of the save area in register 13
just as it was passed to you. By passing
the address of the old save area, you save
the 72 bytes of main storage area required
for a second, and unnecessary, save area.
PASSING CONTROL: The common way to pass
control between one control section and an
entry pOint in the same load module is to
load register 15 with a V-type address
constant for the name of the external entry
point, and then to branch to the address in
register 15. The external entry point must
have
been
identified
using an ENTRY
instruction in the called control section
if the entry point is not the same as the
control section name.
An example of proper register loading
and control transfer is shown in Example 7.
In this example, no new save area is used,
so register 13 still contains the address
of the old save area.
It is also assumed
for this example that the control section
will pass the same parameters it received
to the next entry point.
First, register
14 is reloaded with the return address.
Next,
register 15 is loaded with the
address of the external entry point NEXT,
using the V-type address constant at the
location
NEXTAOOR.
Registers 0-12 are
reloaded, and control is passed by a branch
instruction using register 15. The control
section to which control is passed contains
an ENTRY instruction identifying the entry
point NEXT.
NEXTADDR
Exarople
L
L
LM
BR
14,12(13)
CSECT
15,NEXTADDR
ENTRY NEXT
0,12,20(13)
15-------->NEXT SAVE (14,12)
DC
V(NEXT)
7.
Passing Control
Structure
in
a Simp'le
14
•
•
An example of the use of a parameter
list is shown in Example 8. Early in the
routine the contents of register 1 (that
is, the address of the fullword containin9
the PARM field address) were stored at the
fullwoxd PARMADDR.
Register 13 is loaded
with the address of the old save area,
which had been saved in word 2 of the new
save area. The contents of register 14 are
restored, and register 15 is loaded with
the entry point address •
The address of the list of parameters is
loaded into register 1. These parameters
include the addresses of two data control
blocks (DCBs) and the original register 1
contents. The high-order bit in the last
address parameter (PARMADDR) is set to 1
using an OR-immediate instruction.
The
contents of registers 2-12 are restored.
(Since one of these registers was the base
register, restoring the registers earlier
would have made the parameter list unaddressable.)
A branch instruction using
registe.r 15 passes control to entry point
NEXT.
Passing control With Return
The control program passed control to
your program, and your program will return
control when it is through processing.
Similarly, control sections within your
program will pass control to other control
sections, and expect to receive control
back.
An example of this type of control
section is a "monitor" portion of a program; "the monitor de"t:.ermines the order of
execution of other control sections based
on the type of input data. The following
procedures should be used when passing
control with rE~turn.
INITIAL REQUIHEMENTS:
Registers 15 and 1
are used in exactly the same manner as they
were used when control was passed without
EARLY
•
•
PARMLIs~r
DCBADDRS
PARMADDH
NEXTADDH
Example
return.
Register 15 contains the entry
point address in the new control section
and register 1 is used to pass a parameter
list.
Using the standard convention, register
14 must contain the address of the location
to which control is to be passed when the
called control section completes processing.
This time, of course, it is a location in the current control section.
The
address can be the instruction following
the instruction which causes control to
pass~
or it can be another location within
the current control section designed to
handle all returns. Registers 2-12 are not
involved in the passing of control; the
called control section should not depend on
the contents of these registers in any way.
You should provide a new save area for
use by the called control section as previously described, and the address of that
save area should be passed in register 13.
Note that the same save area can be reused
after control is returned by the called
control section.
One new save area is
ordinarily all you will require regardless
of the number of control sections called.
PASSING CONTROL: Two standard methods are
available for passing control to another
control section and providing for return of
control. One is merely an extension of the
method used to pass control without a
return, and requires a v-type address constant and a branch or a branch and link
instruction.
The other method uses the
CALL macro-instruction to provide a parameter list and establish the entry point and
return point addresses. Using either method, the entry point must be identified by
an ENTRY instruction in the called control
section if the entry name is not the same
as the control section name. Example 9 and
Example 10 illustrate the two methods of
USING
ST
*,12
1,PARMADDR
Establish addressability
Save parameter address
L
L
L
LA
OI
LM
BR
13,4(13)
14,12(13)
15,NEXTADDR
1,PARMLIST
PARMADDR,X'80'
2,12,28(13)
15
Reload address of old save area
Load return address
Load address of next entry point
Load address of parameter list
Turn on last parameter indicator
Reload remaining registers
Pass control
DC
DC
DC
DC
DC
OA
A (INDCB)
A (OUTDCB)
A (0)
V(NEXT)
8.
Passing Control With a Parameter List
section I:
Supervisor Services
15
CNOP
BAL
DC
DC
DC
DC
DC
DC
BALR
15,NEXTADDR
0,4
1,GOOUT
OA
A(INDCB)
A (OUTDCB)
B'10000000'
AL3(AREA)
V(next)
14,15
Paranleter list address in register 1
Start of pararreter list
Input dcb address
Output dcb address
Last parameter bit on
Answer area address
Address of entry point
Pass control; register 14 contains return address
DC
12F'0'
Answer area from NEXT
L
PARNLIST
DCBADDRS
ANSWERAD
NEXTADDR
GOOUT
HETURNP'l.'
AREA
Example
9.
Entry point address in register 15
passing Control With Return
passing control; in each example, it is
assumed that register 13 already contains
the address of a new save area.
Use of an in-line parameter list and an
answer area is also illustrated in Example
9.
The address of the external entry point
is loaded into register 15 in the usual
manner. A branch and link instruction is
then used to branch around the parameter
list and to load register 1 with the
address of the parameter list. An in-line
parameter list such as the on~ shown in
Example 9 is convenient when you are debugging because the parameters involved are
located in the listing (or the dump) at the
point they are used, instead of at the end
of the listing or dump.
Note that the
first byte of the last address parameter
(ANSWERAD) is coded with the high-order bit
set to 1 to indicate the end of the list.
The area pointed to by the address in the
ANSWERAD parameter is an area to be used by
the called control section to pass parameters back to the calling control section.
This is a possible method to use when a
called control section must pass parameters
back to the calling control section. Parameters are passed back in this manner so
that no additional registers are involved.
The area used in this example is twelve
full words; the size of the area for any
specific
application
depends
on
the
requirements of the two control sections
involved.
RETURNPT
AREA
CALL
NEXT, (INDCB,OUTDCB,AREA),VL
DC
12F'0'
NEXT
a V-type address constant is created
for NEXT, and the address is loaded
into register 15.
(INDCB,OUTDCB,AREA)
A-type address constants are cLeated
for the three parameters coded within
parentheses, and the address of the
first
A-type
address constant is
placed in register 1.
VI
the high order bit of the last
address constant is set to 1.
Passing Control With CALL
The CALL macro-instruction in Example 10
provides the same functions as the instructions in Example 9. When the CALL macroinstruction is expanded, the operands cause
the following results:
A-type
Control is passed to NEXT using a branch
and link instruction. The address of the
instruction
following
the CALL macroinstruction is loaded into register 14
before control is passed.
In addition to the results described
acove,
the
V-type
address
constant
generated by the CALL macro-instruction
causes the load module with the entry point
NEXT to be automatically edited into the
same load module as the control section
containing
the
CALL macro-instruction.
Refer to the publication IBM System/360
Operating System: Linkage ~ditor if you are
interested in finding out more about this
service.
The parameter list constructed from the
CALL macro-instruction in Example 10 contains only A-type address constants.
A
variation on this type of parameter list
results from the following coding:
CALL
Example 10.
•
NEXT,(INDCB,(6),(7»,VL
In the above CALL macro-instruction, two of
the parameters to be passed are coded as
registers rather than symbolic addresses.
The expansion of this macro-instruction
again results in a three-word parameter
list; in this example, however, the expansion also contains the instructions necessary to store the contents of registers 6
and 7 in the second and third words,
16
J4
respectively, of the parameter list.
The
high-order bit in the third word is set to
1 after register 7 is stored.
You can
specify as many parameters as you need as
address parameters to be passed, and you
can use symbolic addresses or register
contents as you see fit.
•
ANALYZING THE RETURN:
When control is
returned from the control program after
processing a system macro-instruction, the
contents of registers 2-13 are unchanged.
When control is returned to your control
section from the called control section,
registers 2-14 contain the same information
they contained when control was passed, as
long as system conventions are followed"
The called control section has no obligation to restore registers 0 and 1, so the
contents of these registers mayor may not
have been changed.
Register 15, when control is returned,
can contain a return code indicating the
results of the processing done by the
called
control section.
If used, the
return code should be a multiple of 4, so a
branching table can be used easily, and a
return code of 0 should be used to indicate
a normal return.
The control program frequently uses this method to indicate the
results of the requests you make using
system macro-instructions; an example of
the type of return codes the contrel program provides is shown in the description
of the IDENTIFY and S'I'OW macro-instructions
in the publication IBM System/360 Operating
System:
Supervisor and Data
Management.
Macro-Instructions.
The meaning of each of the codes to be
returned must be agreed upon in aavance.
In some cases, either a "good" or "bad"
indication (zero or nonzero) will be sufficient for you to decide your next action.
If this is true, the code shown in Example
11 could be used to analyze the results.
Many times, l'lOwever, the results and the
alternatives are more complicated, and a
RETURNP'I'
•
,
LTR
BNZ
Example 11.
RETURNP,]~
RETTAB
B
B
B
B
B
Example 12.
15,15
ERRORTN
branching table, such as shown in Example
12, could be used to pass control to the
proper routine.
How Control Is Returned
In the discussion of the return under
the heading "Analyzing the Return" it was
indicated that the control section returning control must restore the contents of
registers 2-14. Because these are the same
registers reloaded when control is passed
without a return, refer to the discussion
under "Passing Control without Return" for
detailed information and examples.
The
contents of registers 0 or 1 do not have to
be restored.
Register 15 can contain a return code
when control is returned.
As indicated
previously, a return code should be a
multiple of four with a return code of zero
indicating a normal return.
The return
codes other than zero that you use can have
any meaning, as long as the control section
receiving the return codes is aware of that
meaning.
The return address is the address originally passed in register 14; return of
control should always be passed to that
address.
You can either use a branch
instruction such as BR 14, or you can use
the RETURN macro-instruction. An example
of each method of returning control is
discussed in the following paragraphs.
Example 13 is a portion of a control
section used to analyze input data cards
and to check for an out-of-tolerance condition. Each time an out-of-tolerance condition is found, in addition to some corrective action, one is added to the value at
the address STATUSBY. After the last data
card is analyzed, this control section
returns to the calling control section,
which proceeds based on the number of
out-of-tolerance conditions
encountered.
The coding shown in Example 13 causes
register 13 to be loaded with the address
Test return code for zero
Branch if not zero to error routine
Test for Normal Return
RETTAB(15)
NORMAL
CONDl
COND2
GIVEUP
Branch
Branch
Branch
Branch
Branch
to
to
to
to
to
table using return code
normal routine
routine for condition 1
routine for condition 2
routine to handle impossible situations
Return Code Test Using Branching Table
Section I:
Supervisor services
17
of the save area this control section used,
then reloads register 14 with the proper
return address. The contents of register
15 are set to zero, and the value at the
address STATUSBY (the number of errors) is
placed in the low-order eight bits of the
register. The contents of register 15 are
shifted to the left two places to ~ake the
value a multiple of four.
Registers 2-12
are reloaded, and control is returned to
the address in register 14.
The RETURN macro-instruction is provided
to save coding time. The expansion of the
RETURN
macro-instruction
provides
the
instructions necessary to restore a designated range of registers, provide the proper return code value in register 15, and
branch to the address in zegister 14. In
addition, the RETURN macro-instruction can
be used to flag the save area used by the
returning control section; this flag, a
byte containing all ones, is placed in the
high-order byte of word four of the save
area after
the
registers
have
been
restored.
The flag indicates that the
control section that used the save area has
returned to the calling control section.
You will find that the flag is useful when
tracing the flow of your program in a dump.
For a complete record of program flow, a
separate save area must be provided by each
control section each time
control
is
passed.
This is usually not done because
it requires too much main sto.rage.
The contents of register 13 must be
restored
before
the
RETURN
macroinstruction is issued. The registers to be
reloaded should be coded in the same order
as they would have been designated had a
SR
IC
SLA
LM
BR
13,4(13)
14,12(13)
15,15
15,STATUSBY
15,2
2,12,28(13)
14
DC
X'OO'
L
L
STATUSBY
Example 13.
18
•
Example 15 illustrates another use of
the RETURN macro-instruction. The correct
save area address is again established,
then the
RETURN
macro-instruction
is
issued.
In this example, registers 14 and
0-12 are reloaded, a return code of 8 is
placed in register 15, the save area is
flagged, and control is returned. Specifying a return code overrides the request
to restore register 15 even though register
15 is within the designated range of registers.
L
RETURN
13,4(13)
(14,12),T,RC=8
Example 15.
RETURN
Flag
Macro-Instruction With
Load address of previous save area
Load return address
Set register 15 to zero
Load number of errors
Set return code to multiple of 4
Reload registers 2-12
Return
SR
IC
SLA
RETURN
13.,4 (13)
14,12(13)
15,15
15, STATUS BY
15,2
(2,12),RC={15)
DC
X' 00"
Example 14.
The code shown in Example 14 provides
the same result as the code shown in
Example 13.
Registers 13 and 14
are
reloaded, and the proper value is established in register 15. The RETURN macroinstruction causes registers 2-12 to be
reloaded, and control to be passed to the
address in register 14. The save area used
is not flagged.
The
RC=(15)
operand
indicates that register 15 already contains
the return code value, and the contents of
register 15 are not to be altered.
Establishing a Return Code
L
L
STATUSBY
load-multiple (LM) instruction been coded.
You can load register 15 with the return
code value before you code the RETURN
macro-instruction, you can specify
the
return code value in the RETURN macroinstruction, or you can reload register 15
from the save area.
Restore save area address
Return address in register 14
Zero register 15
Load number of errors
Set return code to multiple of 4
Reload registers and return
Use of the RETURN Macro-Instruction
~,
Return to the Control Program
•
The discussion in the preceding paragraphs has covered passing control within
one load module, and has been based on the
assumpt~ion that the load module was brought
into main storage because of the program
name
specifi.ed in the EXEC statement.
Whether you were using an operating system
with t~he Pri.roary Control Program, MFT, or
MVT, has not affected the previous discussion. The control program established only
one task to be performed for the job step.
When the logical end of the program is
reached, control is returned to the address
passed in register 14 to the first control
section in the program. When the control
program receives control at this point, it
termina.tes the task it created for the job
step,
compares the return code in register
15 with any COND values specified on the
JOB and EXEC statements, and determines
whethe.:r or not the following job steps, if
any, should be executed.
PASSING CONTROL IN A PLANNED OVERLAY
STRUCTURE
A complete discussion of the require-·
ments for passing control in an overlay
environment is provided in the publication
IBM System/360 Operating System: Linkage
Editor.
PASSING CONTROL IN A DYNAMIC STRUCTURE
The discussion of passing control in a
simple structUJre has provided the necessary
background for the discussion of passing
control in a dynamic structure. Within
each load module, control should be passed
as in a simple structure or planned overlay
structure.
If you can determine which
control sections will make up a load module
before you code the control sections and if
they will fit in the main storage available, you should pass control within the
load module wi1:hout involving the control
program.
The macro-instructions discussed
in this section provide increased linkage
capability, but they require control pro-'
gram intervention and possibly increased
execution time ..
•
requests for dynamic acquisition; these
requests are made through the use of the
LOAD, LINK,
ATTACH,
or
XCTL
macroinstructions.
The following
paragraphs
discuss the proper use of these macroinstructions.
LOAD MODULE LOCATION:
Initially, all the
load modules you can acquire dynamically
are located in one of three libraries
(partitioned data sets); the link library,
the job library, or a private library.
• The link library is always present and
is available to all job steps of all
jobs. The control program provides the
necessary data control block for the
library, and logically connects the
library to your program, making the
members of the library available to
your program.
• The
job library is established by
including
one or more //JOBLIB DD
statements iwnediately following the
JOB statement in the input stream, and
is available to any job step in your
job.
The control program provides the
necessary data control block for the
library, and issues the OPEN macroinstruction to logically connect the
library to your program.
• A private library is established by
including a DD statement ~n the input
stream and is available only to the job
step in which it is defined. You must
provide
the necessary data control
block
and
issue
the OPEN macroinstruction for each data set. You may
use more than one private library by
including more than one DD statement
and
associated data control block.
Section 2 of this manual explains the
use of a partitioned data set.
If you are using an operating system
with MVT, some of the load modules from the
link library may already be in main storage
in an area called the link pack area.
The
contents of this area are determined at
Initial Program Loading time, and will vary
depending
on the requirements of your
installation. In general, the link pack
area contains frequently used, reenterable
load modules from the link library along
with data management load modules; these
load modules can be used by any job step in
any job.
Eringinq the Load Module Into Main Storage
'W"
'rhe load module containing the entry
point name you specified on the EXEC statement is automatically brought into main
storage by thE~ control program. Any other
load modules your require during you job
step al:."e brought into main storage by the
control program as a result of specific
With the exception of those load modules
contained in the link pack area, copies of
all of the load modules you request are
brought into your area of main storage, and
are available to any task in your job step.
The portion of your area containing the
copies of load modules is called the job
pack area.
Section I:
supervisor Services
19
SEARCH
FOR THE LOAD MODULE:
In
response to your request for a copy of a
load module, the control program searches
the libraries, the job pack area, and, when
one exists~ the link pack area. If a copy
of the load module is found in one of the
pack areas" the control program determines
whether or not that copy can be used, based
on criteria discussed under the heading
"Using an Existing Copy." If an existing
copy can be used, the search stops. If it
can not be used, the search continues until
the module is located in a library.
The
load module is then brought into the job
pack area.
'rHE
The order in which the libraries and
pack areas are searched depends upon the
operands
used in the macro-instruction
requesting the load module.
The operands
that define the order of the search are the
:EP " EPLOC, DE, and DCB operands" The EP,
EPLOC, and DE operands are used to specify
the name of the entry pOint in the load
module; you code one of the three every
time you use a LINK, LOAD, XCTL, or ATTACH
macro-instruction. The DCB operand is used
to indicate the address of the data control
Table
3.
block for the library containing the load
module, and is optional. Omitting the DCB
operand or using the DCB operand with an
address of zero specifies the data control
blocks for the job and link libraries.
The following paragraphs discuss the
order of the search when the entry point
name used is a member name.
•
The EP and EPLOC operands require the
least effort on your part; you provide only
the entry point name, and the control
program searches for a load module having
that entry point name. Table 3 shows the
order of the search when EP or EPLOC is
coded, and the DCB operand is omitted or
DCB=O is coded.
If you know that the load module you are
requesting is a member of one of the
private libraries~ you can still use the EP
or EPLOC operands, this time in conjunction
with the DCB operand. You would specify
the address of the data control block for
the private library in the DCB operand.
The order of the search for EP or EPLOC
with the DCB operand is shown in Table 4.
Search for Module, EP or EPLOC Operands With DCB=O or DCB Operand Omitted
r~~i;~~;-~~~~~~i-;~~;~~;-----T;;;--------------------------T~~;~------------------------l
~
~----------------------------+-----------------------------+----------------------------1
IThe job pack area is
IThe job pack area of the
IThe job pack area of the
I
Isearched for an available
Ipartition is searched for an Iregion is searched for an
I
lavailable copy
lavailable copy
I
I copy
~----------------------------+-----------------------------+----------------------------~
IThe job library, if any, is IThe job library, if any, is IThe job library, if any" is I
Isearched
I searched
I searched
I
~----------------------------+-----------------------------+----------------------------1
IThe link library is searchedlThe link library is searched IThe link pack area is
I
I
I
I searched
I
IIL____________________________ II_____________________________ IThe
~----------------------------1
link library is searchedl
____________________________
~
Table
4.
Search for
Library
Module,
~
J
EP or EPLOC Operands With DCB Operand Specifying Private
r----------------------------T-----------------------------T----------------------------,
I MFT
I MVT
I
I Primary Control Program
~----------------------------+-----------------------------+----------------------------1
IThe job pack area is
Isearched for an available
Icopy.
IThe job pack area of the
IThe job pack area of the
Ipartition is searched for an Iregion is searched for an
lavailable copy
lavailable copy
I
I
I
~----------------------------+-----------------------------+----------------------------1
IThe specified library is
I searched
IThe specified library is
I searched
IThe specified library is
I searched
I
I
I
IThe link pack area is
I searched
II
I
I
L ____________________________
I
I
I
I
~----------------------------1
I
I
~----------------------------1
~,
I _____________________________ IThe
link library is searchedlJ
____________________________
~
~
20
•
'-'"
•
The EP and EPLOC operands, when used
without the DCB operand, provide the most
general method of requesting a load ~odule
located on the link library or job library.
Also,
since the job library is searched
before the link library, the job library
can contain an updated or special version
of
a
module that would otherwise be
obtained from the link library or link pack
area. The data sets which make up the job
library are searched in the same oLder as
the //JOBLIB DD statements defining them;
therefore, an updated version of a load
module normally in the job library can be
obtained by placing the DD statement for
the data set containing the updated module
ahead of the
DD
statement
for
the
"standard"
job library data set.
No changes are required in the program requesting
t.he load module.
To save time, the BLDL macro-instruction
used must obtain directory entries for more
than one entry point name. You specify the
names of the load modules and the address
of the data control block for the library
when using the BLDL macro-instruction; the
control
program places a copy of the
directory entry for each entry point name
requested in a designated location in main
storage.
If the link and job litraries are
specified in the BLDL macro-instruction,
the directory information indicates from
which
library the directory entry was
taken. The directory ent.ry always indicates the exact relative track and block
location of the load module in the library.
If the load module is not located on the
library' you indicate, a return code is
given. You can then issue another BLDL
macro-instruction specifying a different
library.
Use of the DE operand requires more work
on your part,
but it can cut down on the
amount of time spent in finding a copy of
the load module.
To use the DE operand,
you must provide a copy in main storage of
the directory entry from the library for
that load module,
using the BLDL macroinstruction.
To use the DE operand, you provide the
address of the directory entry, and code or
omit the DCB operand to indicate the same
library
specified
in the BLDL macroinstruction. The order of the search when
the DE operand is used is shown in Table 5
for the link, job, and private libraries.
Table
5.
Search for Module Using DE Operand
r----------------------------T-----------------------------T----------------------------,
I Primary Control Program
I MFT
I MVT
I
•
~----------------------------~-----------------------------~----------------------------i
I
Directory Entry Indicates Link Library and DCB=O or DCB Operand Omitted
I
~----------------------------T-----------------------------T----------------------------i
IThe job pack area is
ITh~ job pack area for the
IThe job pack area for the
I
Isearched for an available
Ipartition is searched for an Iregion is searched for an
I
I copy
lavailable copy
lavailable copy
I
~----------------------------+-----------------------------+----------------------------i
IThe module is obtained fro~ IThe module is obtained from
IThe link pack area is
I
Ithe link library
Ithe link library
I searched
I
I
I
~----------------------------i
I
I
IThe module is obtained from I
I
I
Ithe link library
I
~----------------------------~-----------------------------~----------------------------i
I
Directory Entry Indicates Job Library and DCB=O or DCB Operand Omitted
I
~-------------,---------------T-----------------------------T----------------------------i
IThe job pack area is
IThe job pack area for the
IThe job pack area for the
I
Isearched for an available
Ipartition is searched for an Iregion is searched for an
I
lavailable copy
lavailable copy
I
I copy
~----------------------------+-----------------------------+----------------------------i
IThe module is obtained from IThe module is obtained from
IThe module is obtained from I
Ithe job library
Ithe job library
Ithe job library
I
~----------------------------~-----------------------------~----------------------------~
I
DCB Operand Indicates Private Library
I
~-------------·---------------T-----------------------------T----------------------------i
IThe' job pack area is
IThe job pack area for the
IThe job pack area for the
I
Isearched for an available
Ipartition is searched for an Iregion is searched for an
I
lavailable copy
lavailable copy
I
I copy
~-------------.---------------+-----------------------------+----------------------------i
IThe module is obtained from IThe module is obtained from
IThe module is obtained from I
Ithe specified private
Ithe specified private librarylthe specified private
I
library
library
LI _____________
._______________ I _____________________________ I ____________________________
JI
~
~
Section I:
Supervisor Services
21
The preceding discussion of the search
is based on the premise that the entry
point name you specified is the member
name.
When you are using an operating
system with the primary control program or
MFT,
the
same
search
results
from
specifying an alias rather than a member
name. When you are using an operating
system that includes MVT, the control program checks if the entry point name is an
alias when the load module is found in a
library. If the name is an alias, the
control program obtains the corresponding
member name from the library directory,
then searches the link pack and job pack
areas using the member name to determine if
a usable copy of the load module exists in
main storage.
If a usable copy does not
exist in a pack area, a new copy is brought
into the job pack area.
Otherwise, the
existing copy is used, conserving main
storage and eliminating the loading time.
As the discussion of the search indicates, you should choose the operands for
the
macro-instruction that provide the
shortest search time.
The search of a
library actually involves a search of the
directory, followed by copying the directory entry into main storage, followed by
loading the load module into main storage.
If you know the location of the load
module, you should use the operands in your
macro-instruction that eliminate as many of
these unnecessary searches as possible, as
indicated in Table 3, Table 4, and Table 5.
Examples of the use of these tables are
shown in the discussion of passing control.
USING AN EXISTING COPY: The control program will use a copy of the load module
already in the link pack area or job pack
area if the copy can be used. Whether the
copy can be used or not depends on the
reusability and current status of the load
module; that is, the load module attributes, as designated using linkage editor
control statements, and whether or not the
load module has already been used or is in
use.
The status information is available
to the control program only when you specify the load module entry point name on an
EXEC statement, or when you use ATTACH,
LINK, or XCTL macro-instructions to transfer control to the load module. The control program will protect you from obtaining an unusable copy of a load module as
long as you always "formally" request a
copy using these macro-instructions (or the
EXEC statement); if you ever pass control
in any other manner (for instance, a branch
or a CALL macro-instruction), the control
program, because it is not informed, cannot
protect you.
Operating System With MVT:
If you are
using an operating system with MV'I' , all
reenterable modules (modul~s designated as
22
reenterable using the linkage editor) from
any library are completely reusable; only
one copy is ever placed in the link pack
area or brought into your job pack area,
and you get immediate control of the load
module.
If the module is serially reusable, only one copy is ever placed in the
job pack area; this copy will always be
used for a LOAD macro-instruction. If the
copy is in use, however, and the request is
made using a LINK, ATTACH, or XCTL macroinstruction, the task requiring the load
module is placed in a wait condition until
the copy is available.
A LINK macroinstruction should not be issued for a
serially reusable load module currently in
use for the same task; the task will be
abnormally terminated.
(This could occur
if an exit routine issued a LINK macroinstruction for a load module in use by the
main program.)
If the load module is nonreusable, a
LOAD macro-instruction will always bring in
a new copy of the load module; an existing
copy is used only if a LINK, ATTACH, or
XCTL macro-instruction is issued and the
copy
has
not
been
used previously.
Remember, the control program can determine
if a load module has been used or is in use
only if all of your requests are made using
LINK, ATTACH, or XCTL macro-instructions.
Operating System Without MVT: If you are
using an operating system with the primary
control
program
or
MFT,
the macroinstruction used to request the load module
also determines if an existing copy can be
used.
If a LOAD macro-instruction
is
issued, an existing copy is always used to
satisfy the request, without regard to the
reusability designation or the current status of the copy. Howeve:r', if an ATTACH,
LINK, or XCTL macro-instruction is issued,
an existing copy is used only if that copy
was brought into main storage as a result
of a request using a LOAD macro-instruction
and the copy is not in use; otherwise, a
new copy is brought into the job pack area.
USE OF THE LOAD MACRO-INSTRUCTION:
The
LOAD macro-instruction is used to ensure
that a ~opy of the specified load module is
in main storage in your job pack area if it
is not preloaded into the link pack area.
When a LOAD macro-instruction is issued,
the control program searches for the load
module as discussed previously, and brings
a copy of the load Thodule into the job pack
area if required. When the control program
returns control, register 0 contains the
main storage address of the entry point
specified for the requested load module.
Normally, the LOAD macro-instruction is
used only for a reenterable or serially
reusable load ruodule, since the load module
is retained even though it is not in use.
•
The control program also establishes a
"responsibility" count for the copy, and
adds one to the count each time
the
requirements of a LOAD macro-instruction
are satisfied by the same copy. As long as
the responsibility count is not zero, the
copy is retained in main storage.
•
The responsibility count for the copy is
lowered by one when a
DELETE
macroinstruction is issued during the task which
was act.i ve when the LOAD macro-instruction
was issued. When a task is terminated, the
count is lowered by the number of LOAD
macro-instructions issued for the copy when
the task was active minus the number of
deletions.
When the responsibility count for a copy
in a job pack area reaches zero, the main
storage area contai:1ing the copy is made
available; the copy is never reused after
the responsibility count established by
LOAD macro-inst.ructions reaches zero.
Copies of load modules are not added to
or deleted from the link pack area; LOAD
and DELETE macro-instructions issued for
load modules already in the link pack area
result in returns indicating successful
completioa, however.
Passing Control With Return
The LINK macro-instruction is used to
pass control be-tween load modules and to
provide for return of control.
In an
operating system with the primary control
program
or
MFT,
the
ATTACH
macroinstruction is ,executed in a similar manner
to the LINK macro-instruction.
You can
also pass control using branch or branch
and link instructions or the CALL macroinstruction; however, when you pass control
in this manner you must protect against
multiple uses of nonreusable or serially
reusable modules. The following paragraphs
discuss
the
requirements
for passing
control with re-turn in each case.
•
THE LINK MACRO-INSTRUCTION: When you use
the LINK macro-instruction, as far as the
logic of your program is concerned~ you are
passing control to another load module.
Remember, however, that you are requesting
the control program to assist you in passing control.
You are actually passing
control to the control program, using an
SVC instruction, and requesting the control
program to find a copy of the load module
and pass control to the entry point you
designate.
There
is
some
similarity
between passing control using a LINK macroinstruction and passing control using a
CALL
macro-instruction
in
a
simple
structure, so these similarities are discussed first.
The convention regarding registers 2-12
still applies; the control program does not
change the contents of these registers, and
the called load module should restore them
before control is returned. You must provide the address in register 13 of a save
area for use by the called load module; the
control program does not use this save
area. You can pass address parameters in a
parameter list to the load module using
register 1; the LINK macro-instructiori provides the same facility for constructing
this list as the CALL macro-instruction.
Register 0 is used by the control program
and the contents will be modified.
Now some differences.
When you pass
control in a simple structure, register 15
contains the entry point address and register14 contains the return pOint address.
When the called load module gets control,
that is still what registers 14 and 15
contain, but when you use the LINK macroinstruction, it is the control program that
establishes these addresses. When you code
the LINK macro-instruction, you provide the
entry point name and possibly some library
information using the EP, EPLOC, or DE, and
DCB operands. But you have to get this
entry point and library information to the
control program. The expansion of the LINK
macro-instruction does this, by creating a
control
program
parameter
list
(the
information
required
by
the
control
program) and placing the address of this
parameter list in register 15.
After the
control program finds the entry point, it
places the address in register 15.
The return address in your control section is always the instruction following
the LINK; that is not, however, the addr~ss
that the called load module receives in
register 14. The control program saves the
address of the location in your program in
its own save area, and places in register
14 the address of a routine within the
control program that will receive control.
Because control was passed using the control program, return must also be made
using the control program.
The control
program
establishes
a
responsibility count for a load module when
control is passed using the LINK macroinstruction.
This
is
a
separate
responsibility count ftom the count established for LOAD macro-instructions, but it
is used in the same manner. The count is
increased
by
one when a LINK macroinstruction is issued, and decreased by one
when return is made to the control program
or when the called load module issues an
XCTL macro-instruction.
Example 16 shows the coding of a LINK
macro-instruction used to pass control to
an entry point in a load module from the
Section I:
Supervisor Services
23
job library. Except for the method used to
pass control, this example is similar to
Examples 9 and 10.
A problem program
parameter list containing the addresses
INDCB, OUTDCB, and AREA is passed to the
called load module; the return pOint is the
instruction following the
LINK
macroinstruction.
A v-type ,address constant is
not generated, because the load module
containing the entry point NEXT is not to
be edited into the calling load Rodule.
Note that ,the EP operand is chosen, since
the search begins with the job pack area
and the job library as shown in Table
SEARCH1.
Example 17 shows the use of the BLDL and
LINK macro-instructions to pass control.
Assuming control is to be passed to an
entry point in a load module from the link
library, a BLDL macro-instruction is issued
to bring the directory entry for the member
into main storage.
(Remember, however,
that time is saved only if more than one
directory entry is requested in a BLDL
macro-instruction. Only one is requested
here for simplicity.)
The first operand of the BLDL macroinstruction is a zero, which indicates tha't
the directory entry is on the link or job
libraries.
The second operand is
the
address in main storage of the list description field for the directory entry.
The first two bytes at LISTADDR indicate
the number of directory entries in the
list; the second two bytes indicate the
length of each entry. If the entry is to
be used in a LINK, LOAD, ATTACH, or XCTL
macro-instruction, the entry must be 58
bytes in length (hexadecimal 3A). A character constant is established to contain
the directory information to be placed
there by the control program as a result of
the
BLDL
macro-instruction.
The LINK
RETURNPT
AREA
NAMEADDR
The ECB operand allows you to specify
the address of an event control block~ a
fullword which will be used by the control
program to inform you of the completion of
the called load module. The return code
from the called load module will also be
DC
12F'0'
Use of the LINK Macro-Instruction
BLDL
O,LISTADDR
DC
DC
DC
DS
X'OOOl'
X'003A'
CL8'NEXT'
25H
Number of list entries
Length of each entry
Member name
Area required for directory information
Use of the BLDL Macro-Instruction
DE=NAMEADDR,DCB=O,PARAM=(INDCB,OUTDCB,AREA>,VL=l
Example 18.
24
The ATTACH macro-instruction performs
exactly the same functions as the LINK
macro-instruction, and should be used in
exactly the same way. You should use the
ATTACH macro-instruction only when coding
for upward compatibility with an operating
system that includes MVT.
There are two
additional optional operands provided with
the ATTACH macro-instruction: the ECB and
EXTR operands.
They provide a means of
communicating between tasks from the same
job step when they are used in an operating
system with MVT. They do not provide this
service in the other configurations of the
operating system because there is only one
task for each job step. If your program is
ever to be run in a system with MVT, the
use of these operands in the other configurations provides an opportunity to check
the routines associated with these operands.
Refer to "Task Management" for a
discussion of the ECB and ETXR operands if
this is the case. You may find other uses
for these operands in your current system.
EP=NEXT,PARAM=(INDCB,OUTDCB,AREA>,VL=l
Example 17.
LINK
USE
OF
THE
ATTACH
MACRO-INSTRUCTION
(WITHOUT MVT):
This discussion applies
only if you are using an operating system
with the primary control program or with
MFT.
In an operating system with MVT, you
use the ATTACH macro-instruction to cause
parallel execution, as discussed under the
heading "Task Creation."
LINK
Example 16.
LISTADDR
macro-instruction in Example 18 can now be
written.
Note that the DE operand refers
to the name field, not the list description
field, of the directory entry.
The LINK Macro-Instruction With a DE Operand
•
placed in the fullword.
For a complete
discussion of the event control block and
its purpose, see "Task Management."
The ETXR operand provides the means of
specifying an end-of-task exit routine to
be given control following the completion
of the called load module.
This exit
routine must be in main storage when it is
required. The routine is given control by
the control program and must return control
to the control program using the address in
register 14.
The control program then
returns control to the instruction following the ATTACH macro-instruction~
USING CALL OR BRANCH AND LINK: You can
save time by passing control to a load
module without using the control program.
passing control without using the control
program is performed as follows: issue a
LOAD macro-instruction to obtain a copy of
"the load module, preceded by a BLDL macroinstl:"uction if you can shorten the search
time by using it.
The control program
returns i:he address of the entry point in
register o.
Load
this
address
into
register 15. The linkage requirements are
the same when passing control between load
modules as when passing control between
control sections in the same load Il,odule:
register 13 must contain a save
area
address, register 14 must contain
the
return point address, and register 1 is
used to pass parameters in a parameter
list.
A branch instruction, a branch and
link
instruction,
or
a
CALL macroinstruction can be used to pass control,
using register 15. The return will be made
directly to you.
CAUTION:
When control is passed to a load
module without using the control program,
you must check the load module attributes
and current status of the copy yourself,
and you must check the current status in
all succeeding uses of that load module
during 1:he job step, even when the control
program is used to pass control.
The reason you have to keep track of the
usability of the load module has been
discussed previously: you are not allowing
the control program to determine whether
you can use a particular copy of the load
module. The following paragraphs dlSCUSS
your responsibilities when
using
load
modules with various attributes. You must
always know what the reusability attribute
of the load module is. If you do not know,
you should not~ attempt to pass control
yourself"
If the load module is reenterable, one
copy of the load module is all that is ever
required for a job step. You do not have
to determine the current status of the
copy; it can always be used. The best way
to pass control is to use a CALL macroinstruction or a branch or brancn and link
instruction.
If the load module is serially reusable,
one use of the copy must be completed
before the next use begins.
If your job
step consists of only one task, preventing
simUltaneous use of the same copy involves
making sure that the logic of your program
does not require a second use of the same
load module before completion of the first
use.
An exit routine must not require the
use of a serially reusable load module also
required in the main program.
Preventing simultaneous use of the same
copy when you have more than one task in
the job step requires roore effort on your
part.
You must still be sure that the
logic of the prograrr' for each task does not
require a second use of the same load
module before completion of the first use.
You must also be sure that no more than one
task requires the use of the same copy of
the load roodule at one time; the ENQ
macro-instruction can be used for this
purpose.
Properly used, the ENQ macroinstruction prevents the use of a serially
reusable resource, in this case a load
module, by more than one task at a time.
Refer to "Program Management Services" for
a complete discussion of the ENQ macroinstruction.
A conditional ENQ
macroinstruction can also be used to check for
simultaneous use of a serially reusable
resource within one task when using an
operating system with MFT or MVT.
If the load module is nonreusable, each
copy can only be used once; you must be
sure that you use a new copy each time you
require the load module.
If you are using
an operating system with MVT, you can
ensure that you always get a new copy by
always using a LINK macro-instruction or as
follows:
• Issue a LOAD macro-instruction
you pass control.
before
• Pass control using a branch or a branch
and link instruction or a CALL macroinstruction only.
• Issue a DELETE macro-instruction as
soon as you are through with the copy.
If you are using an operating system
with the primary control program or MFT,
you should perform the same three steps
indicated above# and also make sure that
you do not require a second use of the load
module before completion of the first use.
Section I:
Supervisor Services
25
How Control Is Returned
The return of control between
load
modules is exactly the same as return of
control between two control sections in the
same load module. The program in the load
module returning control is responsible for
restoring registers 2-14, possibly establishing a return code in register 15, and
passing control using the address in register 14. The program in the load module
to which control is returned can expect the
contents of registers 2-13 to be unchanged,
the contents of register 14 to be the
return pOint address, and optionally, the
contents of register 15 to be a return
code. The return of control can be made
using a branch instruction or the RETURN
macro-instruction. If control was passed
without using the control program, that is
all there is to it.
However, if control
was originally passed using the control
program, the return of control is to the
control program, then to the calling program. The action taken by the control
program is discussed in the following paragraphs.
when control was passed using a LINK
or
ATTACH
macro-instruction,
the
responsibility count was increased by one
for the copy of the load module to which
control was passed to ensure that the copy
would be in main storage as long as it was
required. The return of control indicates
to the control program that this use of the
copy is completed, so the responsibility
count is decremented by one.
If you are
using an operating system with the primary
control program or MFT, the main storage
area containing the copy is made available
when the responsibility count reaches zero.
If you are using an operating systen with
MVT, the copy is
retained
when
the
responsibility count reaches zero if all
three of the following requirements are
met:
• The load module attributes are serially
reusable or reenterable.
• The count was not reduced to zero
because of a DELETE macro-instruction.
• The main storage area is not required
for other purposes.
If control was originally passed using
an ATTACH macro-instruction (primary control program or MFT only), the control
program takes the following action:
• If the ECB operand was specified, the
control program posts the return code
in the indicated fullword.
• If the El'XR operand was specified, the
control program passes control to the
26
designated address, using register 15
to contain the entry pOint address, and
register 14 to contain the return point
address (to the control program). When
the exit routine returns control, the
control program passes control to the
instruction following the ATTACH macroinstruction
without
modifying
the
contents of any register except register 14.
Register 15 does not, in
this case, contain the return code.
If the ETXR operand was not specified,
or if the LINK macro-instruction was used
to pass control, the control program only
places the return point address into register
14, and passes control to that
address. No other register contents are
modified.
Passing Control Without Return
The XCTL macro-instruction is used to
pass control between load modules when no
return of control is required. You can
also pass control using a branch instruction; however, when you pass control in
this manner, you must protect against multiple uses of non-reusable or ser~ally
reusable modules. The following paragraphs
discuss the requirements for passing control without return in each case.
PASSING CON'l'ROL USING A BRANCH INSTRUCTION:
The same requirements and procedures for
protecting against reuse of a nonreusable
copy of a load module apply when passing
control without return as were stated under
"Passing Control With Return." The procedures for passing control are as follows.
A LOAD macro-instruction
should
be
issued to obtain a copy of the load module.
The entry point address returned in register 0 is loaded into register 15.
The
linkage requirements are the same when
passing control between load modules as
when passing control between control sections in the same load module; register 13
must be reloaded with the old save area
address,
then
registers
14 and 2-12
restored from that old save area. Registers 1 is used to pass parameters in a
parameter list. A branch instruction is
issued to pass control to the address in
register 15.
Mixing
branch instructions
macro-instructions is hazardous.
topic explains why.
and
The
XCTL
next
USE OF THE XCTL MACRO-INSTRUCTION: The
XCTL
macro-instruction, in addition to
being used to pass control, is also used to
indicate the control program that this use
of the load module containing the XCTL
macro-instruction is completed.
Because
control is not to be returned, the address
•
of the old save area must be reloaded into
registe~: 13.
The return point address must
be loaded into register 14 from the old
save area, as must the contents of registers 2-12.
The XCTL macro-instruction
can be written to request the loading of
registez·s 2-12, or you can do it yourself.
When usi.ng the XCTL macro-instruction, you
pass parameters in a parameter list, with
the address of the list contained in register 1. In this case, however, the parameter li.st must be established in a portion
of main storage outside the current load
module
containing
the
XCTL
macroinstruction. This is because the copy of
the cu.rrent load module may be deleted
before the called load module can use the
paramete!rs, as explained in more detail
below.
Control Program
A
1
LOAD B
BALR B
r----
B
Step 1
Control
Pro~r~ -+ A
Control
Program
I
I
,
I
BALR
-B
tJ
j
XCTL C
'l'he XCTL macro-instruction is similar to
the LINK macro-instruction in the method
used to pass control: control is passed by
way of the control program using a control
program parameter
list.
The
control
program loads a copy of the load module, if
necessa:r::'Y! establishes the entry
point
address ln register 15, saves the address
passed in register 14 and replaces it with
a new return point address within the
control program, and passes control to the
address in register 15. The control program addis one to the responsibility count
for the! copy of the load module to which
control is to be passed, and subtracts one
from the responsibility count for the current loa.d module. The current load module
in this: case is the load module last given
cont~rol using the control
program in the
performance of the active task. If you
have be!en passing control between load
modules without using the control program.,
chances are the responsibility count will
be lowered for the wrong load module copy.
And remember, when the responsibility count
of a copy reaches zero, that copy may be
deleted, causing ~npredicatable results if
you try to return control to itA
•
Figure 3 shows in detail how this could
happen. Control is given to load module A,
which passes control to load module B (step
1) using a LOAD macro-instruction and a
branch and link instruction.
Register 14
at this: time contains the address of the
instruct.ion following the branch and link.
Load module B then is executed, independent
of how control was passed, and issues an
XCTL macro-instruction when it is finished
(step 2:) to pass control to load module C.
The cont.rol program, knowing only of load
module A, lowers the responsibility count
of A by one, resulting in its deletion.
Load module C is executed and returns to
the addz·ess which used to fol·low the branch
and link instruction. step 3 of Figure 3
indicatE!s the result.
?
Sr
Control Program 1 - - - - - ,
B
I
,
:
..
XCTL C
Figure
3.
Step 2
1- I
I
I
I
I
I
'
-'
C
1
Step 3
RETURN -
Misusing Control Program Facilities
Two methods are available for ensuri~g
that the proper responsibility count 1S
lowered.
One way is to always use the
control program to pass control with or
without return. The other method is to use
only LOAD and DELETE macro-instructions to
determine whether or not a copy of a load
module should remain in main storage.
TASK CREATION
In any configuration of the operating
system, one task is created by the control
program as a result of initiating execution
of the job step. This task, called the job
step task, is the only task in the job step
in an operating system with the primary
control p~og ram or MFT. . Tas k creat ion is
not possible in one of these configurations. The job step task is also the
only task in a job step being executed in
an operating system with MVT if you decide
not to create any additional tasks. The
benefits of a multiprogramming environment
are still available even with only one task
in the job step; work is still "being
performed when your task is unable to use
the system while waiting for an event, such
as an input operation, to occur.
The
Section I:
Supervisor Services
27
advantage
in creating additional tasks
within the job step is that more than one
task in the job you are concerned with are
competing for control; when a wait condition occurs in one of your tasks" it is not
necessarily a task from some other job that
gets control. It may be one of your tasks"
a portion of your job. The general rule is
that parallel execution of a job step (that
is"
more than one task in a job step)
should be chosen only when a significant
amount of overlap between two or more tasks
can be achieved. The amount of time taken
by the control program in establishing and
controlling addi tional tasks"
and
your
increased effort to coordinate the tasks
and provide for communications between them
must be taken into account.
CREATING THE TASK
A new task is created by issuing an
ATTACH macro-instruction.
The task which
is active when the ATTACH macro-instruction
is issued is the originating task, the
newly created task is the subtask of the
originating task. The subtask competes for
control in the same manner as any other
task in the system, on the basis of priority and the current ability to use the
central processing unit.
The address of
the task control block for the subtask is
returned in register 1.
The entry point in the load module to be
given control when the subtask becomes
active is specified in the same way as in a
LINK macro-instruction; that is, through
the use of the EP, EPLOC, DE, and DCB
operands.
The use of these operands is
discussed in the section titled "Program
Management."
Pararoeters can be passed to
the subtask using the PARAM and VL operands, also described in "Program Management." Ownership of subpools is transferred or shared using the GSPV, GSPL,
SHSPV, and SHSPL operands discussed in
"Main Storage Management." The only additional operands are those dealing with the
priority of the subtask, and the operands
which provide for communication between
tasks.
SUBTASK PRIORITY
Every job to be executed in an operating
system with MVT is assigned a priority for
the job using either the PRTY parameter of
the JOB statement or the associated default
option. This priority is used in assigning
devices to the job steps ·in the job and in
determining the next job step to be initiated.
Once a job step has been formalized as the job step task, this priority
28
becomes the limit priority for every task
in the job step.
The tasks compete for
control on the basis of another priority,
the dispatching priority.
When the job
step is first formalized as a job step
task, the dispatching priority is the same
as the limit priority.
The dispatching
priority of any task can be lowered and
raised,
but can never be higher than the
current limit priority of the task.
The
limit priority of any subtask can be lowered and raised by the originating task,
but can never be higher than the limit
priority of the originating task.
The
original limit priority of the job step
task cannot be modified.
When the subtask is created, the limit
and dispatching priorities of the subtask
are the same as the current limit and
dispatching priorities of the originating
task except when the subtask priorities are
modified by using the LPMOD and DPMOD
operands of the ATTACH macro-instruction.
The LPMOD operand specifies the number to
be subtracted from the current limit priority of the originating task. The result of
the subtraction is assigned as the limit
priority of the new task. The DPMOD operand specifies the number to be added to the
current dispatching priority of the originating task. The result of the addition is
assigned as the dispatching priority of the
new task, unless the number is greater than
the limit priority, in which case the limit
priority value is used as the dispatching
priority.
There are no absolute rules for assigning
priorities to tasks and subtasks.
Priorities should be assigned on the basis
that tasks of higher priority will be given
control when competing with tasks of lower
priority. Tasks with a large number of
input/output operations should be assigned
a higher priority than tasks with little
input/output because the tasks with much
input/output will be in a wait condition
for a greater amount of time. The lower
priority tasks will be executed when the
higher priority tasks are in a wait condition; when the input/output operation has
completed, the higher priority tasks will
get control so that the next operation can
be started.
In addition, if one or more
subtasks must be completed before the originating task can proceed beyond a certain
point, the subtasks which must be completed
should be assigned a priority which will
eliminate as much as possible a long wait
time in the originating task.
since tasks from other job steps are
competing for control, the priority initially established for the subtasks may be
too high or too low to properly process the
job step. To correct this, the priorities
of these tasks can be changed after the
t
tasks have been created by using the CHAP
macro-instruction.
The
EXTRACT
macro·instruction, discussed previously, can be
used to determine the current dispatching
and limit priorities of the current task
and its subtasks.
•
The CHAP macro-instruction changes the
dispatching p:riority of the active task or
one of its sub-tasks. By adding a positive
or negative value, the dispatching priority
of the active task or a subtask is changed •
The dispatching priority of the active task
can be made less than the dispatching
priority
of
another task waiting for
control. If this occurs!, the waiting task
would be given control after execution of
the CHAP macro-instruction.
formed and are terminated asynchronously.
However, since each task is ~erforming a
portion of the same job step, you will
usually require some communication and constraints between tasks, such as notification of the completion of subtasks.
If
termination of a predecessor
task
is
attempted before all of the subtasks are
complete, those subtasks tasks and the
predecessor task are abnormally terminated.
Job
Step
Task
//'-.,.
/
/
//
'The CHAP macro-instruction can also be
used to increase the limit priority of any
of the active t.ask's subtasks. The active
task cannot change its own limit priority.
The dispatching priority of a subtask can
be rais~=d abovE~ its own limit priority, but
not above the limit of the originating
task. ~~hen the dispatching priority of a
subtask is raised above its own limit
priority, the subtask's limit priority is
automatically raised to equal its new dispatching priority.
TASK
MANAGEMEN~
/
•
Task .A is the originating task for both
tasks Al and A2# and task A2 is the
originating task for task A2a. A hierarchy
of tasks exists within the job step, therefore; the job step task~ task A, and task
A2 are ~redecessors of task A2a., while task
B has no direct relationship to task A2a.
All of the tasks in the job step compete
independ4::mtly j:or cont:rol; if no
constraints are provided, the tasks are per-
\
\,
\
\\
//
\
/
0
CD
/
/
/
\
\
\
\
/
o
/
\
I
\
//
I
IT~~kl
The t;ask management information in this
section is required only for establishing
communications between tasks in the same
job step, and therefore applies only to an
operating system with MVT.
The relationship of tasks in a job step is presented
here, using Figure 4.
The horizontal lines in Figure 4 divide
the tasks into various levels.
These
levels have no relation to task priorities;
they serve only to separate originating
tasks and subtasks. Tasks A, B, Ai, A2,
A2a, Bl, and B1a are all subtasks of the
job step task; tasks Al, A2, and A2a are
subtasks of task A. Tasks A2a, and B1a are
the lowest level tasks in the job step.
Although task Bl is at the same level as
tasks A1 and A2, it is not considered a
subtask of task A.
\
I
I
I
L::J
4.
Y
I
I
~
Figure
~
I
~
~
Task Hierarchy
TASK AND SUBTASK COMMUNICATIONS
Two operands, the ECB and ETXR operands,
are
provided
in
the
ATTACH
macroinstruction to assist in
communication
between a subtask and the originating task.
These operands are used to indicate the
normal or abnormal termination of a subtask
to the originating task. If either the ECB
or ETXR operands, or both, are coded in the
ATTACH macro-instruction, the task control
block of the subtask is not removed from
the system when the subtask is terminated .
The originating task must remove the task
control block from the system after termination of the subtask by issuing a DETACH
macro-instruction. The task control blocks
for all subtasks must be removed before the
originating task can terminate normally.
Section I:
Supervisor Services
29
The ETXR operand specifies the address
of an end-of-task exit routine in the
originating task to be given control when
subtask being created is terminated. The
lend-of-task routine is given control asynchronously after the subtask has terminated, and must be in main storage when it is
required. After the control program terminates the subtask, the end-of-task routine
specified when the subtask was created is
scheduled to be executed.
The routine
competes for control on the basis of the
priority of the originating task, and can
be given control even though the originating task is in the wait condition. When
the end-of-task routine returns control to
the control program" the originating task
remains in the wait condition if the event
control block has not been posted.
The end-of-task routine can issue an
EXTRACT macro-instruction specifying the
task control block of the terminated subtask; the address of that task control
block is contained in register 1 when the
routine is given control.
The EXTRACT
macro-instruction, discussed
under
the
heading "Obtaining Information From the
Task Control Block," can be used to obtain
such information as floating point register
contents and completion code. Although the
DETACH macro-instruction does not have to
be issued in the end-of-task routine, this
is a good place for it.
The ECB operand specifies the address of
an event control block (di~cussed under
"Task Synchronization") which is posted by
the control program when the subtask is
terminated. After posting, the event control block contains the completion code
specified for the subtask.
If neither the ECB nor ETXR operands are
specified in the ATTACH macro-instruction,
the task control block for the subtask is
removed from the system when the subtask is
terminated. No DETACH macro-instruction is
required. Use of the task control block in
a
CHAP,
EXTRACT,
or
DETACH
macroinstruction in this case is risky as is
task termination; since the originating
task
is
not
notified
of
subtask
termination,
you may refer to a task control block which has been removed from the
system, which would cause the active task
to be abnormally terminated.
TASK SYNCHRONIZATION
Task synchronization requires some planning on your part to .determine what portions of one task are dependent on the
completions of portions of all other tasks.
The POST macro-instruction is used to sig-
nal completion of an event; the WAIT macroinstruction is used to indicate that a task
cannot proceed until one or more events
that have occurred.
The control block used with both the
WAIT and POST macro-instructions is the
event control block.
An event control
block is a fullword on a fullword boundary
and is shown in Figure 5.
o
1
2
31
IwI I
p
completion code
Figure
5.
Event Control Block
An event control block is used when the
ECB operand is coded in an ATTACH macroinstruation.
In this case the control
program issues the POST macro-instruction
for
the
event
(subtask termination).
Either the return code in register 15 (if
the task completed normally) or the completion code specified in the ABEND macroinstruction (if the task was abnormally
terminated) is placed in the event control
block
as
shown
in
Figure
5.
The
originating task can issue a WAIT macroinstruction specifying the event control
block; the task will not regain control
until after the event has taken place and
the event control block is posted.
When
an
event
control
block
is
originally created, bits 0 and 1 must be
set to zero. An event control block can be
reused;
if it is reused, bits 0 and 1 must
be set to zerp before either the POST or
WAIT macro-instruction can be issued. When
a WAIT macro-instruction is issued, bit 0
of the associated event control block is
set to 1. When a POST macro-instruction is
issued, bit 1 of the associated event
control block is set to 1, and bit 0 is set
to O.
A WAIT macro-instruction can specify
more than one event by specifying more than
one event control block.
Only one WAIT
macro-instruction can refer to an event
control block at one time, however.
If
more than one event control block is specified in a WAIT macro-instruction, the WAIT
macro-instruction can also specify that all
or only some of the events must occur
before the task is taken out of the wait
condition.
When a sufficient number of
events have taken place (event control
blocks have been posted) to satisfy the
number of events indicated in the WAIT
macro-instruction, the task is taken out of
the wait condition.
30
4
PROGRAM l'1ANAGEMENT SERV ICES
•
The control program provides a set of
optional services which are available to
your program t:hrough the use of macroinstructions.
The following paragraphs
discuss each of these services and the way
to obtain them. The proper use of any of
these services results in an improved and
more efj: icient program; the misuse
or
overuse of the services results in a waste
of main 8torage and execution time.
ADDITION1~L
ENTRY POINTS
Through the use of linkage editor facilities you can specify as many as six
diff erent: names
(a member name and
5
aliases> and associated entry points within
a load module.
It is only through the use
of the member name or the aliases that a
copy of t:he load modul e can be brought into
main stol:age. Once a copy has been brought
into main storage, however"
additional
entry points can be provided for the load
module, subject to the following restrictions:
• The "identify" option must have been
included in the operating system during
systE~m genez'ation (standard in an operatingr system with MVT, optional with
the other configurations of the operating Si ystem> •
• The load module copy to which the entry
point: is to be added mus t be one of the
following:
a copy which satisfied the requirements of a LOAD macro-instruction
ise:ued during the same task, or
the copy of the load module most
recently given control through the
control program in performance of the
same task.
•
•
meets the requirements listed above; if it
is not, the entry point will not be added,
and you will be given a return code of OC
(hexadecimal>.
The name can be any valid
symbol of up to eight characters, an~ does
not have to correspond to a name or symbol
within the load module. The name must not
be the same as any other name used to
identify any load module available to the
control program; duplicate names
would
cause errors.
The control program checks
the names of all load modules currently in
the link pack area and the job pack area of
the job step when you issue an IDENTIFY
macro-instruction, and provides a return
code of 08 if a duplicate is found.
You
are
responsible for not duplicating a
member name or an alias in any of the
libraries unintentionally.
The added entry point can be used only
in an ATTACH macro-instruction when you are
using an operating system with the primary
control program or MFT, and can be used in
an ATTACH, LINK,
LOAD"
or XCTL macroinstruction in an operating system with
MVT. The added entry point can be used in
the performance of any task in the job
step; if the copy is in the link pack area,
the
entry
point can be used in the
performance of any task in the system.
The added entry point is available for
as long as the copy is retained in main
storage. Proper task synchronization is
required when using an added entry point in
the. performance of a task which has not
directly requested the associated copy of
the load module; the load module may otherwise te deleted before the use is complete.
The added entry point is treated as an
entry point to a reenterable load module by
the control program, regardless of the
actual module attributes of
the
load
module.
You must guard against reuse of
non-reusable code.
The entry point is added through the use
of the IDENTIFY macro-instruction.
An
IDENTIFY macro-instruction can be issued by
any program in the job step, except by
asynchronous
exit
routines established
using other supervisor macro-instructions.
A further restriction exists for an operating syst;em with either MFT or the primary
control
program:
an
IDENTIFY
macroinstruction can not be issued when the load
module is: given control at an entry point
which wa,s added by an IDENTIFY, macroinstructi.on.
ENTRY POINT AND CALLING SEQUENCE
IDENTIFIERS
An entry point identifier is a character
string of up to 70 characters which can be
specified in a SAVE macro-instruction. The
character string is created as part of the
SAVE macro-instruction expansion. The dump
program uses the calling point identifier
and the entry point identifier as shown in
the publication IBM System/360 Operating
System:
Messages, Completion Codes"
and
Storage Dumps •
When
you
use
the IDENTIFY macroinstructi.on, you specify the name to be
used to identify the entry point, and the
main stox'age address of the entry point in
the copy' of the load module. The address
must be ~Ii thin a copy of a load module that
A
calling sequence identifier is a
16-hit binary number which can be specified
in a CALL or a LINK macro-instru~tion.
When coded in a CALL or a LINK macroinstruction,
the
calling
sequence
identifier is located in the two low-order
Section I:
supervisor Services
31
bytes of the fullword at the return point
address. The high-order two bytes of the
fullword form a NOP instruction.
USING A SERIALLY REUSABLE RESOURCE
The example of a serially
reusable
resource already encountered was a load
module that was designated serially reusable.
In the discussion of the serially
reusable load module it was emphasized that
simultaneous uses of the load module must
be prevented. This is true for any serially reusable resource when one or more of
the users will modify the resource.
Consider a data area in main storage
that is being used by programs associated
with several tasks of a job step. Some of
the users are only reading records in the
data area; since they are not changing the
records, their use of the data area can be
simultaneous.
Other users of the data
area, however, are reading, updating, and
replacing records in the data area.
Each
of these users must acquire, update, and
replace records one at a time, not simultaneously. In addition, none of the users
that are only reading the records wish to
use a record that another user is updating"
until after the record has been replaced.
This illustrates the manner in which all
serially reusable resources must be used.
For all of the uses of the serially
reusable resource made during the performance of a single task"
you must prevent
incorrect use of the resource yourself.
You must make sure that the logic of your
program does not require the second use of
the resource before completion of the first
use. Be especially careful when using a
serially reusable resource in an exit routine; since exit routines are given control
asynchronously from the standpoint of your
program logic, "the exit routine
could
obtain a resource already in use by the
main program. For the uses of the serially
reusable resource required by more than one
task, the ENQ macro-instruction is provided
to ensure use of the resource in a serial
manner.
The ENQ macro-instruction cannot
be used to prevent simultaneous use of the
resource within a single task. It can be
used to test for simultaneous use within
one task-rn-an operating system with MFT or
MVT only.
The
ENQ
and
DEQ
macroinstructions are not available
in
an
operating system with the primary control
program.
delays assignment of control by placing the
active task in the wait condition. When
the status of the resource changes so that
control can be given to a waiting task, the
task is taken out of the wait condition and
placed in the ready condition. The use of
the ENQ macro-instruction is discussed in
the following paragraphs.
Naming the Resource
You represent the resource in the ENQ
macro-instruction by two names, known as
the qnarne and the rname. These names may
or may not have any relation to the actual
name of the resource. The control program
does not associate the name with the actual
resource; it merely processes requests having the same qname and rname on a first-in,
first-out basis.
It is up to you to
associate the names
with
the
actual
resource.
It is up to all users of the
resource to use qname and rname to represent the same resource.
The control
program treats requests having different
qname and rname combinations as requests
for
different
resources.
Because the
actual resource is not identified by the
control program, it is possible to use the
resource without issuing an ENQ macroinstruction
requesting
it.
If
this
happened, the control program cannot provide any protection.
If the resource is used only in the
performance of tasks in your job step, you
can assign the qname and rname combination.
You should, in this case, code the STEP
operand in the ENQ macro-instructions that
request the resource, indicating that the
resource is used only in that job step.
The control program will add the job step
identifier to the rname so that no duplicate qname and rname combination will be
used unintentionally in
different
job
steps. If the resource is available to any
job step in the system, the qname and rname
combination must be agreed upon by all
users and perhaps published.
The SYSTEM
operand should be coded in each ENQ macroinstruction
requesting
one
of
these
resources.
When selecting a qname for the resource,
do not use SYS as the first three characters; qnames used by the control program
start with SYS and you might accidentally
duplicate one of these.
Exclusive and Shared Requests
The ENQ macro-instruction requests the
control program to assign control of a
resource to the active task.
The control
program determines the current status of
the resource, and either grants the request
by returning control to the active task or
32
You can request exclusive or shared
control of the resource for a task by
coding either "E" or US", respectively, in
the ENQ macro-instruction. If this use of
the resource will result in modification of
•
the resource, you must request exclusive
control. If you are requesting use of a
serially reusable load module and passing
control yourself, as discussed previously,
you must request exclus:i!lve control, since
that program modifies itself during execution.
If you are updating a record in a
data are'a, you must request exclusive control.
If you are only reading a record,
and you will not change the record, you can
request shared control. In order to protect any user of a serially
reusable
resource, all users must request exclusive
or shared control on this basis.
When a
task is given control of a resource in
response to an exclusive request, no other
task will be given simultaneous control of
the resource. When a task is given control
of a resource in response to a shared
request, control will be given to other
tasks simultaneously only in response to
other requests :for shared control, never in
response to requests for exclusive control.
A request for shared control will protect
against modification o:f the resource by
another task only if the above rules are
followed.
Processing the Reguest
The control program essentially const.ructs a lis"t for each qname and rname
combination it receives in an ENQ macroinstruction, and makes an entry in the list
representing the task which is active when
the ENQ macro-instruction is issued.
The
entry is made in an existing list when the
control
program
receives
a
request
specifying a qname and rname combination
for which a list exists; if no list exists
for that qname and rname combination, a new
list is built. The entry repres~nting the
task is placed en the list in the order the
request is received by the control program;
the prio.rity of the task has no effect in
this case.
Centrol of the resource is
allocated to a task based on two factors:
• The position on the list of
representing the task.
the
Eventually control of the resource is
released for the task represented by ENTRY
1 and the entry is removed from the list.
As shown in Figure 6, Step 2, ENTRY 2 is
now first on the list, and the corresponding task is assigned control
of
the
resource. Because the request which established ENTRY 2 was for exclusive control,
the tasks represented by all the other
entries in the list are kept in the wait
condition.
Figure 6, Step 3 shows the status of the
list after control of the resource is
released for the task represented by ENTRY
2. Because ENTRY 3 is now at the top of
the list, the task represented by ENTRY 3
is given control of the resource. ENTRY 3
indicated the resource could be shared,
and, tecause ENTRY 4 also indicated the
resource could be shared, ENTRY 4 is also
given control of the resource.
In this
case, the task represented by ENTRY 5 will
not be given control of the resource until
control has been released for both the
tasks represented by ENTRY 3 and ENTRY 4.
The remainder of the list is processed in
the same manner.
ENTRY] (5)
ENTRY2 (E)
ENTRY2 (E)
ENTRY3 (5)
ENTRY3 (5)
ENTRY4 (5)
ENTRY4
(~)
ENTRY4 (5)
ENTRY5 (E)
ENTRY5 (E)
~RY5(E)
ENTRY6 (5)
5tep]
ENTRY6 (5)
5tep 2
ENTRY6 (5)
5!ep 3
ENTRY3 (5)
---.~-----
Figure
6.
ENQ Macro-Instruction
ing
Process-
entry
• The exclusive control or shared control
requirements of the
request
Which
caused the entry to be added to the
list.
•
represented by ENTRY 1 (Figure 6, step 1)
is assigned the resource.
The request
which established ENTRY 2 was for exclusive
control,
so the corresponding task is
placed in the wait condition, along with
the tasks represented by all the other
entries in the list.
The control program uses these two factors in determining whether control of a
resource can be allocated to a task, as
indicated below.
Figure 4 shows the current sta"tus of a list built for a very
popular qname and rname combination. The S
or E next to the entry indicates that the
request lWias for shared or exclusive control, respectively.
The task represented
by the first entry on the list is always
given ciontrol of the resource" so the task
The following general rules are used by
the control program:
• A task represented by the first entry
in the list is always given control of
the resource.
• If the request is for exclusive control, the task is not given control of
the resource until the corresponding
entry is the first entry in the list.
• If the request is for shared control,
the task is given control either when
the corresponding entry is first in the
list or when all the entries before it
in the list also indicate a shared
request.
Section I:
Supervisor Services
33
Proper Use of ENQ and rEQ
Proper use of the ENQ and DEQ macroinstructions is required to avoid dUplicate
requests, to avoid tieing-up the resource,
and to avoid interlocking the
system.
Guides to proper use are given in the
following paragraphs.
DUPLICATE, REQUESTS: A dUplicate request is
a second ENQ macro-instruction requesting a
resource made when performing a task which
has already been assigned control of the
resource
or which is waiting for the
resource. If the second request resulted
in a second entry on the list, the control
program recognizes the contradiction and
refuses to place the task in the ready
condition (for the first request) and in
the wait condition (for the second request)
simultaneously. The second request results
in abnormal termination of the task. You
must plan the logic of your program to
ensure that a second request for a resource
is never issued until control of
the
resource is released for the first use.
Again, be especially careful when using an
ENQ macro-instruction in an exit routine.
RELEASING CONTROL OF THE RESOURCE: The DEQ
macro-instruction is used to release control
of
a serially reusable resource
assigned to a task through the use of an
ENQ macro-instruction. The task must be in
control of the resource.
Control of a
resource cannot be released if the task
does not have control. As you have seen,
it is possible for many tasks to be placed
in the wait condition while one task is
assigned control of the resource. This may
reduce the amount of work being done by the
system. Issue a DEQ macro-instruction as
soon as possible to release control of the
resource, so that other tasks can be performed.
If you return to the control
program at the end of processing for any
task which is still assigned control of a
resource, that task is abnormally terminated.
CONDITIONAL
AND UNCONDITIONAL REQUESTS:
The normal use of the ENQ and DEQ macroinstruction is
to
make
unconditional
requests.
These are the only requests we
have considered to this point. As you have
seen, abnormal termination of the task
occurs when two ENQ macro-instructions are
issued for the same resource in performance
of the same task, without an intervening
DEQ macro-instruction.
Abnormal termination also occurs if a DEQ macro-instruction
is issued in the performance of a task
which has not been assigned control of the
resource. Both of these abnormal termination conditions can be avoided by either
more careful program design or through the
use of the RET operand in the ENQ or DEQ
macro-instructions.
The
RET
operand
34
(RET=TEST, RET=USE, and RET=HAVE for ENQ,
RET=HAVE for DEQ) indicates a conditional
request for control or release of control.
RET=TEST is us~d to test the status of
the list for the corresponding qname and
rname combination. An entry is never made
in the list when RET=TEST
is
coded.
Instead a return code is provided indicating the status of the list at the time the
request was made.
A return code of 8
indicates
an entry for the same task
already exists in the list. A return code
of 4 indicates the task would have been
placed in the wait condition if the request
had been unconditional. A return code of 0
indicates the task would have been given
immediate control of the resource if the
request had been unconditional.
RET=TEST
is most useful when used to determine if
the task has already been assigned control
of the resource.
It is less useful when
used to determine the current status of the
list and to take action based on that
status; in the interval between the time
the control program checks the status and
the time the return codes are checked by
your
program
and
another ENQ macroinstruction issued, another task could have
been made active and the status of the list
could have been changed.
RET=USE indicates to the control program
that the active task is to be assigned
control of the resource only
if
the
resource is immediately
available.
A
return code of 0 indicates that an entry
has teen made on the list and the task has
been assigned control of the resource. A
return code of 4 indicates that the task
would have been placed in the wait condition if the request had been unconditional;
no entry is made in the list.
A return
code of 8 indicates an entry for the same
task already exists in the list.
RET=USE
can be best used when there is other
processing that could be performed without
using the resource. You would not want to
wait for the resource as long as there was
other work that you could do.
RET=HAVE is used in both the ENQ and
DEQ macro-instructions.
An ENQ macroinstruction
is
processed as a normal
request for control unless an entry for the
same task already exists. A return code of
8 indicates an entry for the same task
already exists in the list. A return code
of 0 indicates that the task has been
assigned control of the resource. A DEQ
macro-instruction is processed as a normal
request to return control unless the task
does not have control of the resource.
A
return code of 0 indicates that control of
the resource has been released.
A return
code of 8 indicates that the task does not
have control of the resource (although the
task may be in the wait condition because
'.,.
of a request for the resource).
RET=HAVE
can be used to good advantage in an exit
routine t.o avoid abnormal termination.
«
AVOIDING INTERLOCK: An "interlock" situation occurs when two or more tasks are
dependent. on each other in such a way that
none of the tasks can be taken out of the
wait condition until one of the same tasks
has been performed. An example of a fully
developed interlock situation is shown in
.Figure 7. The task represented by ENTRY 1
in List 1 is thE~ same task represented by
ENTRY 2 :in List 2. The task represented by
ENTRY 2 in List 1 is the same task represented by ENTRY 1 in List 2. Control of
the resource represented by List 1 is
assigned to the task which is waiting for
the resource represented by List 2. Control of t.he resource represented by List 2
is assigned to the task which is waiting
for the Jresource represented by List 1.
Other tasks requiring either of the resources are also in a wait condition because of
the inb~rlock, although in this case they
have not. contributed to the condi tions
which caused thE~ interlock.
~-------ENTR~raSk 1 _
• The ENQ macro-instruction can be written to request control of more than one
resource at a time; control of any of
the resources will not be given until
control of all resources requested in
the macro-instruction can be given.
For example, instead of coding the two
ENQ macro-instructions shown in Example
19, the one ENQ macro-instruction shown
in Example 20 could be coded. If all
requests were made in this manner, it
would avoid the interlock shown in
Figure 5. All of the requests for one
task would be processed before any of
the requests for the second task.
The
DEQ macro-instruction should be written
in the same manner to release the
entire "set" of resources at once.
ENQ
ENQ
(NAME1ADD,NAME2ADD,E,8,SYSTEM)
(NAME3ADD,NAME4ADD,E, 10, SYSTEM)
Example 19.
ENQ
(NAME1ADD,NAME2ADD,E,8,SYSTEM,
NAME3ADD,NAME4ADD,E, 10, SYSTEM)
Example 20.
Task 2
Two Requests for Two Resources
C
One Request for Two Resources
ENTRY 1 (E)
~~
ENTRY 2 (E)
ENTRY 2 (E)
-------
List 2
list 1
Figure
7.
Interlock Condition
The above example involving two tasks
and two lC'esources is a simple example of an
interlock situat.ion. The example could be
expanded to cover many tasks and many
resources. It is imperative that interlock
situations be avoided. The following procedures indicat:e some ways of preventing
interlock situat:ions:
• Do not request resources that are not
immediately required.
If you can use
the serially reusable resources one at
a time, you should request them one at
a tillle" and release control for one
befOJre requE~sting control for the next.
•
shared control as much as posIf t:he entries in the lists
shown in Figure 7 had indicated shared
requE~sts,
t:here would have been no
intelt"lock.
This does not mean you
should indicate a reques~for shared
contJrol when you will
modify
the
:reSOllrce. It does mean that you should
anal~{ze
your requirements
for
the
resources carefully, and
not
make
:requE~sts
for exclusive control when
.requests for shared control would suffice ..
RequE~st
sibl~~.
• If the use of one resource always
depends on the use
of
a
second
resource, then the pair of resources
can be defined as one resource in the
ENQ and DEQ macro-instructions. This
procedure can be used for any number of
resources that are always used in conjunction. There would be no protection
of the resources if they are also
requested independently, however.
The
request would always have to be for the
set of resources.
• If there are many users of a group of
resources and some of the users require
control of a second resource while
retaining
control
of
the
first
resource, it is still possible to avoid
interlocks. In this case the order in
which control of the resources
is
requested should be the same for each
user. For instance, if resources A, B
and C are required in the performance
of many tasks~ the requests for control
should always be made in the order of
A, Band C. In th~s manner an interlock situation will not develop, since
requests for resource A will always
precede requests for resource B.
The above is not an exhaustive list of
the procedures to be used to avoid an
interlock condition. You could also make
repeated requests for control spec~fying
the RET=USE operand, which would prevent
the task from being placed in the wait
condition; if no interlock situation was
section I:
Supervisor Services
35
developing"
of course, this would be an
unnecessary waste of execution time.
The
solution to the interlock problem in all
cases requires the cooperation of all the
users of the resources.
trol program or MFT" each additional item
of information requested will result in the
corresponding fullword in the answer area
being set to zero.
TIMING SERVICES
OBTAINING INFORMATION FROM THE TASK CONTROL
BLOCK
Most of the information available from
the task control block is useful primarily
in task management.
The following paragraphs discuss the information available
and how to obtain it.
How you use the
information provided depends on the application of your program.
The EXTRACT macro-instruction is used to
obtain the information from the task control block. The full power of the EXTRACT
macro-instruction
is
available
(and
required) only in an operating system with
MVTi however, a limited amount of information can be obtained through the use of the
EXTRACT macro-instruction with the other
configurations of the operating system.
Information can be obtained from the
task control block for the active task or
any of its subtasks. The following information can be requested:
• The address of the general and floating
point registers save areas. These are
the save areas used by the control
program when the task is not active.
• The address of the end-of-task exit
routine to be given control after the
specified task is terminated.
• The limit and dispatching priorities of
the specified task.
• The completion code if the task has
been terminated. If the specified task
has not been terminated~ the completion
code value is set to zero.
• The address of the task input/output
table. This is the only information
provided in response to an EXTRACT
macro-instruction when using an operating system with the primary control
program or MFT.
You must provide an area into which the
control program places the information you
request.
If you request all of the fields
(by coding FIELDS=ALL)~ the area must be
seven full words long. If you request only
a portion of the information, the area must
be one fullword in length for each item of
information you request.
If you request
information other than the address of the
task input/output table when you are using
an operating system with the primary con36
The timing services available depend on
options selected when the operating system
was generated. These options are the time
option, which provides the ability
to
request the date and time of day, and the
interval option, which includes the time
option functions and also provides the
ability to set, test, and cancel intervals
of time.
The interval option is standard
in an operating system with MVTi either
option can be selected with the other
configurations of the operating system. If
neither of these options was selected, the
date is the only timing service provided.
Date and Time of Day
The operator is responsible for initially supplying the currect data and time of
day information, based on a 24-hour clock~
for control program use. The control program updates the time of day information
every 16.1 milliseconds for 60 cycle-persecond
line
frequency,
or
every 20
milliseconds for 50 cycle-per-second line
frequency.
You request the date and time
of day information using the TIME macroinstruction.
The control program returns
the date in register 1 and the time of day
in register o.
The date is returned in register 1 as
packed decimal digits of the form OOYYDDDC,
where YY are the last two digits of the
year and DDD is the day of the year. C is
a sign character which allows the year and
day information to be unpacked directly for
printing.
One procedure used to request
the day of the year is shown in Example 21.
The time of day is returned in register
in the form specified in the TIME macroinstruction. The time of day is returned
as an unsigned 32-bit binary number that
specifies the elapsed number of either
hundredths of a second, if BIN is coded, or
timer units, if TU is coded.
(A timer unit
is equal to 26 micro-seconds.) If DEC is
coded or the operand is omitted, the time
of day is returned as packed decimal digits
of the form HHMMSSth (hours,
minutes~
seconds, tenths of a second, and hundredths
of a second).
The packed decimal digits
can be unpacked by changing the "h" value
to a zone sign and using an UNPK instruction or by inserting zones between each
decimal digit. If both the time and interval options have not been selected, the
operand is ignored and the content of
register 0 is set to zero.
o
'-'
ANS
DOUBLE
TIME
ST
UNPK
1,ANS
DOUBLE,ANS
Request date
store packed date
Unpack date for printing
08
DB
F'
D
Fullword for packed date
Double word for unpacked date
Example 21.
Day of Year Processing
Interval Timing
•
A time interval can be established for
any task in the job step through the use of
the STIMER macro-instruction, and the time
remaining in the interval can be tested and
canceled through the use of the TTl MER
macro-instruction. When you are using an
operating system with the primary control
program or MFT, only one time interval can
be in effect at anyone time during the job
step.
With an operating system with MVT,
each task in the job step can have an
active time interval.
The time interval can be established by
anyone of the following four methods.
• BINTVL - requires an unsigned 32-bit
binary number, the low order bit having
a value of 0.01 second.
• TUINTVL
requires an unsigned 32-bit
binary number, the low order bit having
a value of 26 micro-seeonds (1 timer
unit).
• DINTVL - requires 8-byte field containing unpacked decimal digits of the form
HHMMSSth (hours,
minutes,
seconds,
tenths and hundredths of a second,
based on a 24-hour clock).
• TOD .- requil~es a 8-byte field similar
to the field required for DINTVL. The
control program interprets the time
specified as the time of day at which
the interval is to expire.
When you test the time remaining in the
interval" the ti.me remaining is returned as
a 32-bit unsigned binary number in register
0,
the low order bit having a value of 26
micro-seconds. If the interval has already
expired, the content of register 0 is set
to zero.
When you request a time interval, you
als-o specify the manner in which the interval is to be decremented, through the use
of the TASK, REAL, or WAIT parameters of
the STIMER -macro-instruction.
REAL and
WAIT both indicate that the interval is to
be decrE!mented continuously whether the
associated task is active or not. TASK
indicates that the interval is to be decremented only when the associated task is
active. If REAL or TASK is coded, the task
continues to compete with the other ready
tasks for control; if WAIT is coded, the
task is placed in the wait condition until
the interval expires, at which time the
task is placed in the ready condition.
WAIT should not be coded in an operating
system with the primary control program,
because no productive work can be performed
when the only task is in a wait condition.
When TASK or REAL is designated, the
address of a timer completion exit routine
can be specified. This is the first routine to be given control when the associated task is made active after the completion
of the time interval.
(If the address of
the exit routine is not specified, there is
no notification of the completion of the
time interval.> The exit routine must be
in main storage when required# and must
save and restore registers and return control using the address in register 14.
After control is returned to the control
program, control is passed to the next
instruction in the main program.
Example 22 shows the use of a time
interval when testing a new loop in a
program. The STIMER macro-instruction sets
a time interval of 5.12 seconds, to be
decremented only when the task is active,
and provides the address of a routine
called FIXUP to be given control when the
time interval expires. The loop is controlled by a BXLE instruction.
The loop continues as long as the value
in register 12 is less than or equal to the
value in register 7.
If the loop completes, the TTIMER macro-instruction causes
any time remaining in the interval to be
canceled; the exit routine is not given
control. If, however, the loop is still in
effect when the time interval expires,
control is given to the exit routine FIXUP.
The exit routine saves registers and turns
on the switch tested in the lOop. The
FIXUP routine could also print out a message indicating that the loop did not
complete
successfully.
Registers
are
restored and control is returned to the
control program.
The
control
program
returns control to the main program and
processing continues. When the switch is
tested this time, the branch is taken out
of the loop.
Section I:
Supervisor Services
37
Set time interval
STIMER
TASK,FIXUP,BINTVL=TIME
TM
BC
BXLE
TTIMER
TIMEXP,X'Ol'
1,NG
12,6"LOOP
CANCEL
Test if fixup routine entered
Go out of loop if time interval expired
If processing not complete, go through loop again
If loop completes, cancel remaining time
NG
TIME
TIMEXP
DC
DC
X'000OO200'
X'OO'
Time is 5.12 seconds
Timer switch
FIXUP
USING
SAVE
01
FIXUP,,15
(14,12)
TIMEXP,X'Ol'
Provide addressability
Save registers
Time interval expired, set switch in loop
RETURN
(14,12)
Restore registers
LOOP
Example 22.
Interval Timing
The accuracy of the time interval is
affected by two factors: the resolution of
the timer and the "competition" of other
tasks for control. The resolution of the
timer (the time between successive updating
of the timer) is 16.7 milliseconds for 60
cycle per second line
frequency.
An
attempt to measure an interval of less than
16.7 milliseconds or an attempt to time to
an accuracy of greater than 16.7 milliseconds can lead to erroneous results.
When you are using an operating system
with MFT or MVT, the priorities of other
tasks in the system may also affect the
accuracy of the time interval measurement.
If you code REAL or WAIT, the interval is
decremented continuously and may expire
when the task is not active.
(This is
certain to happen when WAIT is coded.)
After the time interval expires~ assuming
the task is not in the wait condition for
any other reason, the task is placed in the
ready condition and then competes for control with the other tasks in the system
that are also in the ready condition. The
additional time required before the task
becomes active will then depend on the
relative dispatching priority of the task.
WRITING TO OPERATOR OR SYSTEM LOG
The ability to write messages to the
operator is provided through the use of the
WTO and WTOR macro-instructions; the WTOR
macro-instruction also provides for a reply
from the operator. In an operating system
with MVT, a system log is provided.
You
can make entries in the system log through
the use of the WTL macro-instruction.
To use the WTO or WTL macro-instruction,
you code the message within apostrophes.
(The written message does contain these
apostrophes.) The message can include any
characters which are valid in a character
38
(C-type) DC instruction, and is assembled
as a variable length record. When using
the WTO macro-instruction, the maximum message length is 126 characters. You do not
have to provide a data control block when
writing to the operator or to the system
log.
A sample WTO macro-instruction is
shown in Example 23.
WTO
'MODIFYING SYSTEM DATA SETS.
DO NOT CANCEL JOB'
Example 23.
C
Writing to the Operator
When using the WTOR macro-instruction,
the message is designated exactly as in the
WTO macro-instruction. When the message is
written, the control program adds a twocharacter message identifier before the
message to associate the reply with the
message. You must, however, indicate the
operator response desired.
In addition,
you must supply the address of the area in
which the control program is to place the
reply, and you must indicate the length of
the reply. You also supply the address of
an event control block which the control
program will post after the reply has been
placed, right-adjusted, in your designated
area.
(The use of the event control block
is
discussed
under the heading "Task
Management.") An example of the use of the
WTOR macro-instruction is shown in Example
24.
PROGRAM INTERRUPTION PROCESSING
Unusual conditions encountered in a program cause a program interruption.
These
conditions include incorrect operands and
operand specifications, as well as exceptional results.
Some of these program
interruptions
(fixed point and decimal
overflow, exponent underflow, and signi-
ECBAD
REPLY
'WTOR
'STANDARD RESIDENT AREA? REPLY YES OR NO',REPLY,3,ECBAD
DC
DC
F'O'
CL3'
Example 24.
Event control block
Answer area
Writing to the Operator with a Reply
ficance)
can be disabled by setting thE!
corresponding hits in the program status:
word to zero.
When a task becomes active for the first
time, all program interruptions that can be
disabled are disabled# and a standard control program routine, specified when the
system was gE!nerated, is provided. This
control program routine is given control
when any program interruptions occur" and
issues an ABEND macro-instruction specifying
task
abnormal
termination
and
requesting a dump~
You can specify your own exit routine to
be given control for one or more ~rogram
interruption types by using a SPIE macroinstruction.
The SPIE macro-instruction
specifies the address of the exit routine
to be griven control when specified program
interruptions occur. If any interruption
types t,hat can be disabled are specified,
these interruptions are enabled.
~'
The SPIE macro-instruction can be issued
by
any
program
being
executed
in
performance of the task, ~nd applies for
all program interruptions of the types
specified that occur when the task is
active. If a program interruption of a
type not specified in a
SPIE
macroinstruction occurs, the control program
routine is given control. Succeeding SPIE
macro-instructions completely override any
exit
routine
and
interruption
types
specified previously.
The
expansion
of
the SPIE macroinstruction results in a control program
parameter
list~
c~lled
a
program
interruption
control area (PICA).
The
PICA, shown in Figure 8/1 contains the new
program mask for the interruption types
that can be disabled, the address of the
exit routine to be given control, and a
code for one interruption types specified
in the S:I?IE macro-instructions.
DISPLACEMENT
(Sy...)
r i:;:~
2
0000
~
B.
4
Exit Routine Address
L
-__
: Mask
Fi.gure
3
1
__________________
Program
Area
5
Interruption
Type
~
______
Interruption
~
Control
At the first execution of a SPIE macroinstruction during the performance of a
task, the control program creates a 32-byte
program interruption element (PIE) in the
main storage area assigned to the job step
(subpool 0 in an operating system with
MVT). This program interruption element is
used each time a SPIE macro-instruction is
issued during the performance of the task,
and
contains the information shown in
Figure 9.
DISPLACEMENT
(Bytes) 0
2
Reserved
4
I
Old Program
Status Word
3
Pica Address
I
L.. _
_ _ _ _Codes}
____
{Interruption
12
Register 14
16
Register 15
20
Register 0
24
28
Register
32
Register 2
Figure
9.
1
Program Interruption Element
The PICA address in the program interruption element is the address of the
program interruption control area used in
the last execution of a
SPIE
macroinstruction for the task.
The old program status word contains the
interruption code in bits 16-31; these bits
can be tested to determine the cause of the
program interruption.
The contents
of
registers 14, 15, 0, 1~ and 2 at the time
of the interruption are stored by the
control program as indicated.
The old program status word contains the
address of the next instruction to be
executed in bits 40-63, and the length of
the previous instruction in bits 32 and 33.
The address of the next instruction may not
be precise because of overlapping conditions in instruction fetching; if it is not
precise, the instruction length code (bits
32 and 33) is set to zero. You should test
the instruction length code for zero before
Section I:
Supervisor services
39
using the next instruction address. The
publication IBM System/360 Principles of
Operation covers imprecise interruptions in
more detail.
Before control is returned to the calling
program or before an XCTL macroinstruction is issued~ any program that
issues a
SPIE
macro-instruction
must
restore the PICA that was in affect when
control was received. The control program
indicates the address of the previous PICA
as follows:
• Register 15: address of the
tine.
• When additional SPIE macro-instructions
are issued in the performance of a
task, the control program returns the
address of the previous PICA in register 1.
The contents of register 1 can be used
to restore the PICA as shown in Example 25.
The first SPIE macro-instruction designates
an exit routine called FIXUP that is to be
.given
control if fixed point overflow
occurs. The address returned in register 1
is stored in the fullword called HOLD.
At
the end of the program, the execute form of
the SPIE macro-instruction is used to restore the previous PICA.
When control is passed to the designated
exit routine the register contents a.re as
follows:
internal
control program
• Register 1: address of the program
interruption element for the task.
• Registers 2-12: same as when the program interruption occurred.
• Register 13: address of the save area
for the main program. The exit routine
must not use this save area.
•
HOLD
Reg~ster
14: return
control program).
ABNORMAL CONDITION HANDLING
It is not possible to provide procedures
for all possible conditions which can occur
during the execution of a program.
You
should, of course, be sure that you can
process all valid data, and that your
program satisfies all the requirements of
the problem. The more general you make the
program, the greater the number of additional routines you will require to handle
special cases. But you will not be able to
provide routines to detect and correct all
of the special or abnormal conditions that
can occur.
The control program does a great deal of
checking for abnormal conditions. A standard program interruption routine is provided to detect and process errors such as
protection violations or addressing errors.
The data management and supervisor routines
provide some error checking facilities to
ensure that, based on the information you
have provided, only valid data is being
processed, and that no requests with conflicting requirements have been made. For
the abnormal conditions that can possibly
be corrected, control is returned to your
program with a return code indicating the
probable source of the error. For conditions that indicate that further processing
would result in degradation of the system
or destruction of existing data, the control program abnormal termination routine
is given control.
(to the
to
There will be abnormal conditions unique
your program, of course, that the con-
SPIE
ST
FIXUP,(S)
1,HOLD
Provide exi·t routine for fixed point overflow
Save address returned in register 1
L
SPIE
5,HOLD
MF= (E, (5»
Reload returned address
Use execute forn and old PICA address
DC
F'O'
Example 25.
40
address
rou-
The exit routine must be in main storage
when it is required~ and must return control to the control program using the
address passed in register 14. The control
program restores registers 14, 15, 0, 1,
and 2 from the program interruption element
after control is returned, but does not
restore the contents of registers 3-13. If
a program interruption occurs when the
program interruption exit routine is in
control, the control program exit routine
is given control.
• When the first SPIE macro-instruction
is issued in the performance of the
task, the control program returns zero
in register 1.
• Register 0:
information.
exit
Use of the SPIE Macro-Instruction
trol program cannot detect. Figure 10 is
an example of one of these. The routine
shown in Figure 10 checks a control field in
an input parameter list to determine which
function the program is to perform. Only
characters between 1 and 4 are valid in the
control field. The presence of any other
character is invalid, but the routine must
be prepared to detect and handle these
characters.
The routine could indicate
that the task should be terminated when an
invalid character is detected, by returning
cont.rol to the calling program. But return
of control usually means that some normal
processing was done, and this program cannot process at all.
In addition, it is
possible that many "levels" of calling
programs must return control before the
task is terminated. That is, control must
be returned to a calling prcgram, which
must analyze the return code, restore registers, and return control to another calling program, and so on, until control is
returned to terminator portion of the control program.
A better solution in this
case might be to pass control to the
control program abnormal termination routine by using the ABEND macro-instruction.
The following paragraphs discuss t,he abnormal
termination
facilities
available
through
the
use of the ABEND macroinstruction;
the
dump facilities also
available are discussed in the paragraphs
titled "The Dump."
The position within the job step hierarchy of the task for which the ABEND macroinstruction is issued determines the exact
function of
the
abnormal
termination
routine.
If an ABEND macro-instruction is issued
when the job step task (the highest. level
or only' task) is active, or if the STEP
operand
is
coded in. an ABEND macroinstruction issued during the performance
of any task in the job step, all the tasks
in t.he jlob step are t,erminated.
An ABEND
macro-instruction (without a STEP operand)
that is issued in performance of any task
other than the job step task causes only
that task and the subtasks of that task to
be abnormally terminated.
The abnormal
termination
routine works in the same
manner ~Ihether it is given control from the
control program or a problem program.
When a task is abnormally terminated,
the control program performs the following
functions:
~!
y
Figure 10.
"'--_~_~~"UN2
Abnormal Condition Detection
• Cancels the time interval if one had
been established for the task.
• Issues a CLOSE macro-instruction for
any data control blocks which were
opened during the performance of the
task.
• Purges any outstanding input or output
requests.
• Cancels
any
replies
made
instruction.
requests for operator
using a WTOR macro-
• Cancels any requests for resources made
using an ENQ macro-instruction.
If the job step is not to be terminated,
the following action is taken:
• Low€!rs the responsibility counts for
the load modules brought into main
storage during the performance of the
task.
• The
abnormal
termination functions
listed above are performed, starting
with the lowest level task, for each of
the subtasks of the task which was
active when the ABEND macro-instruction
was issued. A DETACH macro-instruction
is issued by the control program for
each of the subtasks.
• Releases the main
ownE!d by the tasks,.
• The completion code specified in the
ABEND macro-instruction is placed in
storage
subpools
Section I:
Supervisor Services
41
the task control block of the active
task (the task for which the ABEND
macro-instruction was issued).
• If the ECB operand was designated in
the ATTACH macro-instruction issued to
create the active task, the completion
code specified in the ABEND macroinstruction is placed in the designated
event control block, and the completion
bit is turned on.
• If the ETXR operand was designated on
the ATTACH macro-instruction issued to
create the active task, the end-of-task
exit routine is scheduled to be given
control
when
the originating task
becomes active.
• If neither the ECB nor ETXR operands
were designated when the ATTACH macroinstruction was issued, a DETACH macroinstruction is issued by the control
program for the active task.
If the job step is to be terminated, the
following action is taken:
• The abnormal
termination
functions
listed above are performed, starting
with the lowest level task, for all
tasks in the job step. All main storage
belonging to the job step is
released. None of the end-of-task exit
routines are given control.
• The completion code specified in the
ABEND macro-instruction is written on
the system output device.
the data set described by the DD statement
you provide. If a printer is selected the
dump is printed immediately. However, if a
direct-access or tape device is designated,
a separate job is scheduled to obtain a
listing of the dump, and to release the
space on the device.
The format of the dump is shown in the
publication
IBM
System/360
Operating
System: Messages, Completion Codes, and
Storage Dumps.
The entire dump shown in
that publication is provided in an abnormal
termination dump. Use of the SNAP macroinstruction allows you to request only
selected portions of the entire dump for
any task in the job step; the format of the
portions selected is the same as the format
of the same portions of
an
abnormal
termination dump.
When an abnormal termination dump is
requested, the entire dump is provided for
the active task, along with a dump of the
control blocks and save area for each of
the higher level tasks which are predecessors of the active task being terminated
and for each of the subtasks of the active
task. The control program dump routine
uses the addresses you stored in words 2
and 3 of each save area to follow the
"chain" of save areas provided by each
calling program in each task. If an ABEND
macro-instruction was issued when task Bl
(Figure 4) was active, for example, a
complete dump would be provided for task
Bl. The control blocks and save areas for
task B, task Bla, and the job step task
would also be provided in separate dumps.
Reguirements
• The remaining job steps in the job are
skipped.
The job control
language
statements defining these jobs
are
checked for proper syntax, however.
THE DUMP
There are two ways in which dumps of
main storage can be obtained: through the
use of the DUMP operand in the ABEND
macro-instruction, and, in an operating
system with MVT, through the use of the
SNAP macro-instruction. When the dump is
requested using an ABEND macro-instruction,
no further processing is performed for the
active
task;
use of the SNAP macroinstruction allows the task to continue
after the completion of the dump. The
control program generally requests a dump
for you when it issues an ABEND macroinstruction.
The data set containing the dump can
reside on any device which is supported by
the basic access technique using sequential
organization (BSAM). The dump is placed in
42
In order that the requested dump can be
produced, the following requirements must
be met:
• A DD statement must be provided for
each job step in which a dump is
requested. For an abnormal termination
dump, the ddname must be SYSABEND; for
a SNAP macro-instruction dump,
the
ddname must be any name except SYSABEND. The requirements for writing the
DD statement are described in the publication IBM System/360 Operating System: Job Control Language.
• To obtain a dump using the SNAP macroinstruction, you must provide a data
control block, and issue an OPEN macroinstruction for the data set before any
SNAP
macro-instructions are issued.
The data control block must contain
the following parameters-:---DSORG=PS,
RECFM=VBA, MACRF=W, BLKSIZE=l632, and
LRECL=l25.
(The data control block is
discussed in Section
II
of
this
manual.>
•
• suf:ficient unused main storage must be
available in the area assigned to the
job step to hold the control program
dump routine and, if not already in
main storage, the BSAM data management
rou,tines. For an abnormal termination
dump, additional
main
storage
is
reqlllired for the routines to process
the OPEN macro-instruction issued by
the control program, and for the trace
table. Refer to the publication IBM
Sys1tem/360 Operating System: storage
Estimates for storage requirements.
Indicative Dump
In an opera1:ing system with the primary
control program or MFT, you can obtain an
indicative dump, as shown in the publication IBM System/360 Operating System: Messages, completion Codes" and storage Dumps.
This dump is provided in response to a
request for an abnormal termination dump
when either you did not provide a DD
statement with the ddname SYSABEND, or the
control program entry for that DD statement
was destroyed.
The indicative dump is
printed on the system output device. The
indicative dump is not provided in an
operating systE~m with MVT.
MAIN STORAGE MANAGEMENT
No Ioatter which configuration of the
operating system you are using, there is a.
finite amount of main storage available to
your job step.
If you are using the
primary control program, you have available
all main storage not. used by the control
program;r i f you are using an operating
system with MFT or MVT, you have a partition or region of fixed size available to
your job step.
You should remember the
following requirements when using the primary control program if your job is ever
going to be run in an operating system with
MFT or MVT.
When you are using an operating system
with MFT or MVT, the size of the area
required for your job becomes important
from the standpoint of the amount of time
required for your job to complete.
In an
operating system with MFT the main storage
area no1: used by the control program is
divided into from one to four fixed partitions. The size and number of these partitions is determined when the operator performs 1:he initial program loading procedure. Jef any job step in your job requires
more main storage than is available in the
partition in which it is being executed,
the job step will be abnormally terminated.
In an operating system with MVT, you indicate the amount of main storage required
for each job step or for the entire job, or
both, on the EXEC or JOB statements defined
in the publication IBM System/360 Operating
System: Job Control Language. The control
program reserves a region of main storage
for your job step based on the size you
indicated on the EXEC or JOB statement.
The regions vary in number and size depending on the requirements of the job steps
being performed, but they cannot be extended after the job step is initiated.
Your job steps are selected for execution based on the priority designated on
the JOB statement.
However, if the job
step requires a region larger than is
currently available, the control program
cannot initiate execution of the job step;
instead, a job step from another job with a
region requirement that does not exceed the
available main storage area is initiated.
You obtain the use of the main storage
area assigned to your job step through
implicit and explicit requests for main
storage.
The
use
of a LINK macroinstruction is an implicit request for main
storage;
the control program allocates
space before bringing the load module into
your job pack area. The use of the GETMAIN
macro-instruction is an explicit request
for a certain number of bytes of main
storage to be allocated to the active task.
In addition to your requests for main
storage, requests are made by the control
program and data management routines for
areas to contain some of the control blocks
required to manage your tasks.
The following paragraphs discuss some of
the techniques that can be applied for
efficient use of the main storage area
reserved
for
your
job
step.
These
techniques apply as well to the data management portions of your programs. The
specific data management main storage allocation facilities are discussed in section
II of this publication; the principles
discussed here provide the background you
will need to use these facilities.
EXPLICIT REQUESTS
Main storage can be explicitly requested
for the use of the active task by issuing a
GETMAIN macro-instruction. The main storage request is satisfied by allocating a
portion of the main storage area reserved
for the job step to the active task.
You
cannot use the main storage area reserved
for the job step without first requesting
it; if you attempt to use it without
requesting it, the task is abnormally terminated.
The main storage area is not set
to zero when allocated.
You return control of main storage by
issuing a FREEMAIN macro-instruction. This
does not release the area from control of
Section I:
Supervisor Services
43
the job step; it only makes the area
available to satisfy the requirements of
additional requests for any task in the job
step. The main storage assigned to a task
is also released for other uses when the
task terminates# except as indicated under
"Subpool Handling."
Specifying Lengths
Main storage areas are always allocated
to the task in multiples of eight bytes and
begin on a double word boundary.
The
request for main storage is given in terms
of bytes; if the number specified is not a
multiple of eight, it is rounded to the
next higher mUltiple of eight.
You can
make repeated requests for a small number
of bytes as you need the area or you can
make one large request to completely satisfy the requirements of the task. There are
two reasons for making one large request:
it is the only way you can be sure of
getting contiguous
storage
area
and,
because you only make one request, the
amount of control program overhead is less.
Types of Explicit Requests
There are four methods of explicitly
requesting main storage using a GETMAIN
macro-instruction. Each of the methods#
which are designated by coding an associated character in the operand field of the
GETMAIN
macro-instruction,
has certain
advantages. depending on the requirements
of your prograro. The last three methods do
not produce reenterable code ~nless coded
in the list and execute forms as indicated
in the paragraph "Implicit Requests." The
methods are as follows:
REGISTER TYPE (R): Specifies a request for
a single area of main storage of a spec~
fied length.
The address of the area is
returned in register 1.
This type of
request produces reenterable code, because
parameters are passed to the control program in registers, not in a parameter list.
ELEMENT TYPE (E): Specifies a request for
a single area of main storage of a specified length.
The control program places
the address of the allocated area in a
fullword you supply.
LIST TYPE (L): Specifies a request for one
or more areas of main storage. You place
the length of each area in a list; each
list entry represents a request for one
area of main storage. The control program
places the addresses of the allocated areas
in consecutive full words in another list
you sup~ly. The addresses are placed in
the list in the same order they were
requested.. This type of request can be
made only in an operating systao with MVT.
44
VARIABLE TYPE (V): Specifies a request for
a single area of main storage with a length
between two values you specify.
The control program will attempt to allocate the
maximum length you specify; if not enough
storage is available to allocate the maximum length, the largest area with a length
between the two values is allocated. The
control program places the address of the
area and the length allocated in two consecutive full words you supply.
In addition to the above methods of
requesting main storage, you can designate
the request as conditional or unconditional.
(A register type request is always
unconditional.> If the request is unconditional and sufficient main storage is not
available to fill the request, the active
task is abnormally terminated.
If the
request is conditional, however, and insufficient main storage is available, a return
code of four is provided in register 15; a
return code of zero is provided if the
request was satisfied. When a conditional
list-type request is made, no main storage
is allocated unless all of the requested
areas can be allocated.
An example of the use of the GETMAIN
macro-instructions is shown in Example 26.
The example assumes a program which operates most efficiently with a work area of
16,000 bytes. with a fair degree of efficiency with 8000 bytes or more, inefficiently with 4000 to 8000 bytes, and not at
all with less than 4000 bytes. The program
uses a reenterable load module with an
entry point name of REENTMOD, and will use
it again later in the program; to save
time, the load module was brought into the
job
pack
area
using
a LOAD macroinstruction so that it would be available
when it was required.
A conditional request for a
single
element of main storage with a length of
16000 bytes is requested in Example 26.
The return code in register 15 is tested to
determine if the area was available; if the
return code was zero (the 16,000 bytes were
allocated), control is passed to the processing routine. If sufficient area was
not available, an a·ttempt to obtain more
main storage area is made by issuing a
DELETE macro-instruction to free the area
occupied by the load module REENTMOD.
A
second GETMAIN macro-instruction is issued,
this time an unconditional request for an
area
between 4000 and 16000 bytes in
length. If the minimum size is not available, the task is abnormally terminated. If
at least 4000 bytes was available, however,
the task can continue.
The size of the
area actually alloca·ted is determined and
one of the two procedures (efficient or
inefficient> is given control.
~,
GETMAIN
LTR
BZ
DELETE
GETMAIN
CH
BNL
EC,LV=16000,A=ANSWADD
15,15
PROCEED1
EP=REENTMOD
VU,LA=SIZES,A=ANSWADD
4,ANSWADD+4
4,MIN
PROCEED1
Conditional request for 16000 bytes
Test return code
If 16000 bytes allocated, proceed
If not, free main storage
Attempt to get smaller amount
Load and test allocated length
If SOOO or more, use procedure 1
If less than SOOO, use procedure 2
DC
DC
DC
DC
DC
H'SOOO'
F'4000'
F ' 16000'
F'O'
F'O'
Minimum
Minimum
Size of
Address
Size of
L
PROCEED2
PROCEEDl
MIN
SIZES
ANSWADD
Example 26.
size for procedure 1
size to proceed at all
area for maximum efficiency
of allocated area
allocated area
Use of the GETMAIN Macro-Instruction
Subpool Handling
There is only one unnumbered subpool in
an operating system with the p:r'imary control program or MFT.
In these configurations of the operating system all main
storage requests are satisfied by allocating storage from this unnumbered subpool;
if subpool numbers are specified, they are
ignored. The remainder of the discussion
of subpool handling applies only to an
operating system with MVT.
In an operat.ing system with MVT, subpools of maln storage a:re provided to
assist in main storage management and for
communications between tasks in the same
job step.
Because the use of subpools
requires some knowledge of how the control
program manages main storage, a discussion
of main storage control is presented here.
I'-1AIN STORAGE CONTROL: When the job step is
given a region of main storage, all of the
storage area available for your use within
that region is unassigned.
Subpools are
created only
when
a
GETMAIN
macroinstruct.ion is issued designating a subpool
number.
If
no
subpool
number
is
designated, the main storage is allocated
from subpool 0, which is created for the
job step by the control program when the
job stE!P task is initiated. The storage
areas in subpool 0 are shared by every task
in the job step. The areas of subpool 0
allocated to a task can be returned only
through
the
use
of
FREEMAIN macroinstructions; the areas are not released
when the task terminates unless the task is
the job step task.
For purposes of control and main storage
protection, the control program considers
all main storage within the region in terms
of 2048-byte blocks.
These blocks are
assigned to a subpool, and space within the
blocks allocated to a task, by the control
program when requests for main storage are
made. When there is sufficient unallocated
main storage within any block assigned to
the designated subpool to fill a request,
the main storage is allocated to the active
task from that block.
If
there
is
insufficient unallocated main storage within any block assigned to the subpool, a new
block (or blocks, depending on the size of
the request) is assigned to the subpool,
and the storage is allocated to the active
task. The blocks assigned to a subpool are
not necessarily contiguous unless they are
assigned as a result of one request. Only
blocks within the region reserved for the
associated job step can be assigned to a
subpool.
Figure 11 is a simplifieu view of a main
storage region containing four 204S-byte
blocks of storage.
All the requests are
for main storage from subpool O. The first
request from some task in the job step is
for 504 bytes; the request is satisfied
from the block shown as BLOCK A in the
figure.
The second request, for
2000
bytes~
is too large to be satisfied from
the unused portion of BLOCK A, so the
control program assigns the next available
block, BLOCK B, to subpool 0, and allocates
2000 bytes from BLOCK B to the active task.
A third request is then received, this time
for 1000 bytes. There is not sufficient
unallocated area remaining in BLOCK
B
(blocks are checked in the order last in,
first out), but there is enough space in
BLOCK A, so an additional 1000 bytes are
allocated to the task from BLOCK A.
Note
that since all tasks share subpool 0,
Request 1 and Request 3 do not have to be
made from the same task, even though the
areas are contiguous and from the same
204S-byte block.
Request 4, for
3000
bytes, requires that the control program
allocate the area from 2 contiguous blocks
which were previously unassigned, BLOCK D
and BLOCK C. These blocks are assigned to
subpool O.
Section I:
Supervisor Services
45
Request 3 - 1000 bytes
Figure 11.
Main storage Control
As indicated in the previous example, it
is possible for one 2048-byte block in
subpool 0 to contain many small areas
allocated to many different tasks in the
job step, and it is possible that many
blocks could split up in this manner. Even
if FREEMAIN macro-instructions were issued
for each of the small areas before a task
terminated, the probable result would be
that many small, unused areas would exist
within each block, while the control program would be continually assigning new
blocks to satisfy new requests. To avoid
this situation., subpools other than subpool
o can be used.
When a subpool is initially specified,
the control program assigns a new 2048-byte
block to that subpool" and allocates storage from that block.
The task which is
active when the request is made is assigned
ownership of the subpool and therefore of
the block. When additional requests are
made by the same task for the same subpool,
the requests are satisfied by allocation of
area from that block and as many additional
blocks as are required.. If another task is
active when a request is made with the same
subpool number, the control program assigns
a new block to a new subpool, allocates
area from the new block, and assigns ownership of the new subpool to the second task.
A task can specify any number of subpools,
and may also continue to allocate storage
from
subpool
o.
FREEMAIN
macroinstructions can be issued to
release
entire subpools for a task (not possible
for subpool 0); when the owning task is
terminated"
all main storage areas identified by subpool numbers belonging to the
task are released. This means that instead
of returning many small areas of main
storage, you are releasing main storage in
2048-byte blocks.
No other task will own
any of the areas in those blocks.
46
Owning and Sharing: The subpool is initially owned by the task which was active
when the subpool was created. The subpool
can be shared with other tasks, and ownership of the subpool can be assigned to
other tasks.
Two macro-instructions are
used in the handling of subpools; the
GETMAIN macro-instruction and the ATTACH
macro-instruction. The operands that deal
with subpools
in
the
ATTACH
macroinstruction are the GSPV and GSPL operands,
which transfer ownership of the subpool to
the subtask being created, and the SHSPV
and SHSPL operands, which allow the subpool
to be shared by the new subtask. The SP
operand in the GETMAIN macro-instruction
can be written to include the subpool
number.
All
of
these
operands are
optional; if omitted, subpool 0 is assumed.
creating a Subpool:
A new subpool is
created whenever any of the operands described above is written in an ATTACH or a
GETMAIN macro-instruction, and that operand
specifies a subpool which is not currently
owned by or shared with the active task.
If one of the ATTACH macro-instructions
operands causes the subpool to be created,
the subpool number is entered in the list
of subpools owned by the task, but no
blocks are assigned and no storage is
actually allocated. If a GETMAIN macroinstruction results in the creation of a
subpool, the subpool number is aSSigned to
one or more 2048-byte blocks, and the
requested
storage is allocated to the
active task. In either case, ownership of
the subpool belongs to the active task; if
the subpool is created because of an ATTACH
macro-instruction, ownership is transferred
or retained depending on the operand used.
Transferring Ownership:
An owning task
gives ownership of a subpool to a direct
subtask by using the GSPV or GSPL operands
in the ATTACH macro-instruction issued when
that subtask is created.
Ownership of a
subpool can be given to any subtask of any
task, regardless of the control level of
the two tasks involved and regardless of
how ownership was obtained.
A subpool
cannot be shared with one or more subtasks
and then transferred to another subtask,
however; an attempt to do this results in
abnorma1 termination of the active task.
Ownership of a subpool can only be transferred if the active task has ownership; if
the active task is sharing the subpool and
an attempt is made to pass ownership to a
subtask, the subtask receives shared control and the originating task relinquishes
the subpool. Once ownership is transferred
to a subtask or relinquished, any subsequent use of that subpool number by the
originating task results in the creation of
a new subpool. When a task terminates that
has ownership of one or more subpools, all
of main storage areas in those subpools are
released.
Therefore~ the task with ownership should not terminate until all uses by
task sharing the subpool have been completed.
Sharing a Subpool: Shared use of a subpool
can be given to a direct subtask of any
task with ownership or shared control of
the subpool. Shared use is given by specifying the SHSPV and SHSPL operands in the
ATT,ACH m"acro-instruction issued when the
subtask is created. Any task with ownership 01: shared control of the subpool can
add to or reduce the size of the subpool
through the use of GETMAIN and FREEMAIN
macro-instructions. When a task terminates
that has shared control of the subpool~ the
subpool is not affected.
'-"
SUBPOOLS IN TASK COMMUNICATION: The advantages of subpools in main storage management al:e that., by assigning separate subpools to separate subtasks, the breakdown
of main storage into small fragments is
reduced. An additional benefit from the
use of subpools can be realized in task
communication. A subpool can be created
for an originating task and all parameters
to be passed to the subtask placed in the
subpool.,
When the subtask is created, the
ownership of the subpool can be passed to
the subtask.
After all parameters have
been acquired by the subtask, a lo'REEMAIN
macro-instruction can be issued, under control of the subtask, to release the subpool
main storage areas. In a similar manner, a
second subpool can be created for the
originating task, to be used as an answer
area in the performance of the subtask.
When thE~ subtask is created, the subpool
ownership would be shax:'ed with the subtask.
Before the subtask is terminated, all parameters to be passed to the originating
tas k aJce placed in the subpool area; when
the subt.ask is terminated, the subpool is
not released, and the originating task can
acquire the pal:ameters,. After all parameters have been acquired for the originating!
task, a FREEMAIN macro-instruction again
makes the area available for re-use.
IMPLICIT REQUEST
You make an implicit. request for main
storage every time you issue a LINK, LOAD,
ATTACH,
or XCTL macro-instruction.
In
addition, you make an implicit request for
main sit,orage when you issue an OPEN macroinstruction for a data set.
The data
managemlsnt routines required to process the
data Slst must be in main storage; the main
storage areas llsed as buffers may also b~
allocatlsd.
When you make an
implicit
request for more main storage than is
available, the active task is abnormall~'
termina·ted,.
This section discusses some of the techniques you can use to cut down on the
amount of main storage required by a job
step, and the assistance given you by the
control program.
Load Module Management
The discussion of program structures
indicates the advantages and disadvantages
of each of the three types of program
designs; simple, planned
overlay,
and
dynamic. The program structure you selected was based on the complexity of the
program and the execution time considerations.
Once you have selected the program
structure, you should plan efficient use of
the main storage area that will be assigned
to your job step. Note that main storage
is assigned in 2048-byte blocks for implicit requests made in an operating system
with MVT.
The size of your load modules
should be planned to take advantage of this
method of allocation.
The maximum size
load module that can be brought into main
storage is 524,248 bytes in an operating
system with the primary control program or
MFT.
REENTERABLE LOAD MODULES:
A reenterable
load module is designed so that it does not
in any way modify itself during execution.
It is "read-only".
The advantage of a
reenterable load module is most apparent in
an operating system with MVT; only one copy
of the load module is brought into main
storage to satisfy the requirements of any
number of tasks in a job step. This means
that even though there are six tasks in the
job
step
and
each task concurrently
requires the load module, the only main
storage area requirement is for an area
large enough to hold one copy of the ioad
module (plus a few bytes for
control
blocks). The same main storage requirement
would apply if the load module were serially reusable; however, the load module could
not be used by more than one task at a
time.
An additional benefit of a reenterable
load module occurs when the module is
placed in the link pack area. In this case
not only is time saved because no loading
must be performed, but in addition no main
storage area assigned to the job step is
required to hold the load module. A link
pack area exists only in an operating
system with MVT. The contents are established when the operating system is generated and when the operator performs the
initial program loading procedure.
Any
reenterable load module from the
link
library may be placed in the link pack
area. Many of the frequently usett data
management routines are also placed in the
link pack area. If any of your reenterable
load modules are used frequently or are
Section I:
Supervisor Services
47
used by many jobs, it may save considerable
time and space to have those load modules
placed in the link pack area.
REENTERABLE MACRO-INSTRUCTIONS: All of the
macro-instructions described in the publication IBM System/360 Operating System:
supervisor
and
Data Management MacroInstructions can be written in reenterable
form.
From
the
standpoint
of
reenterability, these
macro-instructions
are classified as one of two types: macroinstructions
which
pass parameters in
registers 1 and 0, and macro-instructions
which pass parame~ers in a list. The use
of the macro-instructions which pass parameters in registers presents little problem
in a reenterable program; when the macroinstruction is coded, the required operand
values should be contained in registers.
For example, the POINT macro-instruction
requires that the dcb address and block
address be coded as follows:
One method of coding a reenterable program
would be to require that both of these
addresses
refer to a portion of main
storage
allocated
to the active task
through
the
use of a GETMAIN macroinstruction. The addresses would change
for each use of the load module, therefore.
You would load one of general registers
2-12 with the address, and designate the
appropriate registers when you code the
macro-instruction. If register 4 contained
the dcb address and register 6 contained
the block address,
the
POINT
macroinstruction would be written as follows:
POINT (4),(6).
The macro-instructions which pass parameters in a list require the use of special
forms of the macro-instruction when used in
a
reenterable
program.
The
macroinstructions which pass parameters in a
list are identified in the publication IBM
Systeml360 Operating System: Supervisor and
Data Management Macro-Instructions by a
reference
to
Section
III
of
that
publication for the list and execute forms.
The expansion of the standard form of these
macro-instructions (that is, the form described in Section II of that publication)
results in an in-line parameter list and
executable instructions required to branch
around the list, load the address of the
list, and pass control to the required
control program routine. The expansions of
the list and execute forms of the macroinstruction simply divide the functions
provided in the standard form expansion:
the list form provides only the parameter
list,
and
the
execute form provides
48
executable instructions to modify the list
and pass control. You provide the instructions to load the address of the list into
a register.
The list and execute forms of a macroinstruction are used in conjunction to
provide the same services available from
the standard form of the macro-instruction.
The advantages of using list and execute
forms are as follows:
• Any operands which remain constant in
every use of the macro-instruction can
be coded in the list form.
These
operands can then be omitted in each of
the execute forms
of
the
macroinstruction which use the list. This
can save appreciable coding time and
main storage area when you use a macroinstruction
many
times.
(Any
exceptions to this rule are listed in
the description of the execute form of
the applicable macro-instruction.)
• The execute
form
of
the
macroinstruction can modify any of operands
previously designated.
(Again, there
are exceptions to this rule.)
• The list used by the execute form of
the macro-instruction can be located in
a portion of main storage assigned to
the task through the use of the GETMAIN
macro-instruction.
This ensures that
the program remains reenterable.
Example 27 shows the use of the list and
execute forms of a DEQ macro-instruction in
a reenterable program. The length of the
list constructed by the list form of the
macro-instruction
is
obtained
by
subtracting two symbolic addresses; main
storage is allocated and the list is moved
into the allocated area. The execute form
of the DEQ macro-instruction does not modify any of the operands in the list form.
The list had to be moved to allocated
storage because the control program can
store a return code in the list when
RET=HAVE is coded. Note that the code in
the routine labeled MOVERTN is valid for
lengths up to 255 bytes only. Some macroinstructions do produce lists greater than
255 bytes when many operands are coded (for
example, OPEN and CLOSE with many data
control blocks, or ENQ and DEQ with many
resources), so in actual practice a length
check should be made.
NON-REENTERABLE LOAD MODULES: The use of
reenterable
load
modules
does
not
automatically conserve main storage; in
many applications it will actually prove
wasteful. If it is not used in many jobs
and if it is not employed by more than one
task in a job step, there is no reason to
make the load module reenterable.
The
LA
LA
SR
BAL
DEQ
*
3,.MACNAME
5,* NSIADDR
5,3
14,MOVERTN
, MF= (E, (4) )
I,oad address of list form
Load address of end of list
Length to be moved in register 5
Go to routine to move list
Release allocated resource
The MOVERTN allocates storage from subpool 0 and moves up to 255 bytes into the
allocated area. Register 3 is from address, register 5 is length. Area address
returned in register 4.
MOVERTN
MOVEINs~r
MACNAME
NSIADDR
NAME 1
NAME 2
Example 21.
GETMAIN
LR
BCTR
EX
BR
R~LV=(5)
Allocate main storage for list
Address of area in register 4
Subtract 1 frow area length
Move list to allocated area
Ret.urn
mc
4,1
5,0
5, MOVEINST
14
0(1,4) .,0 (3)
DEQ
(NAME1,NAME2,S,SYSTEM),RET=HAVE,MF=L
DC
DC
CLS'MAJOR'
CLS'MIN~'
Use of List and Execute Forms
allocation of main storage for the purpose
of moving code from the load module to the
allocatE~d area is a waste of both time
and
main s1::orage when only one task requires
the use of the load module.
One method of conserving main storage
re-enterability is not a consideration
~s
to use a planned overlay structure. A
completE! description of the planned overlay
structu.re is contained in the publication
IBM System/360 Operating System: Linkage
Editor.
Briefly, in a planned overlay
structuz:e only portions of the loaq modules
are brought into main storage at a time;
when a portion of the load module not in
main storage is required, it is loaded in
the areal occupied by existing port~ons of
the load module.
While the use of an
overlay structure requires more planning on
your paz't to determine all the portions of
a load module required at anyone time" it
can result in a considerable saving of
storage.
A well planned overlay structure
can result in a savings of 50 percent or
more over bri:nging the entire load module
into main sto:rage at once.
This does
increase the amount of ·t.ime spent in bringing in portions of the load module, however.
~hen
It is also possible for you to use an
overlay type of approach in the design of
your load module without using the linkage
edito~
by reusing the areas containing
completed routiI)es within a load module.
For example, :if your load module consists
of three control:· sections of 2000 bytes
each which are always executed sequentially, as SIDon as control is passed to the
second ,control section you have 2000 bytes
(the size of the first control section)
available to use as a data area. If you
reuse this area, you can save up to 2000
bytes of additional main storage which
would
otherwise be allocated using OS
instructions or GETMAIN macro-instructions.
Releasing Main Storage
As indicated in Program Management, the
control
program
establishes
two
responsibility counts for every load module
brought into main storage in response to
your requests for that load module.
The
responsibility counts are lowered as follows:
• If the load module was requested in
a
LOAD
macro-instruction,
that
responsibility count is lowered using a
DELETE macro-instruction.
• If the load module was requested in a
ATTACH,
or
XCTL
macroLINK,
instruction, that responsibility count
is lowered using
an
XCTL
macroinstruction or by returning control to
the control program.
• When
a
task
is
terminated, the
responsibility counts are lowered by
the number of requests for the load
module made in LINK, LOAD, ATTACH, and
XCTL macro-instructions during the performance of that task, minus the number
of deletions indicated above.
Except for those modules contained in
the link pack area, the main storage area
occupied by a load module is available for
reuse when the responsibility counts reach
zero.
When you plan your program~ you can
Section I:
Supervisor Services
49
design the load modules to give you the
best trade-off between execution time and
efficient main storage use. Naturally, if
you will use a load module many times in
the course of a job step, you will issue a
LOAD macro-instruction to bring it into
main storage, and you will not issue a
DELETE macro-instruction until all uses of
the load module have completed.
In this
case it is better to have the load module
in main storage all the time then to bring
it in every time you require it. Conversely, if a load module is used only once
during the job step, or if its uses are
widely separated, it will conserve main
storage if you issue
a
LINK
macroinstruction to load the module and issue an
XCTL from the module (or return control to
the control program) when it has completed.
50
There is a minor problem involved in the
deletion of load modules containing data
control blocks. An OPEN macro-instruction
must be issued before the data control
block is used,
and
a
CLOSE
macroinstruction issued after
the
use
is
finished.
If you do not issue a CLOSE
macro-instruction
for the data control
block, the control program will issue one
for you when the task is terminated. However, if the load module containing the
data control block has been removed from
main storage, the attempt to issue the
CLOSE macro-instruction will cause abnormal
termination of the task. You must either
issue the CLOSE macro-instruction yourself
before deleting the load module, or ensure
that the data control block is still in
main storage when the task is terminated.
SECTION II:
DATA MANAGEMENT SERVICES
Section II is a tutorial presentation of the Data Management features
and facilities provided by the operating system. The reader should be
familiar with the theory and philosophy of System/360 Operating System
data management and with the various general terms and concepts
necessary
to
begin preparation for actual coding.
Each macroinstruction is discussed in sufficient detail so that the reader can
turn directly to the macro-instruction format description to determine
the operand requirements.
Part 1, Introduction to Data Management, is concerned with the
charac1:eristics of data sets and direct-access devices.
It also
describes the means and methods used to communicate with the operating
system during program assembly and execution. It contains a general
description of the various control blocks, their contents, and their
functions.
Part 2~ Data Management Processing Procedures, describes data access
and processing techniques in terms of data set organization, buffer
acquisition and control, and jobs to be done. The major emphasis is on
work requirements rather than access methods.
Part 3, Data Set Disposition and
techniques required for efficient and
space allocation.
A sufficiently
definition (DD) statement is included
Space Allocation, describes the
effective data set disposition and
detailed description of the data
to get the reader "on-the-air."
Section II:
Data Management Services
51
.PART 1:
INTRODUCTION TO DATA MANAGEMENT
DATA SET CHARACTERISTICS
The manner in which data is transferred between main storage and
external devices is of paramount importance in most data processing
applications. The data management function of Operating System/360
assists you in achieving maximum efficiency in managing the mass of data
associated with the many programs that are processed at an installation.
To attain this objective, data management facilities have been designed
to provide systematic and effective rr.eans of organizing, identifying,
storing,
cataloging, and retrieving all data, including
loadable
programs, processed by the operating system.
Data set storage control, supported by an extensive catalog system,
makes it possible for you to retrieve data by symbolic name alone,
without specifying device types and volume serial numbers. In freeing
computer personnel from the necessity of maintaining involved volume
serial number inventory lists of data and programs stored within the
system, the catalog reduces manual intervention and the possibility of
human error.
Data sets stored within the cataloging system can be classified
according to installation needs. For example, a sales department could
classify the data it uses by geographic area, by individual salesman, or
by any other logical plan.
The cataloging system also makes it possible for you to classify
successive generations or updates of related data.
These generations
can be given an identical name and subsequently be referred to relative
to the current generation. The system autorratically maintains a list of
the most recent generations.
Data from a direct-access volwne, a remote terminal, or a tape; data
organized sequentially or as in a library; all may be requested by you
in essentially the same way. In addition, data management provides:
• Allocation of space on direct-access voluilies.
Flexibility and
efficiency of direct-access devices is improved through greater use
of available space.
• Automatic retrieval of data sets by name alone.
• Freedom to defer specifications such as buffer length, block size,
and device type until the job is submitted for processing. This
permits the creation of programs that are in many ways independent
of their operating environment.
Control of confidential data is provided by the data set security
facility of Operating System/360. Using this facility, you can prevent
unautho.rized access to payroll data, sales forecast data, and all other
data sets requiring special security attention. The security-protected
data set is available for processing only when a correct password is
furnished.
The data access facilities provided by the operating system are a
major extension of previous input./output control systems. Input/output
routines are provided to efficiently schedule and control the transfer
of data between main storage and input/output devices. Routines are
available to:
Section II:
Data Management Services
(Part 1)
53
•
•
•
•
•
•
•
•
•
Read data.
Write data .•
Block and deblock records.
Overlap reading, writing, and processing operations.
Read and verify volume and data set lacels.
Write data set labels.
Automatically position and reposition volumes.
Detect error conditions and correct when possible.
Provide exits to user-written error and label routines.
Corresponding to the range of system facilities available for control
of data is an equal range of facilities for access to the data.
The
variety of techniques for gaining access to a data set is derived from
two variables: data set organization and data access technique.
Operating System/360 data sets can be organized in four ways:
• Sequential: This is the familiar tape-like structure, in which
records are placed in physical rather than logical sequence. Thus,
given one record, the location of the next record is determined by
its physical position in the data set. The sequential organization
is used for all magnetic tapes, and may' be selected for directaccess devices. Punched tape, punched cards, and printed output are
considered to be sequentially organized.
• Indexed Sequential: Records are arranged in collating sequence,
according to a key that is a part of every record, on the tracks of
a direct-access volume.
In addition, a separate index or set of
indexes maintained by the system gives the location of certain
principal records. This permits direct as well as sequential access
to any record.
• Direct: This organization is available for data sets on directaccess volumes. The records within the data set may be organized in
any manner you choose. All space allocated to the data set is
available for data records.
No space is required for indexes~
Records are stored and retrieved directly with addressing specified
by you.
• Partitioned: This structure has characteristics of
both
the
sequential and the indexed sequential organizations.
Independent
groups of sequentially organized data, each called a member, are in
direct-access storage.
Each member has a simple name stored in a
directory that is part of the data set and contains the location of
the member's starting point. Partitioned data sets are generally
used to store programs. As a result, they are often referred to as
libraries.
Requests for input/output operations on data sets through macroinstructions
are divided into two categories or techniques: the
technique for queued access and the technique for basic access.
Each
technique is identified according to its treatment of buffering and
input/output synchronization with processing.
The combination of an
access technique and a given data set organization is called an access
method. In choosing an access method for a data set, therefore, you
must consider not only its organization, but also the macro-instruction
capabilities. Also, you may choose a data organization according to the
access techniques and processing capabilities available.
The code
generated by the macro-instructions for both techniques is optionally
reenterable depending on the form in which parameters are expressed.
an
54
In addition to the access methods provided by the operating system,
elementary access technique called execute channel program is also
provided. To use this technique, you must establish your own system for
organizing, storing, and retrieving data. Its primary advantage is the
complete flexibility it allows you in using the computing facilities
directly.
An important feature of data management is that much of the detailed
information needed to store and retrieve data, such as device type"
buffer processing technique, and format of output records need not be
suppliE~d
until the job is ready to be executed. This device independence permits changes to be ~de in those details without requiring
changes in the program. Therefore, you may design and test a program
without knowing the exact input/output devices that will be used when it
is executed.
Device independence is a feature of both access techniques when you
are processing a sequential data set. The degree of device independence
achieved is to some extent determined by you. Many useful devicedependent features are available as part of special macro-instructions,
and achieving device independence requires some selectivity in their
use.
DATA SET IDENTIFICATION
Any informat:ion that is a named, organized collection of logically
related records can be classified as a data set. The information is not
restricted to a specific type, purpose, or storage medium. A data set
may be, for example, a source program, a litrary of macro-instructions~
or a file of data records used by a processing program.
Whenever you indicate that a new data set is to be created and placed
on auxiliary storage, you (or the operating system) must give the data
:set a name. The data set name identifies a group of records as a data
set. All data sets recognized by name (i.e., referred to without volume
identification) and all data sets residing on a given volume must be
distinguished from one another by unique names. To assist in this, the
system provides a means of qualifying data set names.
A data set name is one simple name or a series of simple names joined
together so that each represents a level of qualification. For example#
1:he data set name DEPT58. SMITH. DATA3 is composed of three simple names
1:hat are delimited to indicate a hierarchy of categories.
Proceeding
from the left, each simple name is a category within which the next
simple name is a subcategory.
Each simple name consists of one to eight alphameric characters, the
first of which must be alphabetic. The special character period (.)
separates simple names from each other. Including all simple names and
periods, the length of the data set name must not exceed 44 characters.
ThUS, a maximum of 22 qualification levels is possible for a data set
name.
,.,..'
To permit different data sets to be processed without prog~am
reassembly, the data set is not referred to by name in the process1ng
program"
When the program is executed, the data set name and other
pertinent information (e.g., unit type and volume serial number)
is
specified in a job control statement called the data definition (DO)
statement. To gain access to the data set during processing, a
ieference is made to a data control block , associated with the name of
t.he DD statement. Space for a data control block is reserved by a DCB
macro-instruction when your program is assembled.
Section II:
Data Management Services
(Part 1)
55
DATA SET STORAGE
System/360 provides a variety of devices for collecting, storing, and
distributing data.
Despite the variety, the devices have many common
characteristics. For convenience, therefore, the generic term volume is
used to refer to a standard unit of auxiliary storage. A volume may be
anyone of the following:
•
•
•
•
•
A reel of magnetic tape.
A disk pack.
A bin in a data cell.
A drum.
That part of an IBM 2302 disk storage device served by one access
mechanism (the device would have either two or four volumes in all).
Each
data
set
stored on a volume has its name, location,
organization, and other control information stored in the data set label
or volume table of contents (direct-access volurees only).
Thus, when
the name of the data set and the volume on which it is stored are made
known to the operating system, a complete description of the data set,
including its location on the volume, can be retrieved. Following this,
the data itself can be retrieved, or new data added to the data set.
Keeping track of the volume on which a particular data set resides
can be a burden and often a source of error. To alleviate this problem,
the system provides for automatic cataloging of data sets. A cataloged
data set can be retrieved by the system if given only the name of the
data set. If the name is qualified, each qualifier corresponds to one
of the indexes in the catalog.
For
example,
the
data
set
DEPT58.SMITH.DATA3 is found by searching a master index to determine the
location of the index name DEPT58. That index is then searched to find
the location of the index SMITH. Finally, that index is searched for
DATA3 to find the identification of the volume containing the required
data set .•
By use of the catalog, collections of data sets related by a common
external name and the time sequence in which they were cataloged (i.e.,
their generation) can be identified, and are called generation data
groups.
For example, a data set name LAB.PAYROLL(O) refers to the most
recent data set of t.he group; LAB. PAYROLL (-1) refers to the second most
recent data set, etc. The same collection of data set names can be used
repeatedly
with no requirement to keep track of the volume serial
numbers used.
Direct-Access Volumes
Direct-access volumes play a major role in the System/360 Operating
system.
They are used to store executable programs, including the
operating system itself. Direct-access storage is also used for data
and for temporary working storage. One direct-access storage volume may
be used for many different data sets, and space on it may be reallocated
and reused.
A volume table of contents (VTOC) is used to account for
each data set and available space on the volume.
Each direct-access volume is identified by a volume label, which is
usually stored in track 0 of cylinder o. You may specify up to seven
additional labels for further identification. These are located after
the standard volume label.
The volume table of contents describes the contents of the directaccess voluroe. It is a data set that is composed of'a series of data
set control blocks (DSeB), each of which is composed of one or more
control blocks. The VTOC can contain the following data set control
blocks:
56
• A DSCB for each data set on the volume.
• A DSCB that indicates the space allocated to the VTOC itself.
• A DSCB for all tracks on the volume that are available for
allocation.
The DSCB for each data set contains the name, description, and
location of the data set on the volume.
Its size depends on the
organization and the number of noncontiguous areas of the data set.
Each direct-access volume is initialized by a utility program before
being used on the system.
The initialization program generates the
proper volume label and constructs the table of contents.
When a data set is to be stored on a direct-access volume, you must
supply the operating system with control information designating the
amount of space to be allocated to the data set. The amount of space
can be expressed in terms of blocks, tracks, or cylinders. Space can be
allocated in a device independent manner if the request is expressed in
terms of blocks.
If the request is made in terms of tracks or
cylinde.rs, you must be aware of such device considerations as cylinder
capacity and track size.
Magnetic Tape Volumes
Because of the sequential organization of magnetic tape devices, the
operating system does not require space allocation facili-ties comparable
to those for direct-access devices. When a new data set is to be placed
on a magnetic tape volume, you must specify the data set sequence number
if it is not the first data set on the reel. A volume with standard
labels or no labels will be positioned by the operating system so that
the data set can be read or written. If the data set has nonstandard
labels,
the
installation must provide volume-positioning in its
nonstandard label processing routines. All data sets stored on a given
magnetic tape volume must be recorded in the same density.
When a data set is to be stored on an unlabeled tape volume and you
have not specified a volume serial number, the system assigns a serial
number to that volume and to any additional volumes required for the
data set. The first such volume is assigned the serial number LGL001:
lthe second LGL002 -, etc.
If you specify volume serial numbers for
unlabeled volumes on which a data set is to be stored, the system
a.ssigns volume serial numbers t~o any additional volumes required.
If
data sets residing on unlabeled volumes are to be cataloged or passed,
you should specify the volume serial numbers for the volumes required.
~rhis will prevent data sets residing on
different volumes from being
cataloged or passed under identical volume serial numbers. Retrieval of
such data sets could result in unpredictable errors.
Each data set and each data set label group on magnetic tape that is
t:o be processed by the operating system must be followed by a tape mark.
']~ape marks cannot exist within a data set.
When the operating system is
used to create a tape with standard labels or no labels, all tape marks
are automatically written.
Two tape marks are written following the
last tra.iler label group on a volume to indicate the last data set on
t:he volume.
On an unlabeled volume, the two tape marks are written
following the last data set.
When the operating system is used to create a tape data set with
nonstandard labels, the delimiting tape marks are not written.
If the
data set is to be retrieved by the operating system, those tape marks
must bE~ written by an appropriate installation nonstandard label
processing routine. Otherwise, tape marks are not required following
nonstandard labels since positioning of the tape volumes must be handled
by the installation routines.
Section II:
Data Management SerVices
(Part 1)
57
DATA SET RECORD FORMATS
A data set is composed of a collection of records that usually have
some logical relation to one another. The record is the basic unit of
information used by a processing program.
It might be a single
character, ·all information resulting from a given business transaction.,
or parameters recorded at a given point in an experiment. Much data
processing consists of reading, processing, and writing individual
records.
The process of grouping a number of records before writing them on a
volume is referred to as blocking. A block is considered to be made up
of the data between interrecord gaps (IRG). Each block can consist of
one or more records. Blocking conserves storage space on the volume
because it reduces the number of interrecord gaps in the data set. In
many cases, blocking also increases processing efficiency by reducing
the number of input/output operations required to process a data set.
Records may be in one of three formats: fixed-length (format F).,
variable-length (format V), or undefined-length (format U).
The prime
consideration in the selection of 'a record forma.t is the nature of the
data set itself. You must know the type of input your program will
receive and the type of output it will produce. Selection of a record
format is based on this knowledge, as well as an understanding of the
type of input/output devices that are used to contain the data set and
the access method used to read and write the data records.
The record
format of a data set is indicated in the data control block according to
specifications in the DCB macro-instruction, the DD statement, or the
data set label.
Fixed-Length Records
The size of fixed-length (format F) records, shown in Figure 12, is
constant for all records in the data set. The number of records within
a block is usually constant for every block in the data set, unless the
data set contains truncated (short) blocks. If the data set contains
unblocked format F records, one record constitutes one block.
Record
r-----T---------------------------,
I C I
Data
I
L _____
~
__________________________
~
I
I
__ ".-
".-"'-
Block
r----------------~---------------T----------------T---T---.------------~
I ________________
Record
Record
I ________________
Record
IIRGI
Record
L
i I ________________
___ ______________
_
~
I
I
I
I
~
~
Unblocked Records
t----------------T---T----------------T---T----------------·T---I
I
Record
IIRGI
Record
IIRGI
Record
IIRG
L ________________
Figure 12.
~
___
~
________________
~
___
~
________________
~
__ _
Format F Records
The system automatically performs physical length checking on blocked
format F records making allowance for truncated blocks.
Because the
channel and interrupt system can be used to accommodate length checking,
58
and the blocking/deblocking is based on a constant record length, format
F records can be processed faster than format V. A sequential data set
is said to contain records in standard format F if:
• All records in the data set are format F.
• Every track except the last is filled to capacity.
• No blocks except the last are truncated.
Standard format F data sets can be read from direct-access storage
more efficiently than data sets with truncated blocks because the system
can determine the location of each block to be read.
Format F records are shown in Figure 12. The optional control
character (e), used for stacker selection or carriage control# may be
included in each record to be printed or punched.
Variable-Length Records
Format V provides for both variable-length records, each of which
specifies its own length, and variable-length blocks of records, each of
which specifies its own block length.
The system performs length
checking of the block and uses the record length information in blocking
and deblocking.
As shown in Figure 13, the first four bytes of a
variable-length record contain control information: '11' represents the
length of the record and 'bb' represents two bytes reserved for system
use.
You must supply these four bytes when creating the record.
The
optional control character (e)
may be specified as the fifth byte of
each rE~cord.
Block
------------------------------LL-------------------------------
r~~~I~~~I~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I
Record
"-
~--T---T---T-------------~
/
~
/
111 Ibb I e I
Data
I
~---~---~---~------------~
-------------11-------...:-::::"'----
-- --
/
Unblocked Records
[~~~I~~~~~~~~~~~~~~~~~~~~~~I~~~~I~~~I~~~~~~~~~~~~~~~~~~I~~~~I~~I~~~~
------------LL-----------Figure 13.
-----------LL------------
Format V Records
The block length is represented by ILL' and 'bb' represents the two
bytes reserved for system use. When records are blocked by the system,
i.e., 1:he queued access technique is used, these characters are provided
automa1:ically when the data set is written. This information must be
supplied if you do your own blocking. Both your input and output buffer
areas must be large enough to accommodate the additional four bytes.
If
your records are unblocked, the record length plus the block control
information constitute the block length.
The initial eight bytes (nine if the optional
used) of the block are not printed or punched.
be used for any other purpose.
Section II:
control character is
These bytes should not
Data Management Services
(Part 1)
59
Undefined-Length Records
Format U is provided to permit processing of any records that do not
conform to the F or V formats. As shown in Figure 14, each block is
treated as a record; therefore" deblocking must be performed by your
program.
The optional control character may be used in the first byte
of each record. Because the system does not perform length checking on
format U records, your program may be designed to read less than a
complete block into main storage.
Record
r-----T---------------------------,
I C I
Data
I
t-----~----------------------::-~
I
Block
__ -- :Block
Block
~----------------~--T----------------T---T----------------------------~
I ________________
Record
L
Figure 14.
IIRGI
___
~
~
Record
________________
IIRGI
Record
___ ___________________________
_
~
~
Format U Records
Control Character
You may specify, in the DD statement, the DCB macro-instruction, or
the data set label that an optional control character is part of each
record in the data set. The one-byte character is used to indicate a
carriage control channel when the data set is printed or a stacker bin
when the data set is punched. Although the character is a part of the
record in storage, it is never printed or punched. For that reason,
buffer areas must be large enough to accommodate the character. If the
immediate destination of the record is a device that does not recognize
the control character, e.g., disk, the system assumes that the control
character is the first byte of the data portion of the record. If the
destination of the record is a printer or punch and you have not
indicated the presence of a control character, the system regards it as
the first byte of data.
DIRECT-ACCESS DEVICE CHARACTERISTICS
Regardless of organization, data sets created using the operating
system can be stored on a direct-access volume. Each block has a
distinct location and a unique address making it possible to locate any
record without extensive searching.
Thus, records can be stored and
retrieved either directly or sequentially.
Although direct-access devices differ in physical appearance, capacity, and speed, they are functionally and logically similar in terms of
data recording, checking, format, and programming.
The recording
surface of each volume is divided into many tracks, each defined as the
circumference of the recording surface.
The tracks ar'e arranged
concentrically; their number and capacity varies with the device.
Each
device has some type of access mechanism, containing a number of
read/write heads that t:ransfer data as the recording surface rotates
past.
The logical arrangement of related tracks is vertical rather than
horizontal. As shown in Figure 15, a 2311 cylinder is comprised of ten
tracks, which is equal to the number of recording surfaces. Because
there are 203 tracks per disk, there are 203 vertical cylinders of ten
tracks each.
60
00
Tracks
r----------
202
I
I
I
Figure 15.
~rRACK
2311 Disk Drive
FORMAT
Information is recorded on all direct-access volumes in a standard
format.
In addition to device data, each track contains a track
descriptor record ("capacity record" or RO), and data records. As shown
in Figure 16~ there are two possible data record formats
Count-Data
and Count-Key-Data -- only one of which can be used for a particular
data se"t.
Ir-----lI
r-----'
Iil Count
I Data
_____ JI L
_____ JI
Track Descriptor
Record (RO)
Ir-----'
I
IL Count
_____ JI
r-----'
IL Data
_____ JI
Track Descriptor
Record (RO)
lrigure 16.
Count-Data Format
r-----' r-----'
r-----' r-----'
L _____ J
L _____ J
I Count I LIData
I
_____ J
ICountl
IData
I
L _____ J
Data Record
(Rn)
Data Record
(R1)
Count-Key-Data Format
r-----' r----' r-----'
r-----' r----' r-----'
I Count I IKey I IData I
ILCount
I IKey
I IData
I
_____ J
L ____ J
L _____ J
Data Record (R1)
Data Record (Rn)
L _____ J
L ____ J
L _____ J
Direct-Access Volume Track Formats
.,
In addition to device data, the count area contains eight bytes that
identify the location of the record in terms of the cylinder, head, and
Jrecord numbers; its key length (0 if no keys are used); and its data
length.
If the records are written with keys, the ~~ (1 to 255 bytes)
contains a record key that identifies the following data area in terms
of a pa:rt number, account number, sequence number, etc.
In some cases,
records are written with keys so that they can be located quickly.
section II:
Data Management Services
(Part 1)
61
TRAC.K ADDRESSING
There are two types of addresses that can be used to store and
retrieve data on a direct-access volume: actual and relative. The only
real advantage of using actual addresses is the reduction in time
required to convert from relative to actual address and vice versa.
When sequentially processing a multiple volume data set, you can refer
only to records of the current volume.
Actual Addresses: When the system returns the actual address of a
record on a direct-access volume to your program, it is in the form
MBBCCBER, where:
M
is a one-byte binary number specifying the relative location of an
entry in a data extent block (DEB). The data extent block is
created by the system when the data set is opened.
Each extent
entry
set.
describes
a set of contiguous tracks allocated for the data
BBCCHB
is a six-byte binary number specifying the cell (bin), cylinder,
and head number for the record, i.e., its track address. The
cylinder and head numbers are recorded in the count area for each
record.
R
is a one-byte binary number specifying the relative block number on
the track. The block number is also recorded in the count area.
If you use actual
treated as "unmovable."
addresses in your
program~
the data set must be
Relative Addresses: There are two kinds of relative addresses that can
be used to refer to records on a direct-access volume: relative block
address or relative track address.
The relative block address is provided as a three-byte number that
indicates the position of the block in relation to the first block of
the data set. Allocation of noncontiguous tracks does not affect the
number.
The relative track address is provided in the form TTR, where:
TT
is a two-byte binary number specifying the position of the track in
relation to the first track allocated for the data set. The TT for
the first track is zero. Allocation of noncontiguous tracks does
not affect the number.
R
is a one-byte binary number specifying the number of the block in
relation to the first block on the track TT. The first block is
zero.
TRACK OVERFLOW
If the record overflow feature is available for the direct-access
device 'being used, you can reduce the amount of unused space on the
volume by specifying the track overflow option in the DD statement or
the DCB macro-instruction associated with the data set.
If the opticn
is used, a block that does not fit on the track is partially written on
that track and continued on the next available track. Each segment of
62
an overflow block (the portion written on one track) has a count area.
The data length field in the count area specifies the length of that
slegment only. If the block is written with a key, there is only one key
a:rea for the block. It is written with the first segment.
If the
option is not used, blocks are not split between tracks.
Although a block can begin on one cylinder and continue on the next,
it. cannot be continued on a noncontiguous track or from one separately
allocated area to another.
WRITE VA:LIDITY CHECK
....
You can specify the write validity option in either the DD statement
the DCB macro- instruction. The system will read each record back
(,~ithout
data transfer)
and" by testing for a data check from the I/O
device, verify that the record transferred from main to secondary
storage was written correctly. This verification requires an additional
r~:!vol ution
of the device for ea.ch record that was wri t ten. Standard
error recovery procedures are initiated if an error condition is
OJr
d~:!tected.
INTERFACE WITH THE OPERATING
SYSTE~
You must describe the characteristics of a data set, the volume on
which it resides" and its processing requirements before processing can
begin.
During execution, the descriptive information is made available
to the operating system in the data control block. A data control block
is required for each data set, and is created in a processing program by
a DCB macro-instruction.
Primary sources of information to be placed in the data control block
al:e a DCB macro-instruction, a data definition (DD) statement, or a data
SE!t label.
In addition, you can provide or modify some of the
information during execution by storing the pertinent data in the
appropriate field of the data control block. The specifications needed
for input/output operations are supplied during the initialization
pl~ocedures of the OPEN macro-instruction.
Therefore, the pertinent data
can be provided when your job is to be executed rather than when you
wl~ite your program (see Figure 17).
Data Set Label
B
F
G
H
J
C
D
A
ABCDEFGHIJ
Figure 17.
completing the Data Control Block
section II:
Data Management Services
(Part 1)
63
When the OPEN macro-instruction
performs four primary functions:
is
executed,
the
open
routine
• Completes the data control block.
• Loads all necessary data access routines not already in main
storage.
• Initializes data sets by reading or writing labels and control
information.
• Constructs the necessary system control blocks.
Information from a DD statement is stored in the job file control
block (JFCB) by the operating system. When the job is to be executed"
the JFCB is made available to the open routine. The data control block
is filled by using information from the DCB macro-instruction, the JFCB,
or an existing data set label. If more than one source specifies a
particular field, only one source is used.
A DD statement takes
precedence over a data set label; a DCB macro-instruction over both.
However, you can mOdify any data control block field either before the
data set is opened, or when control is returned to your program by the
operating system (during the data control block exit). Some fields can
be modified during processing.
Figure 18 illustrates the process and the sequence of filling in the
data control block from various sources. The primary source is your
program, i.e., the DCB macro-instruction. In general, you should use
only those DCB parameters that are needed to ensure correct processing.
The other parameters can be filled in when your program is to be
executed. When a data set is opened, any field in the JFCB not
completed by a DD statement is filled in from the data set label (if one
exists). Any field not completed in the data control block is filled in
from the JFCB.
Any field in the data control block then can be
completed or modified by your own DCB exit routine.
DeB
r - - - - - - - - - - - - - - - - I Exit
Routine
Old
Data Set
Label
Figure 18.
---0-----.---...
Source and Sequence for Completing the Data Control Block
When the data set is closed, the data control block is returned to
its condition prior to opening; it is then available for reuse with
another data set. The open and close routines also use the updated JFCB
to write the data set labels for output data sets. If the data set is
not closed when your job terminates, the operating system will perform
the close functions automatically.
There is usually one data control block for each data set.
It is
possible to concurrently open more than one data control block for
processing the same data set on a direct-access volume.
However, you
must exercise caution with respect to volume positioning, switching,
space allocation, label processing, and device control.
64
-.,
DATA SET DESCRIPTION
For each data set you are going to process there must be a
corresponding data control block and data definition statement. The
characteristics of the data set and device~depend€nt information can be
supplied by either source. In addition, the DD statement must supply
data
set identification~ device characteristics, space allocation
requests, and related information. 'l'he logical connection between a
data control block and a DD statement is made by specifying the name of
·the DD statement in the DCB macro-instruction (DDNAME), or by completing
the field yourself before opening the data set.
Once the data set characteristics have been specified in the DCB
1nacro-instruction, they can only be changed by modifying the data
control block during execution. The fields of the data control block
discussed below are common to most data organizations and access
t.echniques.
pata Set Organization (DSORG): specifies the organization of the data
set as physical sequential (PS), indexed sequential (IS), partitioned
(PO), o.r dir·ect (DA).
If the data set contains location-dependent
:lnforma·tion (i.e., absolute rathE~r than relative addresses), it must be
marked as unmovable, e.g., PSU.
You must specify t.he data set
organization in the DCB macro-instruction. When creating an indexed
sequential or direct organization data set, this information must also
be supplied in the DD statement.
Format (RECFM): specifies the characteristics of the records in
the data set as fixed-length (F), variable-length (V), or undefinedlength (U).
Blocked records are specified as being E'B or VB. Track
overflow can be requested, e.g., FBT.
l~ecord
Record Lenqth (LRECL)~ specifies the length, in bytes~ of each record
1n the data set. If the records are variable-length, the maximum record
length must be specified.
The field should be omitted for format U
records ..
Size (BLKSIZE): specifies t.he maximum length, in by·tes, of a
hlock.
If the records are format. F, the block size must be an integral
multiple of the record length, including the key length. If the records
are format V, the block size must be the maximum block size.
If the
records are unblocked:, LRECL must equal BLKSIZE.
1~10ck
Each
of the data set description fields of the data control block,
as noted for data set organization, can l::e specified when your
job is to be executed.
In addition, data set identification and
disposition, as well as device characteristics, can be specified at that
t:ime. ~('he parameters of the DD statement discussed below are common to
most data set organizations and devices.
E~xcept
Data Definition Name (ddname):
is the name of the DD statement and
provides a logical relationship to the data control block that specifies
t~he sam~~ ddname.
!;)ata Set: Name (DSNAME): specifies the name of a newly defined data set,
or refers to a previously defined data set.
Data
Control Block (DCB):
provides, by means of subparameters,
Informat.ion to be used to complete those fields of t.he data control
block that were not specified in the DCB macro-instruction. This
parametE~r cannot be used to modify a data control block.
Channel Separation and Affinity (SEP/AFF): requests that specified data
sets use different channels during input/output operations.
Section II:
Data Manageme:i.lt Services
(Part 1)
65
Input/Output Device (UNIT): specifies the quantity
devices to be allocated for use by the data set.
and
type
of
I/O
Space Allocation (SPACE): designates the amount of space on a directaccess volume that should be allocated for the data set.
Unused space
can be released when your job is finished.
Volume Identification (VOLUME):
identifies the particular volume or
volumes, or the number of volumes to be assigned to the data set or the
volumes on which existing data sets reside.
Data Set Label (LABEL): indicates the type and contents of the label or
labels associated with the data set. The operating system verifies
standard labels (SL) or standard user labels (SUL). Nonstandard labels
(NSL) can be specified only if your installation has incorporated into
the operating system routines to write and process nonstandard labels.
Data Set Disposition (DISP): describes the status of a data set
indicates what is to be done with it at the end of the job step.
..
and
PROCESSING PROGRAM DESCRIPTION
There are several types of processing information required by the
operating
system
to ensure proper control of your input/output
operations,. The forms of macro-instructions in the program, buffering
requirements, and the addresses of your special processing routines must
be specified during either the assembly or the execution of your
program. The DCB parameters specifying buffer requirements are discussed in the section "Buffer Acquisition and Control."
Because macro-instructions are expanded during the assembly of your
program, you must supply the macro-instruction forms that are to be used
in processing each data set in the associated DCB macro-instruction.
Buffering requirements and related information can be supplied in the
DCB macro-instruction, the DD statement, or by storing the pertinent
data in the appropriate field of the data control block before the end
of your DCB exit routine.
If the addresses of special processing
routines are omitted from the DCB macro-instruction, you must complete
them in the data control block before opening the data set.
Macro-Instruction
Form
(MACRF):
specifies not only the macroinstructions used in your program, but also the processing mode as
discussed in the section "Buffer Control." The organization of your
data set, the macro-instruction form, and the processing mode determine
which of the data access routines will be used during execution.
Exits to Special Processing Routines:
used to identify the location of:
The DCB macro-instruction can be
• A routine that performs end-of-data procedures.
• A routine that supplements the operating system's error
routine.
• A list that contains addresses of special exit routines.
recovery
The exit addresses can be specified in the DCB macro-instruction or
you can complete the data control block fields before opening the data
set.
Table 6 summarizes the exits that you can specify either
explicitly in the data control block, or implicitly by specifying the
address of an exit list in the data control block~
66
--.
Table
6.
Lata Management Exit Routines
r--------------------T------------------------T------------------------,
I Exit Routine
I When Available
I Where specified
I
.,
~------.--------------+------------------------+------------------------~
,Data Control Block IOpening a data set
IEXLIST operand and
I
lexit list
I
I
I
~------.--------------+------------------------+------------------------i
IStandard User Label IOpening/closing a data IEXLIST operand and
I
lexit list
I
I (only for sequentiallset or when changing
I organization)
I volumes
I
I
~--------------------+------------------------+------------------------i
I End-of-Data-Set
INo more sequential
IEODAD operand
I
I
Irecords or blocks are
I
I
I
I
I
I available
.--------------------+------------------------+------------------------i
IError Analysis
IAfter an uncorrectable ISYNAD operand
I
I ____________________ 4linput/output
error
L
____________• ____________
I ________________________ JI
~
Exit Routine (EODAD): specifies the address of end-ofdata routine that performs any final processing on an input data set.
~rhis routine is entered when a READ or GET request is made and there are
no mor,e records or blocks to be retrieved. Your routine can repos ition
the volume for continued processing, close the data set, or process the
next sequential data set. If no routine is provided, the task will be
abnormally terminated.
J~nd-of-Data-Set
~)ynchronous Error Routine
E~rror
:coutine that is
Exit (SYNAD): specifies the address of an
to be given control when an input/output error
occurs. This routine can be used to analyze exceptional conditions or
uncorrectable errors. The error can be skipped, accepted, or processing
Gan be terminated.
If
an input/output error occurs during data transmission, standard
recovery procedures, provided by the operating system, attempt to
correct the error before returning control to your program.
An
lllncorreetable error usually causes an abnormal termination of the job
step.
However, if you specify in the DCB macro-instruction the address
of an error analysis routine, the routine is given control in the event
of an uncorrectable error.
E~rror
You can write a SYNAD routine to determine the cause and type of
error that occurred by examining:
•
•
•
•
The
The
The
The
contents of the general registers.
data event control block (DECB).
exceptional condition code.
standard status and sense indicators.
Having
completed the analysis, you can return control to the
system or close the erroneous data set and terminate processl.ng. In no case can you attempt to reread or rewrite the record since
the system has already attempted to recover from the error.
~perating
When using GET/PUT macro-instructions to process a sequential data
set, the operating system provides three automatic error options (EROPT)
to be used if there is no SYNAD routine or if you want to return control
to your program from the SYNAD routine:
• Ace
accept the erroneous block.
• SKP -- skip the erroneous block.
• ABE -- abnormally terminate the task.
I:f the EROPT and SYNAD fields are not completed, ABE is assumed.
Section II:
Data Management Services
(Part 1)
67
Upon entry to your SYNAD routine register 0 will contain either the
address of standard status indicators and a displacement value to reach
the channel command word (GET/PUT), or the address of the data event
control block (READ/WRITE).
Register 1
indicates
which
macroinstruction caused the error and the address of the data control block.
Registers 2 through 13 remain as they were.
Register 14 contains a
return address and 15 the address of your SYNAD routine.
When using READ/WRITE macro-instructions, errors are detected by
issuing a CHECK macro-instruction. If you return directly to the CHECK
routine from your SYNAD routine, the operating system regards that as an
acceptance of the bad record.
Exit List (EXLST):
specifies the address of special
processing
routines.
An exit list must be cre~ted if label or data control block
exits are used.
The exit list is constructed of four-tyte entries that must be
aligned on full-word boundaries. The exit routine type is specified by
a code in the high-order byte, and the address of the routine 1S
specified in the three low-order bytes. Codes and addresses for the
exit routines are shown in Table 7.
Table
7.
Format and Contents of an Exit Routine
r-----------------------T-----------T----------------------------------,
I
I Hexadecimal I
I
IRoutine Type
I
Code
13-Byte Routine Address - Purpose
I
~-----------------------+-----------+----------------------------------i
IInactive entry
I
00
I Ignored; the entry is not active
I
~-----------------------+-----------+----------------------------------~
IInput header label
I
01
IProcess a user input header label I
~-----------------------+-----------+----------------------------------i
loutput header label
I
02
ICreate a user output header label I
~-----------------------+-----------+----------------------------------i
IInput trailer label
I
03
IProcess a user input trailer label I
~-----------------------+-----------+----------------------------------~
loutput trailer label
I
04
ICreate a user output trailer label I
~-----------------------+-----------+----------------------------------~
IData control block exitl
05
IData control block exit routine
I
.-----------------------+-----------+----------------------------------i
ILast entry
I
80
ILast entry in list. This code canl
I
I
I
Ibe specifiea with any of the above I
lbut must always be specified with I
I
IL _______________________ LI ___________ I the
last entry.
__________________________________
JI
~
You can activate or deactivate any entry in the list by placing the
required code in the high-order byte. Care must be taken, however, so
as not to destroy the last entry indication. The list will be scanned
from top to bottom by the operating system. The first active entry
found with the proper code will be selected.
The list can be shortened during execution by setting the high-order
four bits to the hexadecimal value 8. The list can be extended by
setting the high-order four bits to zero.
When control is passed to either a label exit or data control block
exit routine, the general registers contain the following information:
68
,4
Register
o
Contents
Address of label buffer area (label exit only).
Address of data control block currently being processed.
contents prior to execution of the macro-instruction.
Return address (must not be altered by the exit routine).
Address of exit routine entry point.
1
2-13
14
15
Standard User Label Exit: You can specify in an exit list the address
of a routine that creates or verifies up to eight user header or trailer
labels. The label processing routine must terminate with a RETURN
macro-instruction and a return code that indicates what action is to be
taken by the operating system as shown in Table 8.
Because register 14 contains a return address, your label routine
must not alter it.
If any macro-instructions are used in the label
routine, you must save the contents of register 14. Before issuing the
RETURN macro-instruction, the return code can be loaded into 15 and the
contents of register 14 restored.
lrable
8.
System Response to an Exit Routine Return Code
r--------------T-------------------------------------------------------,
I Return Code I
system Action
I
~--------------+-------------------------------------------------------~
I
Verify
I
I
I
I
I
,I
0
I
INormal processing is
Ilabels are ignored.
resumed;
any
additional
I
user I
I
I
I Normal
I
I
I
I
I
user label is to be read; control is returned I
Ito the user label exit routine. If another user label I
I does not exist, normal processing is resumed.
I
.--------------+-------------------------------------------------------~
Create
I
I
II
~
II
4
I
o
4
IThe label created by the user is the last label to be I
I written. Normal processing is resumed after the label I
lis written.
I
I Control is returned to the user label exit routine I
lafter the label is written, unless the maximum number I
labels (eight) has been written.
L ______________ lof
_______________________________________________________
JI
~
Data Control Block Exit: You can specify in an exit list the address of
a routine that completes or modifies a data control block and does any
additional processing required before the data set is completely open.
The routine is entered during the opening process after the job file
control block has been used to supply information for the data control
block. The routine can be used to determine data set characteristics by
examining fields completed by the data set labels.
As with label processing routines, register 14 must be preserved and
restored if any macro-instructions are used in the routine. Control is
returned to the operating system by a RETURN macro-instruction; no
return code is required.
section II:
Data Management Services
(Part 1)
69
MODIFYING THE DATA CONTROL BLOCK
You can complete or modify the data
your program. You can also determine
information supplied by the data set
be made prior to opening the data set,
exit routine, or while ,the data set is
must be supplied before it is needed.
control tlock during execution of
data set characteristics from
labels. Changes or additions can
after closing it, during the DCB
open. Naturally, any information
Because each data control block does not have a symbolic name for
each field" a DCBD macro-instruction must be used to supply the symbolic
names. By loading a base register with the address of the data control
block to be processed, any field can be referred to symbolically.
The DCBD macro-instruction generates a dummy control section (DSECT)
named IHADCB.
The name of each field begins with DCB followed by the
first five letters of the keyword operand that represents the field in
the DCB macro-instruction. For example, the field reserved for block
size would be referred to as DCBBLKSI.
The attributes of each data control block field are defined in the
dummy control section. Because each field in the data control ,block is
not necessarily aligned on a full-word toundary, care must be taken when
storing or moving data into the field. The length attribute and the
alignment of each field can be determined from an assembly listing of
the DCBD macro-instruction.
The DCBD macro-instruction can be used only once in an assembly.
If
it is written before the end of a control section, it must be followed
by a CSECT or DSECT statement to resume the original control section.
Changing an Address in the Data Control Block: The following example
illustrates how you can modify a field in the data control block.
The
DCBD macro-instruction defines the symbolic name of each field.
The USING statement establishes register 10 as a base register for
IHADCB. The LA (Load Address) inst~tion places the address of the
data control block, TEXTDCB, in register 10. The address of ENDJOB is
then stored in register 6. Because the field DCBEODAD is only three
bytes long, the address must first te stored and then moved into the
data control block rather than stored directly so as not to destroy the
high-order byte. Thus, the end-of-data-set address is changed.
TEXTDCB
DCB
ENDSKIP
LA
USING
LA
ST
MVC
B
TEMPADDR DS
ENDJOB
WTO
CLOSE
L
RETURN
DCBD
DSORG=PS,MACRF=(R),DSNAME=TEXTTAPE,EODAD=ENDSKIP,
SYNAD=EROUTINE
C
IHADCD,10
10,TEXTDCB
6,ENDJOB
6,TEMPADDH
DCBEODAD+l(3),TEMPADDR+l
NXTRECRD
CL4
'NOR~~L END OF TEXT90 TAPE CONVERSION'
(TEXTDCB)
13,SAVEAREA+4
(14,12)
DSORG=PS,IS,PO,DA
70
4
PART 2:
DATA MANAGEMENT PROCESSING PROCEDURES
DATA PROCESSING TECHNIQUES
The operating system allows you to concentrate your efforts on
processing the records read or written by the data management routines.
Your main responsibility is to describe the data set to be processed,
the buffering techniques to be used, and the access method.
An access
method can be defined as the combination of data set organization and
the technique used to process the data. Data access techniques can be
divided into two categories -- queued and basic.
QUEUED ACCESS TECHNIQUE
The queued access technique provides GET and PUT macro-instructions
for transmitting data between main and secondary storage.
These
lmacro-instructions cause automatic blocking and deblocking of the
records stored and retrieved. Anticipatory (look-ahead) buffering and
synchronization (overlap) of input and output operations with CPU
processing are automatic features of the queued access technique.
Because the operating system controls buffer processing, you can use
as many I/O buffers as needed without reissuing GET/PUT
macroinstructions to fill or empty buffers. Usually, more than one input
]block is in main storage at any given time to prevent I/O operations
from delaying record processing.
Because the operating system synchronizes input/output with processing,
you
need not test for completion, errors"
or exceptional
conditions. After a GET or PUT macro-instruction is i~sued, control is
not returned to your program until an input area is filled or an output
area is available. Exits to error analysis (SYNAD) and end-of-volume or
end-of-data (EODAD) routines are automatically taken when necessary.
§ET -- Retrieve a Record
The GET macro-instruction obtains a record from an input data set.
It operates in a strictly sequential and device-independent manner. As
.required, the GET macro-instruction schedules the filling of input
buffers, deblocks records, and directs input error recovery procedures.
Alfter all records have been processed and the GET macro-instruction
detects an end-of-data indication, the system automatically checks
labels and passes control to your end-of-data (EODAD) routine.
If an
€!nd-of-volume condition is detected, the system provides automatic
volume switching if the data set extends across several volumes or if
concatenated data sets are being processed.
PUT -- Write a Record
The PUT macro-instruction places a record into an output data set.
Like the GET macro-instruction, it operates in a strictly sequential and
device-independent manner.
As required, the PUT macro-instruction
schedules the emptying of output buffers, blocks records, and handles
output error correction procedures~ It also initiates automatic volume
switching and label creation.
section II:
Data Management Services
(Part 2)
71
If the PUT macro-instruction is directed to a card punch or printer,
the system automatically adjusts the number of records per block of
format F or V blocks to 1.
Thus, you can specify a record length
(LRECL) and block size (BLKSIZE) to provide an optimum block size if the
records are temporarily placed on magnetic tape or a direct-access
volume.
PUTX -- Write an Updated Record
The PUTX macro-instruction is used to update a data set or to create
an output data set using records from an input data set dS a base. PUTX
updates, replaces, or inserts records from existing data sets but does
not create records or add records from other data sets.
When you use the PUTX macro-instruction to updat~, each record is
returned to the data set referred to by a prev~ous GET macroinstruction.
The buffer containing the updated record is flagged and
written back to the same location on the direct-access storage device
from which it was read.
The block is not written out until a GET
macro-instruction is used for the next buffer.
When the PUTX macro-instruction is used to create an output data set,
you can add new records by using the PUT macro-instruction.
As
required, the PUTX macro-instruction blocks records, schedules the
writing
of
output buffers, and handles output error correction
procedures.
BASIC ACCESS TECHNIQUE
The basic access technique provides the READ and WRITE macroinstructions for transmitting data between main and secondary storage.
This technique is used when the operating system cannot predict the
sequence in which the records are to be processed or when you do not
want some or all of the automatic functions performed by the queued
access technique.
Although the system does not provide anticipatory
buffering or synchronized scheduling, macro-instructions are provided to
help you program these functions.
The READ and WRITE macro-instructions process blocks, not records.
Thus, blocking and deblocking of records is your responsibility.
Buffers, allocated either by you or the operating system, are filled or
emptied individually each time a READ or WRITE macro-instruction is
issued. Moreover, the READ and WRITE macro-instructions only initiate
input/output operations.
To ensure that the operation is completed
successfully, you must issue a CHECK macro-instruction to test the DECB
or a WAIT macro-instruction and then check the DECB yourself. The
number of READ or WRITE macro-instructions issued before a CHECK
macro-instruction is used should not exceed the specified number of
channel programs (NCP).
READ -,-
Rea.9~~lock
The READ macro-instruction retrieves a data block from an input data
set and places i t in a designated area of main storage. To allow
overlap of the input operation with processing, the system returns
control to your program before the read opera'tion is completed. The
DECB created for the read operation must bE tested for successful
comple'tion before processing the record or reusing the DECB.
If an indexed sequential data set is being read, the block is brought
into main storage and the address of the desired record is returned to
you in the DECB.
72
"
You can specify variations of the READ macro-instruction according to
the organization of the data set being processed and the type of
processing to be done by the system as follows:
SF - Read the data set
.
SB - Reading
only> •
K
the
sequent~ially.
data
set
backward (magnetic tape, format F and U
- Read the data set.
KU - read for update.
The system maintains the device address of the
record; thus, when a WRITE macro-instruction returns the record,
no index search is required.
Direct
D
- use the direct-access method.
I
- locate the block using a block identification.
K
- locate the block using a key.
F
- provide device position feedtack.
x
- maintain exclusive control of the tlock.
The WRITE macro-instruction places a data block in an output data set
from a designa·ted area of main storage. The WRITE macro-instruction can
also be used to return an updated record to a data set.
To allow
overlap of output operations with processing, the system returns control
to your program before the write operation is completed. The DECB
created for the write operation must be tested for successful completion
before the DEeB can be reused.
As lIIrith the READ macro-instruction, you can specify variations of the
WRITE macro-instruction according to the organization of the data set
and the type of processing to be done by the system as follows:
Sequential
SF - Write the data set sequentially.
Indexed Seguential
K
•
- write a block containing an updated record, or replace a record
with an unblocked record having the same key.
The record to be
replaced need not have been read into main storage.
KN - write a new record.
Direct
SD - write a dummy fixed-length record.
sz - write
a capacity record (RO) • The system supplies t.he data,
writes the capacity record, and advances to the next track.
Section II:
Data Management Services
(Part 2)
73
D
- use the direct-access method.
I
- search argument identifies a block.
K
- search argument is a key.
A
- add a new block.
F
- provide record location data (feedtack).
x
- release exclusive control.
•
CHECK -- Test Completion of Read/Write OQeration
When processing a sequential or direct data set, you can wait and
test for completion of a read or write request by issuing a CHECK
macro-instruction.
The
system tests for errors and exceptional
conditions in the data event control block.
Successive CHECK macr07
instructions issued for the same data set should be issued in the same
order as the associated READ/WRITE macro-instructions.
l'
The check routine will pass control to the appropriate exit routines
specified in the data control block for error analysis (SYNAD) or
end-of-data (EODAD). It will also automatically initiate end-of-volume
procedures, i.e., volume switching or extending output data sets.
WAIT -- Wait for Completion of a Read/Write Operation
When processing an indexed sequential data set, you must ~est for
completion of any read or write operation by issuing a WAIT macroinstruction.
The input/output operation will be synchronized with
processing, but the DECB will not be checked for errors or exceptional
conditions, nor will end-of-volume procedures be initiated. These
functions must be tested for and performed by your program.
The WAIT macro-instruction can be used to await completion of
multiple read/write operations. Each operation must then be checked or
tested separately.
Data Event Control Block (DECB)
A data event control block is a 16- to 28-byte area reserved by you
or the system for each READ/WRITE macro-inst.ruction.
It contains
control information and pointers to standard status indicators.
The
DECB is examined by the check routine when the I/O operation is
completed to determine if an error or exceptional condition exists.
If
it does, error correction procedures are attempted and, if unsuccessful,
control is passed to your SYNAD routine. The job step is abnormally
terminated if you have no error analysis routine.
When processing an indexed sequential data set, you must examine the
first byte of the exceptional condition code in the DECB yourself after
issuing a WAIT macro-instruction to ensure completion of the I/O
operation before checking.
SELECTING AN ACCESS METHOD
Access methods are identified primarily by the data set organization
to which they apply. For instance, we speak of a basic access method
for direct organization (BDAM). Nevertheless, there are times when an
access method identified with one organization can be used to process a
data set usually thought of as organized in a different manner. Thus, a
data set is created using the tasic access method for sequential
organization (BSAM). It is processed using the basic direct access
74
14
method (BDAM).
If the queued access technique is used to process a
sequential data set, the access method is referred to as QSAM.
The basic access methods are used for all data organizations, while
the queued access methods apply only to sequential and
indexed
sequential data sets as shown in Table 9.
Table
..
9.
Data Access Methods
r------------------------T---------------------------------------------,
I
Data Set
I
Access Technique
I
~----------------------T----------------------1
Organization
I
Basic
I
Queued
I
~------------------------+----------------------+----------------------1
I
sequential
I
BSAM
I
QSAM
I
I
Pa:rti tioned
I
BPAM
I
I
I
Indexed Sequential
I
BISAM
I
QISAM
I
IL _____
Direct
BDAM
I _____________________ JI
.___________________ I ______________________
L_
I
I
~
It is possible to directly control an I/O device while processing any
data organization without using a specific access method. The execute
channel program (EXCP) macro-instruction uses the system functions that
provide for scheduling and queuing I/O requests, efficient use of
channels and devices, data protection, interruption procedures, error
recognition and retry.
Complete details about the
EXCP
macroinstruction are in the publication IBM System/360 Operating System:
System Programmer's Guide.
OPENING AND CLOSING A DATA SET
Although your program has been assembled, the various data management
routines required for I/O operations are not a part of the object code.
In other words., your program is not completely assembled until it is
initiat:ed for execution. Initiation is accomplished by issuing the OPEN
macro-instruction. After all data control clocks have been completed,
the system ensures that all required access method routines are loaded
and ready for use and that all channel command word lists and buffer
areas are ready.
Access method routines are
control fields that indicate:
•
•
•
•
selected
and loaded according to data
Data organization.
Buffering technique.
Access technique.
I/O unit characteristics.
This information is used by the system to allocate main storage space
and load the appropriate routines. These routines, the CCW lists, and
buffer areas created automatically by the system remain in main storage
until the close routine signals that they are no longer needed by that
data control block.
When I/O operations are completed for a data set, a CLOSE macroinstruction should be issued to return the data control block to its
original status, handle volume disposition, create data set labels,
Icomplete writing of queued output buffers, and free main and secondary
storage. After the data set has been closed, the data control block can
be used for another data set. If you do not close the data set before a
1task terminates, the operating system closes it automatically.
If the
data control block is not available to the system at that time, the task
is abnormally terminated.
Section II:
Data Management Services
(Part 2)
75
An OPEN or CLOSE macro-instruction can be used to initiate or
terminate processing of more than one data set. Simultaneous opening or
closing is faster than issuing separate macro-instructions; however,
additional storage space is required for each data set specified.
Volume disposition specified in the OPEN or CLOSE macro-instruction
can be overridden by the system if necessary. However, you need not be
concerned; the system automatically
requests
the
mounting
and
dismounting of volumes depending upon the availability of devices at a
particular time.
•
OPEN -- Initiate Processing of a Data Set
The OPEN macro-instruction is used to complete a data control block
for an associated data set. The method of processing and the volume
positioning instruction in the event of an end-of-volume condition can
be specified.
Processing Method:
A data set can be processed as either input or
output (INPUT, OUTPUT) or a combination of the two (INOUT, OUTIN -- BSAM
only). If the data set resides on a direct-access volume, records can
be updated (UPDAT).
Magnetic tape volumes can also be read backwards
(RDBACK -- BSAM and QSAM only). If the processing method operand is
omitted from the OPEN macro-instruction, INPUT is assumed. The operand
is ignored by BISAM; it must be specified as OUTPUT when using QISAM to
create an indexed sequential data set.
Volume Positioning:
When an end-of-volume condition is detected, the
system positions the volume according to the disposition specified in
the DD statement unless the volume disposition is specified in the OPEN
macro-instruction. Volume positioning instructions for a sequential
data set ca'n be specified as LEAVE or REREAD.
LEAVE
positions the volume at the logical end of the data set just read
or written. If the data set has been read backwards, the logical
end is the physical beginning of the data set.
REREAD
positions the volume at the logical beginning of the data set just
read or written.
A volume positioning instruction can be specified only if the
processing method operand has been specified.
It will be ignored if
devices other than magnetic tape or direct-access are used.
It will
also be ignored if the number of volumes exceeds the number of available
units.
Positioning of magnetic tape volumes varies according to the direction of the last input operation and the existence of tape labels.
If
the tape was last read forward:
LEAVE
will pOSition a labeled tape following the tape mark that follows
the data set trailer label group; an unlabeled volume following the
tape mark that follows the last block of the data set.
REREAD
will position a labeled tape preceding the data set header label
group; an unlabeled tape preceding the first block of the data set.
76
If 1:.he tape was last read backwards:
LEAVE
will position a labeled tape preceding the data set header label
group; an unlabeled tape preceding the first block of the data set.
REREAD
will position a labeled tape following the tape mark that follows
the data set trailer label group; an unlabeled tape following the
ta.pe mark that follows the last block of the data set .
•
.Simultaneous Opening of Data Sets:
In this example of the OPEN
macro-instruction, the data sets associated with three data control
blocks are to be opened simultaneously with the indicated options.
..
...
-+-
+
+
+
-11-
'-'"
OPEN
CNOP
BAL
DC
DC
DC
DC
DC
DC
SVC
(TEXTDCB"CONVDCB, (OUTPUT) ,PRINTDCB, (OUTPUT»
0,4
1,*+16 LOAD REGl W/LIST ADDR.
AL1(0) OPTION BYTE
AL3(TEXTDCB) DCB ADDRESS
AL1(lS) OPTION BYTE
AL3(CONVDCB) DCB ADDRESS
AL1(143) OPTION BYTE
AL3(PRINTDCB) DCB ADDRESS
19 ISSUE OPEN SVC
Since no processing method operand is specified for TEXTDCB, the
Bystem 'assumes INPUT. Both CONVDCB and PRINTDCB are opened for output.
No volume positioning options are specified; thus, the position indicated by the DO statement DISP parameter is used.
At execution time, the SVC 19 instruction passes control to the open
which then initiates the three data control blocks and loads
t:he appropriate access method routines.
l~outine,l
CLOSE -- Terminate Processing of a Data Set
The CLOSE macro-instruction is used to terminate processing of a data
set and release it from a data control block.
The volume positioning
that is to result from closing the data set can also be specified.
Volume positioning options are the same as those that can be specified
for end-of-volume conditions.
•
The operating system provides a temporary closing option, CLOSE
(TYPE=T), for data sets being processed by BSAM.
When the macroinstruction is executed for data sets on magnetic tape or direct-access
volumes, the system processes labels and repositions the volume as
required.
However, the data control block maintains its open status.
processing of the data set can be continued at a later stage in your
program without reissuing the OPEN macro-instruction. Performance is
thus improved significantly. Magnetic tape volumes will be repositioned
either preceding the first data tlock or following the last data tlock
of the data set as described in the OPEN macro-instruction. The
presence of tape labels has no effect on repositioning.
Simultaneous Closing of Data Sets:
In this
macro-instruction, the data sets associated
blocks are to be closed simultaneously.
Section II:
example of the CLOSE
with three data control
Data Management Services
(Par.t 2)
77
CLOSE
CNOP
BAL
DC
DC
DC
DC
DC
DC
SVC
+
+
+
+
+
+
+
+
+
(TEXTDCB" CONVDCB" , PRINTDCB)
0,4
1,*+16 BRANCH AROUND LIST
AL1(0) OPTION BYTE
AL3(TEXTDCB) DCB ADDRESS
AL1(0) OPTION BYTE
AL3(CONVDCB) DCB ADDRESS
AL1(128)OPTION BYTE
AL3(PRINTDCB) DCB ADDRESS
20 ISSUE CLOSE SVC
~
Because no volume positioning operands are specified,
indicated by the DD statement DISP parameter is used.
the
position
At execution time, the SVC 20 instruction .passes control to the close
routine which terminates processing of the three data sets and returns
the three data control blocks to their original status.
End-of-Volume Processing
Control is passed automatically to the data management
routine when any of the following conditions is detected:
•
•
•
•
•
end-of-volume
End-of-data indicator (input volume).
Tape mark (input tape volume).
File mark (input direct-access volume).
End of reel (output tape volume).
End of extent (output direct-access volume).
You may issue a force end-of-volume (FEOV) macro-instruction before the
end-of-volume condition is detected.
The end-of-volume routine checks or creates standard trailer labels,
if the LABEL parameter of the associated DD statement indicates standard
labels. Control is then passed to the appropriate user label routine if
it is specified in your exit list.
Multiple volume data sets can be specified in your DD statement
whereby automatic volume switching is accomplished by the end-of-volume
routine.
When an end-of-volume condition exists on an output data set,
additional space is allocated as indicated in your DD statement. If no
more volumes are specified or if more are required than specified, the
storage is obtained from any available volume of the same device type.
If no device is available, your job is terminated.
FEOV -- Force End of Volume
The FEOV macro-instruction directs the operating system to initiate
end-of-volume processing before the physical end of the current volume
is reached.
If another volume has been specified for the data set,
volume switching takes place automatically.
The FEOV macro-instruction can only
sequentially, i.e., BSAM and QSAM.
be
used
when
processing
data
BUFFER ACQUISITION AND CONTROL
The buffering facilities of the operating system provide several
methods of acquisition and control. Each tuffer,
i.e., main storage
area used for intermediate storage of input/output data"
usually
corresponds in length to the size of a block in the data set being
78
.
processed.
When using the queued access technique, any reference to a
buffer actually refers to the next record, i.e., buffer segment.
You can assign more than one buffer to a data set by associating the
buffer with a buffer pool. A buffer pool must be constructed in a main
storage area allocated for a given number of buffers of a given length.
Buffer segments and buffers within the buffer pool are controlled
automa·tically by the system when the queued access technique is us ed.
Howeve:r, you can terminate processing of a buffer by issuing a release
(RELSE) macro-instruction for input or a truncate (TRUNC) macroinstruction for output. Two buffering techniques, simple and exchange,
can be used to process a sequential data set. Only simple buffering can
be used to process an indexed sequential data set.
If you use the basic access technique, you can use buffers as work
areas Jl:'ather than as intermediate storage areas. They can be controlled
either directly by using the GETBUF/FREEBUF macro-instruction, or
dynamically
by
requesting dynamic buffering in your DCB macroinstruction and your READ/WRITE macro-instruction.
If you request
dynamic buffering, the system will automatically provide a buffer each
time a READ macro-instruction is issued. That buffer will be freed when
you issue a WRITE or FREEDBUF macro-instruction.
BUFFER POOL CONSTRUCTION
Buffer pool construction can be accomplished in any of three ways:
• Staticallyus~ng the BUILD macro-instruction.
• Explicitly us~ng the GETPOOL macro-instruction.
• Au1:omatically by the system when the data set is opened.
If the BUILD macro-instruction or dynamic buffer control is used, the
buffers are automatically returned to the pool when the data set is
closed.
If the buffer pool is constructed explicitly or automatically,
the main storage area must be returned to the system by using the
FREEPOOL macro-instruction.
In many applications, single- or double-word alignment of a block
within a buffer is important. You can specify in the data control block
that buffers are to start on eith~~ a double-word or a full-word
boundary that is not also a double-word boundary (BFALN=D or F).
If
double-word alignment is specified for format V records, the fifth byte
of the first record in the block is so aligned. For that reason~
full-word alignment must be requested to align the first byte of the
variable-length record on a double-word boundary. The alignment of the
records following the first in the block depends on the length of the
previous record.
If the BUILD macro-instruction is used to construct the buffer pool,
alignment depends on the alignment of the first byte of the reserved
storage area.
~UILD
-- Construct a Buffer Pool
When you know, prior to program assembly, both the number and size of
the buffers required for a given data set, you can reserve an area of
appropriate size to be used as a buffer pool. Any type of area can be
used
a predefined storage area, or an area of coding no longer
needed, for example.
A BUILD macro-instruction, issued during execution of
:structures the reserved storage area into a buffer pool.
Section II:
Data Management Services
your program,
The address of
(Part 2)
79
the buffer pool must be the same as that specified as the buffer pool
control block (BUFCB) in your data control block.
The buffer pool
control block is an 8-byte field preceding the buffers in the buffer
pool. The number (BUFNO) and length (BUFL) of the buffers must also be
specified.
When the data set using the buffer pool is closed, you can reuse the
area as required. You can also reissue the BUILD macro-instruction to
reconstruct the area into a new buffer pool to be used by another data
set.
You can assign the buffer pool to two or more data sets that require
buffers of the same length.
To do this, you must construct an area
large enough to accommodate the total number of buffers required at any
one time during execution. That is, if each of two data sets requires
five buffers (BUFNO=S), the BUILD macro-instruction should specify ten
buffers.
The area must also be large enough to contain the 8-byte
buffer pool control block.
GETPOOL -- Get a Buffer pool
If a specified area is not reserved for use as a buffer pool, or you
want to defer specifying the number and length of the buffers until
execution of your program, you should use the GET POOL macro-instruction.
This facility enables you to vary the size and number of buffers
according to the needs of the data set being processed.
The GETPOOL macro-instruction structures a main
storage
area
allocated by the system into a buffer pool, assigns a buffer pool
control block, and associates the pool with a specific data set.
The
GETPOOL macro-instruction should be issued either before opening the
data se't or during your DCB exit routine.
Automatic Buffer Pool Construction
If you have requested a buffer pool and have not used an appropriate
macro-instruction by the end of your DCB exit routine, the system
automatically allocates main storage space for a buffer pool.
The
buffer pool control block is also assigned and the pool is associated
with a specific data set. If you are using the basic access technique
to process an indexed sequential or direct data set, you must indicate
dynamic buffer control. Otherwise, the system does not construct the
buffer pool automatically.
FREEPOOL -- Free a Buffer Pool
Any buffer pool assigned to a data set either automatically by the
OPEN macro-instruction (except when dynamic buffer control is used) or
explicitly by the GET POOL macro-instruction must be released before your
program is terminated. The FREEPOOL macro-instruction should be issued
to release the main storage area as soon as the buffers are no longer
needed.
As a general rule, when you are using the queued access
technique, an output data set should be closed first to ensure that all
the records have been written out.
However, when using exchange
buffering or when processing an indexed sequential data set using the
queued access technique, the buffer pool must not be released until all
the data sets have been closed.
--constructing a Buffer Pool: The following examples illustrate several
possible methods of constructing a buffer pool. The examples do not
consider the method of processing or controlling the buffers in the
pool.
80
•
.~
INPOOL,10,50
CLOSE
( INDCB , " OUTDCB)
RETURN
DCB
DCB
CNOP
DS
Processing
Return to System Control
BUFN0=5,BUFCB=INPOOL,EODAD=ENDJOB,--BUFNO=5,BUFCB=INPOOL,--0,8
Force boundary alignment
CL508
Buffer pool
(INDCB,~OUTDtB,
(OUTPUT»
Processing
ENDJOB
INDCB
OUTDCB
..
Processing
Structure a buffer pool
BUILD
OPEN
INPOOL
In the first example, a static storage area named INPOOL is allocated
during program assembly.
The BUILD macro-instruction, issued during
execution, arranges the buffer pool into ten buffers, each 50 bytes
long.
Five buffers are assigned to INDCB and five to OUTDCB, as
specifi.ed in the DCB macro-instruction for each.
The two data sets
share the buffer pool because both specify INPOOL as the buffer pool
control block9
Notice that an additional eight bytes have been
.allocated for the buffer pool to contain the buffer pool control block.
:E;NDJOB
INDCB
OUTDCB
GETPOOL
GET POOL
OPEN
INDCB,10,50
Construct a 10-buffer pool
OUTDCB,5,108
Construct a 5-buffer pool
(INDCB, " OUTDCB, (OUTPUT) )
CLOSE
FREE POOL
FREEPOOL
(INDCB"OUTDCBJi
INDCB
OUTDCB
RETURN
DCB
DeB
Release buffer pools after all
I/O is complete
Return to System Control
DSORG=PS,BFALN=F,LRECL=50,RECFM=F,EODAD=ENDJOB,--DSORG=IS,BFALN=D,LRECL=50,KEYLEN=10,BLKSIZE=100,
RKP=O,RECFM=FB,---
C
In the second example~ two buffer pools are constructed explicitly by
the GET POOL macro-instructions. Ten input buffers are provided, each 50
bytes long, to contain one fixed-length record; five output buffers,
each 108 bytes long, to contain two blocked records plus an 8-byte count
jEield.
Notice that both data sets are closed before the buffer pools
are relleased by the FREEPOOL macro-instructions.
The same procedure
should be used if the buffer pools were constructed automatically by the
OPEN macro-instruction.
BUFFER CONTROL
There are four techniques that can be used to control the buffers
used by your program. The advantages of each depend to a great extent
upon the type of job you are doing. Both simple and exchange buffering
clre provided for the queued access technique.
The basic access
t:echniqlle provides for either direct or dynamic buffer control.
Although only simple buffering can be used to process an indexed
sequential data set" buffer segments and buffers within a buffer pool
are controlled automatically by the operating system.
In addition, the queued access technique provides three processing
modes that determine the extent of data movement in main storage.
I,ocate, move, or substitute mode processing can be specified for either
t~he GET or
PUT macro-instructions.
The buffer processing mode is
s:pecifiHd in the MACRF field of the DeB macro-instruction. The movement
of a record is determined as follows:
Section II:
Data Management Services
(Part 2)
81
• Move mode: The record is moved from an input buffer to your work
area, or from your work area to an output buffer.
• Locate mode: The record is not moved. Instead, the address
next input or output buffer is placed in register 1.
of
the
• Substitute mode: The record is not moved.
Instead, the address of
the next input or output buffer is interchanged with the address of
your work area.
..
Two processing modes of the'PUTX macro-instruction can be used in
conjunction with a GET-locate macro-instruction.
The update mode
returns an updated record to the data set from which it was read; the
output mode transfers an updated record to an output data set. There is
no actual movement of data in main storage. The processing mode must be
specified in the MACRF parameter of the DCB macro-instruction.
If you use the
of two ways:
basi~
access technique, you can control buffers in one
• Directly using the GETBUF macro-instruction to retrieve a buffer
constructed as described above. A buffer can then be returned to
the pool using the FREEBUF macro-instruction.
• Dynamically by requesting a dynamic buffer in your READ/WRITE
macro-instruction. Dynamic buffering can only be used when updating
or adding blocks to an indexed sequential or direct organization
data set. A dynamic buffer is allocated from main storage, not from
a buffer pool. It can be released by a WRITE macro-instruction when
you are updating. Otherwise, you must use the FREEDBUF macroinstruction.
Simple Buffering
The term "simple" buffering refers to the relationship of segments
within the buffer. All segments in a simple buffer are contiguous in
main storage and are always associated with the same dat~ set. When the
buffer pool is constructed, the system creates a channel command word
(CCW) for each buffer in the buffer pool. For this reason, each record
must be physically moved from an input buffer segment to an output
buffer segment. It can be processed within either segment or in a work
area.
If you use simple buffering, records of any format can be processed.
New records can be inserted and old records deleted as required to
create a new data set. Records can be moved and processed as follows:
• Processed in an input buffer and then moved to an output buffer
(GET-locate, PUT-move/PUTX-output).
• Moved from an input buffer to an output
processed (GET-move, PUT-locate).
buffer
where
it
can
be
• Moved from an input buffer to a work area where i t can be processed
and then moved to an output buffer (GET-mOve, PUT-move).
• Processed
in an input buffer
(GET-locate, PUTX-update).
and
returned
to
the
data
set
The following examples illustrate the control of simple buffers and
the processing modes that can be used. The buffer pools may have been
constructed in any way previously described.
82
2
,Simple Buffering -- GET-locate, PUT-move/PUTX-output:
The GET macroinstruction (step A) locates the next input record to be processed.
Its
address is returned in register 1 by the system. The address is passed
to the PUT macro-instruction in register o.
The PUT macro-instruction (step B) specifies the address of the
record in register O.
The system then moves the record to the next
output buffer.
•
,Note: The PUTX-output macro-instruction can be used in place of the
PUT-move macro-instruction.
However, processing will be as described
under exchange buffering (see PUT·-substitute).
•
GET
OUTPUT
OUTPUT
I
NEXTREC GET
INDCB
OUTDCB
B.
LR
PUT
B
DCB
DCB
INDCB
0,1
OUTDCB, (0)
NEXTREC
MACRF=(GL),--MACRF=(PM),---
Simple Buffering -- GET-move, PUT-locate:
The PUT macro-instruction
(step A) locates the address of the next available output buffer. Its
address is returned in register 1 and is passed to the GET macroinstruc:tion in register o.
The GET macro-instruction (step B) specifies the address of the
output buffer into which the system moves the next input record.
Processing can be done either before or after the move operation.
A
filled output buffer
instruction is issued.
is
n0i;:
written until the next PUT macro-
PUT
/
A
I
OUTPUT
NEXTREC PUT
LR
GET
B
INDCB
OUTDCB
B.
DCB
DCB
OUTDCB
0,1
INDCB,(O)
NEXTREC
MACRF=(GM),--MACRF=(PL),---
Simple Buffering -- GET-move, PUT-move: The GET macro-instruction (step
A) specifies the address of a work area into which the system moves the
next record from the input buffer.
The PUT macro-instruction (step B) specifies the address of a work
area from which the system moves the record into the next output buffer.
Section II:
Data Management Services
(Part 2)
83
GET
I
A.
~
OUTPUT
OUTPUT
NEXTREC
GET INDCB,WORKAREA
PUT
B
WORKAREA DS
INDCB
DCB
OUTDCB
DCB
PUT
OUTDCB,WORKAREA
NEXTREC
CL50
MACRF=(GM),--MACRF=(PM),---
Simple Buffering -- GET-locate, PUT-locate: The PUT macro-instruction
(step A)
locates the address of the next available output buffer. The
address is returned in register 1.
The GET macro-instruction (step B) locates the address of the next
input buffer.
Its address is returned in register 1. You must then
move the record from the input buffer to the output buffer.
Processing
can be done either before or after the move operation.
A filled output buffer
instruction is issued.
is
not
written until the next PUT macro-
Note:
If records other than format Fare teing moved, the length
attribute of the MVC instruction must be changed as shown. If the
record is more than 256 bytes, you will have to code a move routine to
process the complete record.
NEXTREC
PUT
A.
GET
PUT OUTDCB
LR 6,1
GET INDCB
LR 7,1
See Note USING IHADCB,5
5,INDCB
LA
LH 4,DCBLRECL
EX 4,MOVREC
B.
MOVEREC
INDCB
OUTDCB
B
NEXTREC
MVC 0(1,6),0(,7)
DCB MACRF=(GL),--DCB MACRF=(PL),--DCBD DSORG=(LR)
Exchange Buffering
The term "exchange" buffering refers to the relationship of segments
within a buffer. All the segments in an exchange buffer are not
necessarily contiguous in main storage, nor are they always associated
with the same data set. When the buffer pool is constructed, the system
creates a channel command word (CCW) for each buffer segment in the
buffer.
This facility makes it possible to "exchange" the CCws of
different storage locations.
To use exchange buffering, you must provide a work area comparable in
size and alignment to a buffer segment. That work area is substituted
84
for the next buffer segment. That is, the storage areas change roles.
The CCW created for the buffer segment actually points to the work area.
Why use exchange buffering? Because there is no need to move the
record.
This means a considerable savings in processing time. On the
other hand, exchange buffering is of no advantage unless substitute mode
or PUTX-output mode is used.
The implementation of exchange buffering
program depends on a number of factors:
•
•
•
•
during
execution
of
your
Input and output buffers must be of the same size and alignment.
Records must be unblocked or blocked format F.
Track overflow cannot be used with tlocked format F records.
GET-move and PUT-locate modes cannot be used.
If you request exchange buffering, but it cannot be implemented, the
system automatically provides simple buffering. Move mode processing is
used in place of substitute mode.
If your records are blocked format F, each segment is aligned as
specified in the DCBBFALN field.
Therefore, your buffer
length
(DCBBUFL) must be large enough to contain segments that are a multiple
of 16 bytes. otherwise, the specified boundary alignment cannot be
achievE~d;
simple buffering is used and only the first byte in the first
record is aligned as specified.
There are two possible error conditions that cannot be pre checked
the system:
by
.. Word alignment that does not correspond to the characteristics of
the machine. If~ for example, you expect to process your data on a
model 65 or 75, your record length should be a multiple of 16; on a
model 50, a multiple of 8; on a model 40, a multiple of 4. No error
will result if the records are processed on a smaller system.
• An I/O device that transfers the data
exchange the addresses in the CCW.
faster
than
the
CPU
can
The following examples illustrate the control of exchange buffers and
the corresponding processing modes that can be used. The buffer pools
may have been constructed in any way previously described.
,Exchanqe Euffering -- GET-substitute, PUT-substitute:
The GET macroinstruction (step A) specifies the address of a work area. The work
area address is exchanged for the address of the next input record
returned in register 1. After processingl, the address of the record is
passed to the PUT macro-instruction.
The PUT macro-instruction (step B) specifies the address of the
output record.
The output record address is exchanged for the address
of the next output buffer available for use as a work area.
The work
area address, returned in register 1, is passed to the GET macroinstruction (step C) in register 6.
Notice that as the areas are exchanged there is no movement of data.
Output records are contained in the original input area and vice versa,
but are logically associated with the correct data set.
section II:
Data Management Services
(Part 2)
85
GET
OUTPUT
A
I
OUTPUT
I
~;
NEXTREC
PUT
PUT
LR
B
WORKAREA DS
INDCB
DCB
OUTDCB
DCB
B.
~
c.
LA
LR
GET
LR
6,WORKAREA
0,6
INDCB, (0)
0,1
OUTDCB, (0)
6,1
NEXTREC
CL50
MACRF=(GT),--MACRF=(PT),---
Exchange
Buffering
GET-locate, PUTX-output:
The GET macroinstruction (step A) locates the address of the next input record.
The
address is returned in register 1. The record must be processed in the
buffer segment-before the PUTX macro-instruction (step B) is issued.
The PUT X macro-instruction specifies the address of both the input and
output data control block.
The two buffer segments are exchanged
without any movement of data.
The GET macro-instruction (step C)
locates the next record to be processed.
Notice that the DCB macro-instruction
specifies move mode; this is required.
for
the
output
data
set
GET
A
-EilltttEa
OUT PUT
OUT PUT
NEXTREC
GET INDCB
INDCB
OUTDCB
PUTX OUTDCB,INDCB
B
NEXTREC
DCB MACRF=(GL),--DCB MACRF=(PM),---
B.
GET
c
INPUT
OUTPUT
Exchange Buffering
GET-locate, PUT-substitute:
The GET macroinstruction (step A) locates the next input record.
Its address is
returned in register 1. You must then move the record to a work area.
processing can be done either before or after the move operation.
The PUT macro-instruction (step B) specifies the address of the work
area containing the next output record. The system returns the address
of the next output buffer available for use as a work area in register
1.
That address is passed to the move (MVC) instruction in register 6.
The GET macro-instruction (step C) locates the next input record.
You must then move the record to the new work area. Notice that the
previous work area has become a part of the output buffer (step C).
86
..
Note: If records other than format F are being moved, the length
attribute of the MVC instruction must be changed as shown. If the
record is more than 256 bytes long, you must code a move routine to
process the complete record.
GET
LA
6,WORKAREA
GET INDCB
LR
7,1
See Note USING IHADCB,5
LA
5,INDCB
LH
4,DCBLRECL
EX
4, MOVEREC
NEXTREC
A
.,
B.~
OUTDCB, (6)
6,1
B
NEXTREC
MOVEREC MVC 0(1,6),0(,7)
WORKAREA DS
CL50
INDCB
DCB MACRF=(GL),--DCB MACRF=(PT),--OUTDCB
DCBD DSORG=(LR)
PUT
LR
GET
c.
Techniques and GET/PUT Processing Modes: As you can see from
·the previous examples, the most efficient coding is achieved by using
;automatic buffer pool construction, and GET-locate and PUTX-output ·with
either
simple
or
exchange buffering.
Table 10 summarizes the
combinations of buffering techniques and processing modes that can be
used.
Notice, for example, that if you use PUT-locate and GETsubstitute, you must provide a work area and you must also move the
:cecord from the work area to the output buffer.
~Bufferin9
~rable
10.
Buffering Technique and GET/PUT Processing Modes
~
I
I-
Simple
I GET-move
Buffering ~--------------I GET-locate
-
I
I-
----------+-------------------+---------I
I----------+------------------------+-------------------+---------Exchange I GET-locate
-,
I
Buffering ~--------------- ----------+---------- ----------+---------I GET-substitute
-,
•
-I
•
i
I
Program must move record
~-------------------------System moves record
-
••
-j
i
- -
----------+-------------------+---------I- - • _. - - -I-----------------------------------+-------------------+---------Record is not moved
I
I -----_._----------------------------+-------------------+---------Work area required
-1-· ----------+----------I- - - r-----------------------------------+---------PUTX-output can be used
I
- - I
~.
.
!:tELSE -_. Release an Input Buffer
When using the queued access technique to process a sequential or
inclexed sequential d~ta set, you can direct the system to ignore the
rema~n~ng
records ~n the input buffer being processed. The next GET
macro-instruction retrieves a record from another buffer.
Section II:
Data Management Services
(Part 2)
87
If you are using move mode, the buffer is made available for
refilling as soon as the RELSE macro-instruction is issued. When used
with locate mode, the system does not refill the buffer until the next
GET macro-instruction is issued.
If a PUTX macro-instruction has been
used, the block is written before the buffer is refilled.
TRUNC -- Truncate an Output Buffer
When using the queued access technique to process a sequential data
set, you can direct the system to write a short block. The first record
in the next buffer is the next record processed by a PUT/PUTX-output
mode.
If the locate mode is being used, the system assumes that a record
has been placed in the buffer segment pointed to by the last PUT
macro-instruction.
The last block of a data set is truncated by the close routine.
Note: A data set containing format F records with truncated blocks
cannot be read from direct-access storage as efficiently as st.andard
format F data sets.
GETBUF -- Get a Buffer From a Pool
The GETBUF macro-instruction can be used with the basic access
technique to request a buffer from a tuffer pool constructed by the
BUILD, GETPOOL, or OPEN macro-instructions. The address of the next
buffer is returned by the system in a register specified by you when the
macro-instruction is issued.
If no buffer is available, the register
contains zeros instead of an address.
FREEBUF -- Return a Buffer to a Pool
The FREEBUF macro-instruction is used with the basic access technique
to return a buffer to the buffer pool from which i.t was obtained by a
GETBUF macro-instruction. Although the tuffers need not be returned in
the order in which they were obtained, they must be returned when they
are no longer needed.
FREEDBUF -- Return a Dynamic Buffer to a Pool
Any buffer obtained using the dynamic buffer option must be released
before it can be used again. If you do not update the block in the
buffer and thus free the buffer when the block is written, the FREEDBUF
macro-instruction must be used.
To effect the release, you must specify the address of the DECB that
was created when the block was read using the dynamic buffering option,
as well as the address of the data control block associated with the
data set being processed.
PROCESSING A SEQUENTIAL DATA SET
Data sets residing on all volumes other than direct-access must be
processed sequentially. In addition, a data set residing on a directaccess volume~
regardless
of
organization,
can
be
processed
sequentially.
This feature of the operating system allows you to write
your program with little regard for the type of device to be used when
the program is executed. Natur.ally, there are restrictions against the
use
of certain device-dependent macro-instructions and processing
options.
88
•
Either the queued or basic access technique may be used to store and
retrieve the records of a sequential data set.
Additionally, a
technique called chained scheduling can 1:e used to accelerate the
input/output operations required for a sequential data set.
DATA FORMAT -- DEVICE TYPE CONSIDERATIONS
Both the record format (RECFM) and device-dependent (DEVD) information must be provided to the operating system prior to execution of your
program. This information can be supplied by a DCB macro-instruction, a
DD stat:ement, or a data set label. The DCB subparameters for the DD
statement differ slightly from those described here.
A complete
description of the DD statement and a glossary of DCB subparameters is
contained in the publication JBM System/360 Operating System: Job
,~ontrol
Languag~,.
The record format (RECFM) parameter of the DCB macro-instruction
specifies the characteristics of the records in the data set as fixed
length (F), variable length (V), or undefined length (U). Fixed-length,
blocked records (FB) can be specified as standard (FBS), i.e., there are
no truncated (short) blocks or unfilled tracks within the data set, with
the possible exception of the last block or track.
If the data set
resides on a direct-access volume, the track overflow feature ('1') can 1:e
specified for the basic access technique.
As an optional feature, a control character can be contained in each
record. This control character will be recognized and processed if the
data set is printed or punched. The control characters are transmitted
on both tapes and direct-access devices.
The presence of a control
character is indicated in the RECFM field of the data control block.
Two options are available: machine code (M) or extended ASA code (A).
If either is specified, the character must be present in every record;
the printer space (PRTSP) or stacker select (STACK) field of the data
control block is ignored. The optional control character must be in the
first byte of format F or U records and in the fifth byte of format V
records. Control character codes are listed in Appendix B: Control
Characters and SYSOUT Writer.
The device-dependent (DEVD) parameter of the DCB macro-instruction
specifies the type of device on which the data set's volume resides:
TA
PT
PR
PC
RD
DA
-
]~agnetic
magnetic tape
paper tape reader
printer
card punch
card reader
direct-access
Tape (TA)
Format F, V, or U records are acceptable for magnetic tape. However,
if the data conversion feature 1 is net available, format V records are
]{lot acceptable on 7-track tape. Data blocks should be at least 15 bytes
long.
',;
Tape density (DEN) specifies the recording density in bits per inch
a.s shown in Table 11. If this information is not supplied, the lowest
density is assumed.
!LData conversion makes it possible to write eight binary bits of data on
seven t:racks. Otherwise, only six bits of an 8-bit byte are recorded.
~rhe
length field of format V records contains binary data and is not
recorded correctly without data conversion.
Section II:
Data Management Services
(Part 2)
89
Table 11.
Tape Density (DEN) Values
r------------------------T---------------------------------------------,
I
Recording Density
I
I
I
I
I
DEN Value
I
Model 2400
I
~----------------------T----------------------~
I
7-Track
I
9-Track
I
.------------------------+----------------------+----------------------i
I
0
I
200
I
I
I
1
I
556
I
I
IL ________________________
2
I ______________________
800
I ______________________
800
JI
~
The track
specified as:
recording
~
technique
(TRTCH)
for
7-track
tape
can be
C - data conversion is -to be used.
E - even parity is to be used; if omitted, odd parity is assumed.
T - BCDIC to EBCDIC translation is required.
Paper Tape Reader (PT)
The paper tape reader accepts format F or U records. Each format U
record is followed by an end-of-record character. Data read from paper
tape is optionally converted into the System/360 internal representation
of one of six standard paper tape codes. Any character found to have a
parity error will not be converted when the reco.rd is transferred into
the input area. Characters deleted in the conversion process are not
counted in determining the block size.
The following symbols indicate the code in which
punched.
If this information is omitted, I is assumed.
the data was
I - IBM BCD perforated tape and transmission code (8 tracks).
F - Friden (8 tracks).
B - Burroughs (7 tracks).
~ - National Cash Register (8 tracks).
A - ASCII (8 tracks).
T - Teletype (5 tracks).
N - no conversion.
Card Reader and Punch (RD/PC)
Format F, V, or U records are acceptable to both the reader and
punch.
The device control character, if specified in the RECFM
parameter, is used to select the stacker; it is not punched. The first
four bytes of format V records (record control data) are not punched.
Each punched card corresponds to one logical record. Therefore, you
should restrict the maximum record size to 80 (EBCDIC mode) and 160
(column binary mode) data bytes. You can specify the read/punch mode of
operation (MODE) as either card image (column binary) Inode (C) or EBCDIC
mode (E).
If this information is omitted, E is assumed.
Stacker selection (STACK) can be specified as either 1 or 2 to
inQicate which bin is to receive the card. If it is not specified, 1 is
assumed.
Note: When QSAM is used, punch error correction on the IBM 2540 Card
Read Punch is automatically performed only for data sets using three or
more buffers.
90
•
Printe:r (PR)
Records of format F, V, or U are acceptable to the printer.
The
first four bytes (record control data) .of format V records are not
printed. Th~ carriage control character, if specified in the RECFM
parameter, is not printed. However, the system does not position the
printer to channel 1 for the first record.
Because each line of print corresponds to one record, the
length should not exceed the length of one line on the printer.
record
If carriage control characters are not specified, you can indicate
printer spacing (PRTSP) as 0, 1, 2, or 3. If it is not specified, 1 is
assumed.
Direct Access (DA)
Direct-access devices accept records of format F, V, or U. If the
records are to be read or written with keys, the key length (KEYLEN)
must be specified.
In addition, the operating system has a standard
track format for all direct-access volumes. Each track contains data
information as well as certain "nondata". or control information such as:
•
•
•
•
The address of the track.
The address of each record.
The length of each record.
Gaps between areas.
A complete description of track format is contained in the section
"Direct:-Access Volume, Characteristics." Your only concern in creating a
sequential data set is to allow for an 8-byte track descriptor record
(capacity record or RO) when requesting space on a direct-access volume.
In addition,
"device overhead," which varies with the device, must be
allocated for each block on the track.
SEQUENTIAL DATA SETS -- DEVICE CONTROL
The operating system provides you with five macro-instructions for
controlling input/output devices. Each is, to varying degrees, devicedependent. Therefore, you must exercise some care if you wish to
achieve device independence.
When using the queued access technique, only unit record equipment
can be controlled directly. When using the basic access technique,
limited device independence can be achieved between magnetic tape and
direct-access devices. All read or write operations must be checked
before issuing a device control macro-instruction.
CNTRL -- Control an I/O Device
The CNTRL macro-instruction
control functions:
provides
a number of device-dependent
• Card reader stacker selection (SS).
• Printer line spacing (SP).
• Printer carriage control (SK).
• Magnetic tape backspace (BSR) over a specified number of blocks.
Section II:
Data Management Services
(Part 2)
91
• Magnetic tape backspace (BSM) past a tape
over the tape mark.
mark
and
forward
space
• Magnetic tape forward space (FSR) over a specified number of blocks.
• Magnetic tape forward space (FSM) past a tape mark and a backspace
over the tape mark.
Backspacing moves the tape toward the
moves the tape away from the load point.
load
point;
forward
spacing
PRTOV -- Test for Printer Overflow
The PRTOV macro-instruction tests for channel 9 or 12 of the printer
carriage control tape. An overflow condition will cause either an
automatic skip to channel 1 or~ if specified, transfer of control to
your routine for overflow processing.
If the data set specified in the data control block is not a printer,
no action is taken.
BSP -- Backspace a Magnetic Tape or Direct-Access Volume
The BSP macro-instruction backspaces one block on the magnetic tape
or direct-access volume being processed. The block can then be reread
or rewritten. An attempt to rewrite the block destroys the contents on
the remainder of the tape or track.
The direction of movement is toward the load point or beginning of
allocated area. You may not use the BSP macro-instruction if the track
overflow option was specified or if the CNTRL, NOTE, or POINT macroinstructions are used. The BSP macro-instruction should be used only
when other device control macro-instructions could not be used for
backspacing.
NOTE -- Return the Relative Address of a Block
The NOTE macro-instruction requests the relative address of the block
just read or written. The feedback identifies the block for subsequent
repositioning of the volume.
The feedback provided by the operating system is returned in general
register 1. The address is in the for~ of a 4-byte relative block
address for magnetic tape; for a direct-address device, it is a 4-byte
relative track address and amount of unused space available on the
track.
POINT -- Position to a Block
The POINT macro-instruction causes repositioning of a magnetic tape
or direct-access volume to a specified block in the data set. The next
read or write operation begins at this block.
SEQUENTIAL DATA SETS -- DEVICE INDEPENDENCE
Device independence is an important consideration when programming
the System/360. The ability to request input/output operations without
regard for the physical characteristics of the I/O devices makes it
possible for you to write one program that will fulfill a variety of
needs. Device independence may be useful for:
92
• Accepting data from a number of recording devices, e.g., 2311 disk
pack, 7- or 9-track magnetic tape, or unit record equipment.
This
situation could arise when several types of data acquisition devices
are feeding a centralized complex.
• Observing constraints imposed by the availability of input/output
devices, i.e., devices on order have not been installed.
• Assembling, testing, and debugging on one System/360 configuration
and processing on a different configuration, e.g., a 2311 directaccess device can be used as a substitute for several magnetic tape
units.
Device independence is clearly a valuable concepti one that is not
difficult to achieve, but which requires some planning and forethought.
There are two areas of planning necessary to achieve device independence
-- system generation considerations and programming considerations.
System Generation Considerations
The user of the operating system can provide for device independence
when the system is generated. This is achieved by generating a system
that meets not only the current input/output configuration requirements
but includes anticipated device attachments.
Creating such a system
entails looking ahead at expected delivery of input/output devices and,
during system generation, constructing in advance the necessary control
blocks and tables.
Thus, when the devices are delivered, they need only
be physically attached.
The operating system recognizes the devices
without, modification. During the interim, unconnected devices must be
placed off-line.
This is accomplished 'by a VARY command issued by the
operator. Effecting a smooth transition to new input/output devices
must not be construed to mean the inclusion of unsupported devices.
This
discussion
is
limited
to
add-on or substitution device
independence. When support for new devices is provided, a new system
'will have to be generated. A complete description of system generation
-techniques is contained in the publication IBM System/360 Operating
~System: System Generation.
programming Considerations
Each of the data set organizations -- partitioned, indexed sequential, and direct -- requires the use of a direct-access device.
Device
independence 1S meaningful, then, only in terms of a sequentially
organized data set. That is~ one block of data following another, thus
allowing input or output ·to be on magnetic tape, direct-access, card
read/punch, or printer.
Your program will be device independent if you do two things:
• Omit all device-dependent macro-instructions
parameters from your program.
or
macro-instruction
• Defer specifying any required device-dependent parameters until the
program is ready for execution. That is, supply the parameters on
your data definition (DD) statement.
~'
In examining the following list of macro-instructions,
the logical layout of your data record without regard for
device used.
Also, consider that any reference to a
"rolume is to be treated like magnetic tape, i. e., you must
data set rather than attempt to update.
Section II:
Data Management Services
consider only
the type of
direct-access
create a new
(Part 2)
93
OPEN
specify INPUT, OUTPUT, INOUT, or OUTIN.
UPDATE are device dependent and cause an
directed to a different device type.
The parameters RDBACK and
abnormal termination if
READ
specify forward reading only (SF).
WRITE
specify
forward writing only (SF); use only to create new records.
PUTX
•
use only output mode.
NOTE/POINT
valid for both magnetic tape and direct-access volumes.
BSP
valid for magnetic tape or direct-access volumes.
However, its use
would be an attempt to perform device-dependent action.
CNTRL/PRTOV
device dependent
DCB Subparameters
MACRF
specify R/W or G/P.
Processing mode can also be indicated.
DEVD
specify DA if any direct-access device is apt to be used. Magnetic
tape and unit record equipment data control blocks will fit in the
area provided during assembly. Specify unit record devices only if
you expect never to change to tape or direct-access devices. Key
length (KEYLEN) can be specified on the DD statement if necessary.
RECFM, LRECL, BLKSIZE
these can be specified in the DD statement. However~ you must
consider maximum record size for specific devices.
Also,
track
overflow cannot be specified unless supported.
DSORG
specify sequential (PS/PSU).
OPTCD
device dependent; specify in the DD statement.
SYNAD
any device-dependent error checking is automatic. Generalize your
routine so that no device-depend'ent information is required.
CHAINED SCHEDULING FOR I/O OPERATIONS
To accelerate the input/output operations required for a data set,
the operating system provides a technique called chained scheduling.
When requested, the system bypasses the normal I/O routines and
dynamically chains several input/output operations together. A series
of separate read or write operations, functioning with chained scheduling, is issued to the computing system as one continuous operation. The
program-controlled interruption (PCI) flag in the CCWs is used for
synchronization of the I/O operations.
94
•
The I/O performance is increased by reducing both the CPU time and
channel start/stop time required to transfer data between main and
secondary storage. The effects of rotational delay are also reduced
since several successive blocks, requested separately, can be retrieved
in a single rotation. Chained scheduling can be used only with simple
buffering. Each data set for which chained scheduling is specified must
be assigned at least two, and preferably three, buffers.
Chained scheduling is most valuable for programs that require
extensive input and output operations. Because a data set using chained
scheduling may monopolize available time on a channel, separate channels
should be assigned, if possible, when more than one data set is to be
processed.
CHEATING A SEQUENTIAL DATA SET
As discussed earlier, a processing program should be developed using
f,actors that are constant.
To provide for as much flexibility as
possible, variable factors should be specified at execution time. For
that reason, the following problem examples are generalized as much as
possible.
They are neither exhaustive nor intended as complete examples. Rather they are presented as introductory sequences.
Since the basic access technique for sequential processing is usually
uBed to create a partitioned data set or a direct data set, examples of
the READ/WRITE macro-instructions are deferred for discussion in those
alreas. There is no other reason, however, for them not to be used in
place of the queued access macro-instructions where automatic blocking
and anticipatory buffering are not required.
Tape-to-l?rint, Move Mode --
Simple Buffering:
In this problem the
two movements of the data records. If the
not change in processing" only one move is
nE:!cessary; you can process the record in the input buffer segment.
A
Gl~T locate can be used to provide a pointer to the current segment.
Gl~T-move and PUT-move require
r~:!cord
length (LRECL) does
NEXTREC
ENDJOB
OPEN
GET
AP
UNPK
PUT
B
CLOSE
COUNT
DS
WORKAREA DS
NUMBER
DC
INDATA
DCB
OUlTDATA
DCB
(INDATA" ,OUTDATA, (OUTPUT»
INDATA,WORKAREA
NUMBER,=P'l'
COUNT, NUMBER
OUT DATA" COUNT
NEXTREC
(INDATA,OUTDATA)
Move Mode
Record count adds 6
bytes to each record
CL6
CLSO
PL4'O'
DDNAME=INPUTDD,DSORG=PS,MACRF=(GM),BFTEK=S,
EODAD=ENDJOB
DDNAME=OUTPUTDD,DSORG=PS,MACRF=(PM),BFTEK=S
C
Ta,pe-to-Print, Locate Mode -- Simple Buffering: This problem is similar
to the previous one. However, since there is no change in the record
l€!ngth, the records can be processed in the input buffer. Only one move
of each data record is required.
Section II:
Data Management Services
(Part 2)
95
OPEN
GET
LR
AP
UNPK
PUT
MVC
ENDJOB
CLOSE
(INDATA"OUTDATA, (OUTPUT»
INDATA
2,1
NUMBER,=P'l'
0(6,2),NUMBER
OUT DATA
0(50,1) ,0(2)
NEXTREC
(INDATA" , OUTDATA)
NUMBER
INDATA
OUTDATA
DC
DCB
DCB
PL4'0'
DDNAME=INPUTDD,DSORG=PS,MACRF=(GL),EODAD=ENDJOB
DDNAME=OUTPUTDD,DSORG=PS,MACRF=(PL)
NEXTREC
B
Locate Mode
Save Pointer
Process in Input Area
Locate Mode
Output Pointer in 1
..
Tape-to-Print, substitute Mode
Exchange Buffering:
Although the
initial problem is the same, the solution described here takes advantage
of two facilities: exchange buffering~ which eliminates the need to move
the data record; and direct reference to individual fields within a
record through the use of a dummy control section (DSECT). The use of
the DSECT allows symbolic reference to be made for storage-to-storage
operations; therefore, the length attributes need not be explicitly
stated.
ENDJOB
OPEN
DSECT
DS
DS
DS
CSECT
USING
LA
GET
LR
AP
UNPK
PUT
LR
B
CLOSE
GIVEAWAY
NUMBER
INDATA
OUTDATA
DS
DC
DCB
DCB
MASKl
ALL
COUNT
RESTOFIT
SECTl
NEXTREC
(INDAT"OUTDATA, (OUTPUT»
CL50
CL6
CL44
MASK1,2
O,GIVEAWAY
INDATA, (0)
2,1
NUMBER,=P'l'
COUNT, NUMBER
OUTDATA, (2)
0,1
NEXTREC
(INDATA" , OUTDATA)
Establish address of DSECT
Set up for first buffer
Substitute Mode
Pointer to next record
Exchange work area
eL50
PL4'O'
DDNAME=INPUTDD,DSORG=PS,MACRF=(GT),EODAD=ENDJOB
DDNAME=OUTPUTDD,DSORG=PS,MACRF=(PT)
PROCESSING A PARTITIONED DATA SET
A partitioned data set is divided
made up of one or more records
unique name, one to eight characters
records of a given member are stored
into sequentially organized members
(see Figure 19). Each member has a
long, stored in a directory.
The
or retrieved sequentially.
The main advantage of using a partitioned data set is that you can
retrieve any individual member once the data set 1S opened.
For
example, a program library can be stored as a partitioned data set, each
member of which is a separate program or sutroutine. The individual
members can be added or deleted as required. When a member is deleted,
96
~
only ·the member name is removed from the directory; the space used by
the member cannot be reused until the data set is reorganized.
The directory, a series of records at the beginning of the data set,
contains an entry for each member. Each directory entry contains the
member name and the starting location of the member within the data set,
as shown in Figure 19. The directory entries are arranged in alphameric
collating sequence by name.
In addition, you can specify up to 62
charac1:ers of information in the entry.
•
The track address of each member is recorded by the system as a
relative track within the data set rather than as an absolute track
address.
Thus, an entire data set can be moved without changing the
relative track addresses.
The data set can be considered as one
continuous set of data tracks regardless of how the space was actually
allocat.ed. If there is not sufficient space available in the directory
for an additional entry, or not enough space available within the data
set for an additional member, no new members can be stored.
[) irectory
R.ecords
Entry for
Member A
Entry for
Member B
Enhy for
Member C
Space from
Deleted
Member
Available
Area
Figure 19.
A Partitioned Data Set
PARTITIONED DATA SET DIRECTORY
The directory of a partitioned data set occupies the beginning of the
area allocated to the data set on a direct-access volume.
It is
searched and maintained by the FIND and STOW macro-instructions. The
directory consists of variable-length records, arranged in ascending
order according to the binary value of the member name or alias.
The directory records are blocked into 256-byte blocks, each containing as many complete records as will fit in a maximum of 254 bytes. Any
r~emaining
bytes are left unused and ignored. Each directory block is
p:receded by a hardware-defined key field containing the name of the last
directory record in the block, i.e., the name with the highest binary
value.
Each directory block contains a 2-byte count field that
specifies the number of active record bytes in the block. The directory
block format is shown in Figure 20.
Section II:
Data Management Services
(Part 2)
97
Directory
Record 1
Directory
Record n
Directory
Record 2
EOD
--- --- ----- --- ----- --- ---- -- --
~------------------~-.~----------------~-----~--------------------~--~
Each Record
C
Key
I
I
8
Name of
Last Entry
in Record
Figure 20.
}J
Member
Entry A
Member
Entry N
Member
Entry B
I
2
\
l{~:~ ,:
Max 254
A Partitioned Data Set Directory Block
Each record in a directory block contains a member name or alias, the
relative track address of the member, and a count field"
as shown in
Figure 21.
It may also contain a user data field.
The last record in
the last directory block has a name field of maximum binary value
(all
ones) •
Optional User Data ----~
Member
Name
C
TTR
I
TTRN
~
TTRN
I
I
TTRN
'~-~~,~-----------------~----------------~
8
~
..............
0-31 ho I fwords
(Max 62 bytes)
....... ...... ......
...........
Pointer to
Fi rst Record
of Member
......
~
...... ......
...........
...........
...........
...... ......
...........
~
"1" If
Alias
Bits
Figure 21.
o
~
No. of
USN Data
Halfwords
No. of
User Data
TTRN's
3-7
1-2
A Partitioned Data Set Directory Entry
NAME
specifies the member name or alias.
alphameric characters, left-justified and
necessary.
I t contains up to eight
padded with blanks if
TTR
is a pointer to the first block of the member; TT is the relative
track from the beginning of the data set, and R is the relative
block number on that track.
98
+
c
specifies the number of halfwords contained in the user data field.
It may also contain additional information about the user data
field~ as shown below:
o
Bi,ts
1-2
3-7
r-T---T-----'
L_.1.
___ .1. _____
J
.
o
when set to 1, indicates that the NAME field contains an alias.
1-2 specifies the
member.
number
of
pointers
to
locations
within
the
A maximum of three pointers is allowed in the user data field.
Additional pointers may be contained in a record referred to as
a note list discussed below. The pointers are updated automatically if the data set is moved or copied by the IEHMOVE
utility program. The data set must be marked "unmovable" under
the following conditions:
• More than three pointers are used in the user data field.
• The pointers in the user data field or note list do not
conform to the standard format.
• The pointers are not placed first in the user data field.
• Any direct-access addresses (absolute or relative> are embedded in any data blocks or in another data set that refers to
this data set.
3-7 contains a binary value indicating the number of half-words of
user data. This number must include the space used by pointers
in the user data field.
The user data field contains variable user data provided as input to the
STOW macro-instruction. If pointers to locations within the member are
provided" they must be four bytes long and placed first in the user data
field.
The pointers must be arranged in ascending order by binary
value. The user data field format is as follows:
User Data
r----T----T----T--------,
ITTRNITTRNITTRNIOptional1
l ____ ____ .1.-___ .1. ________ J
~
TT
is the relative track address of the note list or area to which
you are pointing.
R
is the relative block number on that track.
N
is a binary value that indicates the number of additional
pointers contained in a note list pointed to by the TTR. If
the pointer is not to a note list, N=O.
A note list consists of additional pointers to blocks within the same
mE:!mber o:f a partitioned data set. If the existence of a note list was
indicated as shown above, the list is updated automatically when the
data set is moved or copied by the IEHMOVE utility program. Each 4-byte
entry in the note list has the following format:
r-....·--'
ITTRXI
L
_____ J
TT
is the relative track address of the
pointing.
Section II:
area
to
Data Management Services
which
you
are
(Part 2)
99
R
is the relative block number on that track.
x
is available for any use.
To place the note list in the partitioned data set, you must use the
WRITE macro-instruction. After checking the write operation, use the
NOTE macro-instruction to determine the address of the list and place
that address in the user data field of the directory entry.
+
PROCESSING A MEMBER OF A PARTITIONED DATA SET
Because a member of a partitioned data set is sequentially organized,
it is processed in the same manner as a sequential data set. Either the
basic or queued access technique can be used.
However, you cannot alter
the directory when using the queued technique.
In order to locate a member or to process the directory, several
macro-instructions are provided by the operating system. The BLDL
macro-instruction can be used to structure a list of directory entries
in main storage; the FIND macro-instruction locates a member of the data
set for subsequent processing; the STOW macro-instruction adds or
deletes
a
member name in the directory.
To use these macroinstructions, you must specify DSORG=PO or POU in the DCB macroinstruction.
BLDL -- Construct a Directory Entry List
The BLDL macro-instruction is used to place directory information in
main storage. The data is placed in a "build" list constructed by you
before the BLDL macro-instruction is issued. The format of the list is
similar to the directory. For each memcer name in the list, the system
supplies the address of the member and any additional information
contained in the directory entry.
You can optimize retrieval time by directing a subsequent FIND
macro-instruction to the build list rather than the directory to locate
the member to be processed.
The build list, as shown in Figure 22, must ce preceded by a 4-byte
list description that indicates the number of entries in the list and
the length of each entry (14 to 76 bytes). The first eight bytes of
each entry contain the member name or alias. The next six bytes must be
available to contain the starting address of the member plus some
control data.
If additional information is to be supplied from the
directory, up to 62 bytes can be reserved.
FIND -- Position to a Member
To determine the starting address of a specific member you must issue
a FIND macro-instruction.
If you want to find only one member, the
function is performed automatically when you specify the data set name
and member name in the related DD statement. The system places the
correct address in the data control block so that a subsequent GET/READ
macro-instruction will begin processing at that point.
There are two ways in which the system can be directed to the desired
member: you can specify the address of either an area containing the
name of the member or an entry in a build list you have created.
In the
first case, the system searches the directory of the data set.
If a
build list is used, no search is required; the relative track address is
determined from the list entry.
100
44
(Each Entry Starts on Half-Word Boundary)
List
Description
FFLL
Filled in by BLDL
J
"-
I
Member
Name (C)
TTR
(3)
K
(I)
Z
(I)
C
(I)
~
User
(C Half
Data
Words)
I
)
•
Programmer Suppl ies:
FF :;; Number of member entries in list
LL = Ev(~n no. giving byte length of each entry (minimum of 12)
Member name = eight bytes, left-adjusted
BLD L S uppl ies:
TTR = Member starting location
K = If only data set = 0
If concatenation = no.
Z
= Normally padding for boundary alignment
C = SClme C field from directory. Gives no. of user data
halfwords
User data: as much as will fit in entry
li'igure 22.
Build List Format
STOW -- Alter a Directory Entry
Unless you are adding members to a partitioned data set one at a
you must issue a STOW macro-instruction to enter the member name
J.n the directory.
When adding a single member, the STOW function is
performed automatically when the data set is closed.
~,ime,
You can also use the STOW macro-instruction to delete, replace, or
change a name in the directory, as well as store additional information
with the directory entry. Since an alias can also be stored in the
directory lon -the same way, you should 1:::e consistent in altering all
names associated with a given member. For example, if you replace a
member, you must delete related aliases or change them so that they
point to the new member.
CREATING A PARTITIONED DATA SET
If you have no need to add entries to the directory, i.e., the STOW
and BLDL macro-instructions will not be used, you can create a new data
set and write the first member as follows:
• Code DSORG=PS or PSU in the DCB macro-instruction.
• Indicate in the DO statement that the data is to be stored as a
member of a new partitioned data set, i.e., DSNAME=name(mernbername)
and DISP=NEW.
• Request space for the member and the directory in the DD
statement.
• Process the member with an OPEN macro-instruction, a series of
PUT/'WRITE macro-instructions, and then a CLOSE macro-instruction. A
STOW macro-instruction is issued automatically when the data set is
closed.
Section II:
Data Management Services
(Part 2)
101
As a result of these steps, the data set and its directory are
created, the records of the member are written, and an entry is made in
the directory.
To add additional members to the data set, follow the.same procedure.
However, a separate DD statement (with the space request omitted) is
required for each member.
The disposition should be specified as
modify:, DISP=MOD. The data set must be closed and reopened each time a
new member is specified.
//PDSDD
DD
OUTDCB
DCB
.
---,DSNAME=MASTFILE(MEMBERK),SPACE=(TRK,(100,5,7», C
DISP=(NEW,KEEP)
---,DSORG=PS,DDNAME=DDSDD,---
OPEN
PUT
CLOSE
(OUTDCB,NTM
Ml:;a= ( (M1 /NTM) +1) /It
when M1 >NTM
M3 =«M:;a/NTM)+1)/It
when M:;a>NTM
+1
Example:. Assume that your cylinder index will require 22 tracks. since
large keys are used, only 10 entries will fit on a track. Assuming that
NTM was specified as 2 1, 2 tracks will be required for a master index,
and only one level of master index will be created.
M~
= (22/2+1)/10 = 12/10 = 1.2
Step 8
You will want to anticipate the number of overflow tracks required.
The computations formula is the same as for prime data tracks, but you
must remember that overflow records are unblocked and a 10-byte link
field is added. Remember, if you exceed the space allocated for any
cylindeI." overflow area, an independent overflow area is required. Those
records are not placed in another cylinder overflow area.
Overflow records = 1+
per track
Track
Length of
capacity - last overflow record
Length of other
overflow records except the last
Ot = 1+«Tc-R1)/Ri)
Example:
Approximately 500 overflow records are expected for the data
set described in step 1. Since 29 overflow records will fit on a track,
18 overflow tracks are required. It would probably be best to allocate
2 tracks per cylinder for cylinder overflow.
..
•
ot =1+
3625-(20+12+10+20) =1+ = 3563
81+1Q049(12+10+20)
123
=
29
29 overflow records per track •
Summary: Indexed sequential Space Requirement Calculations
1.
How many records (blocks) will fit on a track?
Bt
=.
1 + «Tc-B1)/Bi)
section II:
Data Management Services
(Part 3)
127
2.
How many index entries will fit on a track?
It
3.
+ «Tc-E1)/Ei)
How many track index tracks are needed per cylinder?
Ti
4.
=1
=
(2Ct+1)/(It+2)
How many tracks on each cylinder can be used for prime data records?
Pc
=
ct - ot - It
it
5.
How many cylinders are needed for the prime data area?
c = --1
Pc
6.
How much space is required for the cylinder index?
Ci
7.
(C+1)/It
How much space is required for master indexes?
M
8.
=
=
«Ci/NTM)+l)/It
How many overflow tracks are required?
ot
=
1 + «Tc-B1)/Bi)
CONTROL AND DISPOSITION OF DATA SETS
There are two levels of status and disposition of the data sets you
use for your processing. The status and disposition information must be
provided to the system in the disposition field of the DD statement,
DISP=(status,disposition). The first level deals with the status of the
data set when you begin processing and the relationship of the data set
to other job steps in your job or other jobs.
The second deals with
what is to be done with the data set when you have completed processing.
It is at this level of control and disposition that you can take
advantage of the cataloging facilities of the operating system.
A data set that is being used for input has a status of OLD.
If it
can be used by more than one job, the status should be specified as SHR.
If you are going to add to the input data set, specify MOD. The system
automatically positions the access mechanism after the last record when
the data set is opened.
A NEW output data set should be so indicated.
Having identified the status of the data set at the beginning of your
job step, you should specify how you want it disposed of at the end of
processing.
If the disposition is to be unchanged, you need not specify
anything more. The status of an existing data set remains unchanged; a
new data set is deleted.
The requested disposition is performed at the end of the job step. A
data set to be used in a later job can be kept (KEEP) until a subsequent
request is made to DELETE it. If the data set is to be used by more
than one job step in the same job, you can specify that it is to be
passed (PASS).
The most useful disposition provided by the system is the cataloging
facility <
..
~
TM
EODI
EOD2
Unl
TM
EOVI
EOV2
UTLl
~
~
~
I-'
c::
a
CD
1:"1
$lJ
C'
CD
....
I-'
~
\0
i.--
TLn
TM
TM
-
TM
EODI
EOD2
Unl
TM
EODI
EOD2
TM
EOVI
EOV2
UTLl
UTLl
nn
8§ ~
nn
TM
TM
TM
TM
~
~
w
Figure 34.
Standard Label Formats for Magnetic Tape
Data Set C
Data Set B
Data Set B
o<
TM
~
UTLn
~
.
EE E§
TM
TM
TM
DIRECT-ACCESS LABELS
Only
standard label formats are used on direct-access volumes.
data set, and optional user labels are used (see Figure 35). In
the case of direct-access volumes, the data set label group is the data
set control block (DSCB).
Volume~
Volume Label Group
The volume label group immediately follows the initial program
loading (IPL) records on track 0 (of cylinder 0) of the volume.
It
consists of the initial volume label plus a maximum of seven additional
volume labels. The initial volume label identifies a volume and its
owner, and is used to verify that the correct volume is mounted. It can
also be used to prevent use of the volume by unauthorized programs. The
additional labels are processed by means of an installation routine that
is incorporated into the system.
The format of the direct-access volume label group is the same as the
format of the tape volume label group, except for Field 5 of the initial
volume label. See "Tape/Direct-Access Volume Labels Format~"
Cylinder
Volume Lobel
Additional Labels
(Optional) _
Tracks
Track 0
~
-
[
-
1
VTOC DSCB
Space Acctg DSCB
DSCB No.1
VTOC
-----
DSCB No.2
I
DSCB No. N
]
All Remaining Track of
Volume
Blank Storage Area
for Data Sets
Figure 35.
144
Direct-Access Labeling
Data Set: Control Block (DSCE) Group
The system automatically constructs a DSCB when space is requested
for a data set on a direct-access volume.
Each data set on a
direct-access volume has a corresponding data set control block to
describE~ its characteristics.
The DSCB appears in the volume table of
contents (VTOC) and contains the equivalent of the tape data set header
and trailer information, in addition to space allocation and other
control informa'tion.
User Label Group
If the LABEL parameter of the DD statement indicates that user labels
are to be used, and if you have requested space allocation in terms of
cylinders by using CYL, SPLIT, or ROUND, the data set is automatically
allocated one additional track for user labels. Otherwise, the first
. track allocated for the data set is reserved for user labels.
The
current minimum track size supports a maximum of eight 80-character user
labels (including both user header and trailer labels). consequently, a
program that creates more than eight user labels becomes devicedependent among direct-access devices. If device independence is not
desired, the program may create up to eight user header labels and eight
Ulser trailer labels, not to exceed one track. The processing and format
of these labels are the same as described for tape user labels •
...
Appendix A:
Volume Labeling
145
APPENDIX B:
CONTROL CHARACTERS AND SYSOUT WRITER
CONTRaIl CHARACTERS
As an optional feature, all record formats may include a control
character in each logical record.
This control charact~r will be
recognized and. processed if a data set is teing written to a printer or
punch.
For format-F and -U records this character is the first byte
logical record ..
of
the
For format-V records it must be the fifth byte of the logical record,
immediately following the logical record length field.
Two options are available. If either option is specified in the data
control block;., the character must appear in every record and other line
spacing or stacker selection options also specified in the data control
block are ignored.
MACHINl~
CODE
You can specify in the data control block that the machine code
control character has been placed in each logical record.
If the record
is to be written, the appropriate byte must contain the command code bit
configuration specifying both the write and the desired carriage or
stacker select operation. ·If the record is not to be written, the byte
can spE~cify any command other than write.
Command codes for specific devices are contained in IBM System
Reference Library publications describing the control units or devices.
EXTENDUD ASA CODE
You may choose to specify this code rather than
For punch operations, the record is always written.
the
machine
code.
The code is as follows:
Interpretation
b
o
+
1
2
34
5
6
7
8
9
A
B
C
V
W
Space one line before printing (blank code)
space two lines before printing
Space three lines before printing
Suppress space before printing
Skip to channel 1
Skip to channel 2
Skip to channel 3
Skip to channel 4
Skip to channel 5
Skip to channel 6
Skip to channel 7
Skip to channel 8
Skip to channel 9
Skip to channel 10
Skip to channel 11
Skip to channel 12
Select punch pocket 1
Select punch pocket 2
Appendix B:
Control Characters and SYSOUT Writer
147
These codes include those defined by ASA FORTRAN. If any other code is
specified, it is interpreted as 'b' or V, depending on the device being
used; no error indication is returned.
SYSOUT WRITERS
Data definition statements defining output data sets can specify
SYSOUT processing. The functions provided by SYSOUT are discussed in
the publication IBM System/360 Operating System: Operator's Guide.
SYSOUT data sets are usually intended for unit-record devices and
must have sequential organization. The programmer uses the OPEN and
CLOSE macro-instructions in the usual fashion, specifying either the
basic sequential access method or the queued sequential access method.
In systems without output writers, processing programs usually write
SYSOUT data sets directly to unit-record devices. The type of device
involved for any particular execution of a processing progzam is
determined by the DD statement that defines the aata set for that
execution. To ensure that a data set will always be eligible for SYSOUT
disposition, you should open it in a device-independent manner, so that
a DD statement will have the freedom to specify the appropriate device
type.
This requires that the DEVD operand in the DCB macro-instruction
reserve the largest device-dependent area.
The records can be written in any format defined for the particular
combination of access method and device type involved.
In all systems,
the record length must never exceed the maximum allowable for the
unit-record device on which the data set will ultimately be written.
Output writers punch only the EBCDIC mode.
The processing program is responsible for any formats, pagination, or
header control. Control character usage is specified in the usual
manner by the DCB macro-instruction or alternate source.
If no control
characters are used, in systems having output wri ters"
a standard
control is supplied; with printers, for example, the output writers will
single-space and skip to channel 1 when channel 12 is sensed, while for
punches stacker 1 is selected.
148
ABEND macro-instruction 40-42
Abnormal conditions
detection and processing 40-42
Abnormal termination
detection I~O
from DEQ macro-instruction 34
from ENQ macro-instruction 34
from program interruption 39
routine 40--42
Abnormal termination dump
(see dump)
Absolute generation names 130,131
Access method 74,75
choosing an 54,74
definition of 54,74
Access techniques
basic 72-7LI
queuE~d
71-72
Accuracy, timing
(see timing services)
Additional entry points
(see entry point)
Address~ direct-access
62
absolute 65,97,99,120-123
relative 65,97,99,120-123
Alias names 22,31,93-101
Alignment, buffer 79,84,85,109
Allocation
(see space allocation, main storage
manage[nent.)
Anticipatory buffering 71,72,95,113
ATTACH macro-instruction
used in MVT 13,27-29
used in PCP, MFT 24,25
(see also EP, EPLOC, DE, ECB, and ETXR
operands)
Attribut:e
(see load module attributes)
Automatic
blocking/deblocking 71
buffer pool construction 80
cataloging 56
error checking 94
retrieval 53
volume switching 130
Backspace
by BSP macro-instruction 92
by CNTRL macro-instruction 91,92
Base register
initial 10
permanent 12
Basic access technique
buffer control 81,82
definition of 72
uses 75,100,103,104,109,113
BDAM
(see direct-access processing)
Bin, data cell 56,62
BISAM
(see indexed sequential processing)
BLDL macro-instruction 21,24,100-104
Block, data
definition of 58
(see also record format)
Block size (BLKSIZE)
65
Boundary alignment
buffer 81,85,109
data control block 70,79
exit list 68
BPAM
(see partitioned processing)
BSAM
(see sequential processing)
BSP macro-instruction 92,94
Buffer pool construction 79,80
(see also BUILD, GETPOOL, and FREEPOOL)
Buffer contzol 81,82,87,88
(see also GETBUF, FREEBUF, FREEDBUF,
RELSE, and TRUNC)
Buffer length (BUFL)
80,109
Buffer number (BUFNO)
80,81
Buffer segment
definition of 79
exchange of 84
Buffering, anticipatory 71,72,95,113
Buffering techniques
and input/output modes 87
exchange 85-87
simple 82-85
Build list 100-104
BUILD macro-instruction
description of 79,80
example 81
CALL macro-instruction
example 16
use in dynamic structure 22,23,25
use in simple structure 15,16
Cancel
at abnormal termination 41
time interval 36
CANCEL operand
in TTIMER 36
(see also timing services)
Capacity
cylinder 57,119
record 61,91,117,119
track 60,109,119-121,124
Card punch
(see input/output devices)
Card reader
(see input/output devices)
Carriage control
character 59,60,91,147
(see also CNTRL, PRTOV)
Catalog
control volumes 130
definition of 53,56
generation data group 131,132
index 130
password 132
Cataloging
a data set 53,128
Index
149
a generation data group
53,130
CCW
(see channel command word)
Chained scheduling 94
Channel, carriage control 60,148
Channel command word (CCW)
address of 68
creation by OPEN 75
PCI flag in 94
use in exchange buffering 84,85
use in simple buffering 82
Channel program
execute (EXCP)
75
number of C'NCP)
72
Channel separation and affinity 65
CHAP macro-instruction 29,30
Check
for dummy records 118
routine 74
write validity 63
CHECK macro-instruction 68,72,74
use of DECB 74
use of WAIT instead of 117
CLOSE macro-instruction 76,77
issued by control program 41,50
TYPE=T 77
Close routine 64,71
Closing a data set 77,102,103
simultaneous 77
CNTRL macro-instruction 91,92
device-independence with 91
Completion code 30,36,42
(see also return code)
Completion of I/O operation 71-74
(see also CHECK, WAIT)
Concatenation
of generations 130
of partitioned data sets 129
of sequential data sets 129
of "unlike" data sets 129
Condition, exceptional 63,64,67,74
(see also CHECK, WAIT, abnormal
condition, and wait condition)
Conditional requests
from DEQ 34
from FNQ 25,34
from GETMAIN 44,45
Control character 60,147
ASA code 147
machine code 147
use of 60
Control volumes 130
Conversion
BCD to EBCDIC 90
paper tape 90
randorr,izing 114
count
area 61-63,106,109,120
block 137,138
field 81,97,98
(see also responsibility count)
Cylinder
allocation by 120
capacity 57,120
definition of 60
index 105
"logical" 120
overflow (CYLOFL)
lln,111
150
DASDI 119
Data access techniques
(see access techniques)
Data control block
completion of 63
deletion of load modules containing 50
description of 64-66
for job library 19
for link library 19
for private library 19
for SNAP macro-instruction 42
modifying 70
specifying address of 20,21
Data definition name (DDNAME)
65
Data definition (DD) statement
relationship to data control block
63,65
relationship to job file control block
64
use in label processing 64
Data event control block
checking for errors 72,74
construction of 72
description of 67
Data set
concatenation of 129
definition of 55
naming conventions 55
PASSWORD 132
security 132
Data set control block (DSCB)
56,57
data set label group 144,145
placement of 121
Data set description 65
Data set labels
nonstandard 141
on direct-access volumes 56,144,145
on magnetic tape volumes 57,137-141
standard 137-141
Data set name (DSNAME)
65
definition of 55
qualification of 55,124,131
Data set organization
description of 54
direct 114-116
DSORG field 65
indexed sequential 104-113
partitioned 96-104
sequential
88-95
Data set security
(see password protection)
Data storage
on direct-access volumes 56,60-62
on magnetic tape volumes 57
DCB macro-ipstruction 64-67
DCB operand
for ATTACH, LINK, LOAD, and XCTL 20
for BLDL 21,24
DCBD macro-instruction 70,71
DD statement
(see data definition statement)
DDNAME
(see data definition name)
DE operand 20-24,28
Deblocking 54,71
DECB
(see data event control block)
Delete code 108,111,112
Deletin9
a member name 100,101
indexed sequential data set records
10ft , 111,112
Density, tape 57,89,90,133,140
DEQ macro-instruction 34-26
example 48-49
DETACH macro-instruction 29,30
Device-dependent macro-instructions 91-93
Device-independence 55,92,93
achieving 92-93
programming considerations 93
system generation considerations 93
DEVTYPE macro-instruction 109
Direct-access labels
data set label (data set control ·block)
14~.
user labels 145
volume labels 144
volume table of contents (VTOC)
144
Direct-access storage space allocation
119-128
absolute address 120
block address 119
cylinders 120
for indexed sequential data sets
122-129
options 120
tracks 120
Direct-access volumes
initialization of 119
(see also data storage, space
allocation, and direct-access labels)
Direct organization data set 54,114-116
space allocation for 119
Directory of a partitioned data. set
21,22,54,96-98
space alloc~tion for 121,122
use of Build list 21,22,24,100
Disk drive 56,60,120,121
Dispatching priority
(see priority)
Disposit,ion
data set (DISP)
66,102,104,128
volume 75,76
Double-word alignment 79
DPMOD operand
( see priority)
DSCB
(see data set control block)
DSECT
(see dwmny control section)
DSNAME
(see data set name)
DSORG
(see data set organization)
Dummy control section (DSECT)
70,96
Dump 42:,43
Duplicat,e
names
in ENQ 32'
in IDENTIFY 31
requests for resource 34
Dynamic buffering 79,80
release of 88,113
usingr READ or WRITE 82,113
(see also RELEX)
Dynamic structure
definition of 13
passing control in
19-27
ECB (see event control block)
ECB operand, for ATTACH
with MVT 29,30,42
with PCP, MFT 24-26,42
Embedded index area 122
End-of-data-set (EODAD) routine 66,71
use with concatenation 130
End-of-volume
condition 71
positioning 76-78
processing 78
(see also FEOV)
ENQ macro-instruction 32-36
to test for previous request 25
use in data management 115
Entry point
additional 31
identifier 31
(see also IDEN~IFY)
EODAD
(see end-of-data-set routine)
EOF 137-139,142
EOV 137-139,142
EP operand 20-24,28
EPLOC operand 20-24,28
Error Analysis (SYNAD) routine 67,68
error correction 74,94
exit address 71
Error options (EROPT)
67
ESETL macro-instruction 110,112
ETXR operand
use in MVT 29,30,42
use in PCP, MFT 24,26
Event control block 30
use with ATTACH 24,30,42
use with WTOR 38
Exceptional condition code 67,71,74
Exchange buffering 79-85
Exclusive control 115
(see also ENQ)
EXCP macro-instruction 75
Execute channel program
(see EXCP macro-instruction)
Execute form
of macro-instruction 48
Exit routines 54,66-69
data control block 69,70
end-of-data-set 67
error analysis 67
list (EXLIST)
68
user label processing 69
Explicit ~equests
for main storage 43-44
for resource 32
Extended search option 115
Extent, data
block (DEB)
62
end of 78
entry 62
EXTRACT macro-instruction 36,29,30
Feed back
description 92
request for 73,74
FEO macro-instruction
78
Index
151
Field operand
(see EXTRACT)
FIND macro-instruction 100
use with build list 102
Fixed-length records 58
standarrl 89
(see also record format)
Flag
save area 18
Formulas
for buffer and work areas 109
for direct-access device capacity
120,121
for indexed sequential space
requirements 124-128
FREEBUF macro-instruction 88
FREEDBUF macro-instruction 88
FREEMAIN macro-instruction 43-41
Generation data groups
cataloging of 53,130-132
concatenation of 131
description of 56
generation names 53,130
relative generation numbers 53,130,131
GET macro-instruction 11
locat.e mode 82
move mode 82
substitute mode 85
GETBUF ITlacro-instruction 88
GETMAIN macro-instruction 43-37
examples 11,45
GETPOOL macro-instruction 80
buffer length (BUFL) requirements 109
GSPL operand
(see subpools)
GSPR operand
(see subpools)
Hierarchy
at abnormal tennination
of tasks 29
41
Identification
entry point 31,32
message 38
IDENTIFY macro-instruction 31
IEHPROGM 131,132
Implicit requests
for main storage 43,41-50
Independent
index area 108,122
. overflow area 106,122,124,127
Index
catalog 56,130-132
cylinder 106
master 106
space allocation for 121-128
track 105
Indexed sequential organization data set
54,104-113
space allocation for 122-128
Indicative dump
(see d 11mp)
Input/Output devices
card reader and punch 60,12,89,90
direct-access 60-63,91
magnetic tape 57,89
152
paper tape reader 90
printer 60,12,89,91,92
Interlock 35
Interval timing
(see timing services)
Job file control block (JFCB)
64
Job library
defining 19
obtaining modules from 20-22
Job pack area 19-24,31,43,49
Key, record
direct-access 61,115,111
indexed sequential 54,104,109
prefix 110
Label
editing 141
(see also direct-access labels, and
magnetic tape labels)
Length
of directory entry 24
of list form 48
of main storage request 44
of roessage to operator 38
of PARM field 13
Levels, subtask
defined 29
effect on abnormal termination 41,42
Library 53,54
(see also link library, job library, ~nct
private library)
Limit priority
(see priority)
Link library
defining 19
obtaining modules from 20-22,47
LINK macro-instruction 22-24
as request for storage 43,47
example 24,25
return from 26
(see also EP, FPLOC, DE, and DCB
operands)
LINK pack area
contents 19,22
placing modules in 47,48
search of 20,21
Linkage conventions 9-13
Linkage editor 13,16,22,31
Linkage registers 12
List form of macro-instruction 48
List, parameter
(see parameter list)
LOAD macro-instruction 19-23
Load module
attrbiutes 22,47,49
execution 13
location 19,20,22
maximum size 47
naIries 31
search 20
types 13
Locate mode processing
and buffering techniques 87
with GET macro-instruction 82-86
with move mode 83
with PUT macro-instruction 82-87
with PUTX macro-instruction
with substitute mode 86
82,86
Log
(see WTL)
LPMOD operand
(see priority)
LRECL (record length) field
65,72,94,95,111,114,115
MACRF (macro-instruction form) field
60,81-87,111,112,117,118
Macro-instructions
(see macro-instructions by name)
Magnetic tape labels
editing of 141
header label group 137
nonstandard 141
organization of 142
standard 133-141
trailer label group 137
user label exit routine 69
user labels 141
volume labels 135,136
Magnetic tape, unlabeled 57,66
Magnetic tape volurnes 57
Main storage management 43-50
method of 45
subpools in 45-47
(see also GEcrMAIN and FREEMAIN)
Master index 105,106
NTM specification 127
space allocation for 127
Member of a partitioned data set 54,96
creation of 101,102
deletion of 97
directory entry for 98-101
retrieving of 103,104
updating 10L~
(see also NOTE, POINT, FIND, and STOW)
Modifyin9 a data control block 70
Move modle processing 82-87
and bufferinq techniques 87
with GET macro-instrnction 83
with locate mode 82
with PUT macro-instruction 82,83
Names
data set 55,124,131
generation data group 53,130
Nonreusable load module
(see load module-attributes)
Nonstandard tape labels 57,66,141,142
editing of 141
Note list 99,100,102
NOTE macro-instruction 92,102
OPEN macro-instruction
Open routine 64,69,77
Options
defined 9,10
identify 31
timinq 36,37
overflow
cylinders 106-108
entry 105
independent area 106
poinber 92
76
track 62,63,65,92,94
Overflow records
deletion of 108
description of 107-109
Overlap 54,71-73
Overlay load modules 13,19,47,49
Pack areas
(see link pack area, job pack area)
Paper tape reader
(see input/output devices)
Paralled executions 13,27-30
Parameter list 12,14-17
from list form 48
with CALL 16,17
with LINK 23,25
with XCTL 27
Parameters
(see parameter list, linkage registers)
PARM field 12,13
Partitioned organization data set
54,96-104
concatenation of 129
space allocation for 121
Passing control
in a dynamic structure 19-27
with return 23-26
without return 26,27
in a simple structure 14-19
with return 14-19
without return 14
(see also IJINK, ATTACH, and XCTL)
PASSWORD data set 53,132
PICA
(see SPIEl
POINT macro-instruction 92,103,104
Position 43
POST macro-instructi.on 30
Predecessor task
(see hierarchy)
Prefix, key 110
Prime data area 105-108
space allocation for 122,128
PRINTER
(see input/output devices)
Priority
changing 28,29
dispatching 28,29,36,38
limit 28,29,36
PRIVATE libraries
defining 19
obtaining modules from 20-22
Protection
of main storage 45
of serially reusable resources 32-36
PRTOV macro-instruction 92
Punch
(see input/output ievices)
PUT macro-instruction 95
locate mode 82-85,87
move wode 82,83,110
substitute mode 83,85
PUTX macro-instruction 72
output mode 82,83,86
update mode 82
Queued access technique
buffer control 81-87
Index
153
definition of 71
uses 95,100,103,104,110
Read backwards 73
READ macro-instruction 72,73
Record blocking
(see blocking)
Record format
fixed-length 58,59
RECFM field 65,89
undefined-length 60
variable-length 59
Record length
(see LRECL)
Reenterable
load module
(see load module attributes)
macro-instruction 48
Region 43,45
Registers
(see base register, linkage register,
and reenterable macro-instructions)
Relative generation numbers 53,130,131
Relative key position (RKP) field
81,109,110
Release
of main storage
(see FREEMAIN and nain storage)
of serially reusable resource
(see DEQ)
RELEX macro-instruction 115
RELSE macro-instruction 87
Reorganization of indexed sequential data
set 107,108,111
Reply
(see WTOR)
Responsibility count 23,26,27,49
Return code 17,27
Return of control
from check routine 68
of CPU 18,23,25~26
(see also RETURN)
of main storage
(see FREEMAIN)
of resource
(see DEQ)
RETURN macro-instruction 18,19,69
Reusability
(see load module-attributes)
RKP
(see relative key position)
Save area 10-12
chaining 11,42
flag 18
SAVE macro-instruction 10
Search
for load module
(sEe load module search)
Search argument 74
Search option, extended 115,117
Security, data set
(see PASSWORD data set)
Segment
buffer 79,82,84-86
overflow record 63
Sequence identifier 31,32
Seqnential organization data
154
set 54,88-95
(see also device-independence)
Serially reusable load module
(see load module attributes)
Serially reusable resource 32-36
SETL macro-instruction 110
Shared control
(see ENQ)
SHSPL operand
(see main storage management)
SHSPV operand
(see main storage management)
Simple buffering 79,81-85,95
Simple structure
definition 13
passing control in 14-19
Space allocation
estimating requirements 12-128
specifying 119
SP operand
(see main storage management)
SPIE macro-instruction 38-40
Stacker selection 89-91
Standard fixed-length records 89
Status
of load module 22v25
of serially reusable resource 32-34
STIMER macro-instruction 36-38
STOW macro-instruction 101
automatic 101
Structure types
(see load module structure)
SUbpool
(see main storage management)
substitute mode processing 82,84-87
and buffering techniques 87
with eXChange buffering 84-87
with GET macro-instruction 85
with PUT macro-instruction 85
Subtask
creating 28,29
corr~unicating with
29,20,47
switching, volume 78,130
Synchronization 54,71,94
(see also task synchronization)
Synchronous error exit (SYNAD) routine
67,68,71,74
SYSOUT writers 89,147,148
Task
communications 29,30,47
creating 27,28
management 28,29
priority 28
synchronization 30
Task control block
address of 28
completion code in 30,42
obtaining information from 36
removal of 29,30
TCB
(see task control block)
Termination
of task 29,30
(see also abnormal termi.nation)
Timing services 36-38
interval 36-38
time and date 36
Trace
save area 11
table 42,43
Track
a ddre~)sing 62
format: 61
index 105
overflow option 62
TRUNC macro-instruction 88
3TIMER macro-instruction 37
'l'TR 62,98,99
Undefined-length records 60,65
Unlabeled magnetic tape 57,66
UPDAT opt:ion 76,104
Use count
(see responsibility count)
Variable-length records 59,65
boundary alignment of 79
VL operand
(see CALL, LINK macro-instructions)
Volume
control 130
disposition 75,76
labels (see volume labels)
positioning 76,77
table of contents (VTOC)
Volun;e labels
editing of 141
nonstandard 141
standard 135
Volumes
direct access 56
magnetic tape 57
VTOC
(see volume)
56
Wait condition
effect of 28,30
from ATTACH, LINK, XCTL 22
from ENQ 32-36
from STIMER 37
from WAIT 30
WAIT macro-instruction 30,74
WRITE macro-instruction 73
Write validity check option 63
WTL macro-instruction 38
WTO macro-instruction 38
WTOR macro-instruction 38,41
XCTL macro-instruction
26-28,19,20,22,40,47,49
Index
155
C28-6646-0
'U
11
.....
::s
rt
CD
0..
.....
::s
·c:en
·
·
~
()
tv
00
I
0\
0\
+:'
0\
I
o
International Business Machinls Corporation
Data Proclssing Division
112 Bast Post Road, White Plains, N.Y.tOBOt
(USA Only)
IBM World Tradl Corporation
82t United Nations Plaza, New York, New York tOOt7
(International]
READER'S COMMENTS
Title: IB.M System/360 Operating System
Form:
C28-6646-0
Supervisor and Data Management Services
Is the material:
Eany to Read?
Well organized?
Complete?
Well illustrated?
Acc:urate?
Suitable for its intended audience?
Yes
No
How did you use this publication?
__ As Other
an introduction
to the subject
________________________________
___
___ For additional knowledge
Please check the items that describe your position:
__ Customer personnel
_Operator
___ IBM personnel
_ Programmer
__ Manager
_Customer Engineer
__ Systems Analyst
_ Instructor
fold
_ Sales Representative
_ Systems Engineer
_Trainee
Other _____________
Please ChEtck specific criticism(s), give page number(s) ,and explain below:
___ Clarification on page(s)
__ Addition on page (s)
__ Deletion on page (s)
__ Error on page (s)
Explana ticm :
fold
FOLD ON TWO LINES,STAPLE AND MAIL
No Postage Necessary if Mailed in U.S.A.
C28-6646-0
staple
staple
fold
r--------------------,
FIRST CLASS
I
I
I
I
PERMIT NO. 81
I
I
IL____________________
POUGHKEEPSIE, N.Y. JI
r------------------------------------------------,
I
BUS INESS REPLY MAIL
I
IL __________________
NO POSTAGE STAMP .NECESSARY
IF MAILED IN .U.S.A.
_______________________
_______ JI
111111
POSTAGE WILL BE PAID BY
IBM CORPORATION
P.O. BOX 390
POUGHKEEPSIE, N. Y.
III1I1
111111
12602
111111
IIIIII
ATTN:
PROGRAMMING SYSTEMS PUBLICATIONS
DEPARTMENT D58
111111
111111
---------------------------------------~----------------------------------------
fold
....
::s
fold
c::
·
·
·
C/)
!J::I
International Susin.s. Machines Corporation
Data Processing Division
112 Ealt POlt Road, White Plains, N.Y.10BOl
(USA Only)
IS:M World Trade Corporation
821 United Nationl Pla.a, New York, New York 10017
(I III terna tiona.)
staple
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 Producer : Adobe Acrobat 9.13 Paper Capture Plug-in Modify Date : 2009:10:06 22:52:25-07:00 Create Date : 2009:10:06 22:52:25-07:00 Metadata Date : 2009:10:06 22:52:25-07:00 Format : application/pdf Document ID : uuid:0bfe77c9-9a9f-442d-9038-4aabf2942556 Instance ID : uuid:bdbb4267-857b-4439-affa-61201f21df97 Page Layout : SinglePage Page Mode : UseNone Page Count : 158EXIF Metadata provided by EXIF.tools