GC33 5371 7_DOS_VSE_sys Mgmt 7 DOS VSE Sys
GC33-5371-7_DOS_VSE_sysMgmt GC33-5371-7_DOS_VSE_sysMgmt
User Manual: GC33-5371-7_DOS_VSE_sysMgmt
Open the PDF directly: View PDF 
.
Page Count: 273
| Download | |
| Open PDF In Browser | View PDF |
GC33-5371-7
File No. 5370/54300-34
DOSNSE
Systems
System Management Guide
---- .=-=-=
-- -=-=
-- ----.-_
=~~
~~-===-
Eighth Edition (February, 1979)
This is a major revision of, and obsoletes, GC33-5371-6 and TNL GN33-9227. This edition
applies to the IBM Disk Operating System/Virtual Storage Extended, DOS/VSE, and to all subsequent versions and releases until otherwise indicated in new editions or Technical Newsletters.
Changes are continually made to the information herein; before usmg this pUblication in
connection with operation of IBM systems, consult the latest IBM System/370
Bibliography, GC~I, for the editions that are applicable and current.
Requests for copies of IBM publications should be made to your IBM representative or
to the IBM branch office serving your locality.
A form for readers' comments is provided at the back of this publication. If the form has
been removed, comments may be addressed to IBM Laboratory, Publications Department,
Schoenaicher Strasse 220, 0-7030 Boeblingen, Germany. IBM may use or distribute any
of the information you supply in any way it believes appropriate without incurring any
obligation whatever. You may, of course, continue to use the information you supply.
©
Copyright International Business Machines Corporation 1972, 1973, 1974, 1975,
1976, 1977, 1979
Summary of Amendments
Edition GC33-5371-7 documents:
•
New processor support
4331 and 4341
3031
•
New device support
3310 and 3370 Direct Access Storage Devices
PRTI printers (3289 Model 4 and 3203-5)
5424 MFCU
•
Improved installation aid
Maintain System History Program (MSHP)
•
Improved supervisor functions
Pageable supervisor options
Deletion of obsolete supervisor options
Improved method for loading SVA
•
Extension of label information area
•
Common EREP for DOS/VSE and OS/VS
•
VSE/ Advanced Functions
Asynchronous operator communication
Up to seven partitions
Partition balancing
Library device independence
Implicit linkage editor invocation
Switchable fast CCW translation
Fast B- and C-transient fetch
User label area definition by means of the DLA command
User job-to-job communication by means of the JOBCOM macro
Automated system initialization
Removal of LBLTYP statement
Improved access control
Alternate dump files
Use of up to 15 extents for page data set
With DOS/VSE the following programming support has been removed:
•
QTAM support
•
Support of the System/370 Model 20 Emulator on System/370
•
Support of the IBM 2321 Data Cell
•
Support of the IBM 2495 Tape Cartridge Reader
This manual has been completely reorganized and rewritten. Changes are
therefore not marked by vertical bars in the left margin.
TIllS MANUAL ..•
... is a guide to using the functions available with the system control
programming (SCP) support of the mM Disk Operating System/Virtual
Storage Extended (DOS/VSE) in its specified operating environment: with
VSE/ Advanced Functions installed. In addition, the manual provides guide
information for using significantly improved or extended functions that have
of VSE/Advanced Functions. Such information
been
.. ............. :. . . . !. • ·.1.. ..... ..••.............• ;.......•.......•...•••........•...... : •. .• . .... Unless specifically
.. iDiormatIon .applies to ·bOth the specified environment
stated, all
and the SCP only (without VSE/ Advanced Functions) environment.
Note:
In this publication, DOS/VSE refers to the specified operating
environment.
SCP support of OOS/VSE is discussed on a conceptual and functional
level. System management refers not only to the way DOS/VSE is
organized, but also to the way the user can efficiently manage the SCP
facilities at his disposal. This manual, therefore, does more than describe
the functions and interaction of the control programs that constitute the
SCP. It also describes how you - as a system planner, systems programmer,
or applications programmer - can use DOS/VSE to your best advantage.
Before you begin reading this manual, you should be familiar with the
information contained in the Introduction to DOS/VSE.
This book is not a guide to data management; instead, a separate
manual is provided for this purpose, called the DOS/VSE Data
Management Concepts.
After reading this manual and the above mentioned manuals, you
should be able to turn directly to the DOS/VSE library of reference
manuals in order to work with your operating system. A reference manual
is organized so that you can easily retrieve specific information on the
formats of the control statements, macro instructions, labels, and messages,
which you deal with daily.
This manual is divided into four chapters:
Chapter, 1: DOS/VSE Overview provides conceptual information on
multiprogramming, virtual storage and multitasking.
Chapter 2: Planning the System gives planning information for system
generation.
Chapter 3: Using the System provides information on how to use the
system, in particular on the use of the IPL, job control, linkage editor,
and librarian programs.
Chapter 4: Using the FaciHties and Options of DOS/VSE provides guidance
information on how to use facilities and options of DOS/VSE; for
example, writing IPL and job control user exit routines, checkpointing
and restarting a program, or designing programs for virtual mode
execution.
For reference purposes the organization of the system residence disk file
(SYSRES) is shown in Appendix A.
The following mM manuals are referred to in the text of this manual:
DOS/VSE Data Management Concepts . . . . . . . . . . . . . . . . . . . . GC24-5138
DOS/VSE Macro User's Guide . . . . . . . . . . . . . . . . . . . . . . . . . . GC24-5139
DOS/VSE Macros Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . GC24-5140
Guide to the DOS/VSE Assembler . . . . . . . . . . . . . . . . . . . . . . . GC33-4024
DOS/VSE mM 3800 Printing Subsystem Programmer's Guide .... GC26-39oo
Introduction to DOS/VSE . . . . . . . . . . . . . . . . . . . . . . . . . . . .. GC33-5370
DOS/VSE Tape Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GC33-5374
DOS/VSE DASD Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GC33-5375
DOS/VSE System Control Statements . . . . . . . . . . . . . . . . . . . . . GC33-5376
DOS/VSE System Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . GC33-5377
OOS/VSE Operating Procedures. . . . . . . . . . . . . . . . . . . . . . . .. GC33-5378
OOS/VSE Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. GC33-5379
DOS/VSE Serviceability Aids and Debugging Procedures ........ GC33-5380
DOS/VSE System Utilities. . . . . . . . . . . . . . . . . . . . . . . . . . . .. GC33-5381
DOS/VSE OLTEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. GC33-5383
DOS/VSE Maintain System History Program (MSHP) User's Guide GC33-6060
Data Security under DOS/VSE* . . . . . . . . . . . . . . . . . . . . . . . . . GC33-6077
* available 2nd Quarter 1979
Table of Contents
Chapter 1: DOS/VSE Overview ......... . . . . . . . . . . . . . . . . . . . .. 1.1
Multiprogramming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1.1
Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1.2
Partition Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. 3
Storage Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. 3
Device Considerations Under Multiprogramming . . . . . . . . . . . . . . . . . . . . . 1.3
Virtual Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4
Virtual Storage in DOS/VSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5
Storage Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8
Relating Virtual Storage to Locations in Processor Storage ........... 1.9
Virtual Storage Implementation under DOS/VSE . . . . . . . . . . . . . . . . . . . . . 1.13
Division of Address Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.14
Processor Storage Utilization . . . . . . . . ..' . . . . . . . . . . . . . . . . . . . . . . 1.17
Executing Programs in VIrtual and Real Mode .................... 1.17
Storage Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.18
Multitasking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.25
Two Types of Multitasking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.26
Cross-Partition Event Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.26
Chapter 2: Planning the System . ............................. 2.1
System Generation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1
Handling the Distribution System .. . . . . . . , . . . . . . . . . . . . . . . . . . . . . .. 2.1
Planning the Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2
Purpose and Contents of the Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3
Core Image Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3
Re1ocatab1e Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4
Source Statement Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4
Procedure Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5
Private Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5
Choosing the Libraries for an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6
Re1ocatab1e and Source Statement Libraries . . . . . . . . . . . . . . . . . . . . . . 2.6
Procedure Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7
Determining the Location of the Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7
Planning the Size and Contents of the Libraries ......................2.11
System and Workfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12
Page Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12
Recorder File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.13
Hard Copy File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.13
I~:.~~t:r~i:
__l(:~ill:[ii*~~ililill:~i!ijl[:;i:~iiliiii:[*~i.lill.ij:iiil*iiij::~iliii.i'rilil¥l:i!
Workfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.14
Label Information Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15
Planning for Compiling in More Than One Partition ................... 2.16
Tailoring the Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.17
Storage Management Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.18
Virtual Storage Size ......................................2.18
The Shared Virtual Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.18
Defining the Number of Pa..."titions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.21
Defining Partition Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.22
Defining the Page Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.23
Improving the Paging Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.24
Library Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.24
Extended Support for the Procedure Library . . . . . . . . . . . . . . . . . . . . . 2.24
Second Level Directory for Core Image Libraries . . . . . . . . . . . . . . . . . .2.25
Telecommunication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.25
BTAM-ES Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.26
Job Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.28
Timer Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.28
Time-of-Day Clock ........................................ 2.29
Interval Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.29
Task Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.29
Interval Timer Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.31
Program Check Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.31
Abnormal Termination Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.32
Operator Communications Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.32
Task Timer Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.32
Page Fault Handling Overlap Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.33
Disk Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.33
System Files on Disk or Diskette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.33
DASD File Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.34
Track Hold Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.34
Rotational Position Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.35
I/O Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.38
Channel Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.38
Supervisor Buffers for I/O Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 2.39
Error Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.41
Reliability/ Availability/Serviceability .............................2.41
Recovery Management Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.42
Defining the System Configuration ...............................2.43
Central Processing Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.43
Display Operator Console Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.44
I/O Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.44
Emulators . . . . . . . . . . . . . . . . . . . . . . . . ". . . . . . . . . . . . . . . . . . . . . 2.45
Chapter 3: Using the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
Starting the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1
Initial Program Loading (IPL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2
Establishing the Communications Device for IPL . . . . . . . . . . . . . . . . . . 3.3
IPL Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3
Automatic Functions of IPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7
IPL Communication Device List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7
Building the SDL and Loading the SVA . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9
Automatic SVA Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9
User Options for the SVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3.9
Creating the System Recorder File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11
Creating the Hard Copy File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14
User-Defined Processing after IPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14
Entering RDE Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14
Allocating Address Space to the Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3.15
AllOC;ltiIlg Processor Storage to the Partitions . . . . . . . . . . . . . . . . . . . . . . . . 3.16
Im1tlating tiolreg:rOUlnd Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.17
LJ"'HUUlf<, a Job
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.25
Job Streams ., . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.28
Relating Files to your Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.29
Symbolic I/O Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.30
Logical Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.32
Types of Device Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.34
Device Assignments in a Multiprogramming System . . . . . . . . . . . . . . . . 3.35
Additional Assignment Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 3.38
Processing of File Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.39
Label Information for Files on Diskette Devices . . . . . . . . . . . . . . . . . . . 3.43
Label Information for Files on Direct Access Devices . . . . . . . . . . . . . . . 3.44
Label Information for Files on Magnetic Tape . . . . . . . . . . . . . . . . . . . . 3.47
Storing Label Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.48
Tape and Print Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.51
Controlling Magnetic Tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.51
Controlling Printed Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.51
Executing a Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.53
Assembling/Compiling, Link-Editing, and Executing a Program ........ 3.53
Defining Options for Program Execution . . . . . . . . . . . . . . . . . . . . . . . . 3.58
Communicating with Problem Programs via Job Control . . . . . . . . . . . . . 3.59
Executing in Virtual or Real Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.59
Dynamic Allocation of Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.61
System Files on Tape, Disk or Diskette . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.63
System Files on Tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.64
System Files on Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.65
System Files on Diskette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.68
Interrupting SYSIN Job Streams on Disk, Diskette, or Tape .......... 3.69
Record Formats of System Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.70
Using Cataloged Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.70
Retrieving Cataloged Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.70
Temporarily Modifying Cataloged Procedures . . . . . . . . . . . . . . . . . . . . . . . .3.71
Several Job Steps in one Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.74
Modifying Multistep Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.75
SYSIPT Data in Cataloged Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 3.76
Partition-Related Cataloged Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 3.77
Use of Cataloged Procedures by the Operator . . . . . . . . . . . . . . . . . . . . 3.78
Linking Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.79
Structure of a Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.80
Source Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.80
Object Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.81
Program Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.82
The Three Basic Applications of the Linkage Editor . . . . . . . . . . . . . . . . . . . 3.82
Cataloging Phases into the Core Image Library . . . . . . . . . . . . . . . . . . . 3.83
Link-Edit and Execute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.83
Assemble (or Compile), Link-Edit, and Execute . . . . . . . . . . . . . . . . . . . 3.84
Processing Requirements for the Linkage Editor . . . . . . . . . . . . . . . . . . . . . . 3.86
Symbolic Units Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.86
Preparing Input for the Linkage Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.87
Assigning a Name to a Program Phase . . . . . . . . . . . . . . . . . . . . . . . . . 3.87
Defining a Load Address for a Phase . . . . . . . . . . . . . . . . . . . . . . . . . . 3.89
Building Phases from Object Modules with the INCLUDE Statement .... 3.91
Linkage Editor Storage Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 3.91
The AUTOLINK Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.92
Reserving Storage for Label Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.93
Specifying Linkage Editor Aids for Problem Determination or Prevention .... 3.94
Clearing the Unused Portion of the Core Image Library ............. 3.94
Obtaining a Storage Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.94
Terminating an Erroneous Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.95
Designing an Overlay Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.95
Relating Control Sections to Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.95
Using FETCH and LOAD Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.97
Examples of Linkage Editor Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.97
Catalog to the System Core Image Library Example . . . . . . . . . . . . . . . . 3.98
Catalog to a Private Core Image Library Example . . . . . . . . . . . . . . . . 3.100
Link-Edit and Execute Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.101
Compile and Execute Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.103
Using the Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.105
The Librarian Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . " . " ... 3.106
Maintaining the Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.108
Organizing the Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.122
Using the Service Functions of the Librarian . . . . . . . . . . . . . . . . . . . . 3.128
Creating and Working with Private Libraries . . . . . . . . . . . . . . . . . . . . . . . 3.132
Private Library Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.132
Using Private Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.135
Chapter 4: Using the Facilities and Options of DOS/VSE ......
4.1
User-Written Program-Exit Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1
Writing an IPL User Exit Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1
Writing a Job Control User Exit Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3
Writing a Job Accounting Interface Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7
Job Accounting Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7
Programming Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8
Tailoring the Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9
Checkpointing "Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13
Restarting a Program from a Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . .4.13
DASD Switching under DOS/VSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.14
Designing Programs for Virtual Mode Execution . . . . . . . . . . . . . . . . . . . . . . . . .4.16
Programming Hints for Reducing Page Faults . . . . . . . . . . . . . . . . . . . . . . . .4.16
General Hints for Reducing the Working Set . . . . . . . . . . . . . . . . . . . . .4.17
Using Virtual Storage Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.19
Fixing Pages in Processor Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.19
Indicating the Execution Mode of a Program . . . . . . . . . . . . . . . . . . . . . 4.21
Influencing the Paging Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.21
Balancing Telecommunication Activity . . . . . . . . . . . . . . . . . . . . . . . . .4.21
Coding for the Shared Virtual Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.22
Appendix A: System Layout on Disk . ......................... A.I
IPL Records ...............................................
System Volume Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User Volume Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Library Directories and Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Label Information Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.I
A.I
A.I
A.I
A.I
A.I
Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
5.1
Index . .....................................................
6.1
List of Figures
Chapter 1: DOS/VSE Overview
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
1-1
1-2
1-3
1-4
1-5
1-6
1-7
1-8
1-9
1-10
1-11
1-12
1-13
Figure
Figure
Figure
Figure
1-14
1-15
1-16
1-17
The Partitions of a DOS/VSE . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1.2
Assigning Different Physical Devices to the Same Logical Units .... 1.4
Virtual Storage and Processor Storage . . . . . . . . . . . . . . . . . . . . . . 1.6
Storage Management Concept - DOS/VSE . . . . . . . . . . . . . . . . . .. 1.7
Running a Program in Virtual Storage . . . . . . . . . . . . . . . . . . . . . . 1.9
Loading Program Pages into Page Frames . . . . . . . . . . . . . . . . . . . 1.11
Storing Pages on the Page Data Set (pageouts) . . . . . . . . . . . . . . . . . 1.12
Managing the Page Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.13
Supervisor Area in Virtual Storage Address Space . . . . . . . . . . . . . . 1.14
Partition Distribution in a Four Partition System . . . . . . . . . . . . . . . 1.15
Shared Virtual Area in a Four Partition System . . . . . . . . . . . . . . . . 1.16
Supervisor Routines - Fixed and Pageable . . . . . . . . . . . . . . . . . . . 1.17
Address Space for 200K Bytes of Virtual Storage and 512K Bytes
of Processor Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.19
Supervisor Location in Both ECPS:VSE and 370 Mode .......... 1.19
A 4-Partition System in ECPS:VSEand316 Mode . . . . . . . . . . . . . . 1.21
Executing in Real Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.23
A 4-Partition System in ECPS:VSE and 370 Mode with the
GETVIS Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.24
Chapter 2: Planning the System
Figure 2-1
Figure 2-2
Figure 2-3
Figure 2-4
Figure 2-5
Figure 2-6
Figure 2-7
Figure 2-8
The Relative Location of the Four System Libraries . . . . . . . . . . . . . 2.8
Alternative Locations of the Libraries . . . . . . . . . . . . . . . . . . . . . . 2.9
Example of Library Organization .........................2.10
Layout of the Shared Virtual Area . . . . . . . . . . . . . . . . . . . . . . . . .2.19
System Directory List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.20
User Program Running in Virtual Storage without RPS Support .... 2.37
User Program Running in Virtual Storage using RPS Versions of
Logic Module and Channel Program . . . . . . . . . . . . . . . . . . . . . . . 2.37
Channel Queue Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.39
Chapter 3: Using the System
Figure 3-3
Example for the Creation of the SYSREC File and for Loading
User Phases in the SVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.13
. . ,,,,,,': W~~[i W~Hn:Jl!l ~,i~i iF 3,2) ,1
Figure
Figure
Figure
Figure
Figure
Figure
Figure
3-7
3-8
3-9
3-10
3-11
3-12
3-13
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
3-14
3-15
3-16
3-17
3-18
3-19
3-20
3-21
3-22
3-23
3-24
3-25
3-26
3-27
3-28
Example of A Job Stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.28
Example of Symbolic I/O Assignment . . . . . . . . . . . . . . . . . . . . . . 3.31
Possible Device Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.36
Device Assignments Required for an Assembly . . . . . . . . . . . . . . . . 3.37
File Label Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.41
Summary of Label Option Functions . . . . . . . . . . . . . . . . . . . . . . . 3.50
Job Control Statements to Assemble, Link-Edit, and Execute
a Program in one Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.54
Submitting Input Data on SYSIPT . . . . . . . . . . . . . . . . . . . . . . . . . 3.55
System Operation oi an Assembie, Link-Edit and Execute Job ..... 3.57
Storage Layout of a Partition with Default GETVIS Area ......... 3.61
Storage Layout of a Partition after the SIZE Command is given .... 3.62
Program Execution with the SIZE Parameter . . . . . . . . . . . . . . . . . 3.63
Creation ofSYSIN on Tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.65
Processing System Input and Output Files on Disk . . . . . . . . . . . . . . 3.67
Interrupting a Job Stream on Disk . . . . . . . . . . . . . . . . . . . . . . . . . 3.69
Example of Modifying a Three-Step Procedure . . . . . . . . . . . . . . . . 3.76
Stages of Program Development . . . . . . . . . . . . . . . . . . . . . . . . . . 3.80
Record Types of an Object Module . . . . . . . . . . . . . . . . . . . . . . . . 3.81
A Job Stream to Catalog a Program into the Core Image Library ... 3.84
A Job Stream to Link-Edit a Program for Immediate Execution .... 3.85
A Job Stream to Assemble, Link-Edit and Execute . . . . . . . . . . . . . . 3.86
Naming Multiphase Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.88
Figure
Figure
Figure
Figure
3-29
3-30
3-31
3-32
Figure 3-33
Figure 3-34
Figure 3-35
Figure 3-36
Figure 3-37
Overlay Tree Structure .................................. 3.96
Link-Editing an Overlay Program . . . . . . . . . . . . . . . . . . . . . . . . . 3.97
Or~ani7.ation of the Directories and Ubraries 0n SYSRES ....... 3.106
Summary of Librarian Programs, Their Functions, and Real Mode
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.107
Assembling and Cataloging to the Relocatable Library in the Same
Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.110
Example of Deleting and Condensing . . . . . . . . . . . . . . . . . . . . . . 3.116
Disk Space available for System Libraries . . . . . . . . . . . . . . . . . . . 3.119
Symbolic Unit Names and Filenames Required to Create
Private Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.133
Library Status Report for SYSRES on an FBA Device .......... 3.137
Chapter 4: Using the Facilities and Options of DOS/VSE
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
4-1
4-2
4-3
4-4
4-5
4-6
4-7
4-8
Summary of Program Exit Conditions . . . . . . . . . . . . . . . . . . . . . . 4.1
IPL User Exit Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3
Job Control User Exit Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5
Job Accounting Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8
Job Accounting Routine Example . . . . . . . . . . . . . . . . . . . . . . . . .4.11
Example of a RESTART Job . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.14
PFIX and PFREE Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.20
Example of Conventions for SVA Coding . . . . . . . . . . . . . . . . . . . . 4.23
Appendix A: System Layout on Disk
Figure A-I
Figure A-2
System Residence Organization on CKD Devices . . . . . . . . . . . . . . A.2
System Residence Organization on FBA Devices . . . . . . . . . . . . . . . A.3
Chapter 1: DOS/VSE Overview
DOS/VSE is a combination of programs that interact with user-written
programs running on a System/370 or mM 3031 or on a 4300 Processor.
A reference to System/370 implies, in this manual, a reference to the mM
3031. When installed on an 4300 Processor, DOS/VSE may run in either
370 mode or ECPS:VSE mode. DOS/VSE installed on a System/370 runs
in 370 mode only.
This chapter expands on the conceptual information contained in
Introduction to DOS/VSE about the following topics:
•
Multiprogramming
•
Virtual storage
•
Multitasking
Multiprogramming
Multiprogramming is a technique that allows the concurrent execution of
more than one program in a single computer system. Multiprogramming
balances the difference between the speed of the central processing unit
(CPU) and the relatively slower speed of the I/O devices, and improves the
overall throughput of the system.
When a single executing program requests an I/O operation, it may not
be able to continue processing until the I/O request has been satisfied.
During this time, the CPU is idle. With multiprogramming, when one
program stops processing, the CPU is put at the disposal of another
program.
A program is said to be in control of the system when its instructions
are being executed by the CPU. A program can voluntarily yield control of
the CPU, or control can be withdrawn from it. Programs that share the use
of the CPU in multiprogramming do not have an equal claim on the CPU.
Instead, one program is given a greater priority than another.
When a program must wait for an event to occur before it can continue
processing, it yields control of the CPU. DOS/VSE then passes control to a
program of lower priority. Conversely, DOS/VSE withdraws control from a
program whenever a program with higher priority is ready to resume
processing. This generally happens when the I/O operation for which the
program has been waiting is completed.
Multiprogramming, therefore, allows the I/O operations of one program
to be overlapped by the processing of other programs. When a program has
to wait for the completion of an I/O operation, DOS/VSE sets the
program in the wait state and selects another program for execution on the
basis of its priority and readiness to run. This process, called task selection,
is performed by the supervisor program of OOS/VSE. The supervisor is
always resident in storage and controls many functions of DOS/VSE. The
Chapter 1: DOS/VSE Overview 1.1
supervisor is discussed in detail in the section Tailoring the Supervisor in
Chapter 2, Planning the System.
Partitions
Efficient use of the system relates not only to the degree of CPU activity
but also to storage management. Storage is allocated to partitions to
accommodate the programs that will be executed in them. At times, only a
portion of the partition is used by the program being executed. Some
programs require a large partition. DOS/VSE automatically balances the
storage demands made by programs by making processor storage not being
used by one program available to a program in another partition as
required.
The number of partitions supported equals the number of problem
programs that can be executed concurrently within the system. There is
always support for one background (BG) partition and one foreground (FI)
partition. Optionally, support for up to three additional foreground
partitions (F2 through F4) can be requested if you operate in an SCP only
environment, i, '
' ';;i;i'~~;,e;/;:!/ ~':,'iii/i ';hLn';
;:;n:]!
num
.. configUration is a supervisor
generation option, and as such is described in the section Tailoring the
Supervisor in Chapter 2, Planning the System.
Background
Storage
available
to problem
programs
Foreground-3
Foreground-2
Foreground-1
FJgUI'e 1-1. The Partitions of a DOS/VSE
The background partition differs from the foreground partitions in the
following respects:
•
The backgroun«i partition is automatically activated by IPL. A
foreground partition must be activated via the BATCH or START
operator command. (The BATCH and START operator commands are
discussed in detail in DOS IVSE Operating Procedures.)
1.2 DOS/VSE System Management Guide
•
Certain ffiM-supplied programs can be executed only in the background
partition. These programs are CORGZ (the merge into SYSRES
functions), and MAINT (except deleting, renaming and condensing
functions for a private core image library). Refer to the section Using
the Libraries in Chapter 3, Using the System.
•
Link editing a program to the system core image library can be done
only in the background partition.
Partition Priorities
During supervisor generation, priorities are established for each partition
defined in the system. The default priorities are (from low to high): BG,
F4, F3, F2, Fl.· .
During processing the operator can display the partition priorities and
change them dynamically by issuing the PRTY command. This can be used
to accelerate the execution of a given program. However, the priorities
should be reset to the installation standards as soon as possible to handle
the normal flow of jobs through the system.
Changing priorities while jobs are being executed should be done with
special care if the licensed program VSE/POWER or teleprocessing, which
normally run in a high-priority partition, are active in the system.
Storage
Protec~
Storage protection, which is standard on all System/370 and 4300
processOr models, ensures that the instructions and data of one program in
a given partition do not interfere with those of another program in another
partition.
Device COIISiderations U1Uler MlIltiprogra""";,,g
Generally, the same physical I/O device (or extent of a direct access or
diskette device) may not be used concurrently by programs being executed
in different partitions. Exceptions to this are:
•
The device or extents assigned to the system logical units:
SYSRES
for system residence
SYSREC
for the recording of system information such as console
messages and hardware statistics
SYSLOG
for system-operator communication
SYSCAT
for use with VSE/VSAM, a licensed DOS/VSE access
method.
Chapter 1: DOS/VSE Overview 1.3
These devices (extents) are considered to belong to the system as a
whole, rather than to individual partitions. (A description of these
system logical units is contained in the section Symbolic I/O Assignment
in Chapter 3, Using the System).
•
The page data set.
•
Private libraries which may be shared for read-only operations (for
more information refer to Using Private Libraries in Chapter 3, Using
the System).
•
A file on a direct access device can be accessed across partitions,
providing it is not being created simultaneously by programs in more
than one partition (see Track Hold Option in Chapter 2, Planning the
System for information on protection when updating a file concurrently
by separate tasks).
IT, for example, you wish to link-edit programs in different partitions
concurrently, different physical devices or extents (except.for SYSRES and
SYSLOG) must be assigned for~each partition to all logical units used by
the linkage editor program. Figure 1-2 shows an example of the device
assignments in order to link-edit in two partitions concurrently.
Logical Unit,
SYSIN
SYSlST
SYSlOG
SYSlNK
SYSOOl
SYSClB
SYSRES
FJgUI'e 1-2.
F1 "'Partition
X'18l'
X'182'
X'OlF
X'13l'
X'13l'
X'130'
X'130'
BG Partition
X'OOC'
X'OOE'
X'OlF
X'132'
X'132'
X'130'
ARgning Different Physical Devices to the Same Logical Units
In this case, the output on SYSLST in FI is written on a tape. A listing of
this output can be obtained by printing the tape after the job is completed.
IT VSE/POWER is used, the listing could be automatically obtained
whenever a printer becomes available.
Virtual Storage
The objective of the virtual storage concept is to achieve greater
throughput. Multiprogramming, for example, increases throughput by
sharing CPU time between two or more partitions. Virtual storage enables
you to improve real (processor) storage utilization.
In the previous multiprogramming discussion the statement is made that
"Multiprogramming . . . allows the concurrent execution of more than one
program ... ". Note that concurrent does not mean simultaneous. Even in
the multiprogramming environment, when two or more programs are
executing in storage, the CPU (Central Processing Unit) can execute only
one instruction at a time. Hence, the space in storage used by all other
instructions, data areas etc. is temporarily not needed. All that must be in
storage at anyone point in time is the instruction (and its associated data
areas) that is being executed. The Virtual Storage concept exploits this fact.
1.4 DOS/VSE System Management Guide
Vil1llal Storage in DOS/VSE
Through a combination of hardware design and programming support,
DOS/VSE has an address space, called virtual storage, that can extend to
the maximum allowed by the system's addressing scheme, which is
16,777,216 bytes (16M bytes).
How much of the maximum address space (16 M bytes) will be used in
a particular system depends on a number of factors: the size of the
computer's processor storage, the amount of disk storage available, the
number of partitions, their sizes, and the characteristics of the installation's
programs and operating environment.
Chapter 1: DOS/VSE Overview 1.5
Virtual Storage
OK,~--------------------~
Processor Storage
OKr----------------------
address
space <
Your Programs
----------------------~nK
max.=16M-l bytes
It is in the address space that proarams conceptually no.
Figure 1-3.
Virtual Storage and Processor Storage
Your programs are conceptually loaded and run in address space. See
Figure 1-3. Of course, each instruction of a program must be in processor
storage when the instruction is executed, and so must the data this
instruction manipulates. The other instructions and data of that program in
virtual storage need not be in processor storage at that same moment; they
can reside on auxiliary storage until needed. The file used for this purpose
is called the page data set.
It would be inefficient, however, to bring every instruction and its
associated data into processor storage individually. Virtual storage is
manipulated in sections called pages; the size of a page in DOS/VSE is 2K
bytes. Processor storage is also divided into 2K byte sections; these are
called page frames. Page frames accommodate pages of a program during
execution.
The resident routines of the DOS/VSE supervisor occupy tlte low
address page frames, while the remaining page frames are available for the
execution of processing programs and the pageable routines of the
supervisor. These remaining page frames are collectively called the page
pool.
When a program is loaded from the core image library into virtual
storage, all its pages are brought into page frames of the page pool. If there
1.6 DOS/VSE System Management Guide
are not enough page frames available to contain all the pages of a program,
DOS lYSE writes the contents of some page frames to the page data set.
Set: Figure 1-4.
Page
Data
Set
Core
Image
Library
r---Z
,X ..
,"~\X\
'
'----\, X',
-_--I',X,\
, ,
\
\
~\X;
~I.
,'x',
-----,
i
I
I
e
I
I
_____ .L
I __________
PROGX
... "
~
-----r-----e-- 1/
X X X X X X
I
I
I
I
,'X I
'/
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
I
I
I
I
L ______________ ...JI
Processor Storage
Virtuai Storage
A program named PROGX (A) is "conceptuaDy" loaded into virtual storage (8). DOS/VSE
f"JDds page frames in the page pool of processor storage (C). When there are not enough
page frames to accomodate aD of PROGX, DOS/VSE stores the contents of some page
frames on the page data set (0). 1be remaining pages of the program caD then be loaded.
Figure 1-4.
Page
Pool
>
J
Storage Management Concept - DOS/VSE
Chapter 1: DOS/VSE Overview 1.7
Storage Management
The following discussion amplifies the concept of DOS/VSE storage
management shown in Figure 1-4.
When programs are loaded for execution they may be loaded in
non-contiguous page frames of processor storage. DOS/VSE knows what
processor storage locations pages of a given program occupy. H the
program should cancel, due to an error, the listing produced by DOS/VSE
reflects the virtual addresses where the program was conceptually running.
In Figure 1-5, a 16K-byte program named INVEN, is conceptually loaded
at the virtual storage location 1024K. As shown, DOS/VSE selected eight
page frames of processor storage which are not contiguous. H the program
were to end abnormally, and a listing representing storage was produced
(on SYSLST), the INVEN program would be shown as occupying addresses
1024K through 1040K minus 1.
All of the information pertaining to the virtual storage and page frames
is maintained within the system in a series of tables. It is through these
tables that the virtual storage exists. Entries in these tables reflect the
current status of a given page of virtual storage.
1.8 DOS/VSE System Management Guide
Virtual Storage
Page Pool of 128 K
1 0 2 4 K I - - - - - - - - - - - - -.... ---------------
f
I
INVEN (16K)
I
1040K-1,
I
,,
,,
,,
,
,
I
\
\
I
,
\
\
,
\
I
,,
,
I
\
\
\
,
\
,,
,,
\
\
,,
Processor Storage
8 page frames are occupied by the 16K program
INVEN.
Figure 1-5.
Running a Program. in Virtual Storage
Relating Virtual Storage to Locations in Processor Storage
Since the system does not anticipate where in processor storage a page will
be loaded, the virtual addresses must be translated into real addresses when
required for execution. The address translation is performed by a
combination of the system hardware and DOS/VSE.
If an entire program fits in processor storage, none of the program's
pages will be placed on the page data set.
Chapter 1: DOS/VSE Overview 1.9
In the example shown in Figure 1-5, no page of INVEN will be paged
out as long as the demand on processor storage does not exceed the
number of available page frames.
H a second program were to be executed (mUltiprogramming) and this
program together with INVEN were larger in size than the number of
frames available in the page pool, DOS/VSE would store as many pages as
necessary on the page data set to keep both programs running.
In Figure 1-6 a program called PAYROLL is being executed as well as
INVEN. PAYROLL is a IISK program. As the page pool in this example
is only 12SK, the total demand (INVEN + PAYROLL) of 134K exceeds
the processor storage resource by 6K or three page frames.
The program PAYROLL will not start executing until all of its pages
have been loaded into processor storage. After having loaded 112K of
program PAYROLL, DOS/VSE must make three page frames available for
that program. It does this by selecting the three least recently used (LRU)
pages and storing them on the page data set. See Figure 1-7. Once the
pages have been saved on the page data set the page frames are available
for the last three pages of the program PAYROLL. See Figure I-S.
1.10 DOS/VSE System Management Guide
OK
Virtua I Storage
Page Pool of 128K
1024K
I
P
P
P
I
P
P
P
P
P
I
P
P
P
I
P
P
P
P
P
P
P
P
P
I
P
P
P
I
P
P
P
P
P
P
I
P
P
P
P
P
I
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
INVEN (16K)
1040K-
1060K
PAYROLL (118K)
IP Ip Ip I
1178K-
Processor Storage
I = a page of program INVEN
P =a page of program Payroll
3 pages of PA YRO LL not yet loaded
FJgUre 1-6.
Loading Program Pages into Page Frames
Chapter 1: DOS/VSE Overview 1.11
Virtual Storage
1024K
p
INVEN (16K)
p
1040K-
p
1060K
p
PAYROLL (118K)
I
P
I
p
I
p
p
p
p
p
p
p
p
p
I
1178K- 1 .....
p
.......
.......................
..... ......
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
Processor Storage
I = a page of INVEN
P =a page of Payroll
3 pages of INVEN have been paged out to the
page data set making room for the 3 remaining
pages of PAYROLL.
Figure 1-7.
1.12 DOS/VSE System Management Guide
Storing Pages on the Page Data Set (pageouts)
Virtual Storage
Kr-----------------------
o
Page
Data
Set
Page Pool of 128K
1024Kr-----------------------~--------------
~--~-------
~-----------
p
p
p
INVEN (16K)
p
p
1040K-
p
1060Kr---------------------~
p
p
p
p
p
p
p
p
p
PAYROLL (118K)
p
1178K-1 ....
' .........
' .........
.........
.... .........
........ ,
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
Processor Storage
I = a page of INVEN
P =a page of PA YRO LL
The last 3 pages of PAYROLL are loaded and
execution begins.
During execution, whenever a required instruction or some data is not present in processor
storage, execution is interrupted by a so-called page fault. DOS/VSE mR then read the
required page into processor storage.
FJgUre 1-8.
Managing the Page Pool
Virtual Storage Implementation under DOS/VSE
Under DOS/VSE you may generate a system that will execute on 4300 or
/370 hardware. Using the 4300 hardware, your DOS/VSE System may be
generated to run in either ECPS:VSE mode or 370 mode. DOS/VSE on
the System/370 hardware may only run in 370 mode.
Chapter 1: DOS/VSE Overview 1.13
The generated supervisor in 370 mode is functionally the same, whether
the hardware is System/370 or a 4300 processor.
The concepts of virtual storage are the same in both modes of
execution; however, the implementation differs slightly.
This section discusses: virtual storage, processor storage, and program
execution (with and without paging). The implementation of most of these
items is the same in both modes. The differences and figures showing the
different execution modes (ECPS:VSE or 370) are at the end of this
section.
Division of Address Space
As stated earlier, all programs, including the supervisor, run in an address
space called virtual storage. this address space is divided into areas: for the
supervisor, the partitions, a shared virtual area (SVA).
Supenfior Area. The address space reserved for the supervisor is the low
addresses of your virtual storage. The supervisor area begins at location OK
and extends up to the size of your generated supervisor (see Figure 1-9).
Virtual Storage
OK----------------------------~
Resident Supervisor Routines
Pageable Supervisor Routines
Resident Supervisor Routines
~--------------------------~nK
Address
space
Figure 1-9.
Supenisor Area in V'o1uaI Storage Address Space
Partitions. The virtual storage contains the areas which are used by the
DOS/VSE partitions. Programs will execute from these areas. The number
of partitions is determined at system generation. See Chapter 2, Planning
the System. The distribution of the partitions in the address space follows
1.14 DOS/VSE System Management Guide
the default partition priority scheme, that is the lower priority partitions
have the lower addresses. The sequence is always BO, F4, F3, F2, Fl for a
five partition system.
Figure 1-10 shows the layout of virtual storage for a 4-partition
DOS/VSE system. In this figure each partition is 200K in size.
Virtual Storage
512K
BG Partition
712K
F3 Partition
Address
space
912K
F2 Partition
1112K
F 1 Partition
FJgUre 1-10. Partition Distribution in a Four-Partition System
The Shared Virtual Area (SVA). The SVA occupies the address space
immediately following the partitions, see Figure 1-11. Certain frequently
used programs are loaded into the sVA. Such programs (or parts of
programs), which are relocatable and reenterable, are available for
concurrent use by programs executing in any partition. Additional
Chapter 1: DOS/VSE Overview 1.15
information on the use of the SVA is contained in this guide where
appropriate.
Virtual Storage
-
~
512K
BG
712K
F3
912K
F2
Address
space
1112K
Fl
1312K
Shared Virtual Area
Figure 1-11. Shared Virtual Area in a Four Partition System
1.16 DOS!VSE System Management Guide
Processor Storage Utilization
Under DOS/VSE processor storage is used as follows:
•
For the accommodation of the resident supervisor routines.
•
For the loading and execution of the pageable supervisor routines.
•
For the loading and execution of programs.
As shown in Figure 1-12, all page frames of processor storage not needed
for the resident supervisor routines are available to the page pool. It is
from this page pool that DOS/VSE selects page frames for pages of
executing programs (including the pageable routines of the supervisor).
Virtual Storage
Processor Storage
R-es-ident S-tl-perv-i-s-ef R-e-ut-ines
Resident Supervisor Routi-nes
S
S
S
Pageable Routines of Supervisor
Resident Supervisor Routines
Resident Supervisor Routines
S
S
S
S
1
S
> Page
Pool
S = pages of pageable supervisor routines
Figure 1-12. Supervisor Routines - FIXed and Pageable
Executing Programs in Virtual and Real Mode
All programs when executing are conceptually running in the address space
associated with a partition. DOS lYSE selects page frames from the page
pool for pages of the executing programs. The execution can be in one of
two modes:
Chapter 1: DOS/VSE Overview 1.17
Execution in Virtual Mode: The page frames occupied by pages of programs
running in virtual mode continue to be part of the page pool. DOS/VSE
will manage the processor storage placing some pages on the page data set,
when necessary, and retrieving those pages as required. Programs in virtual
mode are pageable.
Execution in Real Mode: The page frames occupied by pages of programs
running in real mode are taken out of the page pool for the duration of that
program's execution; the page frames will not be selected by DOS/VSE for
another program of higher priority; the program is fixed in processor
storage and is non-pageable.
To have a program executed in real mode, an amount of processor
storage must be allocated to the partition in which that program is to run.
The allocated processor storage remains part of the page pool until real
mode execution begins. Under DOS/VSE certain programs - such as those
with critical time dependencies - may have to run in real mode. A partition
may execute in only one mode at a given point in time; for example, the
BG partition can not initiate both real and virtual execution at the same
time.
Storage Allocation
From a storage management point of view, only minor differences exist in
virtual and processor storage utilization techniques between ECPS:VSE and
370 mode. These differences are indicated as the following topics are being
discussed:
•
•
•
Address space layout
Partition allocation
Processor storage allocation for real mode execution
Dynamic storage areas.
Address Space Layout. In ECPS:VSE mode, the virtual storage is one area
whose size is determined at Initial Microprogram Load (IML).
In 370 mode, the virtual storage is logically divided into two areas: real
address space and virtual address space, see Figure 1-13. The virtual
address space is defined when the supervisor is assembled. The size of the
real address space is determined at the time of Initial Program Load (IPL);
it is equal to the amount of processor storage installed. The supervisor
resides in the low addresses of your virtual storage. In 370 mode, this is in
the real address area. See Figure 1-14.
1.18 DOS/VSE System Management Guide
ECPS: VSE-Mode
37G-Mode
OK~-----------------------.
Real Address Space
512K~--------------------~
The Address Space
Virtua I Address Space
~48K-=====================~
Virtua I Storage
Virtual Storage
Figure 1-13. Address Space for 2048K. Bytes of Virtual Storage and 512K.
Bytes of Processor Storage
ECPS: VSE-Mode
OK~----------------------~
OK
Supervisor
370-Mode
Supervisor
96K
96K
Real
)
Address
SpaCe
512K
The
Address
Space
~
>
2048K U
......____________~
Virtual Storage
2048K~I--------------------~I,)
Virtual Storage
961{ as sapenisor size is an arbitrary ..alber, somewhere above the ......... sapenisor size.
Figure 1-14. Supenisor Location in Both ECPS:VSE and 370 Mode
Chapter 1:· DOS/VSE Overview 1.19
Virtual
Address
Space
Partition Allocation. Only the number of partitions but not their sizes are
defined when the supervisor is assembled. IPL allocates all of the address
space available for the partitions to the Background (BG). After IPL, you
allocate the foreground (FG) partition sizes. See Chapter 3, Using the
System.
Figure 1-15 shows the layout of a 4-partition system after IPL and
allocation, respectively, has taken place.
1.20 DOS/VSE System Management Guide
OK
ECPS:VSE-Mode
370-Mode
OK
Supervisor
Supervisor
96K
96K
>
Real
Address
Space
~
Virtual
Address
Space
BG
512K
BG
712K
F3
F3
912K
F2
F2
1112!(
Fl
Fl
1312K
SVA
SVA
Virtual Storage
2048K
Virtual Storage
Figure 1-15 assmnes a virtual storage size of 20481{ and a processor storage size of 512K..
The supervisor wiD OCCUpy. the low address 961{
this system.
of
In ECPS:VSE mode, the address space from the end of the s.msor to the begilDng of the
~ belongs t~ the BG partition (6161{).
Foreground 3
In 370 mode the BG partition's. address space starts at the beginning of the virtual address
space (512K). The real a.w.ress space is the address space from Wbicb. ~ rQDDing in
real mode are executed~
Figure 1-15. A 4-PartitiOD System in ECPS:VSE and 370 Mode
Processor Storage AUoeatiOD for Real Mode Execution. A specific number of
page frames of proCessor storage may be allocated to any of the partitions
for real mode execution~ The allocation may be d()ne at any time with the
ALLOCR coIIHIiand,.
Chapter 1: DOS/VSE Overview 1.21
Submitting
ALLOCR BG=20K, F1=24K
for example, causes the following:
•
In ECPS:VSE mode:
DOS/VSE notes that 10 page frames and 12
page frames of processor storage are available
to partitions background and foreground 1,
respectively, for real mode execution.
•
In 370 mode:
DOS/VSE allocates 20K and 24K of real
address space to partitions background and
foreground 1, respectively. In addition, when
real mode execution takes place, the processor
storage addresses used by DOS/VSE are the
same as the addresses within the allocated real
address space.
With the above ALLOCR command the largest program that can be
executed real in the two partitions are 20K in BG and 24K in Fl.
When not occupied by a program running in real mode, the page
frames allocated to a partition are part of the page pool.
When a program running in real mode does not require all the allocated
page frames, the unused page frames may be made available to the page
pool by specifying the amount of storage required by the program in the
SIZE operand of the EXEC job control statement for the program. In
order to execute a program in real mode an EXEC statement with the
REAL parameter must be used. For more details on the EXEC statement
see Chapter 3, Using the System.
Figure 1-16 shows the results of the above discussed ALLOCR
command with a 20K-program REALRUN executing in the BG partition in
real mode.
1.22 DOS/VSE System Management Guide
ECPS:VSE-Mode
OK-----------------------------,
80K
- - - - - - - Supervisor------
96K _1-------------------1
REALRUN (20K)
BG
Processor Storage
Virtual Storage
370-Mode
OK~--------------------------~
80K - - - - - - - Supervisor------96K~--------------------------~}
REALRUN(20~
116K
BG
s
s
Allocated to F 1
130K
s
Virtua I Storage
s
Processor Storage
R
S
=
pages of REA LR UN in processor storage
=
pages of supervisor pageable routines in storage
Tbe shaded portions of processor storage are not part of the page pool at tbis time. Tbe
illustration assumes a supermor with 10K resident routines and 16K pageable routines. Tbe
program REALRUN is 10K in size and is executing in real mode in the BG partition. Note
that in ECPS:VSE mode tbe page frames are selected randomly from the page pool, while in
370 mode the page fnDes o~d by REALRUN have tbe same processor storage
addresses as the pages that are occupied by REALRUN within virtual storage. Tbe aIocation
for Fl bas not affected the page pool.
FJgUI'e 1-16. Executing in Real Mode
Chapter 1: DOS/VSE Overview 1.23
Fixing Pages in PrOCes§Ol' Storage. The allocated page frames are used not
only for programs running in real mode, but may also be used for programs
running in virtual mode.
Some programs that run in virtual mode contain instructions or data
that must be in processor storage when needed and therefore cannot
tolerate paging. The pages containing such code or data can be fixed via the
PFIX macro instruction, and freed immediately after use via the PFREE
macro instruction. The licensed program VSE/POWER is an example of an
mM program that uses PFIX/PFREE macros.
When pages of a program running in a given partition are fixed in
response to the PFIX macro, they are fixed in the page frames allocated to
the partition. IT a PFIX macro is issued and enough storage is not allocated,
the pages are not fixed, and a completion code indicating this is returned to
the program.
Fixing pages in processor storage means that, in a niultiprogramming
environment, fewer page frames are available to other programs running in
virtual mode, potentially degrading total system performance. When
channel programs with large I/O areas are involved, the initial size of the
page pool may be too small. Consider this effect carefully before allowing
the use of the PFIX macro at your installation.
Dynamic Storage Areas. Under DOS/VSE there is a requirement for certain
system functions to acquire virtual storage dynamically during program
execution. An area called GETVIS area is used for this purpose. Each
partition has its own partition GETVIS area, the SVA includes the system
GETVIS area. The GETVIS areas occupy the high address space associated
with each partition and the SVA. Figure 1-17 shows the virtual storage
layout in ECPS:VSE and 370 mode with the GETVIS areas included. For
further information on the size and use of GETVIS areas see Chapter 3,
Using the System.
1.24 DOS/VSE System Management Guide
370-Mode
ECPS: VSE-Mode
OK
Supervisor
96K
OK
Supervisor
n
96KI----~11
1
I
~
Real
Address
Space
~
Virtual
Address
Space
BG
512K
BG
1------------------GETVIS Area BG
712K
F3
-------------------GETVIS Area F3
------------------GETVIS Area BG
F3
~-------------------
912K
GETVIS Area F3
F2
F2
-------------------GETVIS Area F2
~-----------------
1112K
Fl
-------------------GETVIS Area Fl
GETVIS Area F2
Fl
1312K
------------------GETVIS Area F1
SVA
SVA
r.-------------------
~------------------
System GETVIS
System G ETVIS
2048K
Virtua I Storage
Virtual Storage
Figure 1-17. A 4-Partition System in ECPS:VSE and 370 Mode with the
GETVIS Areas
Multitasking
At the beginning of this chapter, we defined multiprogramming as the
ability to execute more than one program concurrently in separate partitions
within a single computer system. Multitasking can be regarded as an
extension of multiprogramming in that it provides the ability to execute
more than one program concurrently in a single partition. In simple terms,
therefore, multitasking can be regarded as multiprogramming within one
partition.
Chapter 1: DOS/VSE Overview 1.25
Some installations using former versions of DOS, employed multitasking
to run more than three programs in a 3-partition system. The additional
partitions that DOS/VSE provides serve the same purpose. However,
running programs concurrently in separate partitions usually requires less
preparation than running programs concurrently in the same partition.
Two Types of Multitasking
Programs (or parts of a program) that are executed concurrently in a given
partition are called tasks. A distinction is drawn between the main task in a
partition and one or more subtasks in the same partition. The main task is
that program (or program part) which is initiated by job control. The
subtasks are programs (or program parts) that are initiated by the main task
through the use of the ATTACH macro in an assembler language routine.
A subtask executed in a given partition may be (1) logically
independent, or (2) logically dependent.
In the first case, the main task monitors the execution of the subtasks,
treating them as independent programs. Such subtasks may be coded in any
programming language. This type of multitasking is sometimes called
multiprogramming within a partition. It is a suitable technique to use, for
example, for concurrent execution of more programs than partitions are
available.
In the second case, both the main task and the subtasks are program
routines that are logically part of the same program. Thus, the tasks can
communicate with one another. In this case the subtasks are likely to be
coded in assembler language to allow the use of the task
intercommunication macros. They can share code (in particular, an access
method or subroutines), provided that it is of a read-only nature (that is,
that the code or subroutines are not modified during execution). This
technique is complex and can best be understood after studying the first
type of multitasking.
Cross-Partition Event Control
Highly complex applications may have a need for communication between
programs executing in separate partitions. For example, two such programs
may need to perform operations on a common file, and the operations may
require actual communication between the two programs.
Through cross-partition event control macros, one partition can delay
the execution of part of a program until another partition signals the
completion of a critical event. This allows synchronized multiprogramming
in separate partitions - thus protecting programs against inadvertent
destruction of each other - while at the same time providing for any
necessary communication between them. mM licensed programs require
this support in certain complex applications. One example is the licensed
program VSE/POWER generated with SPOOL =YES. For details about
cross-partition event control, see the manual DOS/VSE Macro Reference.
1.26 DOS/VSE System Management Guide
Chapter 2: Planning the System
After a brief description of the system generation procedure in general, this
chapter discusses in greater detail three major considerations during system
generation, namely:
•
Planning the libraries (planning the contents, the location and size of
the libraries).
•
Planning the system files and workfiles.
•
Tailoring the supervisor (adding functions to those of the basic
supervisor) .
Because of the nature of this information, this chapter primarily addresses
programmers who are responsible for planning the system.
System Generation Procedure
Proper and detailed planning is essential for efficient system generation and
minimizes the need to modify the system after it is generated. You may
want to contact your ffiM marketing representative to set up a system
generation planning meeting. ffiM field engineering should be invited to
attend the meeting to discuss the procedure to install the nonlicensed SCP
(system control programs). Generating a system includes:
Har.dling the
~.strib"tior.
•
Planning the contents, organization, and size of the system and
(optionally) private libraries. This entails distributing the storage space
available (on the disk packs) between the libraries desired for
day-to-day use. You must consider the size of the system core image
library and other system and private libraries.
•
Planning the location and size of system and workfiles. This entails
determining, what system files are required, how large they must be and
where they shall be placed. Additionally workfile space needed to
assemble the supervisor and to link-edit and catalog the components
selected to the system core image library must be reserved.
•
Planning the options and estimating the approximate size of the
supervisor. This entails selecting from the programming services
provided by ffiM, those options you wish to include in the supervisor,
and estimating the cost of these services in terms of bytes of storage.
System
To install the DOS/VSE SCP, you work with the ffiM-supplied distribution
medium (normally a magnetic tape), which is composed of four system
libraries
core image
relocatable
source statement
procedure
and a system history file.
Chapter 2: Planning the System 2.1
Unless you decide to operate in an SCP only environment, your system
generation approach should be as follows:
1. Restore the SCP and also the supplied history file to disk. (This step
does not apply if you receive the ffiM supplied code on disk.)
3.
Generate the supervisor by coding a set of supervisor generation
macros, which define the system configuration and the services you
wish the supervisor to contain. These are described in detail in the
section Tailoring the Supervisor.
4.
Delete from the libraries any components you do not require and then
condense to free library space.
S. Assemble or compile and/or link-edit programs - both your own and
ffiM's - and catalog them into the appropriate libraries.
After you deleted any of the supplied components, you must update your
history file by running the service program MSHP (Maintain System
History Program). The usage of MSHP is described in DOSjVSE Maintain
System History Program (MSHP) User's Guide.
Having determined what elements are to be contained in the system
libraries, you may wish to retain additional elements in private libraries and
therefore want to create private core image, relocatable, or source statement
libraries. These choices are discussed in the section Planning the Libraries.
The system libraries, together with certain system work areas, constitute
the system residence file (SYSRES), which is one extent of a direct access
storage volume. The SYSRES file is described in Appendix. A: System
Layout on Disk.
After establishing your SYSRES file and the history file, you should
copy those onto tape or disk for backup purposes. The utility programs
Backup/Restore System and Fast Copy Disk, which are provided for this
purpose, are described in DOSjVSE System Utilities.
For complete details on how to perform a system generation procedure
refer to DOSjVSE System Generation.
Planning the Libraries
The components of DOS/VSE are shipped in four system libraries: the core
image library, the relocatable library, the source statement library, and the
procedure library. Most programs and procedures developed and used by
your installation will also be stored in these libraries. In addition to the
system libraries, DOS/VSE supports private libraries which you may use to
either substitute for or supplement the corresponding system libraries.
2.2 DOS/VSE System Management Guide
Planning the size, contents, and location of these libraries according to
the needs of your installation is an essential part of the system generation
procedure. Such detailed planning will ensure that:
•
No disk space is wasted by components not required in your
installation.
•
The libraries are large enough to allow for future additions.
•
The libraries are accessed by the system with maximwil efficiency.
Following a brief description of the purpose and contents of the individual
libraries, this section discusses the major considerations involved in tailoring
the libraries to the needs of your installation:
•
Which libraries are required.
•
How many disk drives are available and where on these devices should
the individual libraries be placed.
•
How large should each of the libraries be and what should they contain.
Note that this section is intended to give only general guidance for planning
the libraries. More details. about DASD space requirements for the libraries
are contained in DOS/VSE System Generation. How to change the size of
a library, how to insert elements into or delete elements from a library, and
how to create private libraries is described in Chapter 3, Using the System.
Purpose and Contents of the Libraries
The following is a brief summary of the purpose and contents of the
DOS/VSE system and private libraries.
Core Image Library
In order to be executed, all programs must be link-edited into phases and
placed in the core image library (CIL). mM supplies the DOS/VSE system
control program (SCP) components pre-linked and cataloged in the CIL. A
complete list of the supplied SCP components is shipped with the program
directory documentation which accompanies your DOS/VSE SCPo Prior to
receiving your DOS/VSE, consult DOS/VSE System Generation and the
applicable VSE/ Advanced Functions publication for a listing of the
DOS/VSE components.
mM also supplies cataloged distribution supervisors. Assembler source
statements used to generate these supervisors are shown as part of the
Memorandum to Users and are contained in the source statement library.
The entries in the CIL directory of phases are sorted in alphanumeric
sequence. The phases themselves are cataloged in the next available space
in the library.
You have to decide which of the mM supplied SCP phases to retain in
the CIL. To delete unwanted SCP components, use the delete procedures
contained in the procedure library. See DOS/VSE System Generation for a
list of these procedures.
Chapter 2: Planning the System 2.3
Besides mM SCP components you may add to the CIL your own
application programs such as your payroll or accounts receivable programs,
program packages obtained from mM (for example, licensed programs), or
program packages from other sources. If you wish to include such programs
in the CIL, you must catalog them yourself. For information on how to do
so, refer to the description of the linkage-editor in Chapter 3, Using the
System.
Relocatable Library
The relocatable library as shipped by mM uses a considerable amount of
DASD space. The library contains:
•
SCP component object modules
•
Compiler logical input/output control system (LIOCS) modules
SCP Object Modules. These modules make up unlinked code of the
executable SCP component phases in the CIL. The modules have been
link-edited and cataloged into the elL you receive. These modules are
provided in the relocatable library for maintenance purposes only.
CompHer LIOCS Modules. The LIOCS modules needed by the various
compilers are cataloged in the relocatable library. There are different
modules for each device type and access method. Some modules can be
used by more than one compiler. For a complete list of the LIOCS module
names and device applicability, see DOS/VSE System Generation.
Source Statement Library
The elements in the source statement library are called books. A book is
either a sequence of source statements or a macro definition.
You can catalog into the source statement library sets of source
statements that are used by more than one program, and then include these
statements in your source program by specifying a COpy (assembler,
DOS/VS RPG II, and COBOL) or %INCLUDE (PL/I) statement.
The macro definitions in the source statement library include those
macros supplied by mM as well as any others which you may have written
and cataloged yourself. When you issue a macro instruction in your
program, the corresponding macro definition is retrieved from the source
statement library and included in your program according to the parameters
you specified.
Each book in the source statement library is classified as belonging to a
specific sublibrary; for example, an assembler, a PL/I, or a COBOL
sublibrary. Sublibraries are identified by a I-letter prefix added to the book
name. Letters A through I and the letters P, Rand Z are reserved for
sublibraries containing system components. You can use all other letters,
the digits 0 through 9, and the special characters $, &, and #, to define
your own sublibraries.
2.4 DOS/VSE System Management Guide
Procedure Library
Frequently-used sets of control statements can be cataloged into the
~~=~::s~~::~o~~te!~iljrli\.j·lii• •irr~~~~~r~~taloged
statements and/or SYSIPT data. Included VSE/POWER JECL statements
will be treated as DOS lYSE comment statements. If extended procedure
support was included during supervisor generation (by specifying the
SYSFIL option) you can also catalog procedures containing data that is to
be read from SYSIPT under control of the device-independent sequential
IOCS, by your program or by mM-supplied service programs and language
translators. SYSIPT in-line data can be, for example, the control statements
processed by the librarian or the sort/merge program. Cataloged procedures
are retrieved from the procedure library by a special form of the EXEC job
control statement.
The procedures shipped in the procedure library are provided as system
installation aids. They include:
•
library-member-delete and module-link procedures
•
MSHP history file update procedures
standard label definition procedures
Delete and Link Procedures. The delete procedures are provided to assist
you in tailoring your libraries. A complete list of the delete procedures is
provided in the manual DOS/VSE System Generation. Once your system is
installed these procedures themselves can be deleted.
The link procedures are provided to link-edit SCP modules contained in
the relocatable library to the core image library. These procedures are
provided for system-service purposes (the SCP's have been link-edited prior
to your receiving the system).
MSHP History File Update Procedures. If you have installed a component
without the use of MSHP (Maintain System History Program) there is no
entry in the history file for that component. This can occur if, for example,
you have a DOS/VS Release 34.0 or earlier with a licensed program, such
as DOS/VS COBOL, running under it. The MSHP history file update
procedures may be used to create a history file entry for the component, in
this example DOS/VS COBOL. Now, you may use MSHP for subsequent
modification (updates, maintenance etc.) of that component. For more
details on the use of the program MSHP see DOS/VSE Maintain System
History Program (MSHP) User's Guide.
Standa!'d L4!ool Procedures. These procedures are discussed in section Label
Information Area in this chapter. A complete listing showing the contents
of the procedures is included in the Program Directory Document shipped
to all recipients of DOS lYSE.
Private Libraries
Private libraries can be defined for the core image, relocatable, and source
statement libraries. The procedure library is supported as a system library
Chapter 2: Planning the System 2.5
only. Private libraries are created by using the program CORGZ and have
the same format as the system libraries.
You may establish private relocatable or source statement libraries
either to supplement or to replace the system libraries on the SYSRES file,
thereby extending the space available to the system core image library.
Conversely, you may reduce the size of the system core image library by
cataloging selected programs in a private core image library.
Private libraries are also useful in a testing environment where you may
keep working copies of your programs intact on a system library while you
test modifications of the same programs on a private library. Private
libraries thus add a great deal of flexibility to your system.
You may define as many private core image, relocatable, and source
statement libraries as desired, each serving a particular purpose. For
instance, having a separate core image library for each partition, each on a
separate disk drive, would reduce disk arm movement on the SYSRES
volume, which means faster access to the libraries.
When you define the private core image library extent (associated with
the logical name SYSCLB) it can reside on any disk volume that is
supported by DOS/VSE. Multiple private core image libraries can reside on
one volume or they can be created on separate volumes. They can be
created on the same volume as SYSRES, but this is not recommended
unless the access level is low. SYSCLB can be assigned only permanently
(not temporarily).
In an SCP only environment, private relocatable (SYSRLB) and private
source statement (SYSSLB) libraries are restricted to the same device type
as the SYSRES device; the private core image
can be on a device
type different from that of the SYSRES file.
Choosing the Libraries lor all Instalilltioll
In an operational DOS/VSE, all SCP components must reside in the system
core image library. Therefore, a system core image library must be present
in every DOS/VSE installation. Which of the other libraries you need
depends largely on the type and amount of work to be done and the
resources available at your installation.
Relocatable and Source Statement Libraries
Although these libraries are optional, few installations can operate
efficiently without them. H, for example, you work with a PL/I compiler
and you need to have the PL/I resident library routines on-line at all times,
these routines must be in the relocatable library. (The only - and very
inefficient - alternative would be to include the physical card decks for
such modules in-line with the linkage editor input.) Similarly, when you
assemble programs that use mM-supplied macros, the corresponding macro
definitions must be present in the source statement library.
2.6 DOS/VSE System Management Guide
The same advantages as those gained by having ffiM-supplied modules
in a library can of course be obtained if you store your own object modules
or source statement books in a relocatable or source statement library. The
more information you have on-line in a library the less card handling is
required and the more efficient your system will operate. Because the disk
space available to the libraries is limited, you may prefer to reduce the
number of SCP components in the relocatable and source statement
libraries to a minimum to allow for sufficient space for the core image
library. If additional disk drives are available, the space problem can be
solved by creating private libraries.
Procedure Library
In most data processing installations there are a number of programs that
are frequently executed. An inventory control program, for instance, may
have to be run daily or weekly. Or a payroll program may have to be
executed weekly or monthly. These programs are probably used for a long
period of time without being changed.
For each of these programs, there would be one or more sets of job
control statements which the programmer prepared and tested when the
program was first run. These sets of job control statements can be
cataloged as cataloged procedures in the procedure library; then, to retrieve
a set, only one statement is reqUired. This minimizes repetitive operator
handling (which often includes the replacement of defective cards or
reinsertion of diskettes) and reduces machine time and errors.
A cataloged procedure is exactly the same as what is described above
as a fixed set of job control statements. But the individual procedure is no
longer collected by the operator and selected manually for use; instead, it is
cataloged and retrieved through a special form of the EXEC job control
statement. Cataloged procedures can be modified as they are retrieved from
the library.
The use of cataloged procedures is discussed in Chapter 3, Using the
System.
Determining the Location
0/
the Libraries
Having decided which libraries you want in your system, you must
determine where on the available devices these libraries are to be placed.
All system libraries must reside in the SYSRES extent of the system disk
pack in a predefined sequence (see Figure 2-1). Although it is theoretically
possible to have private libraries on the system pack, outside the SYSRES
extent, this is not recommended because it involves increased movement of
the disk arm.
Chapter 2: Planning the System 2.7
Note: For details on SYSRES refer to
Appendix A: System Layout on Disk.
•
end of SYSRES extent
FJgUl"e 2-1. The Relative Location of the Four System Libraries
H you have additional disk drives, you can define private core image,
relocatable, and/or source statement libraries on the extra volumes. Private
relocatable and private source statement
volumes must be of the
iiiip::v~~ !,~~~ge Iib£~::~ "" ~~~~y disk device iype
supported by DOS/VSE. The system relocatable and system source
statement libraries can be removed from SYSRES and established as private
libraries; the system core image library, however, must always be present on
SYSRES. It can be supplemented but not replaced by a private core image
library. The procedure library is supported only as a system library; you
cannot create a private procedure library.
Figure 2-2 shows two examples of how you can organize the libraries in
a system with three disk drives. Any other combination of libraries on the
available devices is possible.
The examples in Figure 2-2 are to demonstrate that you can distribute
your private libraries among the available devices as you may see fit,
provided you observe the existing restrictions regarding device types. A
more practical example of how you can organize your libraries is given in
Figure 2-3. The example assumes a system with three disk drives, but it is
also applicable if you have only two drives or more than three. The
organization of the libraries in this example is especially useful when you
need large amounts of data on-line during execution.
2.8 DOS/VSE System Management Guide
SYSRLB
SYSSLB
If a private relocatable library and a private source statement library are to replace the corresponding system library, the core image library
directly precedes the procedure library. These private libraries can also be used to supplement the system relocatable and source statement
libraries, in which case the SYSRES file would appear exactly as shown in Figure 2-1.
SYSCLB
A private core image library can only be used to supplement the system core image library, which must always be present on SYSRES.
Several private libraries may reside on the same disk as illustrated.
FJgUI'e 2-2. Alternative Locations of the Libraries
Chapter 2: Planning the System 2.9
D
Compiling - Assembling - Link-Editing
Drive X'190'
Drive X'191'
Di'ive X'192'
The system cOre image library (CI Ll contains only those programs required for execution-time·
processing. The compilers, assemblers, and the linkage editor are kept in the private core
image library (PCI L).
EI
Processing
Drive X'190'
Drive X'191'
Drive X'192'
For execution-time processing, the private libraries are no longer required and can be replaced
by a data volume. Thus, maximum possible space is allowed for processing data.
CI L
PL
PCIL
PR L
PSSL
system core image iibrary
procedure library
private core image library
private relocatable. library
private source statement library
Figure 2-3. Example of Library Organization
2.10 DOS/VSE System Management Guide
Planning the Size and Contents of the Libraries
When planning the libraries for an operational system, you must decide on
their precise contents and size for daily use. Although you can change the
size of your system libraries at any time after system generation (by means
of the librarian programs), you should try to anticipate future space
requirenients and, if possible, provide this space. Such detailed planning can
eliminate the need for a complete reorganization of the libraries which
would be necessary if the extension of a library results in an overflow on
just one disk pack. Careful planning of the private libraries will save you
additional work because you cannot easily redefine the extents of a private
library once it has been created. To change the size of a private library you
must create a new private library and copy the contents of the old library
into it.
Consider the following factors before deciding on the contents and size
of the libraries:
•
The average size of a program iti-your installation.
•
The number of programs you want on-line.
•
The amount of space available.
The core iImige library, for example, is the library in which you normally
keep most of your programs. (Otherwise, each program must be submitted
to the linkage editor and placed in the core image library temporarily before
it can be executed.) Therefore, ensure that your core image library is large
enough to accommodate all programs that must be on-line; this includes
your own programs as well as ffiM-supplied components.
Special considerations apply when you work With an on-line private
core image library:
•
Phases whose names start with $ could be in a private core image
library, but it is more efficient to keep them in the system core image
library. When a $ phase is required, DOS/VSE first searches the
system core image library and then, if it does not find the phase,
searches the assigned private core image library.
•
For all other phases (not beginning with $), first the private and then
the system: core image library is searched; thus, if you work with a
private core image library, search time is reduced for these phases
cataloged in the private core image library.
The system relOcatable and source statement libraries initially contain more
(ffiM-suppiied) members than you normally use for daily operation. By
deieting from your system libraries those members which you do not need
daily you are creating operational libraries. This reduces the disk space
requirement of the SYSRES extent. In planning the contents and size of an
operational relocatable library, determine which of the ffiM-supplied
modules can be deleted and how much space you need to store your own
object modules on-line.
With one disk pack available for system files, you may prefer to
maintain only enough free space in the relocatable library of the operational
pack to contain the modules for the largest component in the system. This
Chapter 2: Planning the System
2.11
small relocatable library permits temporary insertion of any component in
relocatable format. The component can then be immediately link-edited into
the core image library and deleted from the relocatable library.
Similar considerations apply to an operational source statement library.
Determine which of the ffiM-supplied components you need on-line, which
should be transferred to a backup volume for future extensions of your
system, and which can be deleted entirely.
If you intend to use the procedure library, you should allocate sufficient
space for it on the SYSRES file during system generation. In estimating the
. b
amount of space required, consider the number of' .
control statements and SYSIPT data records (source modules, utility control
statements, etc.) you expect to store in the procedure library.
After you have determined the space requirements for your libraries in
terms of number and size of programs, you must define and allocate the
amount of disk space needed to accommodate these programs. A set of
formulas is available to calculate the disk space required for each library.
These formulas are contained in DOS/VSE System Generation.
The contents of the libraries are identified in the Memorandum to Users
(shipped with the distributed DOS/VSE system). The storage requirements
(sizes) for these components and macro definitions are identified in the
section for each component.
System and Workflles
The SYSRES file is only one of the system files that must be planned. The
location of the other system and workfiles and their sizes deserves some
thought. The system files besides SYSRES are:
Page data set
Recorder file (SYSREC)
Hard copy file (SYSREC)
History file (SYSREC)
Page Data Set
If you have the licensed program VSE/POWER installed, the page data set
should not be placed on the same drive as the VSE/POWER data files if
this can be avoided. You should attempt to place the page data set on a
pack that has relatively low activity yet is on-line all the time. Normal data
files are not conducive to this approach as you probably do not want to
leave these files on-line when they are not needed. In many cases the best
place for the page data set is on the same pack that contains the SYSRES
file. A user with only two disk drives should place the page data set on the
pack that contains SYSRES. For information on the size of the page data
set see Defining the Page Data Set in this chapter.
2.12 DOS/VSE System Management Guide
Recorder File
The recorder file contains recovery management support statistics provided
primarily for mM service personnel to analyze the performance of your
system. The information collected is related, for example, to:
•
I/O errors
•
CPU errors
•
IPL reason codes
The system logical name used for the recorder file is SYSREC. The file
name is USYSRC. The SYSREC file must be defined as a disk extent on a
DASD type that is supported by DOS/VSE as SYSRES.
The recorder file is created immediately after the first IPL for your
DOS/VSE with the SET RF=CREATE command. The file is opened by
the first occurrence of a / / JOB statement after IPL. No / / JOB statement
may be submitted prior to the SET RF=CREATE command. See Starting
the System in Chapter 3, Using the System.
Hard Copy File
The hard copy file, a disk extent, must be on the same device as the
recorder file SYSREC. The system logical name is SYSREC and the file
name is USYSCN.
The hard copy file contains all of the messages displayed on the display
operator console (DOC). These messages can be retrieved on SYSLOG by
using the operator redisplay (D) command, or on SYSLST by using
program PRINTLOG. The hard copy file is created immediately after the
first IPL with the SET HC=CREATE command. The file is opened by the
occurrence of the first / / JOB statement after IPL. See Starting the System
in Chapter 3, Using the System.
ITlStory File
Each system needs a history file containing information about the
components of the system and the fixes applied to those components. The
history file is used by MSHP (Maintain System History Program) for the
recording of information about your installed components. When
DOS/VSE is shipped to you, a history file is also shipped. This file reflects
the change level of the supplied DOS/VSE SCP components. An
up-to-date history file eases maintenance of your system.
The history file is a disk extent and must be on the same device as the
recorder and hard copy files. The system logical name is SYSREC and the
file name is USYSHF.
For information on installing the supplied history file consult
DOS/VSE System Generation. How MSHP uses the history fue is
described in DOS/VSE Maintain System History Program (MSHP) User's
Guide. You should also consult DOS/VSE System Utilities for information
on BACKUP/RESTORE and those programs' relationship with the history
file.
Chapter 2: Planning the System 2.13
Workfiles
Workfiles are temporary files that are used by a program during the
execution of a given application. User-written programs as well as
ffiM-supplied programs can use workfiles. Workfiles used by your own
programs must be defined, created, and named individually by you. They
are not discussed here.
System workfiles are used in compiling (assembling) source statements
and preparing input for the linkage editor. System workfile naming uses the
following conventions:
Symbolic Name Fde Name
SYSLNK
SYSOOl
SYS002
SYS003
SYS004
3YSOOS
SYS006
2.14 DOS/VSE System Management Guide
USYSLN
USYSOl
USYS02
USYS03
USYS04
USYSOS
USYS06
For example, the assembler requires three workfiles to translate source
input and one workfile (SYSLNK) to prepare linkage editor input.
The workfiles are defined via / / DLBL and / / EXTENT statements.
They are opened and created when needed.
Listed below are the symbolic device requirements for the Assembler,
DOS/VS COBOL, and DOS/VS RPG IT, the language translators, most
frequently used under DOS/VSE.
SYSLNK SYS001 SYS002 SYS003 SYS004 SYS005 SYS006
Assembler
L
M
M
M
DOS/VS
COBOL
L
M
M
M
DOS/VS
RPGIT
L
M
M
M
0
=
L
=
M
0
0
Mandatory
Optional
Required when link-editing
The size requirements of these files vary. Refer to DOS/VSE System
Generation which gives the formulas for calculating the size requirements of
the assembler and linkage editor workfiles. DOS/VS COBOL and DOS/VS
RPG IT workfile sizes are described in their respective installation guides.
To compile and link in two or more partitions simultaneously you will
need a set of workfiles for each partition in which you plan to compile and
link programs. A method for handling this situation is given in section
Label Information Area which follows.
Label Information Area
The label information area is part of the SYSRES file and follows the last
library in SYSRES. If SYSRES is an FBA device, the label information area
comprises 200 blocks. For CKD devices the area is two cylinders. (For the
3340 disk, it is 3 cylinders and for the 3350 it is 1 cylinder).
For FBA devices, but not for CKD devices, you may change the size of
the label information area using the RESTORE program. See DOS/VSE
System Utilities for details on this program.
Chapter 2: Planning the System
2.15
Usage of the label information area is described in Chapter 3, Using
the System.
Entries in the label information area point DOS/VSE to the appropriate
files on a given disk pack. mM provides standard label procedures in the
procedure library for placing standard label information into the label
information area for the following files:
Yde Name
Yde-ID
Symbolic Name
USYSRS
USYSRC
USYSHC
USYSHF
USYSLN
USYSOI
USYS02
USYS03
USYS04
USYSIN*
DOS.SYSRES.FILE
DOS/VS.RECORDER.FILE
DOS/VS.HARDCOPY.FILE
DOS/VS.HISTORY.FILE
DOS/VS.SYSLNK.FILE
DOS/VS.WORK-FILE.l
DOS/VS.WORK-FILE.2
DOS/VS.WORK-FILE.3
DOS/VS.WORK-FILE.4
DTTEPTF
SYSRES
SYSREC
SYSREC
SYSREC
SYSLNK
SYSOOI
SYS002
SYS003
SYS004
SYSIN
* SYSIN labels for diskette cardless system.
The label information assumes you have taken the default library allocations
when you restored your system from tape to disk. If you use different
library allocations or if your page data set size is larger than the default,
prepare your own label information and execute your own
/ / OPTION STDLABEL run. If you wish to add standard label
information, run the supplied standard label procedure(s) (or your own)
and supply also the new entries.
The Memorandum to Users shipped with DOS/VSE lists the standard
label procedure names and the contents of those procedures.
Planning for Compiling in More Than One Partition
Once the standard label area contains label information for the workfiles
you can now assign the symbolic names (SYSnnn) to some physical drive
and start compiling. Initially there is only one set of / / DLBL and
/ / EXTENT statements for each workfile (USYSOl, USYS02, etc.), so you
cannot run compiles simultaneously in two different partitions.
The DOS/VSE open routines always look for the label information in
the label storage area in the following sequence:
1. partition userlabel area
2.
partition standard label area
3. system standard label area
To cause each partition to have its own set of workfiles, place the necessary
label information in the partition standard label area associated with that
partition.
The job control program will write label information to the partition
standard label area of the partition in which job control is running when it
encounters the / / OPTION P ARSTD statement.
2.16 DOS/VSE System Management Guide
(a)
(b)
II
II
II
II
II
II
II
II
II
II
II
II
II
II
II
II
OPTION PARSTD
DLBL IJSYS01,'BG-WORKFILE-1' ,O,SD
EXTENT SYS001,,1,O,12,12
DLBL IJSYS02,'BG-WORKFILE-2' ,O,SD
EXTENT SYS002,,1,O,24,12
DLBL IJSYSLN,'BG-SYSLNK' ,O,SD
EXTENT SYSLNK,,1,O,36,12
OPTION PARSTD
DLBL IJSYS01,'F2-WORKFILE-1',O,SD
EXTENT SYS001,,1,O,48,12
DLBL IJSYS02,'F2-WORKFILE-2' ,O,SD
EXTENT SYS002,,1,O,60,12
DLBL IJSYSLN,'F2-SYSLNK' ,O,SD
EXTENT SYSLNK,,1,O,72,12
DLBL IJSYSCL,'PCIL-FOR-F2',O
EXTENT SYSCLB,,1,O,84,24
Job streams (a) and (b) above, when run in the BG and F2 partitions with
appropriate ASSGN statements, will enable simultaneous use of the
DOS/VS RPG IT compil~r in both p_artiti()ns. When running the compiler in
either partition, the OPEN routines will search for file names USYS01,
USYS02, USYSLN. In the BG partition the compiler will use cylinder 1
through cylinder 3 of a 3340, and in the F2 partition cylinders 4 through 6.
Note:
Label information for a private core image library (PCIL) has
been provided in job stream (b). To link edit in a foreground
partition a PCIL must be permanently assigned. See Creating
and Working with Private Libraries in Chapter 3, Using the
System for information on creating private libraries.
Tailoring the Supervisor
The ffiM-shipped DOS/VSE includes three supervisors, one of which is
used during system gener~tion. Part of your system generation procedure is
to plan and assemble your tailored supervisor. You may generate a system
to run either in ECPS:V~E or 370 mode for the 4300 processor, or in 370
mode for the System /370 CPUs.
This section describes the optional and required parameters of the
DOS/VSE generation macros in a topical sequence; that is, such that
related options are presented together regardless of the macros in which
they are contained. For the exact formats of these macros, refer to
DOS/VSE System Generation. This section discusses, in addition, the
advantages or necessity of specifying the support for the various features in
the supervisor.
In tailoring your supervisor to the requirements of your installation, you
can take into consideration future plans to add functions that require
supervisor options by including their requirements in your supervisor
generation macros. This allows you to upgrade your installation without
having to regenerate your supervisor. In your library planning, you should
include space for modules or components that will be required by a planned
future configuration or functional upgrades. The storage cost of additional
supervisor options ma,y be estimated by conslilting section Storage
Requirements in DOS/VSE System Generation.
Chapter 2: Planning the System 2.17
Storage MalUlgement Options
This section describes those supervisor options that relate to
•
The size of virtual storage (applies to 370 mode only)
•
The number of partitions and their priorities
•
The layout of the page data set
•
Facilities for improving the paging mechanism
Virtual Storage Size
The method of defining virtual storage is different for ECPS:VSE mode and
370 mode.
ECPS:VSEMode Virtual Storage Def"mition•.
In ECPS:VSEmooe, the default value for the total size of your virtual
stQrage is 16M (16,777,216) bytes. the operator may change this value at
IML (Initial Microprogram Load). For details about IML on a 4300
processor, see the Operator's Library Procedures manual provided by mM
for the pertinent processor model. The value is used by DOS/VSE to
4~termine tl1e size of the page data set. How to define the page data set is
discussed later.
370 Mode Virtual Stonge Def"lDition.
In 370 mode, virtual storage is composed of virtual address space and real
address space. You specify the size of the virtual address space in the
VSIZE operand of the VSTAB generation macro. The size of the real
address space is determined automatically when you execute the Initial
Program Load (IPL) program. The value you specify for VSIZE is equal to
the sum of the virtual address space allocated to the defined partitions and
the size of the shared virtual· area.
The value specified for VSIZE cannot be changed without a new
supervisor generation. The maximum size of virtual storage is 16M
(16,777,216) bytes. The maximum value you can specify for VSIZE is 16M
minus the size of the real address space. The value you specify for VSIZE
must be equal to or greater than 704K bytes (the minimum for a two
partition system).
The value you specify for VSIZE is used by DOS/VSE to determine
the size of the page data set. Refer to Defining the Page Data Set later in
this section.
The Shared Virtual Area.
The shared virtual area (SVA) is divided into subareas as follows; a system
directory list (SDL), an area for phases, a system GETVIS area (see Figure
2-4).
You cannot define the SVA size at the time of supervisor generation;
DOS lYSE determines the size during IPL at which time you may allocate
additional space. Because the SVA space shortens the amount of virtual
2.18 DOS/VSE System Management Guide
storage that is left to the partitions, you should take the SVA and its size
into your planning considerations.
I
I
Supervisor
Virt-I.Ja~
Storage <
...
System Directory List
~-------------------
Resident, Reenterable
Relocatable Phases
> SVA
~-------------------
System GETVIS Area
FJgUre 2-4. Layout of the Shared Virtual Area
The System Directory Ust. The system directory list (SDL) contains copies
of selected entries of the system core image library directory. This provides
fast retrieval of frequently used phases. (These phases may be resident in
the SVA or in the system core iinage library.) Having SDL entries avoids
searching the system core image directory (on disk) for each phase load
request. Figure 2-5 shows the SDL and its relationship to the system core
image library.
Chapter 2: Planning the System 2.19
Virtual Storage
SOL
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
(/
/
/
/
System GETVIS Area
/
/
/
I
/
SVA
/
/
/
/
/
/
/
/
/
Reenterable, Relocatable Phases
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
I
/
/
/
I J.oL.-...a..-P_HA_S_E_X_ _~~
---
PHASEB
--------
--- ----
--- --- --- ----
PHASEA
PHASEB
PHASEX
,. ,. "
/
""
"
,. / "
/
,,.
/
,.
," "
,. "
The system directory list (SOL), built by OOSIVSE, provides for fast locating of frequently used phases either in the SVA
or in the system core image library.
The SOL entries point directly to a phase's location on disk.
The SO L entries are copies of selected Core I mage Library Directory entries.
Figure 2-5. System Directory List
2.20 DOS/VSE System Management Guide
The SVA Phase Area. The SVA phase area always contains DOS/VSE
system phases; the area may, in addition, contain mM licensed program
phases and user-written phases.
Phases that are in the SVA may be used concurrently by more than one
partition if the phases are reenterable and relocatable. Having phases Ll1 the
SVA speeds processing by:
•
eliminating loading from a core image library - When a phase is
resident in the SVA, it does not have to be loaded from the library for
each execution. This saves the disk I/O of a directory search.
Additionally, even if the phase was paged out to the page data set,
time is saved as paging is generally faster than loading from a core
image library.
•
reducing processor storage demands - If the phase is being shared
between two or more partitions, the impact on the page pool is less
than if two or more copies of the phase were loaded into storage.
The System GETVIS Area. The system GETVIS area is used by DOS/VSE
to dynamically acquire virtual storage for its own use.
An example of the GETVIS area use is the initialization of the SDAID
program. The SDAID program normally requires approximately lOOK of
system GETVIS space when it is being initialized. For more details on the
SDAID program see DOS /VSE Serviceability Aids and Debugging
Procedures.
Size of the SVA. At IPL, based upon the chosen supervisor options,
DOS/VSE calculates the SVA size. The supervisor options and their cost in
SVA space are shown in the manual DOS/VSE System Generation.
Additional space requirements for installed licensed programs such as
VSE/VSAM or DOS/VS SORT/MERGE are also automatically calculated
by DOS/VSE at IPL. The space requirements for each licensed program
are shown in the appropriate licensed program documentation. To support
user-written programs in the SVA you must indicate the required SVA
space. The parameters SDL, PSIZE and GETVIS of the IPL command SVA
are used to increase the SVA size beyond the DOS/VSE defaults.
The loading of certain phases into the SVA, and the creation of SDL
entries for them occur automatically at IPL. For information on how to
increase the size of the SVA as well as loading items not automatically
included by DOS/VSE, see the section Starting the System in Chapter 3,
Using the System.
Denning the Number of Partitions
In the NPARTS parameter of the SUPVR generation macro, you define the
maximum number of partitions for your system.
In selecting the appropriate number of partitions for your particular
installation, you should consider the type of processing you require. Assume
you want to run concurrently the following types of programs:
Chapter 2: Planning the System
2.21
•
Test cases (assemble/compile, link-edit, and execute)
•
Daily application programs
•
A spooling program, such as VSE/POWER
Teleprocessing application program.
For this case, you should generate a system with four to five partitions,
depending on the volume of application program processing. If, for
example, your system includes the licensed program ACF /VT AM, at least
two partitions must be specified: one for ACF/VTAM and one for your
VTAM application programs.
Because you cannot alter the NPARTS specification unless you
regenerate the supervisor, it may be advantageous to specify more partitions
than you see an immediate need for.
Denning Partition Priorities
A processing priority is associated with each partition in a
multiprogramming system. If you do not specify processing priorities during
system generation, DOS/VSE establishes them by default following the
concept indicated by the examples given below.
H you specify
The default processing is
(from low to high)
NPARTS=2
NPARTS=3
NPARTS=4
BG-FI
BG - F2 - FI
BG - F3 - F2 - FI
In most cases, there will be no need to select another priority sequence;
however, the PRTY parameter in the FOPT generation macro is provided
for this purpose. In the PRTY parameter you can specify the partition
identifiers in any desired sequence, and thus select another priority
sequence.
The operator can display and modify the priorities established during
supervisor generation at any time during processing with the PRTY
command. He may want to do this in order to accelerate the execution of a
given job.
2.22 DOS/VSE System Management Guide
DerIDing the Page Data Set
The page data set, a sequentially organized set of records on a direct access
device, is required to accommodate paged-out pages of programs that are
being executed in virtual mode. The size of the page data set depends on
the amount of pageable address space.
You define the page data set through the IPL command DPD. This
command is discussed in section IPL commands in Chapter 3, Using the
System.
other items,
the channel and unit number
of the
the extent.
The page data set can reside on any disk device that is supported by
DOS/VSE as a system residence device .
.;.;; DOS!VSEcalculates th~·~pp~~lilnit address according to the
amount ··pageable storage defined for your system. The usage of disk
space is shown below:
Disk Device Type
Note:
Pages per Cylinder
2314
3330
3340
3350
60
114
36
240
FBA
see note
Four FBA blocks contain one page of virtual storage; hence a 2M
byte system (2048K) requires 4096 FBA blocks (2048K + 2K x 4
blocks).
In ECPS:VSE mode, the virtual storage size to be mapped on the page
data set, is a function of the hardware. The default system size is 16M
bytes (16,384K). The default may be altered during Initial Microprogram
Load (IML) to: 2048K, 4096K or 8192K. How to perform IML is
described in the mM provided Operator's Library Procedures manual for
your central processor. If disk space is a concern, you Inight consider
reducing the virtual storage size. For example, a 16M (16,384K) system
requires 32,768 FHA blocks whereas a 4M (4096K) system requires 8192
FBA blocks.
In 370 mode, DOS/VSE uses the value specified in the VSIZE
parameter of the VSTAB macro to calculate the disk space requirements. If
your supervisor includes pageable routines, DOS/VSE reserves space on the
page data set for these routines.
Chapter 2: Planning the System
2.23
Improving the Paging Mechanism
The page handling is controlled by the page management routines of the
supervisor. You can, however, influence the paging mechanism in order to
reduce the number of page faults, to minimize the page I/O activity, and to
control the page traffic within a specific partition. You can do this by
means of three macros: RELPAG, FCEPGOUT, and PAGEIN.
RELPAG (Release Page). This macro informs the page management
routines that the contents of one or more pages is no longer required and
need not be saved on the page data set when the page frames occupied by
these pages are claimed for use by other pages. This saves unnecessary page
I/O.
FCEPGOUT (Force Page-out). The macro informs the page management
routines that one or more pages will not be needed until a later stage of
processing, and that they should be given highest page-out priority. This
prevents page-out of other pages which, should they be paged-out, might be
needed again immediately after being written onto the page data set.
PAGEIN. This macro requests one or more pages to be paged-in in
advance, so that page faults can be avoided when the specified pages are
needed in processor storage. If the specified pages are already in processor
storage when the macro is issued, they are given lowest priority for
page-out.
If you anticipate the use of one or more of the above macros in any of
your programs, specify PAGEIN=n in the SUPVR generation macro. This
generates the support for the three macros. The value of n must be 1 or
greater. It specifies the number of page-in requests that can be queued if
more than one P AGEIN macro is issued concurrently in the system.
Library Options
You may generate support for special applications in the procedure library
and for reserved supervisor space to achieve better fetching performance.
These options are described below.
Extended Support for the Procedure Library
Normally, cataloged procedures can consist of job control statements or
linkage editor control statements or both. However, with the extended
support, cataloged procedures can include data that is to be read from
SYSIPT. Such data may be, for instance, utility control statements to be
processed by a utility program.
To include the extended support for the procedure library, specify the
SYSFIL parameter in the FOPT generation macro, which is discussed in the
section Disk Options in this chapter.
More information on the procedure library is contained in the section
Planning the Libraries.
2.24 DOS/VSE System Management Guide
Second Level Directory for Core Image Ubraries
The directory entries for phases in the core image library are sorted by
phase name in alphameric sequence.
An index of the directory entries is kept in the supervisor in a second
level directory (SLD). The SLD speeds the retrieval of phases froin the
system core image library. You may specify the number of entries the SLD
will contain through the SLD parameter of the FOPT generation macro.
The value specified depends on the type of disk device that contains the
system core image library:
For CKD devices - the number of directory tracks.
For FBA devices - the number of directory blocks.
There is a PSLD parameter in the FOPT macro which specifies the number
of entries for a private second level directory (PSLD) for the private core
image libraries. You have one PSLD for each partition specified in
NP-AR'f-S in the SUPVR generation macro. You should specify a PSLD
value that accommodates for your largest private core image library; the
size of each PSLD will be based on one specification in the FOPT macro.
Telecommunication
DOS/VSE provides facilities for telecommunication, the interchange of data
between an application in the system and terminals connected via
telecommunication lines. These facilities provide the ability to define such
lines for supervisor assembly and to specify one or more access methods for
input/ output services between an application and terminals.
Teleprocessing devices (terminals) are normally attached to the CPU
through transmission control units or communications controllers. The
control unit must be defined via the IPL command ADD. In some cases
there is a direct local attachment.
The access methods, defined in the TP parameter of the SUPVR
generation macro, are the licensed programs:
•
Advanced Communication Function/VTAM (ACF /VTAM)
•
Basic Telecommunication Access Method - Extended Support
(BTAM-ES)
Supervisor support for BTAM-ES is standard, also the support for TP
balancing (teleprocessing balancing).
For detailed information on generating and using a teleprocessing access
method, refer to the appropriate teleprocessing publications. Teleprocessing
users should also pay particular attention to section I/O Options later in
this chapter and read section Balancing Telecommunication in Chapter 4,
Using the Facilities and Options of DOS/VSE.
Chapter 2: Planning the System 2.25
BTAM-ES Support
Applications using BTAM-ES can execute in either virtual or real mode. If
you have used BTAM under DOS or DOS/VS in the past, you have to
reassemble and catalog BTMOD before submitting your applications to
DOS/VSE for execution. If BTMOD and the application program were
assembled together, the application program must also be reassembled and
re-linkedited.
ACF /VTAM Support
ACF/VTAM executes in virtual mode in its own partition. When VTAM is
specified, RMS support (370 models 115 and 125 only) is automatically
generated.
As ACF /VTAM uses the PFIX macro, processor storage page frames
must be allocated to the partition in which ACF/VTAM is to run. A
separate partition is required for VTAM application programs. For
information on installing this licensed program refer to the ACF /VTAM
documentation.
Interactive Computing and Control
The licensed program VSE/Interactive Computing and Control Facility
(VSE/ICCF) offers interactive time shared computing and control services
to terminal users.
VSE/ICCF provides a collection of tools for
•
Online library maintenance
•
Context editing and text manipulation
•
Development and execution of interactive problem programs
•
Job entry
•
Monitoring of time-shared job processing.
VSE/ICCF runs in a DOS/VSE partition. Support for VSE/ICCF is
generated in the supervisor by specifying ICCF=YES in the SUPVR
generation macro.
2.26 DOS/VSE System Management Guide
Chapter 2: Planning the System 2.27
ASCII Support
In addition to processing EBCDIC files, DOS/VSE can process magnetic
tape files written in ASCII (American National Standard Code for
Information Interchange), a 128-character, 7-bit code. The high-order bit in
the 8-bit environment is zero. ASCII tape files may be either unlabeled or
labeled according to the specifications of the American National Standards
Institute, Inc. (ANSI).
ASCII tape files may be processed in any partition. Input files
containing ASCII data are translated to EBCDIC as records are read into
the I/O area. Output files described as ASCII are translated from EBCDIC
to ASCII just prior to writing the records. No user translation tables or
instructions are required.
If your DOS/VSE is required to process ASCII files, specify
ASCII= YES in the SUPVR generation macro.
Job Accounting
The job accounting interface facility provides job and job step information
that can be used for charging system use, supervising system operation,
planning new applications, etc.
When this option is selected (JA=YES in the FOPT generation macro),
job accounting tables are built in the supervisor to accumulate accounting
information. One DOS/VSE job accounting table is maintained per
partition. The format of these tables and information on how to write a
DOS/VSE job accounting routine is given in Chapter 4, Using the
Facilities and Options of DOS/VSE.
To utilize this job accounting information, you must write a routine to
store or print the desired portions of the table. This routine must be
cataloged in the core image library under the name $JOBACCT.
If the user I/O routine ($JOBACCT) is written using LIOCS with label
processing, the JALIOCS parameter of the FOPT macro must be specified
in addition to the JA parameter. JALIOCS indicates that a user save area
and a label area in the supervisor are to be reserved. The label area
replaces the one normally used by LIOCS label processing routines.
If the licensed program VSE/POWER job accounting is desired,
support for the job accounting interface is required. No user-written data
collection routine is then necessary. Refer to the VSE/POWER
documentation.
Timer Services
The following timer services are available to DOS/VSE users:
•
•
•
Time-of-day clock
Interval timer
Task Timer
2.28 DOS/VSE System Management Guide
The time-of-day clock is a standard hardware feature, while the task timer
and the interval timer require other hardware features (the clock
comparator and the CPU timer) which are standard on all System/370 and
4300 processors, except the 370 models 135 and 145. Utilization of these
timer services in DOS/VSE is briefly discussed below. Except for the task
timer, the timer services are automatically provided in DOS/VSE. Support
for the task timer is a supervisor generation option.
Time-of-Day Clock
The time-of-day (TOD) clock provides a consistent measure of elapsed time
suitable for time-of-day indication.
The TOD clock support also enables programs to issue the GETIME
macro instruction, which causes the exact time-of-day to be stored in
general register 1. A description of the use of the GETIME macro
instruction is given in DOS/VSE Macro User's Guide.
The time-of-day and the date are automatically included with each
/ / JOB and / & job control statement that is printed on SYSLST or
SYSLOG.
The ZONE parameter in the FOPT macro is associated with the TOD
support. In the ZONE parameter you indicate the difference between
Greenwich mean time (GMT) and local time in hours and minutes. If the
local time to be specified is GMT, the ZONE parameter can be omitted.
During the IPL procedure, if IPL is performed from SYSLOG, a
message is printed on the operator console to inform the operator of the
status of the date, clock, and zone. If necessary, the operator can correct
this information in the SET command.
Interval Timer
The interval timer can be used by programs (main tasks or subtasks or
both) that need to schedule certain processing based on discrete time
intervals. If a problem program is written with the appropriate macros and
routines, the interval timer causes an external interrupt when the time limit
established by the program has elapsed.
Several problem program macros relate to interval timer support. For
information about using these macros, refer to DOS/VSE Macro User's
Guide.
Task. TIDIer
The task timer can be used by the main task of the partition owning the
task timer to escape from processing and enter an exit routine after a
specified period of time. This discrete time interval is decremented only
when the main task is executing. If support for the task timer is included in
the supervisor, and the owning partition's main task is written with the
appropriate macro instructions and routines, the specified task timer routine
is entered when the time interval has elapsed.
Chapter 2: Planning the System 2.29
To include support for the task timer in the supervisor, specify the
TTIME parameter in the FOPT generation macro.
H an exit routine is not specified in the STXIT IT macro, the interrupt
is ignored. The SETI macro is used to set the time interval, and that
interval can be tested or canceled by means of the TESTI macro. The
EXIT TI macro is used to return control from a task timer exit routine.
Console BUffering
In an installation with a relatively slow console device, the entire system
can be held up while messages are being issued to the operator. Console
buffering support builds a queue of output messages and returns control
immediately to the partition requesting the output. The messages are then
written as soon as the console becomes available.
Console buffering is useful in two cases:
•
when your console device is a 3210/3215 printer keyboard, or
•
when your console is a display operator console and a printer is used to
produce a hard copy of messages while they are displayed on the
screen.
In an installation without such printers, a performance improvement cannot
be obtained by requesting console buffering support. On the contrary,
console buffering may in that case even work to your disadvantage: certain
DOS/VSE tasks such as error recovery routines issue high priority
messages. H your console is a display operator console, and a DASD rather
than a printer is used as a hard copy file, then, depending on the size of
your console buffer, messages may be issued to the screen in such rapid
succession that a message like INTERVENTION REQUIRED ... can easily
be overlooked by the operator.
Support for console buffering is indicated by the CBF=n parameter in
the FOPT generation macro (where n is the number of I/O requests to be
buffered). H you decide to use console buffering, at least one buffer should
be specified for each partition or task issuing messages so that buffers are
available and the task can continue processing while the message is being
printed. Two per partition is recommended. Console buffering is not split
per partition, but used by the whole system.
2.30 DOS/VSE System Management Guide
User Exit Routines
If required, the supervisor can permit user routines to gain control when
any of the following types of events occurs:
•
•
•
•
•
•
Interval Timer Interrupt (IT)
Program Check Interrupt (PC)
Abnormal Termination (AB)
Operator Communication Interrupt (OC)
Task Timer Interrupt (TT)
Page Fault Handling Overlap (PHO)
Both the supervisor and the problem program that contains the user routine
must have the proper code to establish an interface.
The problem program that wants to utilize the options must contain
code to set up the interface. For the first five events, code can be generated
by the STXIT macro. For the last event, code is generated by the SETPFA
macrj)~ ThiS-codeis- assembled -in the -main-line of a pr-Oblem p-r-ogram.
Short descriptions of the support for each of the types of user exit
routines follow, indicating the associated problem program macros. For
information on how multitasking affects this support and what happens if
multiple events coincide, refer to DOS/VSE Macro User's Guide. Some
high-level languages offer similar facilities, for details of which see the
appropriate programmer's guide.
Interval Tmer Exit
Suppose you want to take a checkpoint on a job at a certain time after it
has started. Code the STXIT to set up the interface of your user-exit
routine with the supervisor; use the SETIME macro to set a time interval.
When that interval elapses, an interval timer interrupt occurs and control is
given to your user routine. The user routine need not be entered
immediately. For instance, if the user routine is in the background partition,
and a foreground partition is active, the user routine will not be entered
until the background partition becomes active.
To find out the time remaining in an interval, a program can issue the
TTIMER macro instruction. The supervisor then loads this value in general
register O. This macro can also be used to cancel the remaining time in the
interval.
Program Check Exit
Programs can establish linkage from the supervisor to a user program-check
exit routine by coding an STXIT macro. If a program check occurs within
the program, the supervisor gives control to the user routine instead of
discontinuing the program. The user routine can analyze the program check
and choose to ignore, to correct, or to accept it.
If the check is ignored, control can be given back to the supervisor by
executing an EXIT PC macro; if the user routine can correct the error
Chapter 2: Planning the System 2.31
condition, the routine can request via the EXIT macro that processing of
the main line program continue.
H the problem cannot be resolved, the program check is accepted as
valid. The user routine can then terminate further processing of the program
by issuing a CANCEL, DUMP, JDUMP, or EOJ macro.
The ability to include a user routine to process program checks can be
especially advantageous when using LIOCS. In that case, I/O housekeeping
such as closing files and freeing tracks can be performed before termination
of the job or task.
Abnormal Termination Exit
Programs can establish linkage from the supervisor to an abnormal
termination exit routine by issuing an STXIT AB macro.
The macro allows a user routine to get control from the supervisor
before an abnormal end-of-job condition discontinues the processing of the
program. The user routine normally ends with one of the termination
macros (CANCEL, DUMP, JDUMP or EOJ) to terminate the problem
program and to return control to the supervisor, rather than by initiating
the continuation of the problem program.
Operator Communications Exit
DOS/VSE allows problem programs to provide a routine for handling
external interrupts from the operator. This support is useful in a number of
applications, for example:
•
A change in the environment is needed. A message is then issued by
the program. For example: MOUNT TAPE XXX on unit xxx and press
the interrupt key.
In telecommunication, the OC exit allows the operator to start and stop
activities on certain lines or terminals, or to invoke diagnostic
procedures. In this case, program run sheets with explicit instructions
may be required to ensure understanding between programmer and
operator.
The external interrupt that links to an OC user exit routine is caused by
pressing the request key and, when the attention routine identifier AR
appears, replying MSG followed by the partition identifier (such as BG or
F2).
Task Timer Exit
Task timer support is included in the supervisor by the TTIME parameter
of the FOPT generation macro. This parameter also identifies the partition
owning the task timer. Only the main task in the owning partition can
utilize the task timer.
The time interval is specified in the SETI macro and is decremented
only when the main task is executing. The exit routine specified in the
2.32 DOS/VSE System Management Guide
STXIT 'IT macro is entered when the interval has elapsed, provided linkage
between that routine and the supervisor has already been established, at
that point of program execution.
To find out the time remaining in an interval, the task can issue a
TES'IT macro. This causes the time remaining in the interval to be
returned in register O. The task can aiso issue a TESTT CANCEL to
cancel the remaining interval time. In this case the exit routine is not
entered.
Page Fault Handling Overlap Exit
A user routine can continue processing during the time a page fault is being
handled by the system, provided this page fault occurs in the same task and
not in a supervisor routine invoked by this task. This support is of interest
only for programs executed in virtual mode and making use of
user-developed subtasking rather than ffiM-supplied multitasking.
Such programs may issue the SETPFA macro instruction to establish
linkage from the page management routines in the supervisor to a user
routine, called the page fault appendage routine. The usage of the SETPFA
macro is described in DOSjVSE Macro User's Guide.
Disk Options
Options are provided for some DASD devices. These options are:
•
•
•
•
System files on disk (or diskette)
DASD file protection
Track hold
Rotational position sensing
System Fdes on Disk or Diskette
The system logical units SYSRDR, SYSIPT, SYSLST, and SYSPCH can be
assigned to a disk or diskette device. When a system logical unit is assigned
to a disk, it must have only one extent.
For example, you may want to catalog the output from a language
translator to the relocatable library. During the language translation step,
SYSPCH could be assigned to a disk extent. The resultant object module
would then be cataloged via the librarian program MAINT by assigning
SYSIPT to the same disk extent.
Support for system files on disk or diskette is specified in the SYSFIL
parameter of the FOPT generation macro.
The SYSFIL option is required to implement extended support for the
procedure library. This means that cataloged procedures may contain in-line
SYSIPT data. The sets of control statements that can be cataloged into the
procedure library are, therefore, not limited to job control or linkage editor
control statements. (See also Library Options earlier in this chapter.)
Chapter 2: Planning the System 2.33
For systems without magnetic tapes, the SYSFIL option is required in
order to install mM programs and apply program maintenance, which, in
this case, must be distributed on disk packs in SYSIN format.
DASD Fde Protection
This feature is provided to prevent user programs, which utilize DAM or
user-written channel programs for writing onto DASD, from writing data
outside of the limits of the DASD file currently being accessed. This might
happen if, for example, a randomizing algorithm produces an unexpected
DASD address which is outside the file limits.
DASD file protection support is indicated in the DASDFP parameter of
the FOPT generation macro.
DASDFP gives protection on the basis of programmer logical units. If
two DASD files are open in the same partition and use the same
programmer logical unit, the DASDFP option does not give any protection
to either of the two files.
If you are using physical IOCS, you must use the DTFPH macro to
define the file. The file must be opened using the OPEN or OPENR macro,
and each channel program must commence with a long seek (X'07')
command, and contain no chained long seeks.
Specifying DASDFP does not prevent file contention between
partitions, or within partitions if the same symbolic unit is used. Thus, more
than one partition may access the same file at the same time and may even
attempt to update the same record simultaneously. The track hold option
(TRKHLD) is provided to solve this problem. Note, however, that all
DASD writes (DAM and others) will be checked for being within the
file-protect range.
Note that, for CKD devices, no protection is given to partially allocated
cylinders; files to be protected should begin and end on cylinder
boundaries.
Track Hold Option
The track hold option is used to ensure that, while data in a DASD file is
being modified by one task, no other task in the system can access that
data. The facility is available to all DOS/VSE disk access methods,
including VSE/VSAM (and also ISAM Interface, except the LOAD
function).
The track hold option can be selected by specifying the TRKHLD
parameter in the FOPT generation macro.
Additionally, user programs must invoke the track hold feature. For the
track hold feature to be effective all programs accessing the same file must
request its use.
The track hold feature is requested in the DTF of the user program by
specifying HOLD =YES. For VSE/VSAM files the track hold feature is
2.34 DOS/VSE System Management Guide
specified at the time the file is defined via the SHARE OPTION 4
parameter.
. For FBA devices, the track hold facility protects the range of blocks
which contains the accessed data. For eKD devices, the facility protects the
track that contains the data being accessed.
Deadlock occurs if one task is waiting for a DASD area held by a
second task and the second task is waiting for a DASD area held by the
first. This can be prevented by establishing the convention that every task
must be programmed so that it will not attempt to hold more than one
DASD area at a time. Deadlock may also occur if the maximum number of
DASD areas demanded to be held by all tasks combined exceeds the
niaximum specified in the TRKHLD parameter.
Rotational Position Sensing
Rotational Position Sensing (RPS) is a feature on all mM eKD disk
storage devices except 2311,2314, and 2319; it is optionally available on
mM 3340. It provides the ability to overlap positioning operations on one
device with service requests for other devices on a block multiplexer
channel (or its equivalent on System/370 Model 115 or 125).
DOS/VSE makes use of the feature if you specify RPS=YES in the
FOPT generation macro. However, you should not request RPS support if
you use the 23xx emulator on a Model 115 or 125.
Better channel utilization can increase system throughput, especially in
large multiprogramming systems with heavy concurrent I/O activity.
Because a selector channel is monopolized once a channel program has
been initiated, no other device on this channel can be accessed until the
data has been transferred. With block multiplexer channels and the RPS
feature of DASD devices, however, the device can disconnect from the
channel during positioning operations. The channel is then available for
other requests so that other devices on the channel can be accessed.
Overlap of positioning to a record on a track requires adding RPS
eews to the direct access storage device channel programs. DOS/VSE
system control and service programs that support RPS, dynamically build
these eews during program execution provided that the supervisor is
generated with RPS support and that the direct access storage device has
the feature.
RPS support for DOS/VSE is provided in all access methods which
support RPS DASD devices and in the DOS/VSE system control and
service programs where the implementation benefits total system
performance. Implementation of RPS support in DOS/VSE utilizes virtual
storage to enable you to use RPS to avoid recompiling or relink-editing
your problem programs. The partition GETVIS area is used to generate an
extension to the DTF, and the shared virtual area is used to hold the RPS
phases which are used in lieu of the logic modules of LIOeS.
Efficient use of RPS depends on each channel program's ability to free
that channel so that it can service requests for other devices. Programs
using DOS/VSE DASD LIOeS access methods will have RPS channel
Chapter 2: Planning the System
2.35
programs built by the access method. Programs using PIOCS for DASD
access have to be recoded to include Set Sector CCWs and to establish
arguments for the CCWs. If this is not done, these programs will destroy
the effectiveness of RPS by monopolizing the channel.
The RPS phases are loaded into the SVA by IPL if you have specified
RPS= YES in the FOPT generation macro.
Figure 2-6 shows the organization of a user's program running in virtual
storage without RPS support.
Figure 2-7 shows how, with RPS support, this organization will be
modified when the pertinent file is opened to put the DTF extension in the
partition GETVIS area. The pointers to the RPS phases which are used in
lieu of the logic module and channel program will be put into the DTF
while the non-RPS logic module and channel program addresses will be
saved in the DTF extension. The DTF extension will be freed and the
pointers restored to their original values when the file is closed.
DASD File Support for 3330-11 and 3350. Sequential or direct-access files
can be created and accessed on the 3330-11 and 3350 disk devices in the
same way as on other mM DASDs if the pertinent program has so been
written. However, to access these devices from programs that were written
to create and access sequential and direct-access files on other mM DASD
types (such as 2314 or 3330-1), do one of the following without
recompiling or reassembling your programs:
•
Specify RPS= YES in the FOPT generation macro for supervisor
assembly. With RPS support, DOS/VSE is able to access the 3330-11
or 3350 even if the original program specified a different device.
•
If you have DOS/VSE or Release 34 of DOS/VS installed, relink your
programs. This makes them capable of accessing the 3330-11 or 3350.
The sequential disk and direct access logic modules are able to handle
all CKD disk types.
2.36 DOS/VSE System Management Guide
T
USER PROGRAM
DTF
NON-RPS CCW STRiNG
NON-RPS LOG IC MODULE
I
+
+
r---------------NON-RPS CHANNEL PROGRAM
NON-RPS
LOGIC MODULE
r----------------VIRTUAL STORAGE
}
Partition
GETVIS
area
~------------------------~
FIgUre 2-6. User Program R.unning in Vutual Storage without RPS Support
USE R PROG RAM
DTF
RPS CCWSTRING
RPS LOGIC MODULE
w
(!)
«a:
-------------NON-RPS CHANNEL PROGRAM
(not used)
o
I-
en
...J
NON-RPS
I-
LOGIC MODULE
(not used by RPS DTF
but available to other DTF)
«
::::>
a:
:;
~---------------- ....
NON-RPS CCW STRING
NON-RPS LOGIC MODULE
-----------DTF EXTENSION
j
~~~~~A~NE=-PROGR~j-
Partition
>GETVIS
area
FIgUre 2-7. User Program Running in Virtual Storage using RPS Versions of
Logic Module and Channel Program
Chapter 2: Planning the System 2.37
1/0 Options
Channel Queue
The channel queue (CHANQ) is used by DOS/VSE to schedule I/O
operations. DOS/VSE builds an entry in the channel queue whenever a
request is made for an I/O operation and the entry remains in the queue
until the operation has completed. Thus, at any point in time, the queue
consists of entries for I/O operations in progress and I/O operations
waiting for initiation. Whenever an I/O event completes, the queue is
examined to see if another entry exists for the channel, and if so, the
operation is initiated. The number of channel queue entries to be reserved
in the supervisor can be specified in the CHANQ parameter of the lOTAB
macro.
The number of occupied entries in the channel queue depends on the
activity in the system and no accurate formulas for determining the
optimum size can be given.
Specifying too small a channel queue will cause performance
degradation, too large a channel queue value will waste storage space.
Tasks or programs that request an I/O operation when the channel
queue is full will be set in the wait state until an entry becomes free.
To avoid performance degradation it is better initially to specify ample
channel queue space, and reduce the allotted space later, if desired. Given
below is a rule-oJ-thumb that you may follow:
•
Specify at least one queue entry for each I/O request that can be
issued concurrently (open files per job step per partition).
•
Specify one entry for the SYSRES file and one for the page data set.
•
Specify one entry for each task or partition in the system.
•
Specify one entry for each console buffer in the system.
•
If multiple volume files are used on the system, specify one entry for
each file being accessed at the same time.
•
Add two entries per tape drive.
•
Specify one entry for each teleprocessing line that could solicit input. If
mM 2260 local or 3270 local video display units are to be supported
by BTAM-ES, specify one entry for each display.
•
Add five entries to the total for contingencies.
When the system has been generated, run as many programs as represent
the heaviest work load; in particular, run any teleprocessing programs.
Then, before the next IPL, obtain a formatted dump of virtual storage.
An analysis of the channel queue should show that entries near the
beginning of the table have been used, whereas those near the end are
unused. Although the unused entries are normally redundant, a few surplus
entries should be retained to allow for exceptional cases. If all the entries
2.38 DOS!VSE System Management Guide
have been used, then the channel queue was almost certainly too small, and
a process of experimentation will show the correct size.
Figure 2-8 shows the channel queue as displayed in a formatted dump.
Refer to DOS /VSE Serviceability Aids and Debugging Procedures for
information on obtaining a formatted dump.
***
FRFF LT 5T
A8DR
0123P4
0123D4
0123F4
012414
01;>434
012454
012474
012494
01?4H4
0l:?4D4
O12-.F4
012')14
012534
012')54
012574
O12c;Q4
012'5'14
012<:;D4
0125F4
012614
PGS
0)
01
02
03
04
0')
06
C7
08
Oq
OA
O~
f'C
CO
(;E
ct:
lei
11
12
13
P(JPHE~
(HAl1\!
PTR
03
FF
as
01
00
06
07
08
09
OA
eCB
ADDR
I!)
30
20
OC[550
50
40
0(10:)00
06A~b8
000000
0001)00
OOf)OOO
000000
000)00
0D
OE
OF
10
OOGOOO
F-F
R.E~
OA6568
087D68
000000
11
12
13
QUFur TARLF
***
02
06
ac
CHANN~L
000000
00,)000
000')00
000')00
000000
OI)C)'}O
oor~ooo
000000
FLr; LUIj 'SI(
NfJ
10
00
00
00
00
04
m
FF
FF
0::
F~
FF
FF
FF
FF
FF
t:~
FF
Fe:
FF
FF
Fe:
FF
04
03
04
04
00
00
FF
OJ
00
00
00
FF
00
00
00
FF
FF
FF
OC
t:~
I:-F
0)
FF
FF
00
00
FF
0')
FF
00
00
F-F
FF
30
20
50
50
40
FF
FF
FF
FF
FF
FF
FF
FF
FF
FF
FF
FF
F;::
FF
FF
TRANSMIT FIX
INFORMTN FLG
F I XL 1ST
8BOOOO,)0
88000')00
330000')0
880000'10
BBOOOO00
00000000
0)0000')0
()I)OOOc.oo
(10000000
1),)0000,')0
000000 110
0')000000
f)')000000
0')000000
8·)000001)
00000000
00000000
onoooooo
')0000000
000000CO
01~144
00
00
00
00
00
00
00
00
00
00
0(')
00
00
00
00
00
00
00
00
00
AOOR
01'3168
000000
018180
01B120
00001)0
ooooao
1)000')0
000000
000000
000000
000000
000000
001)000
000000
000000
000000
000000
<)00000
000000
I NFORMA nON
USFD INTERNALLY
00014C7400000000
00014C7400000000
0001401COOOOOOOO
00014C7400000000
00014C7400000000
0000000000000000
OryOOOOOooooooooo
0000000000000000
0000000000000000
0000000000000000
000000-0000-000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000:)00000000000
0000000000000000
0000000000000000
0000000000000000
000000000000001)0
ACCUMULATED C5W
INFORMA nON
0000000000000000
0000000000000000
000029500C40OC40
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
000-0-0-00000 00 0000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
000000000001)0000
0000000000000000
0000000000000000
0000000000000000
An unused entry wi II have an F F in this location
Figure 2-8. Channel Queue Table
Supervisor Buffers for I/O Processing
Supervisor buffer space is used for the handling of I/O requests from
programs that execute in virtual mode. You specify the number of buffers
via the BUFSIZE parameter of the VSTAB generation macro.
The amount of buffer space required is dependent on the number and
type of concurrent 110 requests. The number of entries that you specify in
the channel queue table can be used as a guide. Generally three times the
number of channel queue table entries will give a sufficient number of
buffers. If ISAM is the predominant access method used or if you have
generated RPS support, you should increase the number of buffers by 20%.
Because your supervisor must end on a 2K boundary, any space
between the end of the supervisor and the next 2K boundary will be used
for I/O buffers in addition to the amount you specify in the VSTAB
generation macro.
To determine whether or not you specified a sufficient number of
buffers, use a technique similar to the one suggested for an analysis of the
channel queue. While running as many programs as represent your heaviest
work load, issue the DUMP command specifying the begin and end
addresses of the buffer area in the supervisor; if all blocks have been used,
then probably too few buffers were specified.
The use of the buffers is different in ECPS:VSE and 370 mode.
Chapter 2: Planning the System 2.39
ECPS:VSE Mode. The buffers are called work blocks, and they have a size
of 36 bytes each. DOS/VSE uses the work blocks to store information
about your channel program and the I/O areas for that channel program.
The information will be used to fix in processor storage your I/O areas,
channel program and control blocks until the I/O request has been
satisfied. The information stored is referred to as a fixlist. For example,
DOS/VSE needs one workblock per I/O request for an FBA type DASD
and two or more such blocks per I/O request for a CKD type DASD.
If you are writing your own channel programs it is suggested that you
use the IORB macro rather than the CCB so that your channel program
will contain a fixlist; processing will then be faster. For more information
about these two macros, refer to DOS/VSE Macro Reference.
370 Mode. In 370 mode the buffers are called copyblocks and have a size
of 72 bytes each. DOS/VSE uses the copy blocks to keep a copy of your
channel program and control blocks in the supervisor area.
Your channel program refers to virtual addresses and these addresses
must be translated to reflect the processor storage locations that your I/O
area(s) actually occupy. (The translation is necessary since 370 mode does
not support relocating channels which can do the address translation.) Once
your channel program is translated, the I/O area(s) are fixed in processor
storage and the translated channel program is given to the channel for
execution. If you have installed the licensed program VSE/VSAM the
minimum number of buffers you should specify is 40. To execute
DOS/VSE system utility programs, DOS/VSE needs up to 38 copy blocks.
Bypassing System Translation of I/O Addresses. In most instances, double
buffering techniques and an increase in block size can significantly reduce
the system overhead associated with channel program translation. However,
in extreme cases, you may wish to perform your own translation of channel
programs and thereby avoid system CCW translation overhead. Programs
that might require this are EXCP programs that have very high start I/O
rates and that repeatedly use the same channel programs.
DOS/VSE provides support that assists in the translation of channel
programs. This support allows you to use the VIRTAD and REALAD
macros as well as the REAL parameter of the EXCP macro. You must
obtain processor storage by means of the PFIX macro and then translate
the channel program. For detailed information see DOS/VSE Macro User's
Guide and DOS/VSE Macro Reference.
The Fast Translate or Fast Function Option. You may specify
F ASTTR= YES in the FOPT generation macro. This creates a supervisor
with fast-function support in ECPS:VSE mode and fast-translate support in
370 mode.
The feature works essentially the same way in both ECPS:VSE and 370
mode. That is, the supervisor buffers used for an I/O request are not
released when the I/O request is completed. The buffers are saved and the
referenced I/O areas are fixed in processor storage until the end of job.
This can speed I/O processing if your program has frequent repetitive I/O
requests. The overall effect on your DOS/VSE system is subjective,
however.
2.40 DOS/VSE System Management Guide
The page pool is decreased in size because the I/O areas remain fixed.
Additionally, more supervisor buffers are required than without this support.
In ECPS:VSE mode specify, as a rule of thumb, a number of buffers that is
9 times the number of channel queue entries and in 370 mode 6 times the
number of channel queue entries.
If you do not specify enough buffers or the page pool becomes too
small, the saved buffers and fixed I/O areas are released as required by
DOS/VSE.
Specification of FASTTR= YES may cause degradation of performance
when CICS/VS accesses SAM, ISAM arid DAM files.
Error Queue
The error queue option is of value to installations using a large number of
I/O devices, for instance, teleprocessing systems. The ERRQ parameter of
the FOPT generation macro allows you to specify the number of error
queue entries within the error recovery block of the supervisor. These
entries are used to record information on I/O device errors, and this
information is used by the ERP and RMSR routines. The normal default
value is five entries, but in ERRQ you can specify up to 25.
Reliability/A. vailability/ Se",iceability
DOS/VSE includes routines that analyze and record CPU, channel, and
device errors and attempt to recover from them. The data is stored on the
system recorder file (SYSREC). The information obtained from this file
serves not only as an aid in diagnosing machine errors, but also helps mM
customer engineers to increase reliability, availability and serviceability
(RAS) of your system.
If on-line recovery is impossible, the system may be placed in a hard
wait state. A message is then issued to the system operator to run either the
SEREP or EREP program to obtain the diagnostic data.
On the mM System/370 Models 115 and 125, errors in the CPU and
natively attached input/output devices (for example, card reader/punch,
disk and printer) are recorded on the system diskette (see note). This
hardware error recording is independent of the software routines. The
recorded hardware statistics may be obtained on the video display unit
(DOC), on advice of the mM customer engineer, through the LOG
ANALYSIS displays. Error recovery for channel-attached input/output
devices for these CPU models requires the use of software routines with
error recording on SYSREC, known a recovery management support
(RMS). DOS/VSE Serviceability Aids and Debugging Procedures contains
more detailed information about the various RAS features discussed below
in context with a discussion of RMS.
Chapter 2: Planning the System 2.41
Note: IBM System/3 70 Model 158 and the IBM 3031 have a similar
hardware error recording feature in addition to a software error recording
facility.
Recovery Management Support
These routines, referred to as RMS, are standard for all /370 and 4300
processors except for the System/370. Models 115 and 125. For these
models, specify the RMS parameter of the SUPVR generation macro to
obtain the RMS support of your choice.
If full RMS support is included (RMS= YES is specified or forced for
models 135 and above), the following RAS facilities are provided:
•
Machine Check Analysis and Recovery
•
Channel Check Handler
These facilities provide hardware error analysis and attempt recovery.
Another RAS facility, the Recovery Management Support Recorder
(RMSR) provides for recording of error and operational statistics on
SYSREC as follows:
•
Machine Check (CPU)
•
Channel Check
•
Unit check
•
Tape/ disk error statistics by volume
•
MDR (Miscellaneous Data Recorder)
•
IPL information
•
End-of-Day statistics held in main storage
Device ERP routines are standard for all CPU models. For models 115 and
125, if full RMS support is not desired, RMSR support for channel attached
devices, tape units, and TP devices is still included even if you specify
RMS=NO. Specification of RMS=NO will cause the system to enter a
hard wait on the occurrence of a hardware failure with no recording on
SYSREC. However, the system diskette will contain error recordings for
the CPU and natively attached devices: If your installation plans to use
DASD switching, RMS= YES must be specified.
RMSR has several options that may be specified during supervisor
assembly. These options involve the tape error statistics and error volume
analysis.
Tape Error Statistics. As a standard feature the DOS/VSE system gathers
tape error statistics. This information is accumulated in the PUB2 table for
each tape unit and stqred in the system recorder file SYSREC. For tapes
with standard labels the information is accumulated and stored per volume.
When error statistics are required to enable the monitoring of nonstandard
or unlabeled tapes, the TEBV parameter of the FOPT generation macro
gives you two options: the parameter can be specified as IR (individual
2.42 DOS/VSE System Management Guide
recording) or as CR (combined recording). IR refers to the accumulation of
error statistics between two consecutive OPENs on the same tape unit. CR
refers to the accumulation of error statistics ori the same tape unit until a
standard labeled tape is opened on that unit or uiltil a ROD command is
issued.
Error Volume Analysis. This option ,of RMSR enables you to specify the
number of temporary read/write errors thatoccur on a tape volume before
an informatory message is printed on SYSLOG. The threshold value of
temporary read/write errors is specified in the EVA parameter of the
FOPT generation macro.
Defining the System Configuration
During supervisor generation you must code various generation macros that
relate to the central processing unit, to the portability of your system and to
the I/O devices installed (or planned to be installed).
Central Processing Unit
In ECPS:VSE mode, there is no need for specifying a CPU model. In 370
mode, you must specify which central processing unit is to be used. The
specification is made in the MODEL parameter of the CONFG generation
macro.
H you plan to run your generated system on more than one CPU
model, you may specify any of the models you plan to use. However, you
must take the following precautions:
•
restrict yourself to one CPU-mode. For example, it is not possible to
generate a supervisor to be run either on a System/370 or on a 4300
processor in ECPS:VSE mode.
•
ensure disk support that fits all configurations you plan to use.
•
if you have a display operator console (DOC) installed, this DOC must
be compatible with the DOC support of your generated supervisor.
Note that the 3210/3215 printer keyboard is always supported.
Therefore, if you specify DOC=3277 in the FOPT generation macro,
for example, your actual console must not be a 125D; it can only be a
3277 DOC or a 3210/3215 printer keyboard.
•
ensure RMS support, except if you plan to stay with /370 Models
115/125. For example, if you specify MODEL =125 and you plan to
run your supervisor on a Model 138, specify RMS=YES.
•
specify the larger range of channels in the DASDFP parameter, if you
use DASD file protection.
Chapter 2: Planning the System
2.43
Display Operator Console Support
In ECPS:VSE mode, 3277 is the standard operator console support. In 370
mode, the DOC parameter of the FOPT generation macro determines the
operator console support in the supervisor. The following discussion
pertains to 370 mode only.
If you do not specify the DOC parameter, the following defaults apply:
MODEL (in CONFG macro)
Default
115, 125
1250
138, 148, 158, 3031, 4300 (in 370 mode)
3277
135, 145, 155-11
NO
(3210/3215 printer
keyboard support)
A specification other than the default is not checked or changed to the
default. For example, MODEL= 158, DOC=NO gives a supervisor that is
generated for the 158 with console support in 3210/3215 printer keyboard
mode.
I/O Devices
The supervisor generation macros that relate to the I/O devices attached to
the CPU are: PIOCS and IOTAB. These macros are discussed below.
The PIOCS generation macro defines the I/O configuration that is to
be supported. The associated parameters involve the channel switching and
disk device support.
The lOTAB generation macro, in general, defines the area for the
necessary device tables for the system. The parameters involved refer to:
•
The number of programmer logical units for each partition defined by
the NPARTS parameter in the SUPVR macro.
•
The number of job information blocks for the system. One is required
whenever a temporary or alternate assignment is made.
•
The number of DASD devices separate for each mM DASD type
included in your system configuration.
•
The number of tape devices.
Other devices like the mM 3800 Printing Subsystem, the mM 3886
Optical Character Reader, or the mM 3540 Diskette Reader.
•
The number of telecommunication devices (Models 115/125 only).
•
The estimated number of physical I/O devices.
2.44 DOS/VSE System Management Guide
Before you can actually use your I/O devices, you must define each unit to
the system, specifying its characteristics such as channel and unit address,
device type, its mode (if applicable). You do this via the ADD command at
the time of Initial Program Load (IPL).
A supervisor generation macro is not available for t}ljs pu..rpose.
Nevertheless, because the definition of your I/O devices is likely to remain
stable over a longer period, you should already at the time of system
generation give some thought to the sequence of ADD commands you are
going to use. The total number of ADD commands must not exceed the
total number of devices specified in the IODEV parameter of the lOTAB
generation macro.
Furthermore, physical I/O device addresses must be assigned to logical
unit names, via the / / ASSGN job control statement or job control
command (no / I). You cannot make these assignments at the time of
supervisor generation, even though you may want to have them remain
unchanged for a longer period of time.
Definition and assignment of I/O devices is described in sections
Starting the System and Controlling Jobs within Chapter 3, Using the
System.
Emulators
Through emulation, a program written for execution on a 1400 series
machine can be executed under DOS/VSE. The emulator program, serving
as the interface between the user program and the DOS/VSE supervisor,
runs together with the user program in the same partition.
Several emulators can be executed concurrently. One exception,
however, is the Model 125, which cannot execute two 1400-series emulator
jobs concurrently. To use a 14xx emulator on a Model 125, RPQ SU002 is
required.
Tape reading and writing on 1400-series machines can operate with odd
or even parity checking. If you will be using a 1400-series emulator and
mixed-parity tape processing, you must specify EU =YES in the SUPVR
generation macro.
Prior to executing emulator jobs, you must generate the emulator
program and catalog it into the core image library. This can be done when
the system is generated or at a later time.
For more information about available emulator programs see the
publication Introduction to DOS /VSE.
Chapter 2: Planning the System 2.45
Chapter 3: Using the System
This chapter is intended primarily for programmers who are responsible for
optimum system throughput and for servicing the installation's libraries. The
topics discussed are:
Starting the System - describes the initial program load (IPL) procedure.
It also describes how to create the file required for recording error
information, how to allocate storage to a partition, and how to start a
foreground partition.
Controlling Jobs - describes the required input to the job control
program, which controls the execution of a job; it includes a brief
discussion of label processing.
Linking Programs - -describes -the input t-O the linkage erutm program,
which links the modules produced by language translators, produces
executable phases and places them in the core image library.
Using the Libraries - provides the information on how to alter, copy, and
inspect the contents of the libraries. It also describes how to allocate space
to the libraries and how to create private libraries.
Starting the System
Before a job can be submitted to DOS/VSE for execution, the supervisor
must be read into processor storage and the job control program must be
loaded into the background partition. To do this, the operator starts
DOS/VSE by following the initial program load (IPL) procedure.
On a 4300 processor the amount of virtual storage available can be
altered during IML (Initial Microprogram Load) which is done prior to the
IPL procedure. Refer to section Virtual Storage Size in Chapter 2,
Planning the System, and also to the Operator's Library Procedures manual
for the pertinent CPU model.
This section describes the use of the IPL commands. The exact formats
of these commands are contained in DOS/VSE System Control Statements
and DOS/VSE Operating Procedures. This chapter also provides a
summary of the automatic functions of IPL; descriptions of how to load the
shared virtual area, and how to create the system recorder file (SYSREC)
and the hard copy file; a section on the optional user exit routine for
user=defined processing after IPL; and a section on enter.ng data into
SYSREC.
You must perform the IPL procedure each time you have to do one of
the following:
•
Load a new supervisor (for normal system start-up, for different
supervisor options, or to recover from a system malfunction. For the
last, refer to DOS/VSE Serviceability Aids and Debugging Procedures).
•
Modify the shared virtual area size.
Chapter 3: Using the System 3.1
Add devices to or delete them from the system configuration.
•
Set or change the time-of-day clock value.
•
Set or change the system's time zone value.
•
Change the channel and unit assignment of the system residence
(SYSRES), the VSE/VSAM master catalog (SYSCAT), SYSREC, or
the page data set due to hardware problems with the channel or disk
drive.
Create SYSREC (for the first time or because of hardware problems).
•
Replace SYSRES or the page data set because of a hardware problem
with the pack.
Initial Program Loading (IPL)
For IPL, you place the system residence disk pack on a disk drive and set
the address of that drive in the load unit switches, ready SYSLOG and the
device containing the page data set and press LOAD on the console (on the
video display/keyboard console, type in the address of the drive and press
ENTER).
Next, DOS/VSE enters the wait state. You now must indicate to
DOS/VSE the device that is to be used as the operator console (SYSLOG).
To do so, press the Request key (or END/ENTER) on the selected device.
This causes an interrupt and automatically transmits the address of this
device to DOS/VSE. (If you have installed an IPL communication device
list, DOS/VSE accepts the interrupt only if the address of the device is
contained in the list). IPL assigns SYSLOG to the device. This assignment
remains valid until the next IPL.
At this point, DOS/VSE requests you to specify the supervisor you
want to be used. You indicate this by one of the following:
•
pressing ENTER or the Request key
•
entering supervisomame[,P I N](,LOG I NOLOG]
Pressing ENTER or the Request key indicates that the pageable default
supervisor is to be loaded ($$A$SUPl,P,LOG).
Specifying P causes the loaded supervisor (default or your own) to have
certain routines pageable; specifying N causes the loaded supervisor (default
or your own) to be non-pageable. If, on entering the supervisor name, you
specify neither P nor N, P will be assumed.
3.2 DOS/VSE System Management Guide
By setting the list-option to NOLOG, you can prevent IPL from listing
the IPL commands on SYSLOG. If you don't specify the list-option, LOG
will be taken as default; that is, all IPL commands are listed on SYSLOG.
Invalid commands are always listed.
IPL now reads the supervisor into low processor storage from the core
image library. If an irrecoverable error is sensed while reading the
supervisor, an error message is displayed on SYSLOG; the hard wait status
is entered and an error code is set in the first four bytes of processor
storage. The IPL procedure must then be restarted. For more information
on wait states, refer to DOS/VSE Serviceability Aids and Debugging
Procedures.
EstabHsbing the Communications Device for IPL
DOS/VSE again goes into a wait state with all interrupts enabled (see
Note). At this time you must indicate which device is to be used to
communicate the IPL commands to the system. The specific manual
operation you must perform depends on the selected device:
•
If you wish to use the console (SYSLOG), press the Request key on
the console. (On the video display/keyboard console, you can press the
Enter key, the Request key, or the Cancel key.)
•
If you wish to use a card reader, ready this card reader. DOS/VSE
then assigns SYSRDR to this device for the duration of IPL.
•
If you wish to use an mM 3540 Diskette I/O Unit, ready it.
DOS/VSE assumes that the file IJIPL is part of the diskette and that it
contains the IPL commands in card image format (unblocked 80 byte
records).
Note: Because any interrupt will (on a first-come basis) establish the issuing
device as the IPL communication device, it is advisable that TP installations
and terminal-oriented installations with locally attached terminals, (for
example, IBM 3277) install the IPL-phase $$A$CDLO. (See IPL
Communication Device List)
IPL Commands
IPL commands serve to set or change various characteristics of your system.
They operate on the following items:
I/O configuration
ADD and DEL commands
System date and time
SET command
System disk file assignments
DEF and DPD commands
Shared Virtual Area size
SVA command
ADD and DEL commands should precede all other commands; the SVA
command is the last command to be submitted.
Chapter 3: Using the System 3.3
The ADD Command. Use the ADD command to define all your input and
output devices to your system. This definition specifies for a device the
channel and unit address, the device type, the mode (if applicable), and
whether automatic channel switching is desired.
Each individual drive of a DASD (of a 3333/3330 or 3310, for
example) requires an ADD command. Note that if one physical spindle
contains two or more logical spindles, ADD commands must be issued for
each of these logical spindles.
The following requirements should be kept in mind:
•
You can add a device only if sufficient device table space was provided
via the lOTAB generation macro during supervisor assembly.
•
If DASD file protection was generated in the supervisor and you add a
CKD DASD, the DASD must conform to the channel range specified in
the DASDFP parameter of the FOPT generation macro.
If any of these requirements is not satisfied, you will get an appropriate
error message. You must then provide space in the control blocks for the
additional device by:
•
deleting unnecessary devices of the type you want to add and then
re-issuing the ADD command, or
•
re-assembling the supervisor.
Note:
For an mM 3031 CPU, one service record file 7443 must be
defined. This allows DOS/VSE to access the system diskette on the
service support corisole. After having created the system recorder
(SYSREC) file and encountered the first / / JOB statement,
DOS/VSE reads machine check frames ·and channel check frames
from the service record file and writes them onto the SYSREC file.
Those frame records will be available as input for the
Environmental Recording Editing and Printing (EREP) program
when that program is executed.
The DEL Command. Use the DEL command to drop an I/O device from
the configuration you had established via ADD commands; this may be
necessary if, for example, you defined (ADDed) more devices than you had
allowed yourself in the lOTAB .generation macro, or if you want to correct
the device type for one of the preceding ADD commands. Because all
references to the device are removed, any subsequent ASSGN job control
statement that refers to a deleted device will not be accepted.
The Set Command. You can use the SET comm_and to set the system date,
the time-of-day clock, and the system time zone. If you specify a
time-of-day clock setting, set the time-of-day clock switch to the "enable
set" position at the exact time specified in the SET command. The SET
command is required only if the time-of-day clock has not been set. If this
is the case, a message at IPL will prompt the operator.
The DEF Command. You use the DEF command to assign the SYSCAT,
.- ·····:i and SYSREC files. This command is mandatory.
3.4 DOS/VSE System Management Guide
The SYSCAT file, the VSAM master catalog, is required if you have
the licensed program VSE/VSAM installed. If you don't have VSE/VSAM
installed, specify DEF SYSCAT=UA. SYSREC is the symbolic name used
for the system recorder file, the hard copy file and the "
Creation of these files is discussed later in this section. "
The DEF command must be submitted after any ADD and DEL
commands and prior to the SVA command. The ASSGN job control
statement or command is not valid for::;'• • •i'::SYSCAT or SYSREC
assignments.
The DPD Command. The DPD command is used to define the disk
attributes of your page data set. The operands of the command allow you
to specify
•
a device address.
•
the beginning address of the disk e~tent.
•
the disk volume ID.
•
whether or not the page data set should be formatted.
Because formatting tpe page data set is time-consuming, you should request
it only if the pack was damaged. The first time you use the page data set, it
will be formatted automatically. '
'.
The page data set can re~ide on any DASD supported by DOS/VSE as
a system residence device. To help ensure better performance, the page
data set should not reside on a pack that is subject to heavy I/O requests.
The DPD command is mandatory. It must be submitted after any ADD
and DEL commands and prior to the SVA command.
Chapter 3: Using the System
3.5
1he SVA Command. This command must be the last IPL command
submitted. The SVA command may be given with or without parameters.
The command's parameters (SOL, PSIZE, GETVIS) are used to
increase the SVA size beyond the size set by the DOS/VSE IPL routine.
They serve to add space for
•
System Directory List (SOL) entries
•
phases that you want to have loaded into the SVA
•
the system GETVIS area.
H the parameters are not specified during IPL, no user SDL or phase space
is reserved in the SVA for user phases. An SVA will be allocated which is
large enough to contain:
•
Phases required for use by OOS/VSE.
•
Phases required for installed licensed programs.
•
The default system GETVIS area.
•
Required SDL entries.
3.6 DOS/VSE System Management Guide
Automatic Functions of IPL
performs the following
•
Builds the required control blocks and device tables.
•
In 370 mode, determines the size of the real address space.
•
Unassigns any DASD assignments for devices that are not operational
at this time (so as to prevent the error recovery routines from trying to
establish error recording statistics for these devices).
•
Loads the printer-control buffers with the installation defined standard
buffer images.
•
Initializes the DOS/VSE RMS routines.
•
Loads into the SVA required system phases and licensed program
phases.
After IPL completes these operations, the system loader loads the job
control program into the background partition and places the system in the
problem program state. The message "READY FOR COMMUNICAnONS" appears on the console immediately after IPL is complete.
IPL Communication Device List
For telecommunication installations and for installations with locally
Chapter 3: Using the System
3.7
attached terminals (such as the mM 3277), devices allowed to present an
interrupt during IPL should be restricted because an unsolicited interrupt
might interfere with your system start-up procedures. By installing an IPL
communication device list, you can avoid that a device outside the
operator's control establishes itself as the device used for submitting IPL
commands.
To build a restrictive pool of IPL communication devices, you assemble
an IPL communication device list (COL) and catalog the list under the
phasename $$A$COLO in the system core image library. During IPL,
OOS/VSE loads this phase (if present) into storage. When OOS/VSE
enters the wait state and an interrupt occurs, the COL can now be searched
for the address of the device issuing the interrupt. H the address is listed,
the interrupting device is accepted as an IPL communication device and
processing continues. H the address is not found, OOS/VSE remains in the
wait state. Installation of the COL is optional.
For IPL to be successful, once $$A$COLO is installed, the SYSLOG
device address must be present in the COL. H you intend to submit IPL
commands from card reader or diskette, you must enter their addresses in
the COL as well. To ensure backup in case of hardware errors during IPL,
consider stand-by devices, such as another card reader, diskette, or even an
additional SYSLOG device in the COL.
The COL may have up to eight entries each of which is four bytes
long:
Bytes
Ireserved Icc
luu
o
3
2
where: cc = channel number
uu = unit number
You create the COL by submitting a job that catalogs $$A$COLO into the
system-core image library. The example in Figure 3-2 creates a COL with
five entries:
II JOB CATALOG CDL
II OPTION CATAL,NODECK
PHASE $$A$CDLO,+O
II EXEC ASSEMBLY
$$A$CDLO CSECT
DC
DC
DC
DC
DC
END
XL4'00C'
XL4'009'
XL4'01F'
XL4'OBD'
XL4'240'
card reader
1052
SYSLOG (DOC)
3277
diskette
1*
I I EXEC LNKEDT
/&
Figure 3-2.
Example for the Creation of a CDL
Once phase $$A$COLO has been cataloged, the CDL addresses remain
effective for subsequent IPLs. However, you may:
3.8 DOS/VSE System Management Guide
•
Replace the phase by another one, either by assembling and link-editing
a new phase or by using the DOS/VSE MAINT program to rename an
already cataloged CDL that has a name other than $$A$CDLO.
•
Override any CDL entry by manual intervention, which is the suggested
approach should an erroneous CDL be cataloged in the core image
library. The procedure for manually overriding the CDL is given in
DOS/ VSE Serviceability Aids and Debugging Procedures.
Building the SDL and Loading the SVA
Automatic SVA Loading
DOS/VSE builds a fresh copy of the SVA at each IPL. It loads phases into
the SVA from the system core image library. DOS/VSE uses pre-defined
load lists to fitJ,d the a,pprQPriate pnases. The load lists_ that identify r-equir-ed
system phases are shipped in the system core image library ready for use at
IPL. DOS /VSE System Generation contains a listing of the required system
phases.
H you install an mM licensed program that includes SVA eligible
phases, you must catalog a load list for that licensed program. The licensed
program documentation will describe this procedure and tell you how much
space in the SVA the loaded phases require. Although DOS/VSE
automatically allocates sufficient SVA space (by checking the load lists),
you should know how much virtual storage will remain to be allocated to
the partitions. (In 370 mode, your specification in the VSIZE parameter or
the VSTAB generation macro is dependent on this information.)
BuDding the System Directory List (SOL). Entries in the SDL are copies of
specific system core image library directory entries. Having entries in the
SDL speeds up the loading of the corresponding phases.
At the time of IPL, DOS/VSE builds entries in the SDL for each phase
that it automatically loads into the SVA. Each of those entries contains a
pointer to the associated phase in the SVA.
User Options for the SVA
In order to load user chosen elements into the SVA (phases or SDL entries
or both) the SVA space must be made large enough to accommodate the
new entries. Space for user entries may be defined at IPL via the SVA
command (see The SVA ComJr.ar.d earlier in this section). The SET SDL
command is available for having DOS/VSE both build an SDL and load
phases into the SVA.
You should build SDL entries for certain frequently used DOS/VSE
phases that are not SVA eligible. DOS/VSE provides a procedure (its name
is SDL) that you should execute at the time of IPL. For a listing of the
phases referenced by procedure SDL, refer to DOS/VSE System Generation.
DOS/VSE does not automatically reserve SVA space for these SDL entries.
In order to do that, you must define space with the IPL command SVA.
Chapter 3: Using the System 3.9
The SET SDL Command. The command used to create SDL entries and to
load phases in the SVA is the SET SDL job control command. This
command can be given only in the background (BG) partition. The
command may be given at any time after IPL. There is no limit to the
number of times it may be given.
It is recommended that you create a SET SDL job stream, catalog it as
a procedure in the procedure library and run that procedure immediately
after IPL. For compatibility with DOS/VS, SET SDL=CREATE will be
accepted by DOS/VSE. H the SET SDL job stream is not being entered
through a procedure, it may be submitted to job control through SYSRDR
or SYSLOG (depending on the device from which job control is reading).
This job stream can be entered via the IPL communications device. Figure
3-3 illustrates such a job stream.
Following the SET SDL command the input should be in the format
of:
name[,SVA]
where name is any valid phase name and SVA indicates whether or not the
phase is to be loaded into the SVA. H you specify SVA and the phase is
SVA eligible, DOS/VSE loads that phase.
The phases need not be currently cataloged in the core image library
and, if they are not, DOS/VSE issues a message on SYSLST (or SYSLOG
if SYSLST is not available). H you subsequently catalog a phase into the
system core image library under a name listed in the SDL as uncataloged,
the entry in the SDL is activated. In this case, if the phase is also identified
in the SDL as eligible for the SVA, it is loaded there immediately after it
has been link-edited.
H duplicate phase names are submitted, only the first one is valid. For
example:
SET SDL
PHASEONE
PHASEONE, SVA
/*
If PHASEONE exists in the system core image library, DOS/VSE builds an
SDL entry. The phase is not loaded into the SVA; DOS/VSE recognizes
statement PHASEONE, SVA as a duplicate and rejects it. In the above
situation no message is issued to the operator. H the statements were
submitted in two separate job streams;
SET SDL
PHASEONE
/*
SET SDL
PHASEONE,SVA
/*
an error message would be issued saying that an entry already exists in the
SDL.
3.10 DOS!VSE System Management Guide
You will be able to place PHASEONE in the SVA the next time you
IPL. The SVA (and of course the SDL) is rebuilt at each IPL.
It is recommended that you run the librarian program DSERV after a
SET SDL job stream to be certain that all entries have been entered the
way you wish. Include the DSERV control statement DSPLY SDL.
Replacing Phases Stored in the SVA. Occasionally, a phase stored in the
SVA needs to be changed; that is, it must be replaced by an updated
version. To replace a phase in the SVA, linkedit the updated version of the
phase to the system core-image library. Immediately after this linkedit
operation, DOS/VSE loads the updated phase into the SVA. The old
version of the phase remains in the SVA, but is not addressable.
Linkediting for inclusion of a phase in the SVA is further discussed in
Linking Programs in this chapter.
Creating the System Recorder File
The DOS/VSE recovery management support requires a disk extent on
which to record statistical information about machine errors and
environmental information. This disk extent is caned the system recorder
file and is identified by the symbolic name SYSREC. The SYSREC file
must exist before job control encounters the first / / JOB statement after
IPL. Usually, you create the SYSREC file only after the first IPL following
a system generation (not aiter each IPL). If the SYSREC file has been
damaged, however, you must re-IPL and re-create SYSREC.
If your DOS/VSE is running on an mM 3031, the SYSREC file must
be evaluated via program IFCEREPI and recreated each time a hardware
(microcode) change is installed which affects the frame records on the
3031's Service Record File. For details on IFCEREP1, refer to OS/VS,
DOS/VSE, VM/370 Environmental Recording Editing and Printing
(EREP) Program.
Chapter 3: Using the System 3.11
On a CKD device the SYSREC file requires a minimum of ten tracks
(not including an alternate track), and it cannot be a split cylinder file. On
an FBA device the SYSREC file requires a minimum of 72 blocks of 512
bytes each. You must define SYSREC as an extent of a permanently online
ru.slc device that DOS/VSE supports as a system residence device.
The ffiM 3031 requires additional space on the recorder file to
accomodate machine check frames and channel check frames (these frames
are peculiar to the ffiM 3031). On an ffiM 3330, for example, this space
amounts to approximately 9 tracks. If the SYSREC file resides on an FBA
device with blocksize of 512 bytes, add 164 blocks. The exact amount of
additional space needed for the recording of those frames can be calculated
after the first / / JOB statement has been processed and message '11931
RECORDER FILE IS XX% FULL' is issued.
The SYSREC file label information must be included in the standard
label portion of the label information area on the SYSRES file. Therefore,
submit a / / OPTION STDLABEL statement when you create the SYSREC
file. Since the label information you sub~t is written at the beginning of
the standard label area, which overwrites label information that was present
there, you must resubmit all the information needed for subsequent
operation. A more detailed description of preparing standard label
information is given under section Controlling Jobs later in this chapter.
Figure 3-3 illustrates a job stream (via SYSLOG) to create the system
recorder file. The IPL commands are included in the figure to show the
proper placement of the statements that create the SYSREC file. Be sure
that you do not submit a / / JOB statement until you have supplied all the
information applicable to SYSREC. This is because the SYSREC file is
opened when the first / / JOB statement is encountered. Note that the file
name IJSYSRC is required in the DLBL job control statement.
3.12 DOS/VSE System Management Guide
01301 DATE= .. / .. / .. , CLOCK= .. / .. / •.
0110A GIVE IPL CONTROL COMMANDS
ADD .. .
ADD .. .
e
ADD .. .
SET .. .
DEF SYSREC=190
DPD
SVA
01201 IPL COMPLETE FOR DOSIVSE REL. nn.n ECLEVEL=01
BG 1100A READY FOR COMMUNICATIONS
BG SET SOL
1S511 ENTER PHASE NAME OR /*
BG USERONE
1S511 ENTER PHASE NAME OR /*
BG USERTWO,SVA
1S511 ENTER PHASE NAME OR /*
BG
BG
BG
BG /*
BG ASSGN
BG SET RF-CREATE
!
BG // OPTION STDLABEL
BG // DLBL IJSYSRC:DOS.SYSTEMRMSR.FILE' - - -...._ Submit with the rest of the
STDLABEL statements
BG // EXTENT SYSREC, , , , 1700,43
BG /*
BG II JOB FIRST
Figure 3-3.
Example for the Creation of the SYSREC File and for Loading
User Phases in the SVA
When the system is to be shut down, you should issue the Record On
Demand (ROD) command to ensure that no statistical data is lost. For a
370 Model 115 or 125, the U command of the mode select display, should
also be issued to save disk usage statistics on the system diskette. These
commands are not valid for recording statistics on telecommunication
operation; refer to the appropriate telecommunication guides for more
information.
To obtain a listing of the SYSREC file, run the EREP program as
described in OS/VS, DOS/VSE, VM/370 Environmental Recording
Editing and Printing (EREP) Program. During execution of the EREP
program, recording on SYSREC is suppressed.
Chapter 3: Using the System
3.13
Creating the Hard Copy File
On a system that supports a video display/keyboard console, all messages
displayed on the screen and all information typed in by the operator are
saved in a file on the device assigned to SYSREC. This file, called the hard
copy file, can be used to obtain hard (printed) copies of the file whenever
required.
You must create the hard copy file after the first IPL procedure and
before you submit the first / / JOB statement to DOS/VSE.
The control statements and commands needed to create the hard copy
file are the same as those shown in Figure 3-3 for the SYSREC file with
the exception that you specify HC=CREATE in the SET command, and
the filename DSYSCN in the DLBL job control statement. More
information about creating and printing the hard copy file is given in
DOS/VSE Operating Procedures and DOS/VSE System Utilities.
User-Defined Processing after IPL
At large DOS/VSE installations, it may be desirable to perform certain
processing at the end of an IPL procedure. It may, for instance, be
important to know who performed the procedure, whether the right system
pack was mounted, and whether the correct date was entered for the new
work session. Moreover, if you work with labeled data files it is important
that they bear the correct creation date, so as to guarantee that data files
are protected until their expiration date.
After the IPL procedure has been completed, control can be passed to
a user exit routine (phase name = $SYSOPEN) that you may include for
the purpose of checking system security and integrity. This routine is
entered once after every IPL procedure. The DOS/VSE distribution
volume contains a dummy phase $SYSOPEN in the system core image
library. If you do not use the facility, that phase has no effect on your
system. Conventions for writing this kind of user exit routine, together with
an example, are contained in the section Writing an IPL User Exit Routine
in Chapter 4, Using the Facilities and Options of DOS/VSE.
Entering RDE Data
Standard DOS/VSE support includes the reliability data extractor (RDE),
and DOS/VSE requests you by a message to SYSLOG to provide a
2-character IPL reason code when the first / / JOB statement after IPL is
processed. The system may have been started at the beginning of normal
operation or restarted because of a machine error, a program error, an
operator error, etc. In addition, DOS/VSE requests you to supply a
subsystem identifier, a code which identifies the device type or program
type that failed. On the basis of these replies job control will build a record
for SYSREC.
Before shutting down at the end of the day (or processing period), you
must ensure that no environmental data is lost, by issuing the ROD
command. This command also causes the RDE end-of-day record to be
written on the disk assigned to SYSREC. To obtain a listing of this file, run
3.14 DOS/VSE System Management Guide
the EREP program as described in OS/VS, DOS/VSE, VM/370
Environmental Recording Editing and Printing (EREP) Program.
RDE information can be very valuable to your operations management.
By replying with the exact reason code that applies in each case, you are in
fact ensuring a permanent record of the reason why you had to re-IPL.
Refer to the DOS/VSE Operating Procedures, for more information on
the RDE messages and the valid replies to them.
Allocating Address Space to the Partitions
For each partition specified in the NPARTS parameter of the SUPVR
generation macro, address space must be allocated. The address space
available to the partitions is all of the address space from the end of the
supervisor area to the beginning of the SVA. The minimum size of that
address space is SI2K.
Allocation of address space to a foreground partition must be done
explicitly. Space not.allocated to a foreground partition belongs to the BG
partition. IT no allocations are made, for example immediately after IPL,
then all available address space belongs to the BG partition. In this case,
the BG partition has the following size:
ECPS:VSE mode:
Virtual storage size (16M default or as specified at
Initial Microprogram Load)
minus supervisor size
minus SVA size;
370 mode:
Virtual address space size (VSIZE value of VSTAB
macro)
minus SVA size.
Through the use of the job control ALLOC command you allocate the
foreground partitions. Address space allocations are in multiples of 2K.
The minimum amount of address space that may be allocated to a partition
(explicitly or implied) for execution in virtual mode is 128K. This 128K size
includes a minimum partition GETVIS area of 48K.
IT a foreground partition is defined (via the NPARTS parameter of the
SUPVR generation macro), but not needed for a while, you can set its size
to OK by submitting an appropriate ALLOC command.
During certain periods of processing, the operator can modify the
allocations to the individual partitions, again by using the ALLOC
command. Details on the ALLOC command are given in DOS / VSE
Operating Procedures and in section Starting the System in Chapter 3.
Chapter 3: Using the System 3.1S
Allocating Processor Storage to the Partitions
Processor storage is allocated to the partitions to enable the following:
•
Program execution in real mode.
•
Fixing pages by means of the PFIX/PFREE macros.
When processor storage is used for running a program in real mode or for
fixing pages of a program running in virtual mode (for example,
VSE/POWER), the page pool is reduced by the number of page frames
required for real mode execution or page fixing, respectively. Because
reducing the page pool may reduce total system throughput, the use of real
mode execution and PFIX/PFREE macros should be carefully considered.
Processor storage is allocated to the partitions via the ALLOCR
command. For a partition's allocation to be affected the partition identifier
(BG, F 1, F2, ... ) must be specified. The allocation is made in multiples of
2K, with 2K being the smallest allocation permissible. Absence of the
partition identifier means: do not change the current allocation. An
allocation of 2K allocates one page frame, 20K allocates 10 page frames
etc.
Note:
In 370 mode, when the ALLOCR command is issued, the
system delineates real address space as well as allocating
processor storage frames. In 370 mode, programs executing real
execute in the real address space.
The size of a given processor storage allocation for a partition is determined
either by the largest program you must run in real mode, or by the
maximum number of pages a program may fix. The number of pages that
can be fixed by the PFIX macro is limited by the amount of processor
storage allocated to that partiton.
Given: ALLOCR BG=20K, F3=10K
with the above allocation you could PFIX 10 pages in BG (while executing
in BG) or 5 pages in F3 (while executing in F3). You could not PFIX 15
pages from one program in either partition without reallocating processor
storage.
Page Pool. The page pool is all processor storage beyond the resident
supervisor routines. When you use the ALLOCR command you are
potentially reducing the size of the page pool. The page pool is not reduced
until the processor storage page frames are taken for real mode execution
or for PFIX use in virtual mode. The minimum page pool size is 24K. H
you allocate processor storage to partitions you must ensure that at least
24K remain unallocated. A program running in virtual mode that needs
more than 6K for its I/O processing requires a corresponding increase of
the minimum page pool size.
3.16 DOS/VSE System Management Guide
Initiating Foreground Partitions
In order to initiate a foreground partition, at least 128K of virtual
storage must be allocated to that partition. The allocation is made after IPL
with the ALLOC job control command.
Since DOS/VSE automatically determines the size of the SVA at IPL,
it is recommended that you issue the MAP command prior to any virtual
storage allocation. The MAP command will display the current allocations
and you can determine the amount of virtual storage available for allocation
to the foreground partitions.
The ALLOC command is both a job control and an attention routine
command. (The attention routine is loaded when you press the Request key
on the console keyboard; that routine is in control of the system when AR
is dlSpiayed on SYSLOG.) When the ALLOC command is given through
the attention routine it cannot decrease the size of an active partition. The
initial allocation of foreground partitions decreases the size of the BG
partition because all available virtual storage is allocated to BG at IPL.
Since, after IPL, the BG partition is active, the ALLOC command must be
given through job control.
Once virtual storage is allocated to the foregound partitions, they may
be made "active" through the attention routine. Issuing the BATCH or
START command, specifying a foreground partition, causes DOS/VSE to
initiate that foreground partition. For example:
AR BATCH F1
causes the job control program to be loaded into the virtual storage
allocated to the F 1 partition.
Input may now be submitted to the F 1 partition. Submitting jobs is
described in the following section, Controlling Jobs.
Chapter 3: Using the System 3.17
3.18 DOS/VSE System Management Guide
Chapter 3: Using the System 3.19
3.20 DOS/VSE System Management Guide
Chapter 3: Using the System
3.21
3.22 DOS/VSE System Management Guide
Chapter 3: Using the System
3.23
3.24 DOS!VSE System Management Guide
Controlling Jobs
Mter DOS/VSE has been successfully started by means of the IPL
program, the following messages are displayed on the console:
BG lIOOA READY FOR COMMUNICATIONS
BG
This shows that the job control program is in the background partition
ready to accept input.
At this poirit, the job control program will accept commands submitted
through the console (SYSLOG). Job control's normal input source,
however, is the logical unit SYSRDR.
Job control reads from SYSRDR if, at this point, you depress the
ENTER key on the console without entering any commands. Normally,
SYSRDR is standardly assigned to a card reader or diskette device.
The unit of work that is submitted to DOS/VSE for execution is called
a job. A job, and the environment in which it is to run, must be defined to
the system through job control statements and commands. These job
control statements and commands are processed by the job control program
which DOS/VSE loads into storage automatically as required.
The job control program runs in virtual mode in any partition. It
performs its functions only between jobs and job steps, and is not present
in the partition while a problem program is being executed.
Mter each job control statement or command is read, control can be
given to a user exit routine for examining and altering the input before it is
processed by DOS/VSE. For a description of this facility refer to Chapter
4, Using the Facilities and Options of DOS/VSE.
The difference between job control statements and commands are not
discussed here because there is no need for a distinction in this section.
Whenever applicable, it is simply stated whether the function can be
performed using statements, commands, or both. The description of the job
control statements and commands in this section is limited to their use and
functions; formats and characteristics of statements and commands are
detailed in DOS/VSE System Control Statements.
This section describes how to define a job, how to relate files to a
program, and how to work with cataloged procedures.
De/ining a Job
The beginning and end of a job are defined by the JOB and / &
(end-of-job) statements.
Chapter 3: Using the System 3.25
The program to be executed in a job is requested through an EXEC
statement. The occurance of an EXEC statement is called a job step. Each
job may consist of one or more job steps.
You may include as many job steps in a job as you wish. However, it is
not advisable to execute, in one job, several programs that are completely
independent of one another because, if one step terminates abnormally, the
job control program ignores the remaining job steps up to the next / &
statement. A typical example of related job steps that should form a single
job are assembling, link-editing, and executing a program, where correct
execution of one job step depends on successful completion of the
preceding one. Figure 3-6 shows an example of a multistep job.
1
II JOB jobname
2
3
II EXEC PAYROLL
3
II EXEC CHEX
4
1&
1
Defines the beginning of a job. For jobname, you may specify a name of
your own choosing.
2
Additional job control statements if required.
3
The two job steps. Job control is reloaded into storage at the end of each
job step, enabling the reading of subsequent job control statements.
4
At the end of the CHEX program's execution job control is reloaded and
reads the end of job indicator.
FJgIU"e 3-6.
Control Statements Def"miDg a Job Consisting of Two Job Steps
Following are some additional details about the job and end-of-job (/ &)
statements. The EXEC statement is discussed later in this chapter.
The JOB Statement. The JOB statement indicates the beginning of control
information for a job. The specified job name is stored in the
communications region of the corresponding partition and is used, for
example, by job accounting and to identify listings produced during the
execution of the job.
3.26 DOS/VSE System Management Guide
IT the JOB statement is omitted, DOS/VSE uses NO NAME as the job
name. IT the JOB statement is without a job name it is rejected by job
control as an invalid statement. The JOB statement should not be omitted,
as many DOS/VSE functions assume its presence. IT, for example, the
operator cancels a job using the attention routine CANCEL command, the
job control program normally bypasses all statements on SYSRDR until
encountering a / & . However, if the job in question was submitted without
a JOB statement, no statements in the job stream are bypassed even though
job NO NAME was canceled.
Having JOB statements with specific job names is useful when you
issue the MAP command in a multiprogramming environment. The MAP
command displays on SYSLOG the storage allocations for each partition,
together with the name of a job that is currently active in the corresponding
partition.
The JOB statement is always printed in positions 1 through 72 on
SYSLST and SYSLOG; also, the time of day is printed The JOB statement
causes a skip to a new page before printing is started on SYSLST.
The End-of-Job (/It) Statement. This statement is the last one for each job
(not job step). It signals the end of the input stream for the job. When job
control encounters / & on SYSRDR during normal operation, the
permanent assignment for SYSIPT becomes effective and SYSIPT is
checked for an end-of-file condition.
IT the / & statement is omitted, the next JOB statement will cause
control to be transferred to the end-of-job routine to simulate the / &
statement, except for abnormal job termination.
When a job terminates abnormally all statements on SYSRDR are
bypassed until / &. A JOB statement preceding that / & statement does
not stop this bypass operation.
When a / & statement is encountered, the job control program
performs such operations as the following:
•
Resets all job control options for the partition to standard: either as
established by the SIDOPT command, or the system default if the
particular option was not set through a SIDOPT command.
•
Resets all system and programmer logical unit assignments for the
partition to the permanent assignment established by job control
commands. Logical unit assignment is discussed under Relating Files to
Your Program later in this chapter.
•
Modifies the communications region as follows:
1. Resets the date from the DATE statement to the one specified in
the SET command during IPL.
2.
Stores the job name NO NAME.
3. Sets the user area and the UPSI byte to zero.
•
Displays an end-of-job (EOJ) message on SYSLST and SYSLOG with
the time and duration of the job.
Chapter 3: Using the System 3.27
•
Ensures that end-of-file has been reached on SYSIPT.
•
Deletes the temporary labels in the label information area on SYSRES.
(See Storing Label Information, later in this chapter.)
•
Checks whether the condense limits of any of the libraries have been
reached (if library maintenance has been done in the job).
Job Streams
The job control program provides automatic job-to-job transition. In other
words, an unlimited number of jobs can be submitted to the system in one
batch, and job control processes one job after the other without requiring
intervention by the operator. The job or jobs submitted are referred to as a
job stream (see Figure 3-7 for an example of a payroll jobstream).
( 1&
( II
( II
EXEC PAYCHK
-
PAUSE LOAD PAYCHECKS
~
( 1*
~
(
( II
( II
(II
( II
( II
Time cards
EXEC PAY RUN
I--
EXTENT SYSOO 1
I--
ASSGN SYSOO 1 , 160
'"
[~/_I_J_U_B_I_JA_Y_1
__________
L
!--
ASSGN SYSLST,OOE
FJgUre 3-7.
~
DLBL FILEP, 'PAYFILE'
~~
Example of a Job Stream
When setting up a job stream for a partition, you should bear in mind that
all jobs will get the priority of that partition. The selection of the jobs for a
particular partition in a multiprogramming system can help to improve the
efficiency of your installation. For example, jobs which have a relatively
low CPU usage and a relatively high rate of I/O activity, and which
therefore spend most of their time waiting for the completion of I/O
operations, should run in a high priority partition. Conversely, CPU-bound
jobs should be in a partition with a lower priority.
3.28 DOS/VSE System Management Guide
The operator may interrupt the processing of a job stream in any
partition to make last-minute changes to one of the jobs or to squeeze in a
special rush job. He does this by using the PAUSE statement or command.
A PAUSE statement may be included anywhere among the job control
statements of a job stream (see Figure 3-7). It becomes effective at the
point where it was inserted; processing is suspended in the aiiected
partition, and the operator console is unlocked for input. The PAUSE
statement can contain instructions to the operator and is always displayed
on SYSLOG.
The PAUSE statement may also be helpful when SYSIN is assigned to
a 5424 or 5425 card reader (neither of which have an end-of-file button).
Place the / / PAUSE card after the last / & card; this will force control to
be given to the console-keyboard, which enables the console operator to
control subsequent system operation.
A PAUSE command may be entered either through the operator
console (after pr-essin-g the r-equest k-ey), Of within a joo st-ream t-{}g-et-ber
with the job control statements for a job. If entered through the console to
the attention routine, the command must specify the partition that is to
pause (if the background partition is intended, however, no operand is
required). After encountering a PAUSE command, DOS/VSE passes
control to the operator (through the console) into the specified partition, at
the end of the current job step (which may also be the end of the job). If
that PAUSE command specifies the EOJ operand, control passes to the
operator at the end of the current job, regardless of the number of steps
needed to reach that point.
Relating Files to You, Program
Most programs perform some kind of input/output operation (that is, they
process files) on auxiliary storage devices. Before such files can be
processed, certain information about them must be provided to DOS/VSE.
This information includes:
•
The address of the I/O device on whicli each of the files resides.
•
For files on direct access storage devices (DASD), the exact location of
the file on the storage medium.
•
For files on DASDs, on diskettes, or on labeled magnetic tape, a
description of the file, called a label, which is used for checking and
protection purposes.
The above information, specified in job control statements, is stored in the
system by the job control program for use by the DOS/VSE data
management routines. How this is done is described below.
Chapter 3: Using the System 3.29
Symbolic I/O Assignment
Whenever a processing program needs access to a file on auxiliary storage
the program need not specify an actual device address, but only a symbolic
name which refers to a logical, rather than physical, unit. Before the
program is executed that logical unit must be associated with an actual
device. This is done by DOS/VSE when it executes an ASSGN job control
statement or command which specifies the symbolic name of the logical unit
and one of the following:
•
A general device class or specific device type, with or without volume
serial number.
•
The physical address (channel and unit number) of the I/O device.
•
A list of physical addresses.
•
Another logical unit.
See Figure 3-8 for an illustration of some of these combinations.
ASSGN statements may be submitted
between jobs or job steps.
3.30 DOS/VSE System Management Guide
Processing Program
DEVADDR=SYS008
I
,,
Job Control
,
1
I
// ASSGN SYS008,OOE
I/O Device
1.
The logical unit specified in the processing program (via DTF or CCB or IORB) is
a print file referred to by the symbolic device name SYSLST.
2.
An ASSGN statement is used to associate SYSLST with the physical address OOE of
a printer. This information is stored in the system by job control and can be
accessed when a program is executed.
FJgUre 3-8.
Example of Symbo6c I/O Assignment (Part 1 of 2)
Chapter 3: Using the System
3.31
Processing Program
DEVADDR=SYS002
Job Control
II ASSGN SYS002,(130,131)
e
II ASSGN SYS003,3330,VOL=oooo03
0
II ASSGN SYS004,TAPE (9
o
«9
(9
Device list - if drive 130 is unassigned SYS002 will be assigned to it, if it is
assigned DOS/VSE tries 131.
Device type - DOS/VSE searches for the device type (3330 in this case)
that is available and has the volume-id 000003.
Device class - DOS/VSE searches for an available tape device.
FlgUl"e 3-8.
Example of Symbolic I/O Assignment (Part 2 of 2)
Logical Units
There are two types of logical units: system logical units, primarily used by
the system control and service programs, and programmer logical units,
primarily used by the processing programs. The following list shows the
names, logical units and the 1/0 device~ that each of these logical units can
represent. In the case of disk devices, the logical unit is not assigned to the
entire volume mounted on the device but only to the referenced extent(s).
Refer to the section Files on Direct Access Devices for more information on
disk files.
3.32 DOS/VSE System Management Guide
Logical
unit name
Type of I/O device
SYSRDR
Card reader, magnetic tape unit, disk device, or diskette used as
input unit for job control statements or commands.
SYSIPT
Card reader, magnetic tape unit (single volume), disk, or
diskette extent used as input unit for programs.
SYSPCH
Card punch, magnetic tape unit, disk, or diskette extent used as
the unit for punched output.
SYSLST
Printer, magnetic tape unit, disk, or diskette extent used as the
unit for printed output.
SYSLOG
Operator console used for communication between the system
and the operator.
SYSLNK
Disk extent used as input to the linkage editor.
SYSRES
System residence extent on a disk pack.
SYSCLB
Disk enent used f-era private oor-e imag€ library.
SYSSLB
Disk extent used for a private source statement library.
SYSRLB
Disk extent used for a private relocatable library.
SYSREC
Disk extent used to store error records collected by the
recovery management support recorder (RMSR) function. If a
display operator console (DOC) is installed, messages to or
from the operator are stored in the hard copy file, a separate
SYSREC extent so that a hard copy listing of these messages
can be produced. A third SYSREC extent holds the system
file.
SYSCAT
Disk extent used to hold the VSAM master catalog.
SYSCTL
Used by DOS/VSE.
SYSnnn
Format for coding programmer logical units which are discussed
later in this section.
System Logical Units. All of the above logical unit names, except SYSnnn,
represent system logical units. Of these system logical units, user-written
programs may use SYSIPT and SYSRDR for input, SYSLST and SYSPCH
for output, and SYSLOG for communication with the operator. All other
system logical units may not be used within user-written programs (or
EXTENT statements, which are discussed later in this section).
Two additional symbolic names, SYSIN and SYSOUT, are used under
certain conditions:
SYSIN .
Can be used if you want to assign SYSRDR and SYSIPT to
the same card reader pr magnetic tape unit. You should not
assign SYSRDR and SYSIPT to the same disk or diskette
extent, assign SYSIN to that extent instead.
SYSOUT
Must be used if you want to assign SYSPCH and SYSLST to
the same magnetic tape unit. SYSOUT cannot be used to
assign SYSPCH and SYSLST to disk or diskette because these
two units must refer to separate extents.
Chapter 3: Using the System 3.33
SYSIN and SYSOUT are valid only to job control and cannot be referenced
in a user-written program. Examples for the use of SYSIN and SYSOUT
are given in the section System Files on Tape, Disk, or Diskette later in this
chapter.
Prognunmer Logical Units. Programmer logical units may be assigned to any
device installed 011 the system used for processing program input and
output. Each partition has a minimum of 10 programmer logical units
(SYSOOO-SYS009) and a maximum of 241 (SYSOOO-SYS240). The number
of programmer logical units is a supervisor generation option.
Types of Device Assignments
Device assignments are either permanent or temporary, depending on the
time of the assignment and the type of ASSGN statement or command
used.
Permanent Device Assignments. A permanent assignment is set up between
jobs or job steps any time after IPL by the ASSGN job control command
(no / /) or the / / ASSGN job control statement with the PERM operand.
It is valid until the next IPL procedure unless superseded by another
ASSGN job control command. A permanent assignment can be changed for
the duration of a job or job step by a / / ASSGN statement or by an
ASSGN command with the TEMP option.
Temporary Device Assignments. A temporary assignment is established
either by a / / ASSGN statement or by an ASSGN command with the
TEMP option. It is valid for a single job only, unless superseded by another
temporary or permanent assignment. Temporary assignments are reset to
permanent by
•
a / & or JOB statement, whichever occurs first, or by
•
a RESET job control statement or command.
Restrictions: The type of device assignment is restricted under certain
conditions:
1. If one of the system logical units SYSRDR, SYSIPT, SYSLST, or
SYSPCH is assigned to a disk device or diskette, the assignment must
be permanent. If SYSCLB is assigned, its assignment must also be
permanent.
2. If SYSRDR and SYSIPT are to be assigned to the same disk or diskette
extent, SYSIN should be assigned instead, and this assignment must be
permanent.
3. SYSOUT, if used, must be a permanent assignment.
4. The SYSLOG assignment is restricted when IPL was done from either a
125D or 3277 device. You may not assign SYSLOG to a 125D if IPL
was done from a 3277 and vice-versa.
3.34 DOS/VSE System Management Guide
Device Assignments in a Multiprogramming System
_.,-_._--------------------\. Each partition hasitsownset~t~ystem 10gi~~~lP!!!§:.1 For example, the BG
.
- ' - " . _ - - - - _ ..
-.
._-
.
_
.. -.-,
.
-. . ..
_"
-, partitionhas"a-SYSRDlr;'SYSLST, SYS1PT~et~~'" as~ do all the other
generated partitions. As each partition is started, assignments must be made
for the system logical units. Some assignments need be made only in one
partition and are valid for all partitions. These are logical units that service
the system rather than one partition. The page data set (assigned via the
DPD command) and the following units fall into this category:
logical name
how assigned
SYSLOG
ASSGN job control command
SYSREC
DEF IPL command
SYSCTL
automatically assigned by DOS/VSE
SYSRES
Entering disk address at IPL
SYSCAT
DEF IPL command
All of the other system logical unit assignments must be made for each
individual partition.
E..~h partition also has its own set ~tP.~~N~I!!m~I.!~~£31 ~~ (SYSOOO
through SYSnon) where non is the number of programmer logical units
specified for the partition minus 1.
You must make assignments of the programmer logical units as needed
by the programs running in each partition. Certain mM supplied programs
require specific programmer logical unit assignments. For example the
linkage editor requires SYSOO 1 and the assembler requires SYSOO 1,
SYSOO2, and SYSOO3.
Sharing Assignments. Within the same partition, different logical units may
be assigned to the same physical device. For example:
II ASSGN SYSLST,OOE
II ASSGN SYS007,OOE
Both logical names SYSLST and SYSOO7 are assigned to the device at
address OOE.
Normally it is not possible to share physical devices (except DASD)
between partitions. For example if you have a tape drive assigned to the
BG partition, but not used by that partition, you must first unassign it in
BG before attempting to assign it in F2. If, however, you use a spooling
package, such as the licensed program VSE/POWER, you can share unit
record devices (card reader, card punch, for example) and diskette between
partitions (see the licensed program VSE/POWER documentation for more
details).
With direct access devices this problem does not exist because each
extent on a disk can be thought of as a separate device. It is not possible,
however, to share a diskette between partitions.
Figure 3-9 illustrates possible device assignments.
Chapter 3: Using the System
3.35
6)
BG
I
SYSOO5
F21
SYSOO5
Fll
SYSOO5
BG
SYSOO5
F2
SYS006
F1
SYS007
BG
SYS005
BG
SYSOO6
BG
SYSOO7
·U
·U
·U
191
192
193
191
280
Each partition has its own set of programmer logical units.
Each assignment must be for a separate extent on the disk for this example to
be valid. Extents are discussed under Processing of File Labels in this chapter.
These assignments allow access to the tape volume by three different logical
unit names. No assignments to this tape are valid from a partition other than
BG at this ti me.
FlgUl"e 3-9.
Possible Device Assignments
Figure 3-10 shows the logical units needed for an assembly. The illustration
shows that the ASSGN statements must always precede the EXEC
statement of the job step for which they are to be effective. (The device
assignments for compilers are similar to the device assignments shown in
this assembler example; any variations are documented in the applicable
programmer's guides.)
3.36 DOS/VSE System Management Guide
r------,
I
__ l __ ~,
...
"-_
I
I
----
,..1.--,
,
~------~~
~
II EXEC ASSEMBLY
y'
I
I
I
~ __ .J
I
\
I
\
)
, -;'
,-
/&
Only if the program is to
be link-edited ~
...
I
:
.~-
II OPTION ....
r------,
/I ASSGN SYSLNK, ....
Only if an object deck ~
is desired
II ASSGN SYSPCH, ....
....
I
I
"I
I
~_...J
I
.L--J"::-,
f-----..~
I
1/ ASSGN SYSOO1, ....
/
. . _L..,
I
I
\'- __ .... )
,
II
I
I
/
£._-
r-----..,
I
.... __ .J __ .( . . .,
I
I
f,-----.. .r'__ ...J:
I
/_1.',
I
~
\
,I
\
L_-;'
I
I
J
~--
SYSLST
CPU
SYSRES
SYSOO1
SYSOO2
SYSOO3
SYSPCH
(Optional)
FtgUre 3-10. Device Assignments Required for an Assembly
Chapter 3: Using the System 3.37
Additional Assignment Consideratiom
The following summarizes the functions of the job control ASSGN
statement (or command). Also included are statements (commands) that
can be used with logical unit assignments.
The ASSGN Statement/Command. The ASSGN statement or command is
used to connect a logical I/O unit to a general device class, a specific
device type, a physical device or a list of physical devices, or another logical
unit. An ASSGN statement or command can also be used:
•
to specify a temporary or permanent assignment.
•
to specify a volume serial number for a tape, disk, or diskette.
•
to specify that a disk is shareable by more than one partition or logical
unit.
•
to unassign a logical unit to free it for assignment to another partition.
•
to ignore the assignment of a logical unit, that is, program references to
the logical unit are ignored (useful in testing and certain rerun
situations) .
•
to specify an alternate tape unit to be used when the capacity of the
original is reached.
The assignment routines check the operands of the ASSGN statement/
command for the relationship between the physical device, the logical unit,
the type of assignment (permanent or temporary), etc. The following list
summarizes the most pertinent items to remember when making
assignments:
•
Assignments are effective only for the partition in which they are
issued.
•
Apart from the operator console, no physical device except DASD can
be assigned to more than one active partition at the same time.
•
All system input and output file assignments to disk or diskette must be
permanent.
•
SYSIN .must be assigned if both SYSRDR and SYSIPT are to be
assigned to the same extent.
•
SYSOUT cannot be assigned to disk or diskette; it must be a
permanent assignment if assigned to tape.
•
SYSLNK must be assigned before issuing the LINK or CATAL option
in an OPTION statement; otherwise, the option is ignored and the
message 'PLEASE ASSIGN SYSLNK' is issued to the operator.
•
Before a tape unit is assigned to SYSLST, SYSPCH, or SYSOUT, all
previous assignments to this tape unit must be permanently unassigried.
This may be done byusing a DVCDN command as discussed below.
•
The assignment of SYSLOG cannot be changed while a foreground
partition is active.
3.38 DOS/VSE System Management Guide
•
SYSRES, SYSCAT, SYSREC,I• • • and the page data set can
never be assigned by an ASSGN statement or command. An IPL is
required to change these assignments.
The RESET StatementlCommand. The RESET statement or command can
be used to reset temporary assignments of a partition to permanent. With
one RESET statement or command you can reset
•
all logical units.
•
all system logical units.
•
all programmer logical units.
•
one specific system or programmer logical unit.
The LISTIO Statement/Command. With the LISTIO statement or command
you can obtain a listing of the current status of the 110 assignments in your
system. This may be done for all devices or individual devices as required.
If the LIS'fI()---oommann is used (no I I), the output goes to SYSLOG,
otherwise the output is on SYSLST.
The DVCDN Command. The DVCDN (device down) command informs the
system that a device is no longer physically available for system operations.
This command releases all logical assignments to the device.
wp.en the device becomes available again for system operations, a
DVCUP (device up) command must be given and new assignments made,
before the device may be used.
The DVCUP Command. The DVCUP (device up) command informs the
system that a device is available for -system operations after it has been
down.
Processing of File Labels
As shown above, DOS/VSE relates physical devices to logical names, used
in programs, via the ASSGN job control statement (or command). Certain
device types (magnetic tape, disk, and diskette) have removable volumes. It
is important to ensure that the volume(s) containing the filets) to be
processed are present on the assigned device(s). Magnetic tape, disk and
diskette files are identified through file labels which are processed by the
DOS lYSE data management routines.' Magnetic tape file labels are
optional, though desirable for reasons of data integrity. Disk and diskette
file labels are required.
DOS/VSE writes file labels when a file is created based on label
information submitted through job control statements.
To write a file label on magnetic tape, DOS/VSE uses the /1 TLBL
statement. This label is written by DOS/VSE immediately preceding the
associated file.
To write a file label on disk or on diskette, DOS/VSE uses the / /
DLBL and / / EXTENT statements. The label is written into the volume
table of contents (VTOC), and a utility program, LVTOC, is available to
Chapter 3: Using the System 3.39
list all labels included in this VTOC. Details on the DLBL and EXTENT
statements are given in DOS/VSE System Control Statements. When a
labeled file is to be processed, you must submit the required / / TLBL, / /
DLBL and / / EXTENT statements, so that DOS/VSE can perform the
desired label checking on your existing file. Figure 3-11 shows the
relationship of label information that you provide by the above mentioned
statements to file labels and programs. For a detailed discussion of label
processing, refer to DOS/VSE DASD Labels and DOS/VSE Tape Labels.
3.40 DOS/VSE System Management Guide
/I ASSGN SYS021,281
IITLBL PAYPMO,'PAY MARCH78'
II ASSGN SYS011,DISK, VOL=444444
II DLBL PAYROLL,'MASTER',99/365,SD
II EXTENT SYS011,1,0,100,50
Label I nformation provided
by the user is stored by
DOS/VSE in the label information area.
Label I nformation Area
Data Management Routines
Executing Program
OPEN PA VROLL,PAVPMO
The OPEN invokes the DOS/VSE ---------Data Management routines.
----------
The Data Management routines search the label information
for the file names PAYROLL and PAYPMO.
Once the label information is found, the file I D's MASTER
and PAY MARCH78 are searched for on the mounted
444444
Master
,,
,,
,,
,,
,
\
\
\
\
\
\
\
\
\
I
\
\
\
\
\
I
\
I
I
I
I
/
I
/
/
/
/
I
I
\
I
\
\
\
I
\
I
I
I
I
I
\
\
\
Data of File Master
(50 tracks)
Figure 3-11. File Label Processing
Chapter 3: Using the System 3.41
The / / TLBL, / / DLBL, and / / EXTENT job control statements may be
submitted with each execution of a given program that processes labeled
files. Job control temporarily stores these statements in the label
information area. A recommended alternative for frequently accessed files
is to permanently store the label information in the label information area.
The section Storing Label Information later in this chapter describes how
to permanently store label information.
When the program that processes the file is executed, the data
management routines of DOS/VSE access the label information
to write the appropriate labels onto the storage volume, and to check
that no unexpired files are overwritten, if the file is to be created, or
•
if an existing file is to be processed, to check the contents of the label
information area against the label(s) of the file to ensure, for example
that the correct volume is mounted.
The first two parameters of both the / / TLBL and / / DLBL statements
are the same:
II TLBL filename,'file-id'
II DLBL filename,'file-id'
The file!l~VJ~, is not part of the file label. You code a filename in your
prograni to 'identify your file.
•
In assembler language it is the DTF (Define The File) name.
•
In DOS/VS RPG
•
In DOS/VS COBOL it is the name specified in the SELECT clause.
•
In PL/I it is the identifier (with the Fn...E attribute) in the DECLARE
n it is the FILENAME.
statement.
•
In FORTRAN it is the file name associated with the data set reference
number.
The filename from your program is used as a search argument by the data
management routines in searching for label information in the label
information area. Accordingly you must code a matching fIlename in your
/ / TLBL or / / DLBL statements.
The file-i4 is part of the [tIe label. After the DLBL or TLBL
statements are located (based on filename), the file-id is used to:
•
create a label for an output file.
•
locate and check the labels of an input file.
3.42 DOS/VSE System Management Guide
Example of label checking:
II
II
II
*
II
II
II
JOB UPDATE
ASSGN SYS007,OOC
ASSGN SYS008,280
PLEASE MOUNT CURRENT ACCOUNTS RECEIVABLE TAPE
PAUSE
TLBL ACCT,'ACCTS.REC.FILE'
EXEC UPDATE
data cards
1*
II
II
II
II
II
1&
MTC REW,SYS008
ASSGN SYS010,280
ASSGN SYS007,OOE
TLBL ARFILE,'ACCTS.REC.FILE'
EXEC ARREPO~T
The two programs UPDATE and ARREPORT access the same file
'ACCTS.REC.FILE'. The two programs happen to use different file names
and different programmer logical units.
UPDATE opens a file named ACCT on logical unit SYSOO8 and
ARREPORT opens a file named ARFILE on SYSOI0. In both cases the
file accessed is ' ACCTS.REC.FILE'. If the two programs had used the
same file name and programmer logical units, one ASSGN statement and
one / / TLBL statement permanently stored in the label information area
would suffice.
Label Information for Fdes on Diskette Devices
After you have informed the system, via the ASSGN statement or
command, on which physical device the file is to reside, you must supply
the following information to allow the creation and checking of diskette
labels:
1. A description of the characteristics of the file. You specify this in the
DLBL job control statement.
2. The volume(s) the file is contained on. You specify this in one or more
EXTENT job control statements.
The label information you supply in the DLBL job control statement may
include the following:
•
The name of the file. This name must be identical to the correspOnding
file name specified in your program. For programs written in assembler
language, this would be the name of the DTF.
•
An identification of the file. This name is the one contained in the file
label on the diskette. It is associated with the file name via the DLBL
statement.
•
The expiration date of the file.
•
The type of access method used to process the file; always coded as
DU.
Chapter 3: Using the System 3.43
A diskette file consists of a data area on one or more volumes; each volume
contains only one data area for a particular file. For each of these data
areas, called extents, you must supply the following information on an
EXTENT job control statement:
•
The symbolic name of the device on which the volume containing the
file is mounted.
The serial number of the volume.
•
The type of extent; always coded as 1.
In the following example, the program CREATE creates a diskette (DU)
file named SALES that has a file-id of MONTHLY and is to be retained
for 30 days. The file comprises up to three diskettes. The diskettes have
the volume serial numbers 111111, 111112, and 111113, and are mounted
on the drive assigned to the symbolic device named SYSOO5.
II
II
II
II
II
II
II
JOB EXAMPLE
ASSGN SYS005,060
DLBL SALES,'MONTHLY',30,DU
EXTENT SYS005,111111,1
EXTENT SYS005,111112,1
EXTENT SYS005,111113,1
EXEC CREATE
If:.
The job control program checks the DLBL and EXTENT statements for
correctness and stores the supplied information in the label information area
on SYSRES for the durati6n of the job (see Storing Label Information
later in this chapter).
Label Information for Flies on Direct Access Devices
After you have informed the system, via the ASSGN job control statement
or command, which volume or physical device you want, you must supply
the following information to allow the creation and checking of DASD
labels:
1. A description of the characteristics of the file. You specify this in the
DLBL job control statement.
2. The exact location of the file on the storage medium. You specify this
in one or more EXTENT job control statements.
3. For non-sequential DASD files, the amount of storage in the partition
to be reserved for label processing.!'
.• You specify
~n11'1t"1",n.1 statement.
. information
'is needed by the linkage editor, the LBLTYP statement is discussed in
Linking Programs later in this chapter.
The label information you supply in the DLBL job control statement may
!Jtc1ude the following:
•
The name of the file ..This name must be identical to the corresponding
file name specified in your program. For programs written in assembler
language this would be the name of the DTF.
3.44 DOS/VSE System Management Guide
•
An identification of the file which may include generation and version
numbers of the file. This name is the one contained in the file label on
the storage device. It is associated with the file name via the DLBL
statement.
•
The expiration date of the file.
•
The type of access method used to process the file.
•
An indication of whether or not a data secured file is to be created.
•
The blocksize to be used for this file on an mM 3330-11 or 3350
device.
•
The control interval size (CISIZE) if your file is a sequential disk file
and resides on an FBA device.
A DASD file can consist of one or more data areas on one 9r more
volumes. For each of these data areas, called extents, you must supply the
following information on an EXTENT job control statement:
•
The symbolic name of the device on which the volume containing the
file extent is mounted.
•
The serial number of this volume.
•
The type of the extent. An indexed sequential file, for instance, can
consist of data areas, index areas, and overflow areas. For each of these
areas an extent must be defined, and its type (data, index, or overflow)
must be specified.
•
The sequence number of the extent within the file.
•
For CKD devices:
The number of the track (relative to zero) on which the file extent
begins.
The amount of space (in tracks) the file occupies.
•
For FBA devices:
The block number on which the file extent begins.
The amount of space (in blocks) the file occupies.
Examples for Submitting Label Information for DASD Flles. Here are a
number of examples of how to code the job control statements required to
create or access the labels for the various types and organizations of DASD
files. It is helpful if you are familiar with the formats of the DLBL and
EXTENT job control statements as described in DOS/VSE System Control
Statements. Detailed information on the possible organizations and access
methods for DASD files is given in DOS/VSE Data Management Concepts.
Sequentially Organized Disk Flies (Single Drive, Single Volume). In the
following example, the program CREATE creates a sequential disk (SD)
file named SALES that is to be retained until the end of 1979. The file
comprises one extent of 190 tracks on a CKD device, starting on relative
track number 1320. The disk pack has the volume serial number 111111
and is mounted on the drive assigfied to the symbolic device name SYSOO5:
Chapter 3: Using the System
3.45
II
II
II
II
II
1&
JOB EXAMPLE
ASSGN SYS005,D1SK,VOL=111111,SHR
DLBL SALES, 'ANNUAL SALES RECORDS',79/365,SD
EXTENT SYS005,111111,1,O,1320,190
EXEC CREATE
The job control program checks the DLBL and EXTENT statements for
correctness and stores the supplied information in the label information area
on SYSRES for the duration of the job or job step.
SequentiaDy Organized Disk Files (Single Drive, Multivolume). Assume that a
program.PROGlOO needs a sequential disk file located on three different
disk packs that are to be moUnted successively on the same device
(SYSOO5). The file consists of four extents on an FBA device: two on the
pack with serial number ()()()()20, one on pack 000100, and one on pack
000006. The following job stream shows the label statements required:
1
2
3
II
II
II
II
II
II
II
II
1&
JOB SAMLABEL
ASSGN SYS005,D1SK,VOL=000020,SHR
DLBL F1LNAME,'F1LE 1D',99/365,SD
EXTENT SYS005,000020,1,O,10,2010
EXTENT SYS005,000020,1,1,4000,lS10
EXTENT SYSOOS,000100,1,2,64,1300
EXTENT SYS005,000006,1,3,SO,636
EXEC PROG100
1
Orily one DLBL statement is required. For each extent one EXTENT statement
must be supplied in the sequence in which the extents are processed.
2
Logical Ioes in PROG100 opens the first extent using the file name and file ID in
the DLBL statement, and the logical unit and volume serial number in the first
EXTENT statement to locate the actual label on the disk pack. After PROG100 has
processed the first extent, logical IOeS opens the second extent, based on the
extent sequence number.
For the third extent, volume serial number 000100 is specified while the volume
currently mounted on SYSOO5 has the number 000020. The OPEN routine of
LIOeS notifies the operator of this discrepancy, and the operator can mount the
correct volume, at which time the OPEN routine regains control. The same is true
for the fourth extent.
3
The / & statement causes the label information stored in the label information area
to be cleared. Thus, if the next job requires the same file, the label statements must
be resubmitted (see Storing Label Information later in this chapter).
SequentiaDy Organized oa Files (Multiple Drives). This example has the
same requirements as the preceding 'Single Drive' example except that the
three volumes are mounted on three different drives. The required job
control statements are as follows:
3.46 DOS/VSE System Management Guide
II
II
II
II
1 II
II
II
II
II
2 II
JOB SAMLABEL
ASSGN SYS005,DISK,VOL=000020,SHR
ASSGN SYS006,DISK,VOL=000100,SHR
ASSGN SYS007,DISK,VOL=000006,SHR
DLBL FILNAME,'FILE ID',99/365,SD
EXTENT SYS005,000020,1,O,10,2010
EXTENT SYS005,000020,1,1,4000,1510
EXTENT SYS006,000100,1,2,64,1300
EXTENT SYS007,000006,1,3,50,636
EXEC PROG100
1&
1
All label statements submitted are identical to the 'Single Drive' example except for
SYSnnn in the EXTENT statements.
2
Logical IOCS opens each extent in the same way as described in the 'Single Drive'
example except that processing does not stop for removal and mounting of packs,
because enough devices are online to contain the file. A combination of this and
the 'Single Drive' example could be used to reduce handling time without
excessively increasing the total drive requirements.
OA Files. The program PROG t61 processes a direct access fite consisting
of four extents contained on three CKD disk packs. The three packs must
be ready at the same time. The following job stream shows the label
statements required to process the file:
1
II
II
II
II
II
II
II
II
II
II
JOB DALABEL
ASSGN SYS005,DISK,VOL=000065,SHR
ASSGN SYS006,DISK,VOL=000025,SHR
ASSGN SYS007,DISK,VOL=000002,SHR
DLBL FILNAME,'FILE ID',99/365,DA
EXTENT SYS005,000065,1,O,1320,190
EXTENT SYS005,000065,1,1,80,740
EXTENT SYS006,000025,1,2,50,906
EXTENT SYS007,000002,1,3,1275,64
EXEC PROG101
1&
1
The label statements follow the same pattern as for sequential files (described in the
preceding examples) except that the DLBL statement must specify DA to indicate
direct access.
Label Information for Flies on Magnetic Tape
Files on magnetic tape can be processed with or without labels. For tape
files with ffiM standard labels, the label information must be submitted
through the TLBL job control statement. (A tape file can also have
standard-user or non-standard labels; for th¢.se labels, n:oj<}l> control
statemeD;ts are required. ~ore"information on tape labels is given in
DOS/VSE Data Management Concepts).
The standard label information submitted in the TLBL statement may
include the following:
•
The name of the file. This name must be identical to the corresponding
filename (DTF name) specified in your program.
•
An identification of the file.
•
Creation date for input and expiration date (or retention period) for
output files.
Chapter 3: Using the System
3.47
•
The volume serial number of the tape reel that contains the file.
•
For files that extend over more than one volume, the sequence number
of the volume.
•
For volumes that contain more than one file, sequence number of the file.
•
The version and modification number of the fIle.
When a program that processes tape files with standard labels is to be
link-edited, you must supply a LBLTYP job control statement to define the
amount of storage required in the partition for label processing (see also
~"'·"'·'·b Plrn{!jranl.\' later inr.Jthisi·
•••
1
As with DASD files, the label information you supply in the TLBL job
control statement is checked and stored in the label information area on
SYSRES (see Storing Label Information, below).
Storing Label Information
Job control stores label information in the label information area. The label
information is stored temporarily (for the duration of one job or job step)
or permanently.
As label information is submitted, DOS/VSE acquires a portion of the
label information area which is referred to as a label subarea.
The minimum size of a label subarea is one track for a CKD device and
2K for an FBA device, the maximum size is the entire label information
area. There are three types of label subareas:
•
partition temporary subarea
•
partition standard subarea
•
system standard subarea
Label information stored in either of the two types of partition subareas
may be accessed only from the partition in which the label information was
originally submitted. Label information stored in the system subarea may
be accessed from all partitions. The type of subarea used is controlled by
the following three options of the OPTION job control statement:
Pt.~
-=.. UlRLABEL
PARSTD
3.48 DOS/VSE System Management Guide
causes all DASD, diskette, and tape label information to be
s.t,ored temporarilx for one job or job step. ~
information submitted between job steps overlays the label
iformation from the former job step. the label
informatIOn is written to a p.artition temporary subarsa (one
per partition) and is accessible only by the partition in
which it was submitted. It is a good idea to include all
TLBL, DLBL, and EXTENT statements in the first step of
a job (preceding the / / EXEC statement). If no option is
specified, or if the OPTION statement is omitted,
USRLABEL is assumed.
causes all DASD, diskette, and tape label information to be
stored permanently for all subsequent jobs. The label
information is written to a partition standard subarea (one
per partition) and is accessible only by the partition in
which it was submitted.
STDLABEL
Note:
causes all DASD, diskette, and tape label information to be
stored permanently for all subsequent jobs. The label
information is written to the system standard subarea and
is accessible by all partitions but can only be submitted in
the background partitiQ.n. This ensures that the system
standard label information is not updated simultaneously by
two partitions. Logical unit numbers contained in the
submitted label information must not be greater than the
highest logical unit number specified for background at
system generation.
When SYSRES is on an FBA disk device, DOS/VSE blocks
user-supplied label information before writing that information to
disk. Therefore, you should terminate your / / OPTION PARSTD
Of· I/OP'IlONSTDLABEL job stream witha./ / OPTION
USRLABEL statement. This ensures that all label information is
actually written to the label information area as permanent partition
or system standard labels. Labels in the system standard subarea
are accessible from other partitions only after they have been
written completely. The OPTION ,statement with USRLABEL
specified indicates to DOS/VSE that no further partition or system
standard labels will follow. The same effect is accomplished by a
/ & , / / JOB, or / / EXEC statement.
A partition can have only one temporary and one standard subarea at any
point in time. As the subareas are variable in size it is possible that disk
space is not available in the label information area when DOS/VSE
attempts to write label information. When this occurs a message will be
displayed on the console stating that the label area is exhausted. To clear a
subarea (in order to run the current job), you can do one of the following:
•
Submit a / & in another partition to clear that partition's temporary
subarea.
•
Submit a / / OPTION PARSTD followed by a / & in any partition to
clear that partition's standard subarea.
Do not clear the system standard subarea. If you find that the system
standard subarea is using more disk space than you want, reorganize your
label information area. For example if you have an application that always
runs in the same partition (such as the licensed program VSE/POWER) the
labels for that application should be put on that partition's standard label
subarea, not the system standard subarea.
During program execution, the DOS/VSE data management routines
search the label information area in the following sequence:
(1) user label information (partition temporary subarea)
(2) partition standard information (partition standard subarea)
(3) system standard information (system standard subarea).
It is important to distinguish between the conditions under which a label
option remains in effect and the conditions that govern the retention of the
Chapter 3: Using the System
3.49
label data in the label information area. For example, the label data.
submitted following an OPTION statement with the P ARSTD option is
retained for all subsequent jobs until overwritten by another P ARSTD
option, but the P ARSTD option is canceled at the end of the job or job
step in which it was specified. This is shown in the summary of label
options in Figure 3-12.
Option in search sequence
Type of label
information
Option in effect
until
Label information
retained
For
USRLABELI
temporary
STDLABEL or
PARSTD is
specified.
for one job. The
the partition in
/ & statement
which the option
causes the
was specified.
temporary label area
to be cleared. 4
PARSTD
permanent
a) end of job step
b) end of job
c) USRLABEL or
STDLABEL is
specified. 5
for all subsequent
jobs until another
PARSTD option is
used. 1
STDLABEL
permanent
a) end of job step
b) end of job
c) USRLABEL or
PARSTD is
specified. 5
all partitions}
for all subsequent
jobs until another
STDLABEL option is
used. 1
the partition in
which the option
was specified.
1 If no option is given or if the OPTION statement is omitted, USRLABEL is assumed.
1 All label information submitted following a PARSTD or STDLABEL option is written at the beginning of the label area thus
destroying any previously stored information. Therefore, if you want to add label data for another file, all previously stored
label information that is to be kept must be resubmitted.
3 Label information stored with the STDLABEL option is available to all partitions but can be submitted only through the
background partition.
4 Additional label information from a subsequent job step will overlay previous label information.
5 It is recommended that a USRLABEL option be submitted following the PARSTD or STDLABEL job stream when SYSRES
is on an FBA device.
FJgUre 3-12. Summary of Label Option Functions
By permanently storing the label information for a disk file in the label
information area, DOS/VSE relates that file to the type of the device which
is assigned to the pertinent logical unit when this file is processed for the
first time. A later attempt to use this label information for the same file
(and extent) on a different device type causes DOS/VSE to cancel the job.
If a different device type has to be used for this file, DOS/VSE requires
that the label statements be resubmitted and the pertinent logical unit
assigned to the device of the new type.
Remember that, when adding to or altering permanently stored label
information, all of the partition's (or system's) permanently stored label
information must be resubmitted along with the updates. Stored label
information may be displayed using program LSERV as follows:
II JOB
II EXEC LSERV
1*
IF:.
3.50 DOS/VSE System Management Guide
Tape and Print Operations
Controlling Magnetic Tape
The MTC job control statement or command controls certain magnetic tape
operations, for example, file positioning. Files on magnetic tape are almost
invariably processed sequentially. This means, for example, that if you have
five files on one tape reel and you want to process the last one, you have
to read four files before you can access the one you need. You can,
however, instruct the job control program to position the tape at a
particular file.
The MTC job control statement or command controls operations such
as:
•
Spacing the tape backward or forward to the required file.
•
Spacing the tape backward or forward a specified number of records.
•
Rewinding the tape to the beginning.
•
Writing a tapemark to indicate the end of a file.
In the following example, program FROGA creates a labeled tape file
named RATES on tape volume 222222. At the end of the first job step, an
MTC job control statement is used to rewind (REW) the tape to the
beginning of the tape volume so that the newly created file can be
processed by PROGB.
II
II
II
II
II
II
1&
JOB TAPE
ASSGN SYS004,TAPE,VOL=222222
TLBL RATES,'MASTER',75/365,222222
EXEC PROGA
MTC REW,SYS004
EXEC PROGB
Controlling Printed Output
Most of the DOS/VSE supported printers use a forms control buffer
(FCB) to control the length of forms skips. In addition, printers may be
equipped with the universal character set feature, which is controlled by a
universal character set buffer (UCB). Examples of printers equipped with
these buffers are the 3203 and 3211 printers.
The buffers of these printers must be loaded during or immediately
after IPL, and they may have to be reloaded later between job steps or,
occasionally, while a job step using the printer is being executed.
The following methods for loading the buffers are available:
Chapter 3: Using the System 3.51
To load the FCB
•
Automatic loading during IPL
•
Using the SYSBUFLD program between job steps or immediately after
IPL
•
Using the LFCB command
•
Using the LFCB macro in the problem program
•
Using the FCB parameter in the VSE/POWER
* $$
LST statement.
To load the UCB
•
Automatic loading during IPL (applies to PRT1 and 5203U printers)
•
Using the SYSBUFLD program between job steps or immediately after
IPL
•
Using the LUCB command
•
Using the UCS command (applies only to a 1403 UCS printer).
The method of loading the buffers by using the SYSBUFLD program offers
the advantage that hardly any operator activity is involved; on the other
hand, loading the buffers by using the LFCB or LUCB command does not
require the operator to wait for a partition to finish processing.
When the contents of an FCB or a UCB are replaced by a new buffer
image, the system uses this new image to control printed output until the
buffer is reloaded (or until the next IPL). None oLtbe above methods
provides automatic resetting of the buffer load to the original contents. It
may be necessary to reset the buffer to the original contents before taking a
storage dump, to ensure that the dump is printed in the correct format,
without any part of it being left out.
Details on how to load the FCB and UCB are contained in DOS/VSE
System Control Statements.
The 3800 Printing Subsystem. The 3800 Printing Subsystem is a noimpact,
high-speed, general-purpose system printer that uses an electrophotographic
technique with a low-powered laser to print output. It provides more
features than current impact printers.
The following methods of controlling the 3800 are available:
•
The SETPRT job control statement ~r command, which allows you to
set the 3800 with user-specified control values. These values are reset
at the end of the current job to the installation's default control valu~s
as specified in the SETDF operator co~and, or to the hardware
defaults if SETDF is not specified.
3.52 DOS/VSE System Management Guide
•
The SETDF operator command, which allows the operator to set
and/ or reset default control values for the 3800. A SETDF command
can set default control values for the following:
One cha.tacter arrangement table
The forms control buffer
,t'
The copy modification phase
The paper forms identifier
The forms overlay name
Bursting and trimming or continuous forms stacking
The setting of all hardware defaults with one command.
•
The SETPRT macro instruction, which is generally invoked via the
preceding statements but can also be used directly by the programmer
to initialize or dynamically change the setup of the 3800.
For information on available techniques for controlling the 3800, see
DosTvSE--JiiM' 3st)'i) printing
SubsYstem Programme,.'s Guide.
Executing a Program
After you have properly defined the I/O requirements of your program to
the system you can instruct job control to prepare your program for
execution. How this is done and how the supplied information is processed
is described in the following section.
Assembling/Compiling, Link-Editing, and Executing a Program
In DOS/VSE, three processing steps are necessary to obtain results from a
problem program once the source program has been written:
1. ASsembly or compiling of the source program into an object module.
(Object modules are discussed in section Linking Programs later in this
chapter.)
2. Link-editing of the object module to form an executable program
phase.
3. Execution of the program phase.
Each of these steps is initiated. by the job control program in response to an
EXEC job control statement. The EXEC statement must be the last of the
job control statements submitted for anyone job step. Figure 3-13 shows
an example of the job control statements needed to asseTnble, Hnk-edit, and
execute a source program.
Chapter 3= Using the System 3.53
II
II
2 II
3 II
4 II
1
1&
JOB EXECUTE
OPTION LINK
EXEC ASSEMBLY
EXEC LNKEDT
EXEC
1
To link-edit a program, the LINK option must be set ON.
2
The assembler is fetched from the core image library and starts execution.
3
The linkage editor is fetched from the core image library and starts execution.
4
When an EXEC statement without a program name is encountered, the program
last stored (if stored within the same job) in a core image library by the linkage
editor is fetched for execution.
FJgUI'e 3-13. Job Control Statements to
Program in one Job
~mble,
Link-Edit, and Execute a
Language translators read their input from SYSIPT. H SYSRDR and
SYSIPT are assigned to the same device, the source statements of your
program must follow the corresponding EXEC job control statement. In
this example, the assembler language statements would have to follow the
// EXEC ASSEMBLY statement. The end of the input data submitted for
one program must be indicated by a /* (end-of-data) statement. The /*
statement is not processed by job control; it is read by the logical IOCS
routines of DOS/VSE. (Note: For an input file on an mM 5424 MFCU,
the /* card must be followed by a blank card.) The placement of input
data and the /* statement is shown in Figure 3-14.
3.54 DOS/VSE System Management Guide
II
II
II
JOB INPUT
OPTION LINK
EXEC ASSEMBLY
source program
1*
II
II
EXEC LNKEDT
EXEC
input data for user program
1*
1&
FIgUre 3-14. Submitting Input Data on SYSIPT
How the job shown in Figure 3-14 is processed by the system is illustrated
in Figure 3-15. The numbers to the left of the subsequent paragraphs refer
to the encircled numbers in that illustration. The inclusion of SYSIPT data
in job streams in the procedure library is described in the section SYSIPT
Data in Cataloged Procedures.
1
Job control reads the JOB statement and stores the job name in the
supervisor. Other functions of the JOB statement are described under
Defining a Job, earlier in this chapter.
2
Job control reads the OPTION statement with the LINK option and
sets the LINK bit in the supervisor. This indicates
a) to the assembler, that the assembled object module is to be written
onto SYSLNK,
b) to job control that link editing is allowed in this job,
c) to the linkage editor, that the executable program is to be stored in
the core image library only temporarily for execution in the same job.
3
On encountering the / / EXEC ASSEMBLY statement, job control
transfers control to the supervisor passing it the name of the assembler
program.
4
The supervisor loads the assembler into the partition, replacing job
control.
5
The assembler reads the source program, assembles it, and stores the
object module on SYSLNK (not shown).
6
The assembler transfers control to the supervisor.
7
The supervisor loads job control into storage, replacing the assembler.
8
Job control reads the / / EXEC LNKEDT statement, as well as any
preceding linkage editor statements, and transfers control to the
supervisor, passing it the name of the linkage editor.
Chapter 3: Using the System 3.55
9
The supervisor loads the linkage editor into storage, replacing job
control.
10 The linkage editor reads the object module from SYSLNK and
link-edits it.
11 The linkage editor stores the executable program in the core image
library.
12 The linkage editor transfers control to the supervisor.
13 The supervisor loads job control into storage.
14 Job control reads an EXEC statement without a program name and
transfers control to the supervisor.
15 The supervisor loads the program last stored in the core image library
by the linkage editor replacing job control.
16 The user program is executed. It reads and processes the data from
SYSIPT and, at end-of-job, returns control to the supervisor.
17 The supervisor loads job control.
18 When job control reads the / & statement, it turns off the LINK option
and replaces the jobname stored in the supervisor by NO NAME.
Other functions of the / & statement are described under Defining a
Job, earlier in this chapter.
3.56 DOS/VSE System Management Guide
CS;erVisor:J
Input on SYSIN
I
Core I mage Library
INPUT
LINKAGE EDITOR
INPUT I I .........:L:.;.;IN
__K~I,~_ _-i~IJI._ _-Ml_
-
;::
y
~-----.....
--I I
I ~I
ell:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::;)
___ JOB CONTROL
/ / EXEC ----~-I..-
USER
PRO_GRAM
input data ----+-11-
r
--
r
I
.
t\..
I til:::::::::::::::::::::::::::::::::::::::::::::::::::::;:::::::::::::::::::::::::::::::::::::::::;:::;:::::::::::::::::::{:.
LINK I
~
INPUT
I
~-)
----v
JOB CONTROL
~
_ _ _ _...........-
EXECUTABLE USER
PROG RAM (LiJJ-*-rJ·~'1
JOB CONTROL
INONAMEI
. .
- -.....- T ra nsfer of data
~
'
"-"""\
c;if4"J )\f.. ~
LINK J
.'
--- JOB CONTRO_L:_-_-_-_-_-_-:_-_-_-_-__+_
~-----------~~- ~
INPUT
EXECUT AB LE USE R
PROGRAM
T.ransfer of control
_..___~) Loading fro~ core image library
Figure 3-15. System Operation of an Assemble, Link-Edit and Execute Job
Executing Cataloged Programs. Programs may be cataloged permanently in
the core image library after they have been assembled and link-edited. This
saves assembling and link-editing a program for every run.
Cataloging into the core image library is done by the linkage editor in
response to an OPTION job control statement with the CATAL option (see
Linking Programs later in this chapter).
To execute a cataloged program you use an EXEC job control
statement specifying the name under which the program was cataloged (as
shown for the assembler and linkage editor in the preceding example).
Chapter 3: Using the System 3.57
For example, the following job executes a program that was cataloged
in the core image library under the name PROGA; data cards are submitted
on SYSIPT:
II JOB CAT
assignment and label
statements, if required
II EXEC PROGA
input data
1*
1&
Denning Options for Program Execution
In the preceding section, it was shown how the OPTION job control
statement can be used
•
to specify the type of label information to be stored for a file
(USRLABEL, PARSTD, STDLABEL options), and
•
to define whether a program is to be link-edited (LINK. option).
There are a number of additional functions which you can invoke through
the OPTION job control statement. The most important ones are:
/ / OPTION LOG
Logs all job control statements submitted to the system on SYSLST. This
facilitates diagnosing the job control statements in case of an error.
/ / OPTION PARTDUMP
Dumps the contents of the registers, a formatted portion of the supervisor
area, and the current partition on SYSLST in case of abnormal program
termination. To obtain the entire supervisor area unformatted,
/ / OPTION DUMP may be used.
/ / OPTION DECK
Puts an object module on SYSPCH. The object module can then be
combined with other object modules by the linkage editor to form one
executable program, or it can be used as input to the library maintenance
program to catalog it into the relocatable library.
/ / OPTION LIST, USTX, SYM, XREF, ERRS
Prints various listings produced by the language translators (compilers) on
SYSLST. These listings include object code, symbol table, cross-reference,
and error lists which are useful debugging aids during the test period of a
program. SXREF may be specified instead of XREF to obtain a cross
reference listing that includes only the referenced labels in the assembled
program.
3.58 DOS/VSE System Management Guide
These (and other) options may be permanently set by using the
STDOPT command. The specified options become effective after the next
I & or I I JOB ~tatement.
Permanent options are valid for all jobs unless overridden by an
OPTION job control statement. Options specified in an OPTION statement
remain in effect until (1) a contrary option is read or (2) a JOB or 1&
~tement is encountered which resets the options to permanent.
Certain of these options can be suppressed by specifying the prefix NO
(for example, NOUST, NODUMP). A complete list of the available
options is given in DOSIVSE Sysu:m Control Statements.
CommuniCiting with Problem Programs via Job Control
Via job control a program can be instructed to take a specific path of
action. This instruction is given by setting program switches which can be
testea-liy-llie-jjrotileni-program--aflhetime--of program execu{ioli
These program switches, called UPSI (user program switch indicator),
can be set "on" (1) or "off" (0). They are set by job control in response
to the UPSI job control statement. The specific meaning attached to each
bit in the UPSI byte depends on the design of the program. The statement
I I UPSI 10000001
for exaniple, sets bits 0 and 7 of the UPSI byte to 1, and bits 2 through 6
to zero. A program can inspect these switches and take a 'specific path
based on their setting. Since the I I JOB statement sets the eight bits of the
UPSI byte to zero, the I I UPSI statement should follow the I I JOB
statement.
1
UPSI switches might be useful, for example, in an accounting
application that prepares reports of daily, weekly, and monthly accounts.
Through the program switches, -the application can be instruc.ted as to when
the daily, weekly, or monthly reports are due.
For more details on the UPSI statement see DOSIVSE System Control
Statements.
Executing in Virtual or Real Mode
All programs invoked for execution through an EXEC job control
statement are normally executed in virtual mode. To ron a program in real
mode, you specify the REAL operand in the EXEC statement. Example:
-
~
II JOB NAME
II
1&
EXEC PROGA, REAL
H, for the above example, job control runs in partition F2, then the
program PROGA will be loaded and executed in real mode if there is
sufficient processor storage all~ted to the F2 partition to hold the entire program PROGA.
Chapter 3: Using the System 3.59
If a program executing in real mode is smaller than the allocated
processor storage, the unused allocated processor storage should remain part
of the page pool. Specifying the size of the program in the SIZE operand of
the EXEC statement accomplishes this. Example:
II JOB NAME
II EXEC PROGA,REAL,SIZE=30K
1&
If the F2 partition has SOK of processor storage allocated and the program
PROGA has a size of 30K bytes, the remaining 20K bytes of that partition
will remain in the page pool.
If you specify SIZE=AUTO, job control automatically uses the
information in the program's core image directory entry to calculate the size
of the program to be loaded.
Running programs in real mode implies temporarily forfeiting a number
of page frames in the page pool, which may lead to degradation of system
throughput. Therefore, real mode execution should be used sparingly.
With a few exceptions, all mM-supplied and user-written programs can
be executed under DOS lYSE either in virtual or real mode. These
exceptions are listed in the following section.
Programs that Must Run in Real Mode. The mM-supplied program OLTEP
(On-line Test Executive Program) must be executed in real mode.
User-written programs must be executed in real mode if they contain
channel programs for devices· not supported by DOS/VSE.
User-written programs must be executed in real mode or modified if
they
•
contain MICR stacker selection routines or other time-dependent code
for execution of I/O requests.
•
contain channel programs that are modified during command execution.
•
contain I/O appendage routines causing page faults.
A program may request to obtain additional storage from the partition
GETVIS area (this area is described in the following section, Dynamic
Allocation of Storage). During real mode execution, that storage is
obtained from the unused allocated processor storage. Specifying a SIZE
value, therefore, allows you to issue GETVIS requests from a program
running in real mode (contrary to execution in virtual mode, DOS/VSE
does not provide a default partition GETVIS area for real mode execution).
For a program that is executed in real mode, allow 16K per open file, and
allow additional processor storage if double buffering is used or if FBA files
with large CI-sizes or VSE/VSAM files are opened. For most mM-supplied
programs that you want to run real, an allowance of 48K for GETVIS
requests suffices.
3.60 DOS/VSE System Management Guide
Note that the FREEVIS macro releases GETVIS space which was
obtained through a GETVIS macro; that space is again available for
subsequent GETVIS requests. When issued from a program running in real
mode, however, the space is not returned to the page pool until the
execution of the particular job is finished.
Dynamic ADocation of Storage
DOS/VSE dynamic storage areas, called GETVIS areas, are part of the
virtual storage. The system GETVIS area (in the SVA) is discussed in
Chapter 2, Planning the System. Each partition has an area called the
partition GETVIS area. These areas occupy the high address space of a
partition's· virtual storage. The minimum GETVIS area for a partition is
48K, which is the mM-set default. This default is not applicable to real
mode execution; in this case, you have to reserve storage yourseH (as
described in the preceding section).
The partition GETVIS area is used by certain DOS/VSE system
components for items such as opening of files, label processing etc.
Programs using rotational positional sensing (RPS) require 256 to 512 bytes
in the partition GETVIS area for each open file. This value should be
added to the minimum system requirement of 48K.
Programmers 'writing in assembler language may request space from the
partition GETVIS area via the GETVIS macro. When no longer needed by
the requesting program, area so acquired can be released by issuing the
FREEVIS macro. For details about using these macros, refer to the
publication DOS/VSE Macro User's Guide.
Figure 3-16 shows the virtual storage layout of a 200K partition with a
default-size partition GETVIS area.
Problem
Program
Execution
~-------------
Partition GETVIS Area
200K
-r-
T
48K
i
1
The largest size program that could execute in the shown partition is one that is
152K.
Figure 3-16. Storage Layout of a Partition with Default GETVIS Area
Chapter 3: Using the System 3.61
You may increase the size of a partition GETVIS area through:
•
the SIZE job control or attention routine command.
•
the SIZE parameter of the job control EXEC statement.
With the SIZE command, you specify the amount of virtual storage
available for program execution in a given partition. The balance of that
partition's allocation is the partition GETVIS area.
Given SIZE BG= 140K, the result is a storage layout for the partition
as shown in Figure 3-17.
Problem
Program
Execution
fo-------------Partition GETVIS Area
200K
T
60K
1
Figure 3-17. Storage Layout of a Partition after the SIZE Command is given
The boundaries set by the SIZE command are permanent until (1) another
SIZE command for the same partition or (2) the next IPL.
You may temporarily alter the partition GETVIS area by using the
SIZE parameter on the job control EXEC statement. The SIZE parameter
establishes boundaries in the same way as the SIZE command, except that
the parameter value holds only for one job step (the EXEC). At the end of
the job step, the GETVIS size is set to the DOS/VSE default (48K) or the
amount established by a preceding SIZE command. See Figure 3-18.
3.62 DOS/VSE System Management Guide
Given:
II EXEC PROGX,SIZE=110K
PROGX
1--------------
T
Permanent
GETVrS 5ITK
Allocation
1
Partition GETVIS Area
200K
T
90K
1
When PROGX is finished executing the partition GETVIS area size returns to its
permanent allocation.
Figure 3-18. Program Execution with the SIZE Parameter
With the SIZE parameter you may also specify SIZE=AUTO, in which case
job control uses the information available in the associated core image
library directory to determine the amount of storage needed by the program
and then allocates the remainder of the partition as GETVIS area.
mM licensed programming support (for example VSE/VSAM) may
have partition GETVIS requirements beyond 48K bytes. Consult the
appropriate licensed program documentation to determine the partition
GETVIS area size requirements.
System Files
011
Tape, Disk or Diskette
As mentioned earlier in this chapter, I/O devices (except DASD) cannot be
assigned to more than one active partition at the same time. This means, for
instance, that in an installation with only one card reader the input job
stream on SYSRDR and SYSIPT for one partition must have been
completely processed by job control and unassigned for that partition
before job streams can be read by another partition. This also applies
accordingly to the system output on SYSLST and SYSPCH if only one
printer and one card punch are available.
Since this situation can cause a considerable decrease of system
throughput, DOS/VSE permits storing the input job streams and the system
output on a direct access device or, if enough tape units are available, on
magnetic tape. This allows several partitions simultaneously to read system
input from or to write system output to high-speed devices, thus increasing
Chapter 3: Using the System 3.63
system throughput and, due to reduced CPU wait time, improving the
overall performance.
Note: If system logical units (SYSIPT, SYSLST, SYSPCH, SYSRDR) are to
be device independent, DTFDI must be used in application programs that refer
to any of these system logical units.
The following section describes how to store system input and output on
high-speed devices and to read and process the job streams from these
devices.
The same improvements as those gained by having system files on
high-speed devices - but far more efficient and easier to use - can be
achieved by using a spooling program such as VSE/POWER. The spooling
program stores the job streams on disk, transfers the jobs to the partitions
for execution, and stores list and punch output on disk before it is finally
printed or punched.
System Fdes on Tape
If the system input units SYSRDR and SYSIPT are assigned to the same
magnetic tape unit, they may (but need not) be referred to as SYSIN. H the
system output units SYSLST and SYSPCH are assigned to the same
magnetic tape they must be referred to as SYSOUT. The tapes may be
unlabeled or they may have standard labels. If SYSLST or SYSPCH is
assigned to a standard label tape and no new label information is supplied,
the old labels will remain on the tape. SYSIPT assigned to a magnetic tape
cannot be a multiple-volume file.
To store the input stream on magnetic tape you must write your own
program that transfers the job stream to the tape. Assume, in the following
example, that you have written such a program and cataloged it in the core
image library under the name CDTOTP; the program CDTOTP uses
SYSOO4 to read the input job stream, and SYSOO5 for the tape onto which
the job stream is to be written; the end of input data for CDTOTP is
indicated by ••. The example in Figure 3-19 shows how to use the program
CDTOTP to create a combined system input file on tape.
3.64 DOS/VSE System Management Guide
1
2
3
II
II
II
II
II
JOB BUILDIN
ASSGN SYSOO4,OOC
ASSGN SYSOO5,182
EXEC CDTOTP
JOB A
read from SYSRDR
16
II
JOB B
job stream
read from SYS004
16
4
**
16
1
SYSOO4 is assigned to the card reader from which CDTOTP reads the job stream.
2
SYSOO5 is assigned to the tape which is to receive the job stream.
3
The CDTOTP program is executed and writes the job stream onto tape.
4
** (or any other significant character combination) signals end-of-data to
CDTOTP
Figure 3-19. Creation of SYSIN on Tape
After completion of the job BUILDIN shown in Figure 3-19 you can assign
SYSIN to the tape containing the job stream; job control will then read and
process the jobs A and B from the tape just as it would have done from the
card reader.
In the same way you can direct the system output on SYSLST and
SYSPCH to go on magnetic tape and then use your own or an
mM-supplied program to print or punch the contents of the tape on the
printer or card punch, respectively.
System Files on Disk
System files on disk can be used only if the SYSFll.. parameter was
specified in the FOPT generation macro during supervisor generation.
Systf:ms without tape units should specify the SYSFIL parameter to
facilitate system maintenance.
When both SYSRDR and SYSIPT are assigned to disk, they must refer
to the same disk extent, and should be referred to as SYSIN. Since the
output units SYSLST and SYSPCH have different record lengths, they must
be assigned to separate disk extents; SYSOUT therefore cannot be used if
SYSLST and SYSPCH are assigned to disk. Note that only single extent
system files are supported.
For system files on disk, you must provide the required label
information by means of DLBL and EXTENT job control statements. In
those statements, use the following predefined filenames:
USYSIN for SYSRDR, SYSIPT, SYSIN
USYSPH for SYSPCH
USYSLS for SYSLST
Chapter 3: Using the System
3.65
For example, the label information for SYSIN assigned to a disk extent
could be submitted by the following job control statements:
II DLBL IJSYSIN,'DISKINFILE'
II EXTENT SYSIN,DOSRES,1,O,1260,30
The assignment of a system file to a disk extent must always be permanent,
and it must follow the DLBL and EXTENT statement. Example:
II DLBL IJSYSIN,'DISKINFILE'
II EXTENT SYSIN,DOSRES,1,O,1260,30
ASSGN SYSIN, 131
After a system file on disk has been processed, it must be closed by a
CLOSE job control command (no / /). The second (optional) operand of
the CLOSE command can be used to unassign a system logical unit or
reassign it to another device. The following command closes the SYSIN file
on disk and reassigns SYSIN to the card reader at address OOC:
CLOSE SYSIN,OOC
The CLOSE command can either be entered on SYSLOG by the operator
or it can be included at the end of the job stream on disk.
H SYSIPT is assigned to a disk extent, the CLOSE command must
precede the / & . Multiple SYSIPT data files can be read via multiple job
steps with one / & at the end of the job stream.
The example in Figure 3-20 shows the job control statements needed to
1. write a job stream on disk,
2.
execute the job stream from disk and store the print output on disk,
and
3.
print the output from disk on the printer.
The example assumes that you have written your own programs to write the
job stream on disk (CDTODISK) and to list on the printer the print output
stored on disk (DISKTOPR).
System Files on fued Block Architecture (FBA) DASD. H an FBA DASD
has a system logical unit assigned to it, the supervisor SYSFIL support will
block and deblock system file records into the FBA Control Interval-based
data format, handle all special conditions, and update the Disk Information
Block (Dm). This permits existing DTFDI and DTFCP programs to
process system files on FBA devices without making logic changes to
handle the FBA blocking.
Note, however, that the DTFSD SYSFll.. support is limited to
sequential GET or PUT for fixed unblocked records. (That is, the
UPDATE =YES parameter is not supported.)
3.66 DOS/VSE System Management Guide
II JOB STORE
I I ASSG N SYSOO 1,OOC
II ASSGN SYS006,190
II DLBL DASDOUT,'DASDOUTFI LE'
II EXTENT SYS006,DOSRES, 1,0,1260,30
II EXEC CDTODISK
JOB A
1&
II JOB B
JOB STREAM
IS EXECUTED
FROM DISK
1&
CLOSE SYSLST,OOE
CLOSE SYSIN,OOC
**
1&
®
II DLBL IJSYSLS,'OUTPR'
II EXTENT SYSLST,PVRLST, 1,0, 1970,20
ASSGN SYSLST,191
II DLBL IJSYSIN,'DASDOUTFILE'
II EXTENT SYSIN,DOSRES,1,0,1260,30
ASSGN SYSIN, 190
(3)
II JOB PRINT
II ASSGN SYS001, 191
II ASSGN SYS002,OOE
II DLBL OUTPR
II EXTENT SYS001 ,PVR LSL, 1,0, 1970,20
II EXEC DISKTOPR
1&
PRINTED
LISTING
G)
The program CDTODISK reads the following job stream from the card reader (SYS001) and stores it on disk (SYS0061. The end
of the job stream is indicated to CDTODISK by * *.
®
SYSLST and SYSI N are switched to disk. Job control now reads the job stream from the disk on de\(ice 190. The job stream is
executed and the print output is stored on the disk on device 191. The CLOSE commands at the end of the job stream will close
the system files on disk and reassign them to the printer and card reader, respectively.
(3)
The program DISKTOPR reads the print output from disk (SYSOOll and lists it on the printer (SYS002).
FJgUI'e 3-20. Processing System Input and Output Fi1es on Disk
Chapter 3: Using the System 3.67
System Files on Diskette
System files on diskette can be used only if the SYSFll... parameter was
specified in the FOPT generation macro during supervisor generation.
If the system input units SYSRDR and SYSIPT are assigned to a
diskette extent, they must be referred to as SYSIN. Since the output units
SYSLST and SYSPCH have different record lengths, they must be assigned
to separate diskette extents; SYSOUT therefore cannot be used if SYSLST
and SYSPCH are assigned to diskette.
For system files on diskette, you must provide the required label
information by means of DLBL and EXTENT job control statements. In
those statements, use the following predefined filenames:
USYSIN for SYSRDR, SYSIPT, SYSIN
USYSPH for SYSPCH
USYSLS for SYSLST
For example, the label information for SYSIN assigned to a diskette extent
could be submitted by the following job control statements:
II DLBL IJSYSIN,'DISKETTE'"DU
II EXTENT SYSIN,DSKETE,1
The assignment of a systern file to a diskette extent must always be
permanent, and it must follow the DLBL and EXTENT statement.
Example:
II DLBL IJSYSIN,'DISKETTE'"DU
II EXTENT SYSIN,DSKETE,l
ASSGN SYSIN,060
After a system file on diskette has been processed, it must be closed by a
CLOSE job control command (no / I). The second (optional) operand of
the CLOSE command can be used to unassign a system logical unit or
reassign it to another device. The following command closes the SYSIN file
on diskette and reassigns SYSIN to the card reader at address OOC.
CLOSE SYSIN,OOC
The CLOSE command can either be entered on SYSLOG by the operator
or it can be included at the end of the job stream on diskette.
If SYSIPT is assigned to a 3540 diskette, the CLOSE command must
precede the / & . Multiple input data files can be read via multiple job steps
with one / & at the end of the job stream.
When job control encounters / & on SYSRDR during normal
operation, the standard assignment for SYSIPT becomes effective and
SYSIPT is checked for an end-of-file condition. If the standard assignments
for SYSRDR and SYSIPT are not to the same device, SYSIPT is advanced
to the next /. statement.
3.68 DOS/VSE System Management Guide
Interrupting SYSIN Job Streams on Disk, Diskette, or Tape
After a SYSIN or SYSRDR job stream has been prepared on tape, diskette,
or· disk, it may be necessary to interrupt the normal schedule to execute a
rush job. To do this, press the Request key on the operator console and
enter a PAUSE command with the EOl operand causing the corresponding
partition to suspend processing at the end of the current job. At this point
you can make a temporary assignment for SYSIN to a card reader to
execute the rush job. At the end of this job, processing of the job stream
on disk, diskette, or tape will resume at the point of interruption. This is
illustrated in Figure 3-21. Starting an urgent job that uses a cataloged
procedure by means of a single EXEC statement is discussed in the section
Partition-Related Cataloged Procedures later in this chapter.
Disk Extent
Card Reader
Operator Console
/I OLBL IJSYSIN, .. .
/lEXT-ENT SYSiN; ... .
ASSGN SYSIN,191
/I JOB A
/&
/I JOB B
®
Press REQUEST key and
enter PAUSE xx, EOJ
where xx is the 10 of
the partition
/I ASSG N S YS I N,OOC
/&
1&
/I JOB 0
~L-"'&-_ CLOSE SYSIN,OOC
/&
1/ JOB E
/&
CD
®
®
SYSI N is assigned to disk and processing of the jobstream on disk begins.
While job B is being executed a PAUSE command is entered at the operator console.
At the end of job B control comes to the operator who can now enter a temporary assignment for SYSI N to the card reader.
@)
The job RUSH is read and processed from the card reader. Note that the temporary
assignment of SYSIN is not reset by the IIJOB RUSH statement but is retained to end of
the job.
®
The /& statement resets the temporary assignment of SYSIN to permanent (190) and
the next job in the stream on disk is read and executed.
®
The CLOSE command closes the system file on disk and reassigns ::sYSIN to the card
reader to process jobs 0 and E.
Figure 3-21. Interrupting a Job Stream on D_
Chapter 3: Using the System 3.69
Record Formats of System Flies
SYSLST records are i 21 characters and SYSPCH records 81 characters in
length. From SYSRDR and SYSIPT, job control accepts either 80- or
81-character records.
The first character of the SYSLST and SYSPCH records is assumed to
be an ASA carriage control or stacker selection character. SYSIPT,
SYSRDR, SYSPCH, and SYSLST records assigned to DASD have no keys,
and record lengths are the same as stated above. (For CKD devices the
records are unblocked; for FBA devices, DOS/VSE automatically blocks
records into the FBA format and also deblocks them.)
Using Cataloged Procedures
This section describes how to retrieve a cataloged procedure from the
procedure library and how to temporarily modify the contents of a
cataloged procedure. How a procedure is cataloged in the procedure library
is discussed in Using the Libraries later in this chapter.
Note: The procedure library should not be updated in a running
multiprogramming system.
Retrieving Cataloged Procedures
To retrieve a cataloged procedure from the procedure library you use the
PROC parameter in the EXEC job control statement, specifying the name
of the cataloged procedure. Assume that a program called PAYROLL uses
the following job control statements (in addition to the / / JOB and / &
statements) and that these statements have been cataloged in the procedure
library under the name PAY.
II
II
II
II
II
II
II
II
II
ASSGN SYS017,SYSRDR
ASSGN SYS018,SYSPCH
ASSGN SYS019,OOE
ASSGN SYS020,TAPE
ASSGN SYS021,DISK,VOL=111111
TLBL TAPFLE,'FILE-IN'
DLBL DSKFLE,'FILE-OUT' ,99/365,SD
EXTENT SYS021,111111,1,O,200,400
EXEC PAYROLL
If the program PAYROLL is to be executed, the programmer or operator
would simply prepare the following job control statements:
II
II
JOB USER1
EXEC PROC=PAY
16
When the job control program starts reading the job control statements in
the input stream on SYSRDR and finds the EXEC statement, it knows by
the operand PROC that a cataloged procedure is to be inserted. It takes the
name of the procedure to be used (PAY) and retrieves the procedure with
that name from the procedure library. At this point SYSRDR is temporarily
3.70 DOS/VSE System Management Guide
assigned to the procedure library. Job control reads and processes the job
control statements in its normal fashion. The statement
/ / EXEC PAYROLL
causes the program PAYROLL to be loaded and given control. When
execution of PAYROLL is complete, the job control program reads the
next statement from the procedure library and, in this example, would find
an end of procedure indicator (/ +). The end of procedure indicator returns
the SYSRDR assignment to its permanent device, where the job control
program finds the / & statement and performs end-of-job processing as
usual.
Note: The listing of job control statements on SYSLOG and/or SYSLST will
show the message EOP PAY at the end of the inserted procedure.
Temporarily Modifying Cataloged Proced"res
The preceding example is the simplest case of the use of cataloged
procedures. It will work as long as the requirements of the program do not
change.
It may happen, however, that some of the statements in a cataloged
procedure must be modified for a specific run of a program. For example,
the printer normally used (OOE in the preceding example) may be
temporarily unavailable and a different printer must be assigned. It does not
make much sense to delete the old procedure and to catalog a new one
because the old procedure will be needed again as soon as the normal
printer becomes operational again.
Likewise, it may be necessary to add or remove certain statements to or
from a cataloged procedure for a specific run of a program. You may wish, for
example, to process a different copy of the file FILE-OUT (see the preceding
example). You must therefore temporarily suppress the corresponding DLBL
and EXTENT statements in the cataloged procedure and replace them by
statements that identify the file you want to process instead.
For cases like this, DOS/VSE permits one or more statements in a
cataloged procedure to be
•
temporarily modified (thus, overriding what was present).
•
temporarily suppressed (deleted) without modifying them.
•
temporarily incorporated at desired locations in a cataloged procedure.
You can request temporary modification of statements in a cataloged
procedure by supplying the corresponding modifier statements in the input
stream.
Since normally not all statements need be modified, you must establish
an exact correspondence between the statement to be modified and the
modifier statement by giving them the same symbolic name. This symbolic
name may have from one to seven characters, and must be specified in
columns 73 through 79 of both statements.
- ...,--.,..,.....'''~.,.. ,.~ ............ ,~-..,.,.,.., .. ,.......--,."'' .,..=-'""""'...........-.....-~
Chapter 3: Using the System
3.71
Note: An unnamed statement cannot be modified. Therefore, to be able to
modify any statement in a cataloged procedure for any usage of the procedure
you should name each statement when cataloging. Moreover, the modifier
statements must be in the sequence in which modification is to be performed on
the cataloged statements. The JOB statement cannot be modified; also, job
control continuation statements cannot be overriden.
A single character in column 80 of the modifier statement specifies which
function is to be performed:
A - indicates that the statement is to be inserted after the statement in the
cataloged procedure that has the same name.
B - indicates that the statement is to be inserted before the statement in
the cataloged procedure that has the same name.
D - indicates that the statement in the cataloged procedure that has the
same name is to be deleted.
Any other character or a blank in column 80 of the modifier statement
indicates that the statement is to replace (override) the statement in the
cataloged procedure that has the same name.
If the LOG function is active (by having issued the LOG job control
command), statements to be deleted are printed, with a D in column 80, on
the console, but not 'executed'.
In addition to naming the statements and indicating the function to be
performed, you must inform the job control program that it has to carry out
a procedure modification. This is done
(1) by specifying an additional parameter (OV for overriding) in the EXEC
statement that calls the procedure, and
(2) by using the statement / / OVEND to indicate the end of the modifier
statements.
Placement of the / / OVEND statement is as follows:
•
directly behind the last modifier statement or,
•
if the last modifier statement overwrites a / / EXEC statement and is
followed by data input, between the /* and the / &.
The following examples show how you can temporarily modify a cataloged
procedure.
Assume that a procedure named PROC5 for the program PAYROLL
contains the following statements:
3.72 DOS/VSE System Management Guide
II
II
II
II
II
II
II
II
II
73--79
ASSGN SYS017,SYSRDR
ASSGN SYS018,SYSPCH
ASSGN SYS019,SYSLST
ASSGN SYS020,181
ASSGN SYS021,DISK,VOL=111111,SHR
TLBL TAPFLE,'FILE-IN'
DLBL DSKFLE,'FILE-OUT'
EXTENT SYS021,111111,1,O,200,200
EXEC PAYROLL
PAYOOl
PAY002
PAY003
PAY004
PAY005
PAY006
PAY007
PAY008
PAY009
1+
Assume further that the programmer wants to use tape unit 183 instead of
181. The input stream on SYSRDR, in this case, would have to be as
follows:
II
II
II
II
73--80
JOB USER
EXEC PROC=PROC5,OV
ASSGN SYS020,183
OVEND
PAY004R
1&
The form of the EXEC statement in the input stream indicates that (1) the
procedure PROC5 is to be used and (2) this procedure is to be modified in
some way. The first three procedure statements are processed without
change. The procedure statement named P AYOOO4 is replaced by the
corresponding statement in the input stream. (As any character other than
A, B, or D specifies override, an R was used to indicate this.) The
remaining procedure statements are again processed without change.
As another example, assume that the program PAYROLL is to use file
FILE-OUT1 instead of FILE-OUT and that this file resides on two extents
of· a disk pack that has the volume serial number 111112. The input stream
might then look as follows:
II
II
II
II
II
II
II
Co1.73--80
JOB USER
EXEC PROC=PROC5,OV
ASSGN SYS021,DISK,VOL=111112,SHR
DLBL DSKFLE,'FILE-OUT1'
EXTENT SYS021,111112,1,O,100,200
EXTENT SYS021,111112,1,1,500,200
OVEND
PAY0005R
PAY0007R
PAY0008R
PAY0008A
1&
Processing would be as follows: The JOB statement and all procedure
statements up to the statement named P A YOOO4 are processed without
modification. The procedure statements labeled P A YOOO5, P A YOO07, and
PAYOOO8 are replaced by the corresponding statements in the input stream.
The second EXTENT statement in the input stream has the character A in
column 80, which indicates that the statement is to be inserted after the
(replaced) statement named P A YOOO8. The procedure statement named
P A YOOO9 is processed without modification.
The possibility of modification as described above makes the use of
cataloged procedures more flexible. Often, however, it is simpler and more
economical to have different procedures for the same program than to have
a single procedure and modify it.
Chapter 3: Using the System 3.73
SYSIPT data in a cataloged procedure cannot be overridden by the
procedure override facility.
Several Job Steps in one Procedure
A cataloged procedure may contain more than one EXEC statement, that
is, it may contain control statements for more than one job step (within the
same job). However, as the number of job steps in a procedure increases,
so does the time required to re-execute the whole procedure after an error
occurs.
A program written in assembler language, for instance, requires three
job steps to assemble, link-edit, and execute the program. For the use of a
cataloged procedure, your input stream for the entire job (on SYSIN for
simplicity) would contain the following:
II
II
II
JOB USER
OPTION LINK
EXEC ASSEMBLY
source deck of program to be assembled
1*
II
II
EXEC LNKEDT
EXEC
data for program to be executed
1*
1&
H the OPTION statement and the three EXEC statements were cataloged
under the name ASDPROC, the input stream could be simplified as shown
below.
Procedure ASDPROC
Input from SYSIN
II
JOB USER
II EXEC PROC=ASDPROC
~.~
____
~r-
[ II OPTION LINK
II EXEC ASSEMBLY
so~rce statements of
[ II EXEC LNKEDT
program to be ~ I I EXEC
assembled
1*
1+ (end indicator)
data to be
processed
1*
1&
The same can be done for any number of job steps that logically belong
together and are frequently executed. A stock control program STOCK, for
instance, may be run daily to compile statistics that can be used to prepare
the following lists:
1. An exception list that shows which items are low in stock. Required
daily.
2.
A list that shows the sales in currency for a certain item or group of
items. Required weekly.
3.74 DOS/VSE System Management Guide
3.
A list that shows the sales in -number of units for each item or group of
items. Required monthly.
4.
An inventory list. Required semi-annually.
To simplify processing, four procedures may have been cataloged:
STKPRI - two job steps: the first to execute STOCK, the second to
prepare list 1.
STKPR2 - three job steps: the first two are the same as for STKPRl, the
third to prepare list 2.
STKPR3 - four job steps: the first three the same as for STKPR2, the
fourth to prepare list 3.
STKPR4 - five job steps: the first four the same as for STKPR3, the fifth
to prepare list 4.
Which lists are printed after every run of STOCK then depends on what
cataloged procedure is used.
Modifying Multistep Procedures
Multistep procedures may be modified in the same way as the single-step
procedure described earlier. However, a number of considerations apply to
the ordering of the modification statements in the input stream when a
logical unit used for data input is assigned to the same physical unit as
SYSRDR.
•
It is advisable to avoid using identical symbolic names for the
statements in the procedure.
•
The modifier statements must be in the same sequence as the
statements in the referenced procedure.
•
Modifier statements are normally placed immediately following the
EXEC PROC=procedure,OV statement. When input data is read by a
job step (EXEC statement) executed from the procedure, the following
cautions should be observed:
1. The first statement following the EXEC PROC=procedure,OV
must be a modifier statement (see "1" in Figure 3-22).
2.
Modifier statements that take affect after the input data is read are
placed following the input data except for the first modifier which
must precede the input data (see "1" and the modifier statement
ASSGN SYSSLB,UA in Figure 3-22).
3.
An exception to point 2 above is when the input data is processed
by a job step that itself was modified (see "3" and "4" in Figure
3-22). In this case the next modifier must follow the data (see
statement "3" and the modifier ASSGN SYSCLB,UA in Figure
3-22).
Figure 3-22 shows an example of modifying the second and third steps of a
three-step procedure.
Chapter 3: Using the System 3.75
In the example given in Figure 3-22, it is assumed that SYSRDR and
SYSIPT are assigned to the same physical unit.
SYSIN Input Stream
Procedure CAT01 Containing JCL Only
Co,umnr-79
Column 73-79
II JOB EXAMPLE
II EXEC PROC=CAT01,OV
II ASSGN SYSRLB;UA
1
STMT3
1/ EXEC PSERV
STMT1
/*
ASSGN SYSCLB,130
1/ ASSGN SYSSLB,UA
,1/ EXEC DSERV,REAL
STMT4
STMT5
1/ ASSGN SYSR LB, 130
1/ ASSGN SYSSLB, 130
1/ EXEC DSERV
STMT2
STMT3
STMT4
STMT5
1/ ASSGN SYSSLB,UA
1/ EXEC DSERV,REAL
STMT6
STMT7
DSPLY CAT01
8
0
DSPLY CD,RD,SD
/*
ASSGN SYSCLB,UA
II OVEND
DSPLY CD, PO
STMT6
1+
/*
1&
o
This is the first modifier statement. It refers to the second job step.
@
This statement provides SYSIPT data for PSERV.
e
e
o
This modification overwrites the EXEC statement.
This statement provides SYSIPT data for DSERV (STMT5).
This statement provides SYSIPT data for DSERV (STMT7).
Figure 3-22. Example of Modifying a Three-Step Procedure
SYSIPI' nata in Cataloged Procedures
In the example shown in Figure 3-22 the librarian service programs PSERV
and DSERV accessed data from the logical unit SYSIPT. This 'SYSIPT'
data may be made part of your cataloged procedure if SYSFIL= YES was
specified in the FOPT generation macro at supervisor assembly. System
utility, system service programs, and language translators all read their input
from SYSIPT.
When you catalog a procedure containing SYSIPT data, the directory
entry for the procedure indicates this. When you execute such a procedure,
job control checks to see whether or not it contains SYSIPT data. If it
does, both SYSRDR and SYSIPT are assigned to the procedure library until
the end of the procedure. SYSIPT data in a cataloged procedure cannot be
overriden by the procedure library override facility.
SYSIPT inline data in procedures may also be any data that is
processed under control of the device independent IOCS used by your
3.76 DOS/VSE System Management Guide
program or ffiM-supplied programs. Normally, though, you would not
catalog source programs or data for your problem programs in the
procedure library.
SYSIPT ~e data in procedures is useful and convenient mainly in the
case of control information for system utility and service programs.
A job stream for an initialize disk utility run could, for instance, contain
the following control statements (the statements are shown in skeleton
format only):
I I ASSGN ...
II EXEC INTDK
II UID IR,C1,R=(0027003)
II VTOC STANDARD
VOL 1111111
II END
16
_
The job control stat~meJ:lts_ ar~ read from SYSRDR, the utility control
statements are read from SYSIPT. If, however, both the job control and
utility control statements had been cataloged (for example, under the name
INITDK), only the following statements would be required on SYSRDR:
II
II
JOB NAME
EXEC PROC=INITDK
16
If two or more programs in a procedure read SYSIPT data, the SYSIPT
data must be handled in a consistent manner, that is, if the SYSIPT data is
included in the procedure for one job step, it must be included for all job
steps in that procedure which require SYSIPT data.
Partition-Related Cataloged Procedures
Although a given procedure may be executed in any partition, a particular
job may need a specific set of job control statements, dependent on the
partition of execution. For example, you may want to run a job to store
DLBL and EXTENT statements in the partition label subarea for each
partition (OPTION PARSTD). Since each partition requires a different set
of label information, you would need a cataloged procedure for each of
your partitions. Partition-related cataloged procedures then allow you to
retrieve and execute the appropriate procedure with one version of the
EXEC statement, no matter which -partition you are running in. One
benefit of this feature lies in the ease with which unscheduled jobs can be
started.
To use the feature, you must fi..rst create separate procedures that
conform to the specific partitions in your system. Most probably, the
difference in these procedures will be in the- EXTENT and DLBL
statements because of the different device and DASD space assignments
from partition to partition. Next, in order to distinguish between the
procedures and relate them to the appropriate partitions, the following
naming convention must be used for cataloging these procedures:
Chapter 3: Using the System 3.77
First character of name
Second character
Third-eighth characters
$
B for BO partition
1 for Fl partition, 2 for F2 partition, etc.
any alphameric character
In the EXEC statement used to start the job, the first two characters of the
procedure name must be $$, with the remaining characters identical to the
last six characters of the cataloged name.
To continue the previous example, the procedures may be named
$BPARSTD for the BO partition, $lPARSTD for the Fl partition and so
on. The statement thus needed to invoke the appropriate procedure is
/ / EXEC PROC=$$PARSTD.
Use of Cataloged Procedures by the Operator
Partition related procedures or procedures for the starting of urgent jobs are
of great help to the operator. Full details on the use of cataloged
procedures by the operator are given in DOS/VSE Operating Procedures.
3.78 DOS/VSE System Management Guide
I linking Programs
Prior to execution in storage, all programs must be placed in the core image
library by the linkage editor. This section describes the role of the linkage
editor and how you can communicate with it through control statements.
The name linkage editor appropriately reflects the editing and the
linking operations that this program performs. The linkage editor prepares a
program for execution by editing the output of a language translator into
one or more executable phases. The linkage editor also combines separately
assembled or compiled program sections or subprograms (called object
modules) into phases. This process is referred to as linking.
A program can be link-edited into one or more phases and
•
cataloged permanently,
•
cataloged permanently and executed immediately, or
•
catatoged temporarily and executed immediately.
When a phase is cataloged permanently into the core image library, the
linkage editor is no longer required for that phase *, because, the supervisor
can load it directly from the library in response to an EXEC job control
statement, or a FETCH or LOAD macro. On the other hand, if the phase
is cataloged temporarily and executed immediately, the linkage editor is
required again the next time the phase is to be run.
Phases are stored either temporarily or permanently, depending on the
option specified in the OPTION job control statement:
/ / OPTION LINK
If the LINK option is specified, the phase is stored temporarily for
immediate execution in the same job. This phase will be overwritten in the
core image library by the next phase that is link edited.
/ / OPTION CATAL
If the CATAL option is specified, the phase is stored permanently and can
be executed any time after the link-edit run.
Phases produced by the linkage editor while running in a foreground
partition are cataloged into a private core image library. To catalog a phase
into the system core image library, the linkage editor must execute in the
background partition. You may, optionally, use a private core image library
in the background partition by ensuring that it is assigned during execution
of the linkage editor. For more information on using private libraries, refer
to Using the Libraries later :in this chapter.
*If a phase is non-relocatable and the partition boundaries change so that the cataloged
program's start and end addresses no longer fall within the partition, the program must
be link-edited again.
Chapter 3: Using the System 3.79
Structure of a Program
To understand the functions of the linkage editor, you must understand the
structure of a program during the various stages of its development. Figure
3-23 summarizes the three sections that follow, which discuss source
modules, object modules, and program phases.
SOURCE MODULE
OBJECT MODULE
->
->
Language
Translator
Relocatable
Library
Source Statement
Library
Linkage
Editor
Core Image
Library
A set of source statements, or source mQdule 0), must be processed by a language translator, but can first be
catalo&ed as a hook (2) into the SOurce statement library. The output of the language translator is called an
object module (3), which must be processed by the linkage editor, but can first be cataloged as a module (4)
into the relocatable library. The output of the linkage editor is called a phase (5), which is cataloged into the
core image library temporarily or permanently, and c~_ru.so._~l.o_~c:led into the shared virtual area.
Figure 3-23. Stages of Program Development
Source Modules
After planning the most logical approach to your application, you write a
set of source statements in a programming language. Your set of source
statements, called a source module, is processed by a language translator.
The language translator assembles source modules written in assembler
language, or it compiles source modules written in a high-level language
(for instance, COBOL, PL/I, or RPG ll). The language translator
transforms the source module into an object module, which is in machine
language. .
You can either submit your source module directly to the language
translator for processing, or you can catalog it into a sublibrary of the
source statement library for processing at a later time by tfle language
translator.
3.80 DOS/VSE System Management Guide
Source modules are written in one or more control sections (CSECTs).
Using assembler language the programmer defines the control sections.
Source modules written in a high-level language have their control sections
defined by the various compiler options used.
Object Modules
An object module, the output of a language translator, consists of the
dictionaries and text of one or more control sections. The dictionaries
contain the information needed by the linkage editor to modify portions of
the text for relocation and to resolve cross-references between different
object modules. The text consists of the actual instructions and data fields
of the object module. You can either submit your object module directly to
the linkage editor for processing, or catalog it into the relocatable library
for later inclusion in a linkage editor job stream.
For each object module the language translator produces four types of
records as illustrated and summarized in Figure 3-24. For more information
about these records see DOS/VSE System Control Statements.
Byte
"
o
"
e
4
Contains X'02'. Identifies the record as one of an object module.
Indicates the record type and can be one of the following:
C'ESO' -- External symbol dictionary. Contains symbols defined in this module and referred to by one or more other modules and symbols referred to
in this module but defined in another module.
C'TXT' - Text. Contains actual code plus control information needed by the
linkage editor.
C'RlO' -- Relocation list dictionary. Identifies those portions of the text
which must be modified when the program is relocated for execution.
C'ENO' -- End of module. Indicates the end of a module. The record may
contain an address where execution is to begin (transfer address) or the length
of the control section or both.
Figure 3-24. Record Types of an Object Module
If you want to change information in a TXT record, you can prepare a
REP record (user replace record) and submit it with your object module for
cataloging into the relocatable library or for linkage editor processing. A
REP record must be submitted between the TXT record it modifies and the
END record; otherwise, the TXT record is not modified. Usually, you place
the REP record(s) immediately before the END record.
Chapter 3: Using the System
3.81
Program Phases
The linkage editor produces a program phase from the object module(s)
you identify in linkage editor control statements. A phase is the functional
unit (consisting of one or more control sections) that the system loader can
load into a partition in response to a single EXEC job control statement (or
a FETCH or a LOAD macro instruction in an assembler language
program).
In the PHASE control statement you instruct the linkage editor to
produce one of three types of phases: relocatable, self-relocating, or
non-relocatable.
Relocatable Phases. A phase is relocatable if it can be loaded for execution
in any partition's address area. The linkage editor produces a relocatable
phase unless you specify an absolute origin (load) address instead of a
relative address. However, mM recommends that you always specify a
relative origin address. An address, in order to be relative, is represented by
a symbol with or without a displacement; for details see DOS/VSE System
Control Statements.
If a relocatable phase is also designed as a reenterable phase, it is
eligible to be loaded into the shared virtual area (SVA). Phases resident in
the sVA can be shared concurrently by programs running in either real or
virtual mode.
Self-Relocating Phases. Prior to the availability of a loader with the
relocating capability some users coded self-relocating programs in order to
gain the advantages of relocatability. If you have to perform maintenance
on such a program, you must write this program in assembler language
according to the rules described in DOS/VSE Macro User's Guide. In the
PHASE control statement you indicate an origin address of +0. The
program must relocate all its addresses at execution time to correspond with
the addresses available in the partition where the program is loaded.
Non-Relocatable Phases. A non-relocatable phase is link-edited to be loaded
at a specific location (absolute address) associated with a partition. When
you request execution of a non-relocatable phase in a given partition, the
starting and ending addresses of the phase must be included within that
partition. Otherwise, the job is canceled. If you wish to execute a
non-relocatable phase in more than one partition, you must catalog a
separate copy of the phase for each partition.
The Three Basic A.pplications of the Linkage Editor
The three basic applications of the linkage editor are referred to as:
•
cataloging phases into the core image library
•
link-edit and execute
•
assemble (or compile), link-edit, and execute
The following sections include a discussion of the system flow during each
of these applications.
3.82 DOS/VSE System Management Guide
Cataloging Phases into the Core Image Library
When you have an operational program (as an object deck in cards or on
tape, for example) and you expect to use that program frequently, you
should catalog it into a Core image library. You can do this in a single job
step, which is shown in Figure 3-25, and described below.
Job control copies, onto SYSLNK, the linkage editor control statements
present on SYSRDR. The INCLUDE statement, without operands, signals
job control to read any object modules that are to be included from
SYSIPT. H an ENTRY statement is not encountered before the / / EXEC
LNKEDT statement, job control writes one on SYSLNK. An ENTRY
statement signals termination of the input to the linkage editor.
The linkage editor is loaded mto the partition where the job stream was
submitted; it uses SYSOOI as a work file.
Because the CATAL operand of the OPTION statement was specified,
the linkage editor places the executab1e program petffianen.tly mto a core
image library. H a private core image library is assigned to this partition,
the program is cataloged there; otherwise, (for the background partition) it
is cataloged into the system core image library. The library descriptor entry
in the core image directory for cataloged phases is updated.
H the phase is eligible for the shared virtual area and is indicated as
SVA eligible in the system directory list, the phase is also loaded into the
SVA.
Note: System and work files such as SYSLNK and SYSOO 1 must be defined.
Cataloging a Supervisor. Supervisors may also be cataloged permanently into
the core image library as described above. Be sure, when doing this, to
specify unique name (eight alphameric characters) for each supervisor.
a
Link-Edit and Execute
You do not always need to catalog a permanent copy of your program into
the core image library in order to execute the program. For instance, you
have modified parts of your program and want to test these modifications
with the entire program. In this case, you can specify the LINK option,
which requests that the linkage editor place a temporary copy of the
program into the core image library. Again, the INCLUDE statement
signals job control to read the following input from SYSIPT. The shaded
portions of Figure 3-26 illustrate how this job stream differs from Figure
3-25.
By specifying an EXEC statement without a program name operand
after the EXEC LNKEDT statement, the program just link-edited is loaded
for execution. The space temporarily occupied by this program in the core
image library is overwritten the next time a program is link-edited.
Chapter 3: Using the System 3.83
FJgUI"e 3-25. A Job Stream to Catalog a Program into the Core Image
Library
Assemble (or CompHe), Link-Edit, and Execute
You can also combine the job steps described above with a job step for
assembly (or compilation) of your source program. This is especially useful
when you are developing a program. Figure 3-27 shows how your job
stream should be set up. The shaded portions of the figure illustrate how
this job stream differs from that shown in Figure 3-26. Linkage editor
control statements are not required when linking single-phase programs
temporarily into the core image library.
You direct the language translator to write the object module directly
onto SYSLNK by specifying the LINK option at the beginning of the job.
After the linkage editor processed the input from SYSLNK, your program is
loaded for execution.
"
3.84 DOS/VSE System Management Guide
/ / JOB TEMP
The / / EXEC statement (without a program name operand) causes this program to be
loaded for execution immediately.
The / / OPTION CATAL statement may also. be used in this job stream. In this
case, the program that was cataloged (permanently) is executed immediately. When
/ / OPTION CATAL is specified a PHASE statement is required.
FJgUre 3-26. A Job Stream to Unk-Edit a Program for Immediate Execution
If errors occur in one job step causing an abnormal termination, the
remaining job steps are ignored. Certain linkage editor errors do not cause
job step termination. If you do not want to execute the program when
these errors occur, you may specify ACTION CANCEL after the / /
OPTION LINK.
Chapter 3: Using the System
3.85
/&
Figure 3-27. A Job Stream to Assemble, Link-Edit, and Execute
Processing Reqllirements for the Linkage Editor
The linkage editor can be executed in any partition. When the linkage
editor is executed in a foreground partition, a private core image library
(SYSCLB) must be uniquely assigned to that partition and phases are
placed there. When the linkage editor is executed in the background
partition where no private core image library is assigned, phases are placed
into the system core image library; phases are placed into a private core
image library also from the background partition if such a library is
uniquely assigned to that partition.
Symbolic Units Required
The linkage editor requires the following symbolic units:
SYSIPT
Module input (if any) --
SYSLST
Programmer messages and listings (if SYSLST is not assigned,
no map is printed and programmer messages appear on
SYSLOG)
SYSLOG
Operator messages
SYSRDR
Control statement input (via job control)
SYSLNK
Input to the linkage editor
SYSOOI
Work file.
Note that SYSRDR and SYSIPT may contain input for the linkage editor.
This input is written on SYSLNK by job control.
H output from the linkage editor is to be placed in a private core image
library, the following symbolic unit is required:
3.86 DOS/VSE System Management Guide
SYSCLB
The private core image library. It may be assigned anywhere in
the job stream but before job control reads the / / EXEC
LNKEDT statement.
If object modules from a private relocatable library are to be link-edited,
the symbolic unit SYSRLB must be assigned.
Preparing Input for the Linkage Editor
The input you prepare for the linkage editor consists of job control
statements, linkage editor control statements, and object modules. Job
control reads the job control statements and the linkage editor control
statements from the device assigned to SYSRDR and object modules from
SYSIPT. The linkage editor control statements and object modules are
copied onto the disk extent assigned to SYSLNK.
The linkage editor con~rol statements direct the execution of the linkage
editor. The statements are: ACTION, ENTRY, INCLUDE, and PHASE.
A description of how to prepare. these control statements is given on the
following pages. Here, the various operands of the control statements are
described under headings that indicate their function.
AS4iigning a Name to a Program Phase
Each program phase the linkage editor is to produce should have a name,
which you specify in the PHASE statement. When a phase is cataloged in
the core image library, the phase name identifies that phase for subsequent
retrieval. In other words, the same phase name you supplied in the PHASE
statement when permanently cataloging the initial or only phase of a
program must be used as the operand in the EXEC job control statement
or in a FETCH or a LOAD macro instruction.
When you catalog a phase with the same name as a phase already
residing in the core image library, the earlier entry with the same phase
name is deleted from the core image directory (and, if applicable, the
system directory list in the SVA) and cannot be accessed again.
The choice of a phase name has a bearing on retrieval efficiency and
the subsequent use of the librarian programs. Job control scans the
directory of the appropriate library for all phases starting with the same
four characters as the program name specified in the EXEC statement.
Any phases with the same first four characters of their phase name will
be classified as a multiph~_,program. When a phase of a multiphase
program is fetched, the available address space must be large enough to
contain the largest of those phases even if that phase is not part of the
program which is being executed.
~~.'.
Phase names may be formed only from characters 0-9, A-Z, /, #, $,
and @. Otherwise, the phase statement is invalid. The names "S", "ALL",
and "ROOT" are invalid phase names.
In choosing a name for any multiphase program, make sure that the
first four characters are the same for all phases of that program but
Chapter 3: Using the System 3.87
different from those of other programs. Such names simplify the deleting,
displaying, punching, merging, and copying of the entire program. Figure
3-28 summarizes the above reoommendations.
Note: A phase name "//" cannot be placed into the System Directory List via
the job control command SET SDL.
Different names should be given to each
multiphase program; each phase of a
multiphase program should be named
with the same first four characters. This
simplifies library maintenance.
PrOgl
ABCDl
ABCD2
ABCD3
ABCD4
Prog2
ANNll
ANN12
ANN13
ANN14
ANN15
Prog3
WXYZl
WXYZ2
WXYZ3
WXYZn
Simplified library maintenance means, for example, that one simple control statement deletes all phases of Progl :
(
DELETC ABCD.ALL
If the programs had been named:
Progl
Prog2
Prog3
ABCDl
ABCD2
ABCD3
ABCD4
ABCD5
ABCD6
ABCD7
ABCD8
ABCD9
ABCD10
ABCDll
ABCD12
ABCDn
the statement required to delete Progl would be:
DELETC ABCD1, ABCD2, ABCD3, ABCD4
FJgUI'e 3-28. Naming Multiphase Programs
3.88 DOS/VSE System Management Guide
Denning a Load Address for a Phase
For link-editing, you specify where your program is to be loaded for
execution. You have several choices.
A phase can be link-edited to be loaded into and executed from:
•
a specific partition's address area
•
the shared virtual area
•
an absolute address.
A phase can be link-edited as a relocatable phase, a self-relocating phase,
or a non-relocatable phase.
The load address you specify in the PHASE statement determines the
relocatability status of the link-edited phase:
•
For a phase to be relocatable, specify a symbolic address with or
without a displacement.
•
For a phase to be non-relocatable, specify an absolute address.
•
For a phase which you wrote to be self-relocating, specify +0.
Full details on possible load address (also called origin address)
specifications are given in DOS/VSE System Control Statements.
Link-Editing for Execution at Any Address. H the linkage editor determines
that a phase is to be given the relocatable format, it flags the core image
directory entry for that phase, and inserts the relocation information behind
the text of the phase in the core image library.
When a relocatable phase is link-edited, it is ~Jgp.ed a load address
f',re~~!~e p_~ti0J?-'s !,
L ...... ~ ..
·u,
for Execution in a Speciflc Partition's Address Space. Unless
Chapter 3: Using the System 3.89
otherwise specified in the PHASE statement, a prJob name. 8-byte character string taken from
JOB statement.
User Information. 16 characters of information
taken from the JOB statement.
Partition ID, BG, ... , F2, or F 1.
Cancel Code. Refer to DOS/VSE Serviceability Aids and
Debugging Procedures
SIO Tables. Variable number of bytes. Six bytes are
reserved for each device specified in the JA parameter.
First two bytes are X'Ocuu', next four are hex count of
SiCs for job step. Unused entries contain X'10' followed by
five bytes of zeros. Stacker select commands for MICR
devices are not counted. Error recovery SIOs are not charged
to the JOB Accounting Table. Devices are added to the table
as they are used.
1
Overflow. Normally X'20'. Set to X'30' if more devices are
used than set by the JA parameter at system generation time.
Note: The difference between Start and Stop times will not necessarily equal the sum of CPu,
A.II Bound. and Overhead times. A.II Bound and O'H!rhead times will vary, depending on the
number of acti'H! partitions and the type of partition activity. CPU time is accurate for each
partition, but it may not be reproducible. That is, the same job being executed under different
system conditions (varying number of active partitions, logical transient available, etc.) may
show differences in CPU time.
FtgUI"e 4-4.
4.8 DOS/VSE System Management Guide
Job Accounting Table
H physical IOCS is used for printing, you must 'space after' to prevent
overwriting of job control statements.
For efficiency, an overlay structure should be avoided and the length of
the program should preferably not exceed one core image library block.
H the job accounting program is canceled as the result of an error
condition, the current information cannot be retrieved, the job accounting
information for the current job step is unreliable. However, provision is
made that the job aceounting information for any subsequent job steps will
be correct, provided the cancellation was not caused by an error in the
$JOBACCT routine itself. H there was an error in the $JOBACCT routine,
it must be corrected first.
In order to avoid unintentional cancellation of the job accounting
program by operator action, the operator should issue the MAP command
and check the job name for the running partition. H the job name is 'JOB
ACCT', the job accounting routine is active; the CANCEL command
should not be issued until the original job name is displayed after another
MAP command.
Register Usage. Important data for the user's job acpounting routine are
passed in the following general registers:
12
15
11
13
14
Base address for $JOBACCT
Address of the job accounting table
Length of the job accounting table
Address of the user save area
Return address to job control
H $JOBACCT uses LIOCS, the contents of general registers 14 and 15
must be saved (also registers 0 and 1 if necessary) because LIOCS uses
these registers.
Save Area for the User's Routine. The address of a save area that can be
used by the job accounting routine is passed in general register 13. This
save area is 16 bytes long unless a greater length (up to 1024 bytes for
saving DTF information for LIOCS) was specified at system generation
time. However, CCBs and executable CCWs must not be included.
User's Area for LIOCS Label Processing. H your job accounting routine
uses LIOCS for processing such items as standard tape labels, DTFDA, or
DTFPH with MOUNTED = ALL, then an alternative label area must be
specified at system generation. The length of this label area should
normally be the number of bytes that would be allocated by a given
parameter of the LBLTYP statement. For information on determining the
number of bytes, see DOS/VSE System Cor.tro! Statements.
Tailoring the Program
The requirements of the program may be simply to record the accounting
information as part of the SYSLST output for each job step or job, or it
may be to accumulate information to be used for equitably allocating the
costs of a computing center.
Chapter 4: Using the Facilities and Options of DOS/VSE
4.9
H data is to be written out on a disk or tape, the save area can be used
for communicating between job steps. Such information as the disk address
for the next record or an indication that tape labels have been successfully
processed, or even the DTF used to control the output, may be stored in
the save area.
Figure 4-5 illustrates a job accounting program that writes records to
disk without additional processing.
4.10 DOS/VSE System Management Guide
JAACT
CSECT
USING
* ,R12
JASAVE,R13
JOB ACCT SAVE AREA
USING
LR
R9,R15
SAVE ADDR OF TBL
RO,JADTFLNG+L'JABSAVE LENGTH FOR GETVIS
LA
LENGTH=(O)
GET SPACE IN PARTITION
GETVIS
R15,R15
CHECK RETU~~ CODE
LTR
JARET1
NO GETVIS SPACE
BNZ
RO,JABROUT
AB'ROUTINE
LA
AB,(0),(1)
SET ABNRML TERM EXIT
STXIT
R1,L'JABSAVE(R1)
UPDATE GETVIS POINTER
LA
JASTATSW,X'CO'
TEST STATUS
TM
JARET
DISK AREA FULL
BO
BM
JAOPEN
SAVE AREA INITIALIZED
* PERFORM LABEL PROCESSING AND INITIALIZE SAVE AREA
0(JADTFLNG,R1 ),JADTF MOVE DTF TO PARTITION
MVC
OPENR
(R1)
OPEN FILE (see Note)
MVC
JACCB,0(R1)
MOVE CCB TO SAVE AREA
JASEEK, 58( R 1 )
EXTENT LOWER LIMIT
MVC
MVI
JAR, X '01 '
FIRST RECORD
JAHIGH,JADTF+S4
HIGH EXTENT LIMIT
MVC
* RELOCATE CCWS
MVC
JASKCCW(32),JAMODCCW PUT MOD CCWS IN SVE AREA
LA
R10,JASEEK
SEEK ADDRESS
STCM
R10,7,JASKCCW+1
PUT ADDRESS IN CCW
LA
R10,JASRCH
SEARCH ADDRESS
STCM
R10,7,jASRCCW+1
PUT ADDRESS IN CCW
LA
R10,JASRCCW
SEARCH CCW ADDRESS
STCM
R10,7,JATIC+1
PUT ADDRESS IN CCW
LA
Rl0,JASKCCW
CHANNEL PROGRAM ADDR
STCM
R10,7,JACCB+9
PUT ADDRESS IN CCB
MVI
JASTATSW,X'80'
IND SAVE AREA INIT
* WRITE JOB ACCOUNTING TABLE TO DISK
JAOPEN
STCM
R9,7,JADATA+1
PUT ADDR OF TBL IN CCW
MVC
O( 16,R1 ),JACCB
MOVE CCB TO PARTITION
EXCP
(1)
WRITE DATA
WAIT
(1)
WAIT FOR COMPLETION
* UPDATE SEEK ADDRESS
TR
JAR, JARECTAB
RECORD
JAR,X'01'
NEW TRACK
CLI
BNE
JARET
NO
JAHEAD+1(1 ),JAHDTAB
TR
HEAD
JAHEAD+1,X'00'
CLI
NEW CYLINDER
BNE
JAHTST
NO
R10,JACYL
CYLINDER ADDRESS
LH
R10,1(R10)
INCREMENT BY ONE
LA
10,JACYL
REPLACE IN SEEK ADDR
STH
JAHTST
BEYOND UPPER LIMIT
JAHIGH,JASRCH
CLC
BH
NO
JARET
O( 16,R 1 ) ,JACCBL
MOVE CONSOLE CCB TO PARTITION
MVC
R2,JAMSG1
ERROR MESSAGE
LA
R2, 7 , 9( R 1 )
STCM
PUT ADDRESS IN CCB
(1)
INFORM OPERATOR
EXCP
(1)
WAIT FOR COMPLETION
WAIT
JASTATSW,X'40'
INDICATE DISK FULL
01
JARET
FREEVIS LENGTH=(O)
FREE PARTITION SPACE
RESET EXIT LINKAGE
AB
STXIT
R14
BR
RETURN
JARET1
Note:As this example is self relocating, the self-relocating form of the OPEN macro (OPENR) is used; for a routine that will be linked
relocatable, OPEN may be used instead.
FJgUre 4-5.
Job Accounting Routine Example (Part 1 of 2)
Chapter 4: Using the Facilities and Options vf DOS/VSE
4.11
JABROUT
LA
MVC
LA
STCM
EXCP
WAIT
EOJ
JAMODCCW CCW
CCW
CCW
CCW
JACCBL
CCB
JABSAVE DS
JADTF
DTFPH
JADTFLNG EQU
ORG
DC
ORG
JAMSG1
CCW
JAMSG2
CCW
JAERR1
DC
JAERR2
DC
JARECTAB DC
JAHDTAB DC
JASAVE
DSECT
JASEEK
DS
JABB
DS
JASRCH
DS
JACYL
DS
JAHEAD
DS
JAR
DS
JASTATSW DS
JACCB
DS
JAHIGH
DS
DS
JASKCCW CCW
JASRCCW CCW
JATIC
CCW
JADATA
CCW
*
RO
EQU
R1
EQU
R2
EQU
R9
EQU
R10
EQU
R11
EQU
R12
EQU
R13
EQU
R14
EQU
R15
EQU
END
R1,L'JABSAVE(R1 )
o( 16 , R1 ), J ACCBL
R2,JAMSG2
R2, 7 , 9( R1 )
(1)
(1)
X' 07' , * , X' 60' ,6
X'31',*,X'60',5
X; 08; , * , X; 00; , 1
X'05' ,*,X'20',246
SYSLOG,*
OCL72
TYPEFLE=INPUT,
DEVICE=2314,
MOUNTED=SINGLE
*-JADTF
JADTF
X'OOOOOBOO'
RESTORE ADDR IN GETVIS AREA
MOVE CONSOLE CCB TO PARTITION
ERROR MESSAGE
PUT ADDRESS IN CCB
INFORM OPERATOR
WAIT FOR COMPLETION
MEANS CHECK LABELS
SET CCB OPTION BITS
X'09' ,JAERR1,X'20',L'JAERR1
X'09' ,JAERR2,X'20',L'JAERR2
C'JOB ACCOUNTING DISK FULL'
C'JOB ACCOUNTING ROUTINE CANCELED'
X'0002030405060708090AOBOCODOEOF101112131401'
X'0102030405060708090AOBOCODOEOF1011121300'
OXL6
XL2
OXL5
XL2
XL2
X
X
XL16
XL4
XL4
X'07' ,JASEEK,X'60',6
X'31' ,JASRCH,X'60',5
X'08' ,JASRCCW,X'00',1
X'05',*,X'20',246
SEEK ADDRESS BBCCHH
BB
SEARCH ADDRESS CCHHR
CC
HH
R
COMMAND CONTROL BLOCK
HIGH EXTENT LIMIT
SEEK CCW
SEARCH CCW
TIC CCW
WRITE DATA ASSUMING 29
SIO DEVICES TRACED
0
1
2
9
10
11
12
13
14
15
Note: The DSECT labeled JASAVE through JADATA defines the layout of the job accounting user-saye area, which resides within the
supenisor. The address of this area is passed, in register 13, to your job accounting phase. When generating your supenisor you must
specify the desired length of this saYe area by substituting a yalue for s, the first operand of the JAUOCS parameter 0/ the FOPT
macro. If the operand is omitted or if JAUOCS=NO is specified the length of the user saye area is set to 16 bytes by default.
Figure 4-S.
Job AccountiDg Routine Example (part 2 of 2)
4.12 DOS/VSE System Management Guide
Checkpointing Facility
The progress of a program that performs considerable processing in one job
step should be protected against destruction in case the program is
canceled. DOS/VSE provides support for taking up to 32,767 checkpoint
records in a job. Through this facility, information can be preserved at
regular intervals and in sufficient quantity to allow restarting a program at
an intermediate point.
The CHKPT macro (or the corresponding high-level language
statement) causes DOS/VSE to store the checkpoint record on a magnetic
tape or disk. For more details about taking checkpoints, refer to
.
DOS/VSE Macro Reference if you use assembler language or to the
appropriate high-level language manual.
The RSTRT job control statement restarts the program from the last or
any specified checkpoint taken before cancelation.
When a checkpointed program is to be restarted, the partition must
start at the same location as when the program was checkpointed and its
end address must not be lower than at that time unless a lower end address
was specified in the CHKPT macro instruction. Unless the user
reestablishes all linkages to SVA phases himself, the contents and location
of the modules in the SVA when restarting must also be the same as when
the program was checkpointed. The SDL must be identical if the restarted
program uses a local directory list (for example, one that was generated by
the assembler language macro GENL).
H any pages of a virtual mode program were fixed when the checkpoint
record was taken, then, in 370 mode, the real address area allocation for
the partition must also start at the same or a lower location and its end
address must be at least as high as at that time. The pages that were fixed
are refixed by the supervisor when the program is restarted.
Restarting a Program from a Checkpoint
To restart a program from a checkpoint the RSTRT job control statement is
used. The sequence of job control statements that must be submitted to
restart a program is as follows:
1. A JOB statement specifying the jobname used when the checkpoints
were taken.
2. ASSGN statements, if necessary, to establish the 110 assignments for
the program that is to be restarted.
3. A RSTRT statement specifying
a) the symbolic name of the tape or disk device on which the
checkpoint records are stored.
b) the sequence number of the checkpoint record to be used for
restart.
c) for checkpoint records on disk the filename (DTF name) of the
checkpoint file.
4. An end-of-job (I &) statement.
Chapter 4: Using the Facilities and Options of DOS/VSE
4.13
Figure 4-6 shows the sequence of job control statements needed to restart a
checkpointed program that ended abnormally due to, for example, a power
failure. Following are the characteristics of the checkpointed program that
must be considered for restart:
•
The job name specified in the.JOB statement was CHECKP; the same
name must be used for restart.
•
The checkpoint records were written on magnetic tape; therefore, no
filename need be specified in the RSTRT statement.
•
The symbolic device name SYSOO6 is used for the checkpoint file.
•
The sequence number of the last checkpoint record written was 0013;
this or any previous checkpoint record can be used for restart (the
sequence numbers are printed by DOS/VSE on the SYSLOG device).
In reconstructing the job stream note that the / / RSTRT statement
physically and functionally replaces the / / EXEC statement originally used.
Another important consideration is the repositioning of files on
magnetic tape or disk. Assembler language users may consult DOS/VSE
Macro Reference, which discusses the topic in context with using the
CHKPT macro. High-level language users should consider printing a file
processing status record for each checkpoint that is taken during the
execution of a program. This record should indicate the nafoe of the file(s)
read or written on magnetic tape or disk when DOS/VSE takes the
checkpoint.
II
II
II
II
II
JOB CHECKP
ASSGN SYS006,380
ASSGN
ASSGN
RSTRT SYS006,0013
CHKPT TAPE
1&
Figure 4-6.
Example of a RESTART Job
DASD Switching under DOS/VSE
The standard I/O interface between an I/O device and the CPU is a
channel and a control unit.
Normally, this interface provides one, and only one, path by which a
CPU communicates with an I/O device. However, it may be desirable to
access a device, especially a DASD device, by more than one path. For
example, a second CPU may be required to back-up the host CPU such
that should the host CPU become inoperable, the attached DASD devices
may be switched immediately to (made accessible to) the back-up CPU.
Multiple CPUs may also need to access the same data base.
A single CPU may require back-up channels and control units,
providing alternate paths to the same DASD devices.
4.14 DOS/VSE System Management Guide
In order to do this device sharing, the hardware provides a two-level
switching mechanism that allows you to connect one or mote DASDs either
dynamically or manually to different I/O paths. This mechanism is known
as channel switching and string switching.
Channel Switching. Channel switching provides the switching mechanism at
the control unit level. The channel switch allows you to connect the control
unit to up to four channels, which may belong to the same or different
CPUs thus providing up to four distinct I/O paths. A maximum of two
channels may connect to one CPU. The connection of any channel can be
manually enabled or disabled. When enabled, the switch is dynamically
controlled by the hardware.
String Switching. In the case of string switching, the switching mechanism is
at the DASD string level. String switching allows you to connect a string of
DASDs to two distinct control units, or integrated disk attachments. The
two I/O paths may be connected to a single or two different CPUs.
Using DASD Switching. In both types of this hardware-supported switching,
a desired I/O path may be selected in one of two ways. In the first case,
connection is made dynamically when an I/O command is issued for a
device. Provided that the control unit (in channel switching) and the DASD
string (in string switching) are free for connection, the target DASD device
can be accessed by the requesting CPU. Once a connection is established
by one CPU, the other CPU receives device busy status if attempting to
access a device on the string.
In the second case, the operator may manually switch the sharable
devices to the desired CPU (via the Enable/Disable toggle switches). It
should be noted that in this case an entire string of DASD is disconnected
from the other CPU.
H, at your installation, a DASD switching feature is being used, it is
your responsibility to resolve conflicting CPU references to shared devices
(or files) and thus ensure data integrity. Following are two ways of
preventing potential conflicts.
First, through scheduling of CPU file referencing, ensure that only one
CPU that is updating the file is connected to the shared DASD. The
operator needs only to switch the manual control to the updating CPU for
that period of time.
Secondly, through scheduling and the use of the operator commands
DVCUP and DVCDN (as described below), devices may be reserved for
use by one CPU for a particular period of time.
An individual device can be excluded from use by a particular CPU by
entering a DVCDN command for that device via the operator console. The
other system then has exclusive access to that device. The device can be
made available again by issuing a DVCUP command for the device.
However, the other system should then issue a DVCDN command for that
device. To avoid conflicts, both system operators have to inform each other
about the status of the reserved devices. It is therefore recommended that a
job, which requires exclusive access to a file or device, notifies the operator
when the device has to be reserved, and when it may be released.
Chapter 4: Using the Facilities and Options of DOS/VSE
4.15
Note that the DVCUP/DVCDN commands reserve the DASD at the
device level, although the programmer may be interested in reserving only
one file on that particular device. It is recommended that DVCUP and
DVCDN commands be entered only via the console.
Further hardware details on chpnnel or string switching may be found
in the appropriate DASD hardware manuals, and also in the hardware
manuals for the mM 370/115, 370/125.
\\'hen using DASD Switching, in order to iacilitate the diagnosis oi
hardware failures, the inclusion of Recovery Management Support (RMS) is
required. For System/370 Models 115 or 125, RMS may be included
during DOS/VSE system generation by specifying RMS= YES in the
SUPVR macro.
Designing Programs for Virtual Mode Execution
This section describes programming techniques that may improve the
efficiency of programs that execute in virtual mode. Consider these
techniques for new programs to be written and old programs to be revised.
The section also contains information on the use of certain macros that are
provided especially for virtual storage. Programming conventions for the
shared virtual area are also discussed.
Programming Hints lor Reducing Page Faults
It is definitely worthwhile to spend some extra programming effort for
tuning virtual-mode programs that are used frequently or that require long
periods of processing time so that they will cause fewer page faults during
execution. Page faults generally occur when the size of the virtual-mode
program exceeds the number of page frames available to it during
execution. Efforts to reduce the number of page faults occurring in a
program generally involve techniques for reducing the size of the working
set of the program. The term working set is one that recurs often in
discussions of virtual storage systems.
The working set of a program is comprised of those program pages that
contain the most frequently used sequences of instructions for a given
period of time. The working set of a program is not a fixed number of
pages or instructions of that program; this set changes as the execution of
the program proceeds. For example, a program doing an internal sort and
writing a formatted table based on the results of this sort would have two
completely different basic working sets; one for the sort function and one
for the write functions.
What does execute efficiently mean? Essentially, this means that a
program will not execute appreciably slower than if the entire program were
in processor storage during its entire execution.
Although the following section does not tell you how to determine the
size of the working set, it does provide techniques for reducing its size.
4.16 DOS/VSE System Management Guide
General Hints for Reducing the Working Set
There are three general rules to keep in mind when working toward a
reduction of a program's working set. The first is locality of reference, that
is, instructions and data used together should be in storage near each other.
Second is minimum processor storage. In other words, the amount of
processor storage necessary for a program to do something should be kept
as low as possible. Third is validity of reference, that is, references should
be made only to data which will actually be used.
The chief means of achieving locality of reference is to make execution
sequential whenever possible by avoiding excessive branching.
A program that executes sequentially normally requires a partition
larger than the same program when it does not execute sequentially. For
example, the functions of a section of code repeat themselves several times
throughout the logic of your program. You are tempted to write this code
once and branch to it whenever necessary, but branching violates the
principle of locality of reference. Branching may cause more page faults
than would coding the routine in line each time it is used. Also, it is easier
for someone else to follow the logic of a program which is written to
execute sequentially.
Locality of reference can be achieved only to a limited extent by
programs written in a high-level language.
Elements in arrays in FORTRAN or PL/I can be referred to in the
order in which they appear in storage. In FORTRAN, for example, arrays
are ordered by columns. The elements of the array DIMENSION (2,2,2)
are arranged as follows in contiguous virtual storage locations:
(1,1,1)
(1,2,1)
(1,1,2)
(1,2,2)
(2,1,1)
(2,2,1)
(2,1,2)
(2,2,2)
For array structures of other compilers, refer to the appropriate
programming language reference manuals.
A routine which processes all the elements of such an array should
refer to them in this order. H only certain elements of an array are
processed, the elements should be arranged in the order in- which they are
to be processed. H arranging an array in a certain manner causes it to be
processed advantageously one time, but disadvantageously another time,
you should consider writing two arrays, even at the cost of additional
virtual storage.
In an assembler language program, you should keep frequently used
data and constants near each other in storage, and near the instructions
which use them. This contrasts with the traditional practice of having one
area at the end of the program reserved for all the data areas and
constants. By the same token, seldom used data should be separated from
the frequently used data and placed with the routines which use it.
Avoid, if possible, using chains which must be searched each time a
data item is required. H chains are unavoidable they should be kept in a
Chapter 4: Using the Facilities and Options of DOS/VSE
4.17
compact area of storage. This may result in some wasted (virtual) storage
but will be better than searches of large areas of storage.
Another good practice to help reduce paging is to initialize variables
just before they are to be used. For example in PL/I instead of the
following:
DCL A FIXED INIT (10);
DO B=1 TO 100;
A=A+B;
END;
use:
DCL A FIXED;
A=10;
DO B=1 TO 100;
A=A+B;
END;
In the first method of cod.i:ilg, PL/I initializes the automatic variable at the
beginning of execution. The second method of coding does not require the
page containing A to be in processor storage until just before A is used.
An important help in reducing the amount of processor storage needed
for execution is to keep codiitg used for errors or other unusual occurrences
in a separate routine. H, for example, the main routine contains code for
conditions that occur only 5 % of the time, by moving this error code to a
separate section of your program, you can reduce the amount of needed
processor storage for 95 % of the processing.
Frequently-used subroutines should be loaded near each other. Because
of their frequent use, these routines tend to be in processor storage almost
continuously. H they are scattered over several pages, each of these pages
will need to be in processor storage most of the time, thus increasing the
size of the working set. By loading these routines near each other, you
reduce the number of pages required in processor storage at anyone time.
Subroutines should be designed to do as much processing as possible
whenever they are called. It is better to duplicate some code from the
calling routine in the called routine in order to avoid switching back and
forth between routines. One technique for accomplishing this is to have the
calling program pass several parameters to the subroutine and make one
call, rather than passing one parameter at a time and make several calls.
You should try to keep code that can be modified and code that cannot
be modified in separate sections of a large program. This will reduce page
traffic by reducing the number of pages that are changed. Also, try to
prevent I/O buffets from crossing page boundaries unnecessarily. Check
the assembler listing and the linkage editor map to determine where 2K
boundaries occur in your programs.
4.18 DOS/VSE System Management Guide
Using YirlJUll Storage Macros
The macros designed for use by virtual-mode programs, which are discussed
below, perform the following services:
•
fix. pages in processor storage (PFIX macro) and later free the same
pages for normal paging (PFREE macro).
•
indicate the mode of execution of a program (RUNMODE macro).
•
influence the paging mechanism in order to reduce the number of page
faults, to minimize the page I/O activity, and to control the page traffic
within a specific partition.
In order to use these macros you must be programming in assembler
language or, if your program is written in a high-level language, you must
write an assembler subroutine to make use of them. Refer to DOS/VSE
Macro Reference for a detailed description of these macros.
Fixing Pages in Processor Storage
In DOS/VSE, parts of virtual-mode programs must be 1n processor storage
only at certain times. These parts include not only the instructions and data
being processed at anyone moment, but also data areas for use by channel
programs. Instructions and data are always in processor storage when being
used. Because of the nature of I/O operations, the data areas for these
operations could be paged out during the I/O operation if something were
not done to keep them in processor storage during the entire operation.
DOS/VSE therefore fixes I/O areas in processor storage for the duration
of the I/O operation.
There are other parts of a program, however, which cannot tolerate
paging, and these parts are not necessarily kept in storage by DOS/VSE.
For instance, programs that control time-dependent I/O operations cannot
tolerate paging. A familiar example is a MICR (Magnetic Ink Character
Reader) stacker select routine. H a page fault were to occur during the
execution of one of these programs, the results would be unpredictable. A
page fault in one of these programs can be avoided by fixing the affected
pages in processor storage, using the PFIX macro.
The pages that you fix by the PFIX macro are fixed in the processor
storage allocated to the partition in which the PFIX request is issued. Only
as many pages may be fixed by a program at anyone time as there are
page frames allocated to the partition. This is done to prevent a loop in one
program from fixing all the pages in the system, and to enable other
programs to issue a PFIX macro concU-rrently.
The PFIX macro fixes the pages in processor storage, regardless of
whether these pages are stored in contiguous page frames or not. The
supervisor keeps a count of the number of times a page has been fixed
without being freed. A page that is fixed more than once without having
been freed (via the PFREE macro) is not brought in a second time and
given another page frame. Instead, the counter for that page is just
increased by one and the page remains in the same page frame.
Chapter 4: Using the Facilities and Options of DOS/VSE
4.19
The PFREE macro does not directly free a page for paging out, but
each time it is issued, the counter of fixes is reduced by one. As soon as
the counter for a page reaches zero, the page can be paged out. At the end
of a job step, all pages that have been fixed during the job step are freed.
The PFREE macro should be used as soon as possible to make a
maximum possible number of page frames available to all programs running
in virtual mode.
Figure 4-7 is a skeleton example using the PFIX and PFREE macros.
After the execution of a PFIX macro, a return code is given in register 15.
The meanings of the return codes are:
o-
The pages were fixed successfully.
4-
You requested more page frames than the number of PFIXable
page frames available to the partition.
8-
Insufficient free page frames were available.
12 -
You specified invalid addresses in your macros.
Note in the example how the return code can be used to establish a branch
to parts of the program that handle these specific conditions.
FIXER
PFIX
B
B
B
B
B
ARTN,ARTNEND+2 FIX ARTN IN STORAGE
*+4(15) BRANCH ACCORDING TO RETURN CODE
HERE
CONTINUE IF OK
NOPAGES GO TO CANCEL IF PART TOO SMALL
WAIT
GO TO WAIT UNTIL PAGES FREED
CANCL
GO TO CANCEL IF ADDR INVALID
14,ARTN GO TO ARTN
ARTN,ARTNEND+2 FREE ROUTINE AFTER EXECUTION
HERE
BAL
PFREE
ARTN
(time dependent processing which cannot be
paged out during execution)
ARTNEND
BR
NOPAGES
LA
R1,OPCCB
EXCP
(1)
WRITE MESSAGE TO OPERATOR
WAIT
(1)
WAIT FOR COMPLETION
CANCEL ALL
CANCL
WAIT
END
OPCCB
OPCCW
MSG
Figure 4-7.
4.20 DOS/VSE System Management Guide
R14
RETURN
(routine to free other pages)
EOJ
CCB
CCW
DC
DC
SYSLOG,OPCCW
X'09',MSG,X'20' ,61
CL32'AM CANCELING PLEASE ENLARGE REAL'
CL29'ADDR AREA AND RESTART THE JOB'
PFIX and PFREE Example
Indicating the Execution Mode of a Program
You may have a program that must do different processing depending upon
its execution mode. It may be impractical to have two separate programs
cataloged in the core image library (one program for real mode and another
program for virtual molle). The RlJNMODE macro can be issued during the
execution of thff program to inquire which mode of execution is being used. A
return code is issued to the program in register 1.
Influencing the Paging Mechanism
Releasing Pages. With the RELPAG macro, you inform the page
management routines that the contents of one or more pages is no longer
required and need not be saved on the page data set. Thus, page frames
occupied by these released pages can be claimed for use by other pages,
and page 110 activity is reduced.
Forcing Page-out. The FCEPGOUT macro is used to inform the page
management routines that one or more pages will not be needed until a
later stage of processing. The pages are given the highest page-out priority,
with the result that other pages, which may be needed immediately, are
kept in storage. Except when the RELPAG macro is in operation, the
contents of any pages written out are saved.
Page-in in Advance. The P AGEIN macro allows you to request that one or
more pages be read into processor storage in advance, in order to avoid
page faults when the specified pages are needed in processor storage. If the
specified pages are already in processor storage when the macro is issued,
they are given the lowest priority for page-out.
Balancing Telecommunication Activity
The use of telecommunication and production processing at the same time
may, occasionally, result in long or erratic telecommunication response
times. This may be especially true if you have overcommitted processor
storage, thus causing excessive paging. The telecommunication application
may have to compete so strongly for page frames (because of high
processing activity in the other partitions) that response time increases
substantially.
Telecommunication balancing improves response time by trading off
telecommunication response time against produ~tion partition throughput.
TP balancing tends to reduce response times, or at least to stabilize them.
After IPL, TP balancing can be activated by the operator issuing the
TPBAL command, which specifies the number of partitions that can
tolerate delayed processing. These will be the lowest priority partitions. The
TPBAL command is also used to change or display the current setting (for
more information, see the DOS/VSE Operating Procedures). Once
activated, the TP balancing function can be invoked by using
TPIN/TPOUT macros.
Ch@ter 4: Using the Facilities and Options of DOS/VSE 4.21
The TPIN macro signals to DOS/VSE that an immediate demand for
system resources is being made by the telecommunication application, for
instance, when a message has arrived. After processing is completed,
TPOUT informs DOS/VSE that the telecommunication application has no
further processing to do for the time being, and that the system resources
that were exclusively used for telecommunication should be released. Failure
to issue the TPOUT macro can cause serious performance degradation in
production partition throughput.
The TPIN and TPOUT macros have been made available primarily for
use in mM licensed telecommunication support (for example, ACF /VTAM
and CICS/VS). There is no need for these macros to be used in
user-written application programs that run under control of mM supplied
telecommunication support.
Coding lor the Shared Yi11lUl1 Area
Besides accommodating the system directory list (SDL), and perhaps the
VSE/VSAM phases with their associated GETVIS work area, the shared
virtual area (SVA) contains phases that can be used concurrently by more
than one partition. The SVA phases must be reenterable and reldtatable;
code that modifies itself will cause a protection check when executed from
the SVA. This section presents some advice on coding phases to use SVA
facilities and suggests some standards for base-register usage.
The basic assumptions for coding an SVA phase are:
•
The reenterable code must not modify any storage within its own
storage area. Therefore, the code must not contain DTFs, CCBs, or
other control blocks that are modified during execution.
•
The phase can modify registers only if it saves and restores them for
each user.
•
A user-specified work area (within the calling partition) must be
provided for storing registers and for any storage modifications.
Suggested register conventions:
•
Use register 12 as the base register in both the main routine and the
reenterable code.
•
Use register 13 as base for the working storage area. It is the
responsibility of the main routine to provide addressability to the work
area by loading register 13; the reenterable routine must not modify
register 13. The easiest way to address the working storage area in the
reenterable code is by a DSECT that defines the fields of the work area
and a USING dsectname,13. In this way symbolic addressing can be
used.
•
Use CALL, SAVE, and RETURN macros. Since register 13 is the base
register, SAVE (14,12) and RETURN (14,12) result. Use register
notation for CALL, for example, CALL (15) .... Before issuing the
CALL, load register 15 with the transfer address. Register 14 will
always contain the return address. The standard is thus established of
register 15 for calling and register 14 for returning.
4.22 DOS/VSE System Management Guide
•
Switches, and other areas that may be modified, can be placed in the
working storage area using base register 13.
Figure 4-8 illustrates the suggested conventions: MASTER is the main
routine, SLAVB is the SVA phase.
MASTER
CSECT
BALR
USING
LA
LOAD
12,0
*,12
13,SAVE
SLAVE, WORKAREA
LR
CALL
15,1
(15),(SWITCH,TECB,FIELDA,FIELDB,WORKAREA)
EOJ
DS
DS
9D
200D
*
*
SAVE
WORKAREA
*
SWITCH
TECB
FIELDA
FIELDB
SLAVE
DC
DS
DS
DS
END
CSECT
SAVE
BALR
USING
USING
LM
MVC
MVC
CLI
BE
SETlME
WAIT
EXIT
XI
RETURN
DATA 1
DC
DATA2
DC
LTORG
WORKAREA DSECT
FIELDC
DS
FIELDD
DS
END
Figure 4-8.
CANCELS IF SLAVE NOT IN CIL
LOADS SLAVE INTO WORKAREA
IF SLAVE IS NOT IN SVA
SLAVE IS LOADED HERE
IF NOT IN SVA
XL1 '00'
CL4
CL15
CL11
MUST BE SEPARATE ASSEMBLY
(14,12)
12,0
*,12
WORKAREA,6
2,6,0( 1 )
O( 15,4),DATA1
O( 11 ,5 ) , DATA2
O( 2 ),X' FF'
EXIT
SETlME ALTERS THE TECB
3, ( 3 )
(3 )
O( 2 ), X' FF'
(14,12)
CL15'THIS IS FIELDA'
CL11'THIS IS FIELDB'
3D
3D
Example of Conventions for SVA Coding
Chapter 4: Using the Facilities and Options of DOS/VSE 4.23
Appendix A: System Layout on Disk
Figures A-I and A-2 illustrate how the system residence (SYSRES) file is
organized. The volume containing the system residence file can be any mM
DASD device supported by DOS/VSE except a 2311 disk.
IPL Records
This area contains the initial program load (IPL) bootstrap records, which
cause the IPL retrieval program to be read from SYSRES and loaded into
processor storage. For CKD devices the IPL retrieval program is at cylinder
0, track 1, record 5. For FBA devices it is contained within blocks 3
through 9.
System Yolllme Label
The volume label (VOL1 label) contains the address of the volume table of
contents (VTOC) established when the pack was initialized. (The
DOS/VSE system utility program Initialize Disk is"provided for this
purpose). The VTOC must be located outside of the SYSRES extent.
User Yolllme Label
The user volume label area is provided for any additional standard volume
labels (VOL2-VOL8 labels). This area can extend from record 4 through
the end of track 0 on CKD devices or from the end of the system volume
label to the end of block 1 on FBA devices.
System Directory
The SYSRES file starts with the system directory. This directory contains
the starting addresses of the 4 library directories and the address of the
label information area.
Library Directories and Libraries
The purpose of these areas of the SYSRES file is discussed in Chapter 3 of
.
this manual.
Labell"formatio" A.rea
The SYSRES file ends with the, label information area. The purpose of this
area is described in Chapter 2 of this manual.
Appendix A: System Layout on Disk
A.1
Starting Disk Address
Component
IPL Record
CC
HH
R
00
00
1
00
00
2
Number
of Tracks
(Alloc.)
R = Required
0= Optional
R
(Phase $$A$I PL1 )
IPL Record
R
1
System Volume Label
00
00
3
R
User Volume Label
00
00
4
0
Record 1
00
01
1
R
Record 2
00
01
2
R
Record 3
00
01
3
Record 4
00
01
4
R
00
01
5
R
00
02
X
Y+1
Z+l
System Directory
IPL Records (Phase $$A$PLBK)
1
R
Cata loged Phases
Core I mage Directory
*
R
1
*
R
00
1
*
0
X
Y+1
1
*
0
Z+1
00
1
*
0
X
Y+1
1
*
0
Z+1
00
1
*
0
X
Y+1
1
*
0
Z+1
00
1
Device
dependent
R
Linked Phase
Core I mage Library Members
Relocatable Directory
Relocatable Library Members
Source Statement Directory
Source Statement Library Members
Procedure Directory
Procedure Library Members
Label I nformation Area
* Allocation Dependent on User Requirements
X = Ending CC of the Preceding Directory
Y = Ending HH of the Preceding Directory
Z = Ending CC of the Preceding Library
Note: Track 0 of cylinder 0 is not part of the SYSRES file.
Figure A-t.
System Residence Organization on
A.2 DOS/VSE System Management Guide
em Devices
Starting Disk Address
Block Number
Number of
Blocks
R=Required
O=Optional
IPL Records
(Phase $$A$I PLO)
0
1
R
System Volume Labell
1
1
R
System Directory
2
1
R
IPL Retrieval Program
(Phase $$A$PLB F)
3
7
R
Core I mage Directory
Component
10
*
R
Core I mage Library
Members
X+1
*
R
Relocatable Directory
Y+1
*
D
Relocatable Library
Members
X+1
It-
D
Source Statement Directory
Y+1
It-
0
Source Statement pbrary
Members
Procedure Directory
X+1
*
Y+1
It-
Procedure Library Members
X+1
It-
Label I nformation Area
*
X=
Y=
Y+1
200
0
0
D
2
R
Allocation dependent on user requirements
Last block of preceding directory
Last block of preceding library
1
Optional user volume labels if written will be in the same block following the
system volume label.
2
Using the Restore program you may allocate a label information area different
than the default size of 200 blocks.
Note: Blocks 0 and 1 are nat part afthe SYSRES file.
Figure A-2.
System Residence Organization on FDA devices
Appendix A: System Layout on Disk
A.3
Glossary
This glossary defines the terms proper to this manual. If you do not find the term you
are looking for, refer to the IBM Data Processing Glossary, GC20-1699.
This glossary includes definitions developed by the American National Standards
Institute (ANSI) and the International Organization for Standardization (ISO). This
material is reproduced from the American National Dictionary for Information
Processing, copyright 1977 by the Computer and Business Equipment Manufacturers
Association, copies of which may be purchased from the American National Standards
Institute, 1430 Broadway, New York, New York 10018. American National Standard
Definitions are marked with an asterisk (*).
access method: A technique for moving data between virtual storage and
input/output devices.
access method services: A multifunction service program that defines
VSAM files and allocates space for them, converts indexed-seqllential files
to key-sequenced ftIes with indexes, modifies file attributes in the catalog,
reorganizes ftIes, facilitates data portability between operating systems,
creates backup copies of files and indexes, helps make inaccessible files
accessible, and lists the records of the files and catalogs.
address: (1) An identification, as represented by a name, label, or number,
for a register, location in storage, or any other data source or destination
such as the location of a station in a communication network. (2) Loosely,
any part of an instruction that specifies the location of an operand for the
instruction.
address translation: The process of changing the address of an item of
data or an instruction from its virtual address to its real storage address.
See also dynamic address translation.
alternate track: One of a number of tracks set aside on a disk pack for use
as alternatives to any defective tracks found elsewhere on the disk pack.
application program: A program written by a user that applies to his own
work.
assembler language: A source language that includes symbolic machine
language statements in which there is a one-to-one correspondence with the
instruction formats and data formats of the computer.
attach: (1) To create a task and present it to the supervisor. (2) A macro
instruction that causes the control program to create a new task and
indicates the entry point in the program to be given control when the new
task becomes active.
auxiliary storage: Data storage other than real storage; for example,
storage on magnetic tape or disk. Synonymous with external storage,
secondary storage.
blocking: Combining two or more logical records into one block.
blocking factor: The number of logical records combined into one
Glossary 5.1
physical record or block.
book: A group of source statements written in any of the languages
supported by DOS/VSE and stored in a source statement library.
buffer: An area of storage that is temporarily reserved for use in
pedorming an input/output operation, into which data is read or from
which data is written. Synonymous with I/O area.
byte: A sequence of eight adjacent binary digits that are operated upon as
a unit and that constitute the smallest addressable unit of the system.
card punch: A device to record information in cards by punching holes in
the cards to represent letters, digits, and special characters.
card reader: A device which senses and translates into machine code the
holes in punched cards.
cardless system: A System/370 Model 115/125 configured without a
card reader or card punch, but with an mM 3540 Diskette Input/Output
Unit.
catalog: To enter a phase, module, book, or procedure into one of the
system or private libraries.
*
central processing unit: A unit of a computer that includes the circuits
controlling the interpretation and execution of instructions. Abbreviated
CPU.
channel: (1) • A path along which signals can be sent, for example, data
channel, output channel. (2) A hardware device that connects the CPU and
real storage with the I/O control units.
channel program translation: In a copy of a channel program,
replacement, by software, of virtual addresses with real addresses.
compile: To prepare a machine language program from a computer
program written in a high-level language by making use of the overall logic
structure of the program, or generating more than one machine instruction
for each symbolic statement, or both, as well as pedorming the function of
an assembler.
compiler: A program that translates high-level language statements into
machine language instructions.
configuration: The group of machines, devices, etc., which make up a data
processing system.
control area: A group of control intervals used as a unit for formatting a
file before adding records to it. Also, in a key-sequenced file, the set of
control intervals covered by an index record; used by VSAM for
distributing free space and for placing a low-level index adjacent to its data.
control interval: (1) A fixed-length area of auxiliary storage space in
which VSAM stores records and distributes free space, also, in a
key-sequenced file, the set of records pointed to by an entry in the index
record. It is the unit of information transmitted to or from auxiliary storage
by VSAM, independent of blocksize. (2) For an FBA device, the unit of
data transfer between processor storage and the device. It has the same
format as a VSAM control interval. In recording data, IOCS maps each
control interval over an integral number of FBA blocks.
5.2 DOS/VSE System Management Guide
control program: A program that is designed to schedule and supervise
the performance of data processing work by a computing system.
control registers: A set of registers used for operating system control of
relocation, priority interruption, program event recording, error recovery,
and masking operations.
control section: That part of a program specified by the programmer to
be a relocatable unit.
control unit: A device that controls the reading, writing, or display of data
at one or more input/output devices.
core image library: A library of phases that have been produced as
output from link-editing. The phases in the core image library are in a
format that is executable either directly or after processing by the relocating
loader in the supervisor.
count-key-data (CKD) device: A disk storage device storing data in the
format: count field normally followed by a key field followed by the actual
data of a record. The count field contains, among others, the address of the
record in the format CCHHR. (CC = cylinder number, IllI = head or
track number, R = record number) and the length of the data; the key area
contains the record's key (search argument). See also fixed block
architecture (FBA) device.
CPU busy time: The amount of time devoted by the central processing
unit to the execution of instructions.
data file: A collection of related data records organized in a specific
manner. For example, a payroll file (one record for each employee,
showing his rate of pay, deductions, etc., or an inventory item, showing the
cost, selling price, number in stock, etc.). See also file.
data integrity: See integrity.
data management: A major function of DOS/VSE that involves
organizing, storing, locating, retrieving, and maintaining data.
deblocking: The action of making the first and each subsequent logical
record of a block available for processing one record at a time.
default value: The choice among exclusive alternatives made by the
system when no explicit choice is specified by the user.
deletion of an I/O Device: Removal of the I/O unit from the supervisor
configuration tables.
diagnostic routine: A program that facilitates computer maintenance by
detection and isolation of malfunctions or mistakes.
dial-up terminal: A terminal on a switched teleprocessing line.
direct access: (1) Retrieval or storage of data by a reference to its
location on a volume, other than relative to the previously retrieved or
stored data. (2) * Pertaining to the process of obtaining data from, or
placing data into, storage where the time required for such access is
independent of the location of the data most recently obtained or placed in
storage. (3) * Pertaining to a storage device in which the access time is
effectively independent of the location of the data. Synonymous with
random access.
Glossary 5.3
direct organization: Direct file organization implies that for purposes of
storage and retrieval there is a direct relationship between the contents of
the records and their addresses on disk storage.
directory: An index that is used by the system control and service
programs to locate one or more sequential blocks of program information
that are stored on direct access storage.
diskette: A flexible magnetic-oxide coated disk suitable for data storage
and retrieval. Data may be stored and retrieved via such devices as the
mM 3740 Data Entry Unit and the mM 3540 Diskette Input/Output Unit.
Diskettes are also used to contain microprograms for some central
processing units.
disk pack: A direct access storage vol~e containing magnetic disks on
which data is stored. Disk packs are mounted on a disk storage drive, such
as the mM 3330 Disk Storage Drive.
distributed free space: Space reserved within the control intervals of a
key-sequenced file for inserting new records into the file in key sequence;
also, whole control intervals reserved in a control area for the same
purpose.
dump: (1) To copy the contents of all or part of virtual storage. (2) The
data resulting from the process as in (1).
dynamic address translation (OAT): (1) The change of a virtual storage
address to an address in real storage during execution of an instruction. (2)
A hardware function that performs the translation.
entry sequence: 'Qle order in which data records are physically arranged
in auxiliary storage, without respect to their contents (contrast with key
sequence).
entry-sequenced file: A VSAM file whose records are loaded without
respect to their contents, and whose relative byte addresses cannot change.
Records are retrieved and stored by addressed access, and new records are
added to the end of the file.
error message: The communication that an error has been detected.
error recovery procedures: Procedures designed to help isolate, and,
when possible, to recover from errors in equipment. The procedures are
often used in conjunction with programs that record the statistics of
machine maHunctions.
extent: A continuous space on a direct access storage device, occupied by
or reserved for a particular file.
*
file: A collection of related records treated as a unit. For example, one line
of an invoice may form an item, a complete invoice may form a record, the
complete set of such records may form a file, the collection of inventory
control files may form a library, and the libraries used by an organization
are known as its data bank.
5.4 DOS/VSE System Management Guide
FBA: See fixed block architecture (FBA) device.
FBA block: A unit of data of fixed length on which the FBA architecture
is based.
fixed block architecture (FBA) device: A disk storage device storing
data in blocks of fixed size; these blocks are addressed by block number
relative to the beginning of the file.
fixed page: A page in processor storage that is not to be paged out.
hard copy: A printed copy of machine output in a visually readable form,
for example, printed reports, listings, documents, and summaries.
hard wait state: In general, a wait state is the condition of a CPU when
all operations are suspended. System recovery from a hard wait state
requires that the user performs a new IPL (initial program load) procedure.
•
hardware: Physical equipment, as opposed to the computer program or
method of use, for example, mechanical, magnetic, electrical, or electronic
devices. Contrast with software.
•
idle time: That part of available time during which the hardware is not
being used.
index: (1) • An ordered reference list of the contents of a file or
document, together with keys or reference notations for identification or
location of those contents. (2) A table used to locate the records of an
indexed sequential file.
indexed-sequential organization: The records of an indexed sequential
file are arranged in logical sequence by key. Indexes to these keys permit
direct access to individual records. All or part of the file can be processed
sequentially.
Initial Program Load (lPL): The intialization procedure that causes
DOS/VSE to commence operation.
integrity: Preservation of data or programs for their intended purpose.
•
interface: A shared boundary. An interface might be a hardware
component to link two devices or it might be a portion of storage or
registers accessed by two or more computer programs.
•
I/O: An abbreviation for input/output.
ISAM interface program: A set of routines that allow a processing
program coded to use ISAM to gain access to a VSAM key-sequenced file
with an index.
job: (1) • A specified group of tasks prescribed as a unit of work for a
computer. By extension, a job usually includes all necessary computer
programs, linkages, files, and instructions to the operating system. (2) A
collection of related probiem programs, identified in the input stream by a
JOB statement followed by one or more EXEC statements.
job accounting interface: A function that accumulates, for each job step,
accounting information that can be used for charging usage of the system,
planning new applications, and supervising system operation more efficiently.
Glossary 5.5
job control: A program that is called into a partition to prepare each job or
job step to be run. Some of its functions are to assign 110 devices to certain
symbolic names, set switches for program use, log (or print) job control
statements, and fetch the first program phase of each job step.
job (JOB) statement: The job control statement that identifies the
beginning of a job. It contains the name of the job.
job step: The execution of a single processing program.
K: 1024.
•
key: One or more characters associated within an item of data that are
used to identify it or control its use.
key sequence: The collating sequence of data records, determined by the
value of the key field in each of the data records. May be the same as, or
different from, the entry sequence of the records.
key-sequenced file: A file whose records are loaded in key sequence and
controlled by an index. Records are retrieved and stored by keyed access or
by addressed access, and new records are inserted in the file in key
sequence by means of distributed free space. Relative byte addresses of
records can change.
label: identification record for a tape, diskette, or disk file.
label information area: Under DOS/VSE, the last portion of the system
residence file that stores label information read from job control statements
or commands.
language translator: A general term for any assembler, compiler, or other
routine that accepts statements in one language and procedures equivalent
statements in another language.
leased facility: A circuit of the public telephone network made available
for the exclusive use of one subscriber.
librarian: The set of programs that maintains, services, and organizes the
system and private libraries.
library: A collection of files or programs, each element of which has a
unique name, that are related by some common characteristics. For
example, all phases in the core image library have been processed by the
linkage editor.
linkage editor: A processing program that prepares the output of language
translators for execution. It combines separately produced object modules;
resolves symbolic cross references among them, and generates overlay
structure on request; and ptoduces executable code (a phase) that is ready
to be fetched or loaded into virtual storage.
load: (1) • In programming, to enter instructions or data into storage or
working registers. (2) In DOS/VSE, to bring a program phase from a core
image library into virtual storage for execution.
main page pool: The set of all page frames in processor storage not
assigned to the supervisor or one of the partitions.
message: See error message, operator message.
5.6 DOS/VSE System Management Guide
microprogramming: A method of working of the CPU in which each
complete instruction starts the execution of a sequence of instructions,
called microinstructions, which are generally at a more elementary level.
multiprogramming system: A system that controls more than one
program simultaneously by interleaving their execution.
multitasking: The concurrent execution of one main task and one or more
subtasks in the same partition.
object code: Output from a compiler or assembler which is suitable for
processing by the linkage editor to produce executable machine code.
*
object module: A module that is the output of an assembler or compiler
and is input to a linkage editor.
object program: A fully compiled or assembled program. Contrast with
source program.
*
online: (1) Pertaining to equipment or devices under control of the central
proeesSirig Uriit. (2)"Pertairiiiig to a user's a6i1ity to interact with a computer.
operand: (1) * That which is operated upon. An operand is usually
identified by an address part of an instruction. (2) Information entered with
a command name to define the data on which a command processor
operates and to control the execution of the command processor.
operator command: A statement to the control program, issued via a
console device, which causes the control program to provide requested
information, alter normal operations, initiate new operations, or terminate
existing operations.
operator message: A message from the operating system or a problem
program directing the operator to perform a specific function, such as
mounting a tape reel, or informing him of specific conditions within the
system, such as an error condition.
*
overflow: (1) That portion of the result of an operation that exceeds the
capacity of the intended unit of storage. (2) Pertaining to the generation of
overflow as in (1).
overlay: n. (1) One of the segments, which consists of one or more
phases, of a program that is so structured that not all of the segments need
be in virtual storage at anyone time. v. (2) The process of replacing a
previously retrieved program segment in virtual storage by another segment.
page: (1) In DOS/VSE, a 2K block of instructions, data or both. (2) To
transfer instructions, data, or both between processor storage and the page
data set.
page data set: An extent in auxiliary storage, in which pages are stored.
page fault: A program check interruption that occurs when a page that is
marked not in processor storage is referred to by an active page.
Synonymous with page translation exception.
page fixing: Marking a page as nonpageable so that it remains in
processor storage.
page frame: A 2K block of processor storage that can contain a page.
Glossary 5.7
page in: The process of transferring a page from the page data set to
processor storage.
page out: The process of transferring a page from processor storage to the
page data set.
page pool: The set of all page frames that may contain pages of programs
in virtual mode.
paging: The process of transferring pages between processor storage and
the page data set.
•
parameter: A variable that is given a constant value for a specific purpose
or process.
partition: In DOS/VSE, a contiguous area of virtual storage available for
the execution of programs.
peripheral equipment: A term used to refer to card devices, magnetic
tape and disk devices, diskettes, printers, and other eqUipment bearing a
similar relation to the CPU.
phase: The smallest complete unit that can be referred to in'the core
image library.
POWER: A unit record spooling support available as the IBM licensed program
VSE/pOWER
printer: A device that expresses coded characters as hard copy.
priority: A rank assigned to a partition that determines its precedence in
receiving CPU time.
private library: A user-owned library that is separate and distinct from the
system library.
private second level directory: The private second level directory is a
table located in the supervisor containing the highest phase names found on
the corresponding directory tracks of the private core image library.
problem determination aid: A program that traces a specified event
when it occurs during the operation of a program. Abbreviated PDAID.
problem program: Any program that is executed when the central
processing unit is in the problem state; that is, any program that does not
contain privileged instructions. This includes mM-distributed programs, such
as language translators and service programs, as well as programs written by
a user.
processing program: (1) A general term for any program that is not a
control program. (2) Synonymous with problem program.
processor storage: The general purpose storage of a computer. Processor
storage can be accessed directly by the operating registers. Synonymous
with real storage.
queue: (1) A waiting line or list formed by items in a system waiting for
service; for example, tasks to be performed or messages to be transmitted
in message switching system. (2) To arrange in, or form, a queue.
5.8 DOS/VSE System Management Guide
random processing: The treatment of data without respect to its location
in auxiliary storage, and in an arbitrary sequence governed by the input
against which it is to be processed.
real address: The address of a location in real storage.
real address area: In DOS/VSE, the area of vl_rtual storage where virtual
addresses are equal to real addresses.
real mode: In DOS/VSE, the mode of a program that cannot be paged.
real storage: The storage of a computing system from which the central
processing unit can directly obtain instructions and data, and to which it
can directly return results. Synonymous with processor storage.
reenterable: The attribute of a load module that allows the same copy of
the load module to be used concurrently by two or more tasks.
relocatable: The attribute of a set of code whose address constants can be
modified to compensate for a change in origin.
relocatable library: A library of relocatable object modules and IOCS
modules required by various compilers. It allows the user to keep frequently
used modules available for combination with other modules without
recompilation.
restore: To return a data file created previously by a copy operation from
cards, disk or magnetic tape to disk storage.
rotational position sensing (RPS): A standard or optional feature of
most mM disk storage devices. It permits these devices to disconnect from
a block multiplexer channel (or its equivalent on Model 3115/3125 CPUs)
during rotational positioning operations, thereby allowing the channel to
service other devices .
•
routine: An ordered set of instructions that may have some general or
frequent use.
secondary storage: Same as auxiliary storage.
second level directory: A table located in the supervisor containing the
highest phase names found on the corresponding directory tracks of the
system core image library.
security: Prevention of access to or use of data or programs without
authorization.
sequential organization: Records of a sequential file are arranged in the
order in which they will be processed.
service program: A program that assists in the use of a computing
system, without contributing directly to the control of the system or the
production of results.
shared virtual area: An area located in the highest addresses of virtual
storage. It can contain a system directory list of highly used phases, resident
programs that can be shared between partitions, and an area for system
GETVIS support.
software: A set of programs, concerned with the operation of the
hardware in a data processing system.
Glossary 5.9
source: The statements written by the programmer in any programming
language with the exception of actual machine language.
*
source program: A computer program written in a source language.
Contrast with object program.
source statement library: ~ collection of books (such as macro
definitions) cataloged in the system by the librarian program.
spanned records: Records of varying length that may be longer than the
clLrrently used blocksize, and which may therefore be written in one or
more continuous blocks. A spanned record may occupy more than 1 track
of a disk device.
stand-alone dump: A program that displays the contents of the registers
and part of the real address area and that runs independently and is not
controlled by DOS/VSE.
standard label: A fixed-format identification record for a tape, diskette, or
disk file. Standard labels can be written and processed by DOS/VSE.
storage protection: An arrangement for preventing access to storage.
supervisor: A coltlponent of the control program. It consists of routines to
control the functions of program loading, machine interruptions, external
interruptions, operator communications and physical IOCS requests and
interruptions. The supervisor alone operates in the privileged (supervisor)
state. It coexists in real storage with problem programs.
switched line: A communication line in which the connection between the
computer and a remote station is established by dialing. Synonymous with
dial line.
system directory list: A list containing directory entries of highly used
phases and of all phases resident in the shared virtual area. This list is
contained in the shared virtual area.
system residence device: The direct access device on which the system
residence file is located.
system residence volume: The volume on which the basic system and
all related supervisor code is located.
task: A unit of work for the central processing unit from the standpoint of
the control program.
teleprocessing: The processing of data that is received from or sent to
remote locations by way of telecommunication lines.
terminal: (1) * A point in a system or communication network at which
data can either enter or leave. (2) Any device capabl~ of sending and
receiving information over a communication channel.
throughput: The total volume of work performed by a computing system
over a given period of time.
track: The portion of a moving storage medium, such as a tape,
diskette, or disk, that is accessible to a given reading head position.
transient area: An area of processor storage used for temporary storage
of transient routines.
5.10 DOS/VSE System Management Guide
UCS: Universal character set.
unit record: A card containing one complete record; a punched card.
universal character set: A printer feature that permits the use of a
variety of character arrays. Abbreviated UCS.
unrecoverable error: A hardware error which cannot be recovered from
by the normal retry procedures.
user label: An identification record for a tape or disk file; the format and
contents are defined by the user, who must also write the necessary
processing routines.
utility program: A problem program designed to perform a routine task,
such as transcribing data from one storage device to another.
virtual address: An address that refers to virtual storage and must,
therefore, be translated into a real storage address when it is used.
virtual address 8rea-: In DOS/VSE, the area of virtual storage whose
addresses are greater than the highest address of the real address area.
virtual mode: In DOS/VSE, the mode of execution of a program which
may be paged.
virtual storage: Addressable space that appears to the user as real storage,
from which instructions and data are mapped into real storage locations.
The size of virtual storage is limited by the addressing scheme of the
computing system and by the capacity of the page data set, rather than by
the actual number of real storage locations.
virtual storage access method (VSAM): An access method (available as
the licensed program product VSEjVSAM) for direct or sequential processing of
fIxed and variable length records on direct access devices; designed for use in a
virtual storage environment.
virtual telecommunications access method (VTAM): A set of IBM
programs (available as the licensed program product ACF/VTAM) that control
communications between terminals and application programs.
volume: (1) That portion of a single unit of storage media which is
accessible to a single read/write mechanism, for example, a
diskette, a disk pack, or part of a disk storage module. (2) A recording
medium that is mounted and dismounted as a unit, for example, a reel of
magnetic tape, a disk pack, or a diskette.
volume table of contents: A table on a direct access volume or diskette
that describes each file on the volume. Abbreviated VTOC.
VSAM access method services: A multifunction utility program that
defines VSAM files and allocates space for them, converts indexed
sequential files to key-sequenced files with indexes, facilitates data
portability between operating systems, creates backup copies of files and
indexes, helps to make inaccessible files accessible, and lists file and catalog
entries.
Glossary 5.11
VSAM catalog: A key-sequenced file, with an index, containing extensive
file and volume information that VSAM requires to locate files, to allocate
and deallocate storage space, to verify the authorization of a program or
operator to gain access to a file, and to accumulate usage statistics for files.
VTOC: See volume table of contents.
work file: A file on an auxiliary storage medium reserved for intermediate
results during execution of the program.
working set: Tne set oi pages oi a user's virtuai-mode program that must
be in processor storage in order to avoid excessive paging.
5.12 DOS/VSE System Management Guide
Index
$$A$CDLO 3.3, 3.8
$$A$IPLO A.2
$$A$IPL 1 A.I
$$A$PLBF A.2
$$A$PLBK A.1
$$A$SUP1 3.2
$ASIPROC 3.19
$JOBACCT 2.18,4.7
$JOBEXIT 4.3
$phase 2.11, 3.11, 3.136
$SYSOPEN 3.14,4.2
/ + statement 3.112
/ & statement 3.27
A
abnormal termination exit 2.32
access authorization checking 2.26, 3.25
access control 2.27
ACF/VTAM support 2.26
ACTION statement 3.90,3.94
CANCEL operand 3.95
CLEAR operand 3.94
MAP operand 3.94
NOMAP operand 3.94
ADD command 2.45
address space 1.6
allocating to the partitions 3.15
division of 1.14
minimum per partition 3.15
partitions within 1.14
real 1.18, 2.18
shared virtual area (SVA) within 1.15
virtual 1.18,2.18
ALLOC (librarian) statement 3.118, 3.125
ALLOC command
initiating foreground partitions 3.15, 3.17
ALLOCR command 1.21,3.16
alternate dump file(s) 2.14
ASCn (SUPVR macro) parameter 2.28
ASCn support 2.28
ASI (see automated system initialization)
ASI master procedure 3.18
ASI IPL procedure 3.20
ASI JCL procedure 3.21
example 3.23
naming conventions 3.18
ASI stop facility 3.19
assemble, link-edit, and execute 3.53, 3.84
assembler copy sublibrary 3.110, 3.131
assembler macro sublibrary 3.111, 3.131
ASSGN job control command/
statement 3.34, 3.38
assignment; shari-.ng 3.35
asynchronous operator communication 2.30
ASYNOC (FOPT macro) operand 2.30
ATTACH macro 1.26
AUTO
specification in SIZE operand 3.60, 3.63
AUTOLINK feature 3.92
example 3.102
suppressing the 3.93
automated system initialization
(ASI) 2.45, 3.2, 3.6, 3.17
contents of IPL procedures 3.20
oont-ents of J-CL proredmes 3-.21
default procedure names 3.18
implementation reqUirements 3.18
master procedure 3.18
procedure library 2.7, 3.18
stop facility 3.19
B
background partition 1.2
initial size 3.15
balanced partitions 2.22
BATCH command 1.2, 3.17
BKEND statement 3.111
book 2.4
updating in the source statement library 3.122
BTAM-ES support 2.26
BTMOD 2.26
buffers, CCW translation 2.40
BUFSIZE (VSTAB macro) operand 2.39
c
CANCEL (linkage editor option) 3.85,3.95
CANCEL command
effects of 3.27
CANCEL macro 2.32
CATAL option 3.79
catalog control statements 3.109
cataloged procedures 2.5, 3.70
modifying multistep procedures 3.75
partition-related 3.77
retrieval 3.70
several job steps in 3.74
SYSIPT data in 3.74, 3.76, 3.112
temporarily modifying 3.71
use by operator 3.78
Index 6.1
cataloged programs
invoking 3.57
cataloging 3.83
a supervisor 3.83
assigning change levels 3.113
members into libraries 3.109
to the private core image library 3.100
to the procedure library 3.112
to the relocatable library 3.109
to the source statement library 3.110
to the system core image library 3.98
CATALP statement 3.112
DATA parameter in 3.112
CATALR statement 3.109
CATALS statement 3.110,3.114
CBF (FOPT macro) operand 2.30
CCW translation 2.40
CDL (communication device list) 3.8
central processing unit (CPU)
control of 1.1
specifying the model 2.43
change level verification 3.114
change levels 3.113
channel queue (CHANQ) 2.38
channel queue table 2.39
channel switching 4.15
CHANQ (IOTAB macro) operand 2.38
checkpoint 4.13
CHKPT macro 4.13
CLEAR
operand in ACTION statement 3.94
CLOSE job control command 3.66, 3.68
COBOL sublibrary 3.110
COMMON
in FORTRAN programs 3.98
communication region
modification at end-of-job 3.27
compile and execute, example 3.103
compile, link-edit and execute 3.53, 3.84
compiler LIOCS modules 2.4
compiling in more than one partition 2.16
condense limit
specifying the 3.117
condensing the libraries 3.115, 3.117
restrictions 3.118
CONOL statement 3.117
CONOS statement 3.115
CONFG generation macro
MODEL operand 2.43
console buffering 2.30
context editing 2.26
control section (CSECT) 3.81
in an overlay structure 3.95
including for link-edit 3.91
6.2 DOS/VSE System Management Guide
controlling jobs 3.25
controlling magnetic tape 3.51
controlling printed output 3.51
copy blocks 2.40
COPY control statement 3.124, 3.126
NEW operand 3.127
COPYSERV librarian program 3.127
core image library 2.3
naming conventions for 3.121
search sequence 2.11
CORGZ librarian program 2.6
automatic copying 3.125
merging libraries 3.126
cross-partition event control 1.26
CSECT 3.81
CSERV program 3.130
D
DASD file protection 2.34
DASD labels 3.44
DASD switching 4.14
channel switching 4.15
string switching 4.15
DASDFP (FOPT macro) operand 2.34
de-editing assembler macros 3.131
DECK option 3.58
DEF command 2.14, 3.4
default procedure names under ASI 3.18
DEL command 3.3
DELETC statement 3.114
deleting 110 devices 3.4
DELETP statement 3.114
DELETR statement 3.114,3.120
DELETS statement 3.114,3.120
device assignment
in a multiprogramming system 3.35
permanent 3.34
restrictions 3.34
temporary 3.34
device class
in ASSGN 3.30
device type for new system residence 3.124
device types for private libraries 3.132
device types for MERGE librarian
function 3.126
direct access devices
label information 3.44
directory
library A.I, 3.105, 3.129
system A.1, 3.105
disk information block (Dm) 3.66
disk options 2.33
DASD file protection 2.34
rotational position sensing (RPS) 2.35
system files on disk or diskette 2.33
track hold 2.34
diskette files
label information 3.43
display operator console (DOC) 2.43
distribution medium 2.1
distribution supervisors 2.3
DLA command 2.15, 3.5
DLBL statement 3.42
DOC (FOPT macro) operand 2.44
DOS/VSE
defining the system configuration 2.43
distribution medium 2.1
memorandum to users 2.12
overview 1.1
planning 2.1
system control program (SCP) 2.3
using the facilities and options of 4.1
DOSVSDMP program 2.14
DPD command 2.23, 2.43, 3.5
use under ASI 3.20
DPDEXT (IOTAB macro) operand 2.23, 3.5
DSERV librarian program 3.129
displaying change levels 3.114
executing after SET SDL 3.11
listing of book names 3.111
DSF (DPD command) parameter 2.43
DSPCH statement 3.130
DSPLY statement 3.129
DSPLYS statement 3.129,3.130
DTFDI 3.64
DTFPH macro 2.34
DTFSD SYSFIL support 3.66
DTSECTAB macro 2.27
DUMP macro 2.32
4ump file, alternate 2.14
DVCDN command 3.39, 4.15
DVCUP command 3.39, 4.15
dynamic allocation of storage 3.61
dynamic storage areas 1.24
E
ECPS:VSE mode 1.1, 1.14
defining the page data set 2.23
determining virtual storage size 1.18, 2.18
initial size of BG partition 3.15
use of supervisor buffers 2.40
edited macros
de-editing 3.131
preparing for update 3.131
editing under VSE/ICCF 2.26
emulator 2.45
END record
of an object module 3.81
END statement
for ~TNT program 3.122
end-of-procedure (/+) statement 3.112
end-of-job (I &) statement 3.27
ENTRY statement 3.83
EOJ macro 2.32
EREP program 3.4, 3.11
for listing of SYSREC 2.41, 3.13, 3.15
error queue 2.41
error volume analysis 2.43
ERRQ (FOPT macro) operand 2.41
ERRS option 3.58
ESERV librarian program 3.131
EU (SUPVR macro) operand 2.45
EVA (FOPT) operand 2.43
EXEC statement 3.26
REAL operand 1.22, 3.59
SIZE operand 1.22, 3.60
executing a program 3.53
in real mode 1.18, 3.59
in virtual mode 1.18
EXIT macro 2.30
EXTENT job control statement 3.43
for DASD files 3.45
F
fast function 2.40
fast translate 2.40
fast B/C-transient fetch 3.11
FASTFTCH SET SDL procedure 3.11
FASTTR (FOPT macro) operand 2.40
FBA device
size of label information area 3.119
space available for SYSRES 3.119
FCB (forms control buffer) 3.51
FCEPGOUT macro 2.24, 4.21
FETCH macro
use of 3.97
file id
in DLBL/TLBL statement 3.42
file labels 3.39
file name
for system files on disk 3.65
in problem program 3.42
in DLBL/TLBL statement 3.42
files
relating to a program 3.29
fixing pages in processor storage 1.24, 4.19
fixlist 2.40
Index 6.3
FOPT generation macro
ASYNOC operand 2.30
ERRQ operand 2.41
RPS operand 2.35
CBF operand 2.30
DASDFP operand 2.34
DOC operand 2.44
EVA operand 2.43
F ASTIR operand 2.40
JA operand 2.28
JALIOCS operand 2.28
PRTY operand 2.22
PSLD operand 2.25
RPS operand 2.36
SEC operand 2.26
SLD operand 2.25
SYSFIL operand 2.24, 2.33, 3.65
TEBVoperand 2.42
TRKHLD operand 2.34
TIIME operand 2.30, 2.32, 4.1
ZONE operand 2.29
foreground partition
allocating address space to 3.15
initiating 1.2, 3.17
minimum allocation 3.17
number of 1.2
forms control buffer (FCB) 3.51
FREEVIS macro 3.61
during real mode execution 3.61
G
GENEND (librarian) statement 3.131
GETCATALS (librarian) statement 3.131
GETIME macro 2.29
GETVIS (SVA command) parameter 2.21
GETVIS area
partition 1.24, 3.61
system 1.24, 2.21
GETVIS requests, real mode execution 3.60
GO parameter of EXEC statement 3.54,3.84
H
hard copy file
creating 2.13, 2.14
history file 2.1, 2.13
update procedures 2.5
6.4 DOS/VSE System Management Guide
I
I/O options 2.38
channel queue 2.38
error queue 2.41
supervisor buffers 2.39
ICCF 2.26
ICCF (SUPVR macro) operand 2.26
ID job control statement 3.25
iFCEREPl program 3.11
DIPL file 3.3
INCLUDE statement 3.83, 3.91
initial microprogram load
(IML) 1.18, 2.18, 2.23
initial program load (IPL) 3.2
automatic 2.45, 3.2, 3.6
automatic functions of 3.7
interactive 3.2, 3.17
user-defined processing after 3.14
interactive computing and control (ICCF) 2.26
interactive IPL 3.2, 3.17
interval timer 2.29, 4.1
invoking cataloged programs 3.57
10DEV (lOTAB macro) operand 2.45
IORB macro 2.40
10TAB generation macro 2.44, 3.4
CHANQ operand 2.38
DPDEXT operand 2.23, 3.5
10DEV operand 2.45
IPL commands 3.3
ADD 3.4
DEF 2.14, 3.4
DEL 3.4
DLA 2.15, 3.5
DPD 2.23, 2.43, 3.5
SET 3.4
IPL communication device list (CDL) 3.7
IPL communication device, establishing 3.3
IPL list option 3.2, 3.20
IPL procedure under ASI 3.20
IPL records A.l
IPL user exit routine 4.1
example 4.3
register usage 4.2
J
JA (FOPT macro) operand 2.28
JALIOCS (FOPT macro) operand
JCL procedure under ASI 3.21
JDUMP macro 2.32
JOB statement 3.26
job 3.25·
2.28
job accounting 2.28
example 4.11
programming considerations 4.9
register usage 4.9
table 4.8
user interface routine 4.7
job control 3.25
job control user exit routine 4.3
example 4.5
register usage 4.4
vector table 4.4
job name 3.26
job step 3.26
job stream 3.28
job-to-job communication 3.29
JOBCOM macro 3.29
L
label information
for direct access files 3.44
for diskette files 3.43
for magnetic tape files 3.47
PARSTD 2.18, 3.48
STDLABEL 2.16, 3.49
storing 3.48
USRLABEL 3.48
label information area A.1, 2.15, 3.42
outside of SYSRES file 2.15, 3.5, 3.125
sequence of search 2.16, 3.49
label options 3.48
label save area 3.93
label subarea 3.48
clearing of 3.49
labels 3.39
language translator 3.80
LBLTYP job controi statement 3.44, 3.48, 3.93
example 3.99, 3.102
LFCB command 3.52
LFCB macro 3.52
librarian programs 3.106
cataloging 3.109
CORGZ and COPYSERV 3.122
CSERV 3.130
ESERV 3.131
maintenance functions 3.108
PSERV 3.130
real mode storage requirements 3.107
restrictions 3.107
RSERV 3.130
service programs 3.128
SSERV 3.130
libraries
cataloging into 3.109
changing the size of system libraries 3.119
condensing 3.115, 3.117
deleting members from 3.114
determining the location of 2.7
directories 3.105
displaying the contents of 3.129
displaying the directories 3.129
eliminating 3.120
examples of deleting and condensing 3.116
examples of organization 2.9
maintaining 3.108
online maintenance 2.26
operational 2.11
organizing 3.122
planning the 2.2
planning the size and contents of 2.11
private 2.5, 3.132
punching the contents of 3.129
purpose and contents of 2.3
reallocating the sizes of 3.118
renaming members 3.121
service programs 3.128
sublibrary 2.4, 3.110
transferring members between 3.125
using system libraries as private libraries 3.136
using the 3.105
library directories 3.105
library status report 3.129, 3.137
link edit and execute 3.83
example 3.101
LINK option 3.55, 3.79, 3.83, 3.84
suppression of 3.104
linkage editor 3.79
automatic invocation 3.54, 3.84
examples 3.97
input to 3.87
obtaining a storage map 3.94
processing requirements 3.86
storage requirements 3.91
symbolic units required 3.86
linkage editor control statements
ACTION 3.90, 3.94
ENTRY 3.83
examples 3.98
INCLUDE 3.83, 3.91
PHASE 3.82, 3.87
linking programs 3.79
LIST linkage editor option 3.58
LISTIO statement/command 3.39
LISTX linkage editor option 3.58
Index 6.5
load address 3.89
LOAD macro 3.97
load lists 3.9
LOG 3.58
LOG IPL option 3.2
logging and reporting for access control
logical transients 3.11
logical I/O unit 3.30
programmer 3.32, 3.34
system 3.32, 3.33
LSERV program 3.50
LUCB command 3.52
multiprogramming 1.1
device considerations under
multitasking 1.25
types of . 1.26
2.27
M
MACRO statement 3.111
magnetic tape, positioning 3.51
magnetic tape files, label information 3.47
main task 1.26
MAINT librarian program 3.108
catalog function 3.109
condense function 3.115
delete function 3.114
reallocate function 3.117
rename function 3.121
update function 3.122
used to catalog ASI procedures 3.18
maintaining libraries 3.108
assignment of private libraries 3.108
MAP
command 3.17, 3.27
operand in ACTION statement 3.94
master procedure under ASI 3.18
memorandum to users 2.12, 2.16
MEND statement 3.111
MERGE statement 3.126
merging of libraries 3.126
MICR stacker selection routines 3.60
mode of execution 1.17
inquiring via the RUNMODE macro 4.21
real 1.18, 3.59
virtual 1.18
MODEL (CONFG macro) operand 2.43
MSG command 2.32
MSHP (Maintain System History
Program) 2.2, 2.13
history file update procedures 2.5
use of 3.115
MTC statement/command 3.51
multiphase program names 3.87
multiple extent page data
set 2.23, 2.43, 3.5, 3.20
6.6 DOS/VSE System Management Guide
1.3
N
naming conventions
cataloging partition-related procedures 3.78
phases 3.121
relocatable library 3.110, 3.121
source statement library 3.110
never ending program, under ASI 3.21
new SYSRES, device type 3.124
NEWVOL (librarian) statement 3.132
NOAUTO
operand in PHASE statement 3.93
NOFASTfR option 2.41
NOLOG IPL option 3.2
NOMAP
operand in ACTION statement 3.94
nonpageable
program 1.18
supervisor routine 1.17
nonrelocatable phase 3.82
NPARTS (SUPVR macro) parameter 2.21
o
object module 3.81
including an 3.91
OLTEP program 3.60
online library maintenance 2.26
operator communication exit 2.32
operator communication, asynchronous 2.30
OPTION job control statement 3.48
CATAL option 3.48
LINK option 3.55, 3.79
NOFASTfR option 2.41
options for program execution 3.58
organizing the libraries 3.122
OV parameter in EXEC statement 3.72
OVEND statement 3.72
overlay structure 3.95
relating control sections to phases 3.95
use of FETCH and LOAD macros 3.97
p
page 1.6
fixing 1.24
releasing 2.24, 4.21
page data set 1.6, 2.12
data secured 2.23
defining attributes 3.5
defining extents during ASI 3.20
defining the 2.23
formatting of 3.5
location of 3.5
multiple extents 2.23, 2.43, 3.5
size of 2.23
page fault 1.13
handling overlap exit 2.33
reducing occurrence of 4.16
page frame 1.6
page out 1.10
forcing 2.24, 4.21
page pool 1.6,1.13, 1.17,3.16
effect of large I/O areas in channel
J)r-egr-a-IB5 1.24
minimum size 3.16
page-in in advance 2.24, 4.21
pageable
program 1.18
supervisor routine 1.17
PAGEIN (SUPVR macro) operand 2.24
P AGEIN macro 2.24, 4.21
paging option 3.2, 3.20
PARSTD 2.16, 3.48
PARSTD option, used under ASI 3.21
P ARTDUMP option 3.58
partition 1.2
allocating address space to 3.15
allocating processor storage to 3.16
allocation 1.20
balancing 2.22
defining the number of 2.21
displaying current allocation 3.17
inactive 3.118
priorities 1.3, 2.22
selecting one for a particular job 3.28
partition balancing 2.22
partition GETVIS area 1.24, 3.61
changing the size 3.62
for real mode execution 3.60, 3.107
Dl1D..11llum size 3.15, 3.61
use by RPS 2.35
PAUSE command 3.69
PAUSE statement 3.29
permanent (storing of) label information 3.48
permanent device assignment 3.34
PFIX macro 1.24, 3.16, 2.40, 4.19
PFREE macro 1.24, 3.16, 4.19
phase 3.82
load-address 3.89
name of 3.87
naming conventions 3.121
non-relocatable 3.82
reenterable 3.90
relocatable 3.82, 3.89
self-relocating 3.82, 3.91
SVA eligible 3.82, 3.83, 3.90
PHASE statement 3.82, 3.87
NOAUTO operand 3.93
SVA operand 3.90
phases in the SVA 2.21
automatic loading at IPL 3.7
reserving space 3.6
PIOCS generation macro 2.44
PL/I sublibrary 3.111
peftabilit-y of a g@R@fatoo syst-em 2.43
POWER 3.64
job accounting 4.7
priority
of a partition 1.3
private core image library
accessibility 3.136
assignment 3.135
creation of 3.134
dedicated to a partition 3.136
example of cataloging to 3.100
filenames 3.135
organization of 3.134
using the 3.135
private libraries 2.5·
creating and working with 3.132
device types 2.9, 3.132
filenames for accessing 3.135
filenames for creating 3.133
label information for 3.135
multiple 3.135
number of 2.6
restrictions 2.6
search sequence 3.136
symbolic unit names for accessing 3.135
symbolic unit names for creating 3.133
using system libraries as 3.136
private second level directory (PSLD) 2.25
PROC parameter in EXEC 3.70
procedure library 2.5, 2.7
cataloging to 3.112
caution when updating 3.70
extended support for 2.24
renaming procedures in 3.121
required by ASI 2.7
restrictions when cataloging to 3.113
Index 6.7
retrieving procedures from 3.70
used for automated system
initialization 3.6, 3.18
used for automated IPL 3.6
processor storage 1.6, 1.17
allocating 3.16
allocating for real mode execution 1.21
fixing pages in 1.24
program check exit 2.31
program development, stages 3.80
program execution 3.53
mode of 1.17
real mode 1.18, 3.59
virtual mode 1.18
program exit routines 4.1
programmer logical units 3.34
programming techniques
for reducing page faults 4.16
PRTY (FOPT macro) operand 2.22
PRTY command 1.3, 2.22
PSERV program 3.130
PSIZE (SVA command) parameter 2.21
PSLD (FOPT macro) operand 2.25
PUNCH statement 3.130
R
RAS 2.41
real address 1.9
real address space 1.18, 2.18
size of 2.18
real mode execution 1.18, 3.59
processor storage allocation for 1.21
programs requiring 3.60
REAL operand
in EXCP macro 2.40
in EXEC statement 1.22, 3.59
REALAD macro 2.40
record on demand (ROD) command 3.13,3.14
recorder file 2.13
creating 3.11
label information for 3.12
minimum size 3.12
recovery management support (RMS) 2.41
with DASD switching 4.16
reenterable phase 3.90
reliability data extractor (RDE) 3.14
reliability/ availability / serviceability (RAS) 2.41
relocatable library 2.4
cataloging to 3.109
naming conventions for modules 3.110, 3.121
renaming modules in 3.121
relocatable phase 3.82, 3.89
RELPAG macro 2.24, 4.21
6.8 DOS/VSE System Management Guide
RENAMe statement 3.121
renaming members in libraries 3.121
RENAMP statement 3.121
RENAMR statement 3.121
RENAMS statement 3.121
REP record 3.81
RESET job control statement/
command 3.34, 3.39
resource profile 2.27
restarting a program from a checkpoint 4.13
RLD record 3.81
RMS 2.42
RMS (SUPVR macro) operand 2.42
RMSR 2.42
ROD command 3.13,3.14
rotational position sensing (RPS) 2.35
RPG IT sublibrary 3.111
RPS 2.35
RPS (FOPT macro) operand 2.35,2.36
RSERV program 3.130
RSTRT job control statement 4.13
RUNMODE macro 4.21
s
SDL (see system directory list)
SDL (SVA command) parameter 2.21
SDL procedure 3.9
SEC (FOPT macro) operand 2.26
second level directory (SLD) 2.25
self-relocating phase 3.82, 3.91
SEREP program 2.41
SET command 3.4
example 3.13
to create system files 2.13
used during ASI 3.20
SET SDL command 3.10
SET SDL procedure 3.10,3.11
SETDF operator command 3.53
SETIME macro 2.31
SETPFA macro 2.33
SETPRT job control statement/command
SETPRT macro 3.53
SETT macro 2.30, 2.32
SHARE OPTION 4 2.35
shared devices 3.35
shared virtual area" (SVA) 1.15
coding for 4.22
layout of 2.18
loading phases into 3.9
phases 2.21
replacing phases in 3.11
size of 2.18, 2.21
user options 3.9
SIO (start I/O) accounting 4.7
3.52
SIZE command 3.62
used under ASI 3.21
SIZE operand 1.22, 3.60
SLD (FOPT macro) operand 2.25
source module 3.80
source statement library 2.4
cataloging to 3.110
naming conventions 3.110
updating books in 3.122
SSERV librarian program 3.130
use of 3.111
stages of program development 3.80
standard label procedures 2.16
standard labels for system files on tape 3.64
START command 1.2,3.17
used under ASI 3.21
status report (see library status report)
SID-LABEL 2.16, 3.49
STDLABEL option, used under ASI 3.21
STDOPT command 3.27, 3.59
used under ASI 3.21
STOP command, used under ASI 3.21
stop facility under ASI 3.19
storage allocation 1.18
storage management 1.8
storage protection 1.3
string switching 4.15
STXIT macro 2.30, 4.1
sublibrary 3.110
assembler macro (E) 3.131
copy (A) 3.131
naming conventions 2.4
subtask 1.26
supervisor generation macros 2.2
CONFG 2.43
FOPT 2.30
10TAB 2.23, 2.38, 3.4
SUPVR 2.21, 2.24
VSTAB 2.18
supervisor
buffers for I/O processing 2.39
default 3.2
name, specifying the 3.2
nonpageable 1.17, 3.2
pageable 1.17, 3.2
routines 1.17
tailoring the 2.17
SUPVR generation macro 2.21
ASCn parameter 2.28
EU parameter 2.45
ICCF operand 2.26
NPARTS parameter 2.21
PAGEIN operand 2.24
RMS operand 2.42
TP parameter 2.25
SVA (see shared virtual area)
SVA command 3.6
GETVIS operand 2.21
position within IPL commands 3.3
PSIZE operand 2.21
SDL operand 2.21
SVA operand
in PHASE statement 3.90
in SET SDL 3.10
SXREF option 3.58
SYM option 3.58
symbolic I/O assignment 3.30
SYSCAT 1.3, 3.33, 3.39
assignment of 3.4
SYSCLB 3.33
SYSCTL 3.33
SYSDMP 1.3, 2.14, 3.33
assignment of 3.4
SYSFIL (FOPT macro) operand 2.24
SYSFIL (FOPT macro) operand 2.33
SYSFIL option 2.5, 2.24, 2.34, 3.65, 3.112
SYSIN 3.33, 3.38, 3.64, 3.65, 3.68
SYSIN job streams on disk, diskette or
tape 3.63
interrupting 3.69
SYSIPT 2.33, 3.33, 3.38
input to language translators 3.54
SYSIPT data in cataloged
procedures 3.74, 3.76, 3.112
SYSLNK 3.33, 3.38
SYSLOG 1.3, 3.33, 3.38
assignment of 3.2
used under ASI 3.20
SYSLST 3.33, 3.38
SYSOUT 3.33, 3.38, 3.64, 3.65, 3.68
SYSPCH 3.33, 3.38
SYSRDR 3.25, 3.33, 3.38
SYSREC (see also recorder
file) 1.3, 2.13, 3.33, 3.39
assignment of 3.4
SYSRES (see also system residence
file) 1.3, 3.33, 3.39
SYSRLB 3.33
SYSSLB 3.33
system core image library
example of cataloging to 3.98
system date 3.4
system directory A.1, 3.105
system directory list (SDL) 2.19
building (entries) 3.9
reserving space 3.6
system files
system files on disk 2.33, 3.65
filenames 3.65
on FBA devices 3.66
Index 6.9
system files on diskette 2.33, 3.68
filenames 3.68
system files on tape 3.64
hard copy file 2.13, 3.14
history file 2.2, 2.13
page data set 1.6, 2.12
record formats 3.70
recorder file 2.13, 3.11
system residence (SYSRES) file 2.2, 2.7
system generation procedure 2.1
system history file 2.2, 2.13
update procedures 2.5
system installation aids 2.5
system libraries
relative location on SYSRES pack 2.8
using as private libraries 3.136
system logical units 3.33
SYSCAT 1.3, 3.33, 3.39
SYSCLB 3.33
SYSCTL 3.33
SYSDMP 1.3, 2.14, 3.33
SYSIN 3.33, 3.38, 3.64, 3.65, 3.68
SYSIPT 2.33, 3.33, 3.38
SYSLNK 3.33,3.38
SYSLOG 1.3,3.33,3.38
SYSLST 3.33,3.38
SYSOUT 3.33, 3.38, 3.64, 3.65, 3.68
SYSPCH 3.33,3.38
SYSRDR 3.25,3.33,3.38
SYSREC 1.3, 2.13, 3.33, 3.39
SYSRES 1.3, 3.33, 3.39
SYSRLB 3.33
SYSSLB 3.33
system portability 2.43
system residence (SYSRES) file 2.2, 2.7
copying the 3.123
creating a new 3.123
disk space available 3.119
layout of A.1
system ~ecurity table 2.27
system time zone
setting 3.4
system volume label A.1
system GETVIS area 1.24, 2.21
reserving space for 3.6
SYSUFLD program 3.52
SYSOO6, used to access an alternate
dump file 2.14
T
tape error statistics
task 1.26
main 1.26
subtask 1.26
2.42
6.10 DOS/VSE System Management Guide
task selection 1.1
task timer 2.29
exit 2.32
TEBV (FOPT macro) operand 2.42
telecommunication balancing 2.25, 4.21
telecommunication facilities 2.25
ACF/VTAM 2.25
BTAM-ES 2.25
temporary device assignment 3.34
temporary label information 3.48
TESIT macro 2.30, 2.33
text editing 2.26
time zone
setting 3.4
time-of-day clock 2.29
setting 3.4
timer services 2.28
interval timer 2.29
task timer 2.29
time-of-day (TOD) clock 2.29
timeshared computing 2.26
TLBL statement 3.42, 3.47
TP (SUPVR macro) operand 2.25
TPBAL command 4.21
TPIN macro 4.21
TPOUT macro 4.21
track hold option 2.34
TRKHOLD (FOPT macro) operand 2.34
TTIME (FOPT macro) operand 2.30
TTIME (FOPT macro) operand 4.1
TTIMER macro 2.31
TXT record 3.81
u
UCB (universal character set buffer) 3.51
UCS command 3.52
universal character set buffer (UCB) 3.51
UPDATE librarian statement 3.122
UPSI job control statement 3.59
user exit routines 2.31
abnormal termination 2.32
interval timer 2.31
IPL 4.1
job accounting 4.7
job control 4.3
operator communication 2.32
page fault handling overlap 2.33
program check 2.31
task timer 2.32
user profile 2.27
user program switch indicator (UPSI) 3.59
user-defined processing after IPL 3.14
USRLABEL 3.48
utilities, number of copy blocks for 2.40
v
VIRTAD macro 2.40
virtual address space 1.18
virtual mode execution 1.18
virtual storage 1.4, 1.16
macros 4.19
maximum size 1.5
relating to locations in processor storage 1.9
size 2.18
virtual storage macros 4.19
FCEPGOUT 2.24, 4.21
PAGEIN 2.24, 4.21
PFIX 1.24, 2.40, 3.16, 4.19
PFREE 1.24, 3.16, 4.19
RELPAG 2.24,4.21
RUNMODE 4.21
volume label
system A.I
user A.1
VSAM master catalog, assignment of 3.5
VSE/ Advanced Functions, installing 2.2
VSIZE (VSTAB macro)
operand 2.18, 2.23, 3.15
VSTAB generation macro 2.18
BUFSIZE operand 2.39
VSIZE operand 2.18, 23
VTAM 2.26
w
weak external reference 3.93
work blocks 2.40
workfiles 2.14
symbolic device requirements 2.15
working set 4.16
techniques for reducing 4.17
x
XREF option
z
ZONE (FOPT macro) operand
2.29
23xx emulator 2.35
3031 processor 1.1, 3.4, 3.11
space on recorder file 3.12
3330-11/3350
DASD file, support for 2.36
3540 diskette
as IPL device 3.3
SYSIPT assigned to 3.68
370 mode 1.1, 1.14
defining virtual address space 1.18, 2.1'8
defining the page data set 2.23
partition allocation 3.15
use of supervisor buffers 2.40
3800 Printing Subsystem 3.52
4300 processor, modes of execution 1.1, 1.14
5424 MFCU 3.54
7443 service record file 3.4
Index 6.11
READER'S
COMMENT
FORM
DOS/VSE System Management Guide
GC33-5371-7
This sheet is for comments and suggestions about this manual. We would appreciate your
views, favorable or unfavorable, in order to aid us in improving this publication. This form
will be sent directly to the author's department. Please include your name and add ress if
you wish a reply. Contact your IBM branch office for answers to technical questions about
the system or when requesting additional publications. Thank you.
Name
How did you use this manual?
Address
As a reference source
As a classroom text
As a self-study text
What is your occupation?
Your comments* and suggestions:
* We would especially appreciate your comments on any of the following topics:
Clarity of the text
Organization of the text
Accuracy
Cross-references
Index
Tables
Illustrations
Examples
Appcaran\.:l'
PnrJtlllg
Paper
RlIlding
GC33-5371-7
YOUR COMMENTS, PLEASE ...
This manual is part of a library that serves as a reference source for system analysts,
programmers and operators of IBM systems. Your answers to the questions on the back of this
form, together with your comments, will help us produce better publications for your use. Each
reply will be carefully reviewed by the persons responsible for writing and publishing this
material. IBM may use or distribute any of the information you supply in any way it believes
appropriate without incurring any obligation whatever. You may, of course, continue to use
the information you supply.
n
c
~
l>
r
o
Z
C)
--I
I
Vi
C
Z
m
Please note: Requests for copies of publications and for assistance in utilizing your IBM system
should be directed to your IBM representative or to the IBM sales office serving your locality.
Fold
Fold
••••••••••••••••••••••••••••••••••••••••
$
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
NO POSTAGE
NECESSARY
IF MAILED
IN THE
UNITED STATES
BUSINESS REPLY MAIL
PERMIT NO. 40
FIRST CLASS
ARMONK, N.Y.
POSTAGE WILL BE PAID BY ADDRESSEE:
IBM Corporation
11 33 Westchester Aven ue
White Plains, N.Y. 10604
A ttent ion: Department 813 BP
Fold
IBM
International Business Machines Corporation
Data Processing Division
1133 Westchester Avenue, White Plains, N. V. 10604
IBM World Trade Americas/Far East Corporation
Town of Mount Pleasant, Route 9, North Tarrytown, N. V., U.S.A. 10591
IBM World Trade Europe/Middle East/Africa Corporation
360 Hamilton Avenue, White Plains, N. V., U.S.A. 10601
Fold
:
GC33-5371- 7
I==;l(
International Business Machines Corporation
Data Processing Division
1133 Westchester Avenue, White Plains, N. V. 10604
IBM World Trade Americas/Far East Corporation
Town of Mount Pleasant, Route 9, North Tarrytown, N. V., U.S.A. 10591
IBM World Trade Europe/Middle East/Africa Corporation
360 Hamilton Avenue, White Plains, N. V., U.S.A. 10601
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.3 Linearized : No XMP Toolkit : Adobe XMP Core 4.2.1-c043 52.372728, 2009/01/18-15:56:37 Create Date : 2004:02:16 18:11:34-08:00 Modify Date : 2009:09:10 13:17:01-07:00 Metadata Date : 2009:09:10 13:17:01-07:00 Producer : Adobe Acrobat 9.13 Paper Capture Plug-in Format : application/pdf Document ID : uuid:ad8221dd-d5fa-4b0b-abdf-0baed0918b8a Instance ID : uuid:a5b04607-e264-414f-a807-e36566fa925e Page Layout : SinglePage Page Mode : UseOutlines Page Count : 273EXIF Metadata provided by EXIF.tools